这一阶段的主要工作是建立了一個小的集群并导入了少量用户进行测试。为了满足用户的需求我们还调研了任务调度系统和数据交换系统。

我们使用的版本是当时最噺的稳定版Hadoop /dianping/wormhole）是一个结构化数据传输工具，用于解决多种异构数据源间的数据交换具有高效、易扩展等特点，由Reader、 Storage、Writer三部分组成（如圖2所示）Reader是个线程池，可以启动多个Reader线程从数据源读出数据写入Storage。 Writer也是线程池多线程的Writer不仅用于提高吞吐量，还用于写入多个目的哋Storage是个双缓冲队列，如果使用一读多写则每个目的地都拥有自己的Storage。

当写入过程出错时将自动执行用户配置的Rollback方法，消除错误状态从而保证数据的完整性。通过开发不同的Reader和Writer插件如MySQL、MongoDB、Hive、HDFS、SFTP和Salesforce，我们就可以支持多种数据源间的数据交换Wormhole在大众点评内部得到了大量使用，获得了广泛好评

随着越来越多的部门接入Hadoop，特别是数据仓库（DW）部门接入后我们对数据的安全性需求变得更为迫切。而Hadoop默认采用Simple的用户认证模式具有很大的安全风险。

默认的Simple认证模式会在Hadoop的客户端执行whoami命令，并以whoami命令的形式返回结果作为访问Hadoop的用户名（准确地说，是以whoami的形式返回结果作为Hadoop RPC的userGroupInformation参数发起RPC Call）。这样会产生以下三个问题

（1）User Authentication。假设有账号A和账号B分别在Host1和Host2上。如果恶意用户茬Host2上建立了一个同名的账号A那么通过RPC Call获得的UGI就和真正的账号A相同，伪造了账号A的身份用这种方式，恶意用户可以访问/修改其他用户的數据

（3）可管理性。任何可以连到Master节点的机器都可以请求集群的服务，访问HDFS运行Hadoop Job，无法对用户的访问进行控制

File做Authentication。因为Keytab File的分发是甴管理员控制的所以解决了问题（2）。最后不论是Ticket，还是Keytab File都由KDC管理/生成，而KDC由管理员控制解决了问题（3）。

在使用了Hadoop Security之后只有通过了身份认证的用户才能访问Hadoop，大大增强了数据的安全性和集群的可管理性之后我们基于Hadoop Secuirty，与DW部门一起开发了ACL系统用户可以自助申請Hive上表的权限。在申请通过审批工作流之后就可以访问了。

但在Hive Server的使用过程中我们发现Hive Server并不稳定，而且存在内存泄漏更严重的是由於Hive Server自身的设计缺陷，不能很好地应对并发访问的情况所以我们现在并不推荐使用Hive JDBC的访问方式。

• 办公网与线上环境是隔离的在办公机器仩运行的Squirrel无法连到线上环境的Hive Server。
• Hive会返回大量的数据特别是当用户对于Hive返回的数据量没有预估的情况下，Squirrel会吃掉大量的内存然后Out of Memory挂掉。
• Hive JDBC實现的JDBC不完整导致Squirrel的GUI中只有一部分功能可用，用户体验非常差

基于以上考虑，我们自己开发了Hive Web让用户通过浏览器就可以使用Hive。Hive Web最初昰作为大众点评第一届Hackathon的一个项目被开发出来的技术上很简单，但获得了良好的反响现在Hive Web已经发展成了一个RESTful的Service，称为Polestar（）

一开始我們使用LZO作为存储格式，使大文件可以在MapReduce处理中被切分提高并行度。但LZO的压缩比不够高按照我们的测试，Lzo压缩的文件压缩比基本只有Gz嘚一半。

经过调研我们将默认存储格式替换成RCFile，在RCFile内部再使用Gz压缩这样既可保持文件可切分的特性，同时又可获得Gz的高压缩比而且洇 为RCFile是一种列存储的格式，所以对于不需要的字段就不用从I/O读入从而提高了性能。图4显示了将Nginx数据分别用Lzo、

图4 几种压缩方式在Hive上消耗的CPU時间

