Facebook谈Hadoop，Hive，HBase和A/B测试（转载）

转自：http://www.infoq.com/cn/news/2010/07/facebook-hadoop-summit

Hadoop峰会2010上，一系列Hadoop及其相关技术的大规模用户带来了演讲报告。值得注意的是，Facebook的主题演讲展示了他们使用Hive来作分析的详细信息。Mike Schroepfer,Facebook的工程副总裁，作了描述使用Hadoop所处理的Facebook的数据规模的报告。

Schroepfer给出了Facebook如何使用Hadoop来计算大规模分析例子。当Facebook计划推出他们的“Like”按钮时，他们担心会不会发生“自相蚕食”的结果——会不会因此反而减少了文字评论，而不是提升了参与度？为了验证这一点，他们运行了A/B测试来比较用户行为，给一组用户使用新功能(Like按钮)，而另一个对照组则没有。这需要在一个互接连的社区内进行测试，“内生的组织”——在组织之外的连接很少。他们使用了两组南美国家来进行比较，哥伦比业，委内瑞拉 vs 阿根廷，智利。测试的结果是使用Like按钮的时候评论增加了4.46%，而对照组的数据则是0.63%。这一类测试所产生的巨大的数据集正是Facebook使用Hadoop来处理数据的例子。Schroepfer接着给出了另一个例子来说明为什么数据驱动的A/B测试这么重要：Facebook还用同样的方法测试过电子邮件提醒的两种不同的设计。 尽管大多数的人都期望更为图形化更丰富的电子邮件会产出更好的响应率，但与简单的基于文本的电子邮件对比测试时，后者却有着三倍于前者的响应率——这表明了使用数据测试观点而不是依赖直觉所带来的巨大威力。

Schroepfer指出，Facebook有4亿用户，超过一半的用户每天登录，而Neilsen调查指出花在Facebook上的时间，比接近它的6个站点所花的时间的总和还多。Facebook用户每个月分享250亿的内容信息，以及5000亿的单月页面浏览量。要处理这样的数据卷，Facebook使用了大型的Hadoop集群，存储36PB未压缩的数据，有超过2250台机器和23000个核心，每个机器32GB内存，每天处理80-90TB数据(推测是新数据)。该集群每个月有300-400的用户，他们每天提交 25000个任务。

Facebook从两个主要的数据源输入数据到Hadoop集群。他们使用开源的雅虎！来自Hadoop峰会的最新更新获取更多内容)。

为了支持向Hadoop集群载入日志的高可靠性，他们使用Scribe与一个中间聚合器，以及基于树型的分布将数据导出到本地托管的HDFS和Hadoop集群里。在这个层次，运行第二个HDFS实例(使用单独的名字节点)，作为热备份——如果主HDFS宕机，系统将向备份的HDFS写入。当拉出数据载入到生产环境中时，只需要从这两个文件系统拉出数据，压缩，然后传送到生产集群中。

Schroepfer指出，95%的Facebook任务由Hive写成，他们可以快速的写就，通常十分钟就可以。实际上Facebook创建了一个基于Web的工具，HiPal，来让业务分析师使用Hive，只需要简单的撰写查询语句，支持查询载入仓库的近20000个表(HiPal并未公开)。他们一步一步从每天的批处理过渡到实时的查询——他预见将会出现最快查询在一分钟内就可以返回的系统，这必将为一系列新兴的应用开启大门。

接下来，来自Facebook的John Sichi及何永强展示了Hive与HBase和RCFile的集成。HBase是类似BigTable的键值存储模型，将数据存储于Hadoop的DFS文件系统。Facebook正在尝试将HBase用于数据仓库里的持续更新的维数据。Facebook测试了将Hive集成到20个节点的HBase集群——从Hive向HBase载入6TB gzip压缩的数据块用了30个小时，在这种配置下可以达到30GB/每小时的增加载入速率。在HBase运行表扫描比执行原生的Hive查询要慢五倍以上。他们尝试对这一集成进行优化，以利用最新的HBase性能优化所带来的好处。RCFile是Hive中一种新的存储格式，将数据按列式(columnar)存储。他们采用这种格式，平均减少了20%的存储需求，同时可以达到更好的性能(按需延迟对列数据的解压)。

Facebook对Hadoop技术将持续投入，并对他们所使用开源项目作出了贡献，比如Hive(由他们所发起的)以及HBase。他们的计算集群正在处理超大规模的数据并有着支持高可用性的架构，低延迟的应用，和与Hadoop相集成的数据库。更多来自Facebook的案例请查阅infoq.com/facebook。