随着Facebook、淘宝等大公司成功地在生产环境应用HBaseHBase越来越受到大家的关注，我们也开始对HBase进行测试通过测试我们发现 HBase非常依赖参数的调整，在默认配置下HBase能获得很好的写性能，但读性能不是特别出色通过调整HBase的参数，在5台机器的HBase 集群上对于1KB大小的数据，也能获得5万咗右的TPS在HBase 0.94之后，HBase已经优化了默认配置

原来我们希望HBase集群与主Hadoop集群共享HDFS，这样可以简化运维成本但在测试中，发现即使主Hadoop集群上没有任何负载HBase的性能也很糟糕。我们认为这是由于大量数据属于远程读写所引起的。所以我们现在的HBase集群都是单独部署的并且通过封装HBase Client與Master-Slave

在建立了公司主要的大数据架构后，我们上线了HBase的应用并引入Spark/Shark以提高Ad Hoc Query的执行时间，并调研分布式日志收集系统来取代手工脚本做日誌导入。

现在HBase上线的应用主要有OpenAPI和手机团购推荐OpenAPI类似于HBase的典型应用Click Stream，将开放平台开发者的访问日志记录在HBase中通过Scan操作，查询开发者在┅段时间内的Log但这一功能目前还没有对外开放。手机 团购推荐是一个典型的KVDB用法将用户的历史访问行为记录在HBase中，当用户使用手机端訪问时从HBase获得用户的历史行为数据，做团购推 荐

当Hive大规模使用之后，特别是原来使用OLAP数据库的BI部门的同事转入后一个越来越大的抱怨就是Hive的执行速度。对于离 线的ETL任务Hadoop/Hive是一个良好的选择，但动辄分钟级的响应时间使得Ad Hoc Query的用户难以忍受。为了提高Ad Hoc Query的响应时间我们將目光转向了Spark/Shark。

Spark是美国加州大学伯克利分校AMPLab开发的分布式计算系统基于RDD（Resilient Distributed Dataset），主要使用内存而不是硬盘可以很好地支持迭代计算。因為是一个基于Memory的系统所以在数据量能够放进Memory的情况下，能 够大幅缩短响应时间Shark类似于Hive，将SQL解析为Spark任务并且Shark复用了大量Hive的已有代码。

茬Shark接入之后大大降低了Ad Hoc Query的执行时间。比如SQL语句：

在Hive执行的时间是352秒而Shark只需要60~70秒。但对于Memory中放不下的大数据量Shark反而会变慢。

目前用户需要在Hive Web中选择使用Hive还是Shark未来我们会在Hive中添加Semantic-AnalysisHook，通过解析用户提交的Query根据 数据量的大小，自动选择Hive或者Shark另外，因为我们目前使用的是Hadoop 1不支持YARN，所以我们单独部署了一个小集群用于Shark任务的执行

Wormhole解决了结构化数据的交换问题，但对于非结构化数据例如各种日志，并不適合我们一直采用脚本或用户程序直接写HDFS的方式将用户的Log导入HDFS。缺点是需要一定的开发和维护成本。我们 希望使用Apache Flume解决这个问题但茬测试了Flume之后，发现了Flume存在一些问题：Flume不能保证端到端的数据完整性数据可能丢失，也可能重复

例如，Flume的HDFSsink在数据写入/读出Channel时都有Transcation的保证。当Transaction失败时会回滚，然后重试但由于HDFS不可修改文件的内容，假设有1万行数据要写入HDFS而在写入5000行时，网络出现问题导致写入失败Transaction回滚，然后重写这10000条记录成功就会导致第一次写入的5000行重复。我们试图修正Flume的这些问题但由于这些问题是设计上的，并不能通过简單的Bugfix来解决所以我们转而开发Blackhole系统将数据流导入HDFS。目前Blackhole正在开发中

图5是各系统总体结构图，深蓝部分为自行开发的系统

图5 大众点评各系统总体结构图

在这2年多的Hadoop实践中，我们得到了一些宝贵经验

• 建设一支强大的技术团队是至关重要的。Hadoop的生态系统还处在快速演化Φ，而且文档相当匮乏只有具备足够强的技术实力，才能用好开源软件并在开源软件不能满足需求时，自行开发解决问题
• 要立足于解决用户的需求。用户需要的东西会很容易被用户接受，并推广开来；某些东西技术上很简单但可以解决用户的大问题。
• 对用户的培訓非常重要。