信息平台和数据科学家的兴起

　　Facebook有了“自知之明”

　　在2005年9月，Facebook首次向非大学生公开，允许高中生注册账号。忠实的用户愤怒了，但Facebook团队认为这是为网站做出的正常方向。那么它该如何证明它的方案是正确的呢？

　　此外，在几乎所有可登录Facebook网站的学校中，Facebook已经渗入学生当中，但还是在有部分学校中，该网站一直不受青睐。和那些更成功的网络相比，这些落后的网络对于Facebook有什么区别呢？Facebook团队应该如何做才能激励他们的成功？

　　当我在2006年2月参加Facebook面试时，他们正积极地期望找到这些问题的答案。我曾在大学学习数学，在华尔街工作近一年，工作内容是构建模型来预测利率、价格复杂的衍生产品和对冲抵押贷款池；有一定编程经验，GPA成绩“暗淡”。虽然我的背景可能不太理想，但是Facebook却给了我研究科学家的职位。

　　几乎同时，Facebook聘用了一位报告分析主管。该主管在解决问题方面的经验远远超过我。我们和另外一位工程师一起，开始着手构建一个数据收集和存储平台，以便找到我们产品以上问题的答案。

　　我们第一个尝试是构建一个离线信息库，其涉及两个方面：一是用Python脚本把查询分发到Facebook的MySQL服务器层，二是采用C++实现守护进程，实时地处理事件日志。当脚本可以如期运行，我们每天收集大约10GB的数据。我后来明白系统的这部分通常称为“ETL”过程，即抽取、转换和加载。

　　Python脚本和C++守护进程从Facebook的数据源系统中抽取数据，然后这些数据又被加载到MySQL数据库用于离线查询。我们在包含这些数据的MySQL上又运行了一些脚本和查询，对数据进行聚集，以便得到更有用的表现方式。这种用于决策支持的离线数据库即“数据仓库”。

　　最后，通过简单的PHP脚本把数据从离线的MySQL数据库抽取出来，向内部用户展示收集到的信息摘要（Summary）。这是我们第一次可以回答网站特性对用户行为的影响。早期通过以下几种渠道分析最大化增长：登出用户的默认页面的布局、邀请来源、Email联系方式导入器的设计。除了以上分析，我们开始通过历史数据开发简单的产品，包括对赞助商成员特性进行聚集的内部项目。实践证明，该项目很受品牌广告商欢迎。

　　我那时没有意识到，实际上，通过ETL框架、数据仓库和内部控制台，我们已经构建了一个简单的“商业智能”系统。

　　“猎豹”和“大象”(译注1)

　　从第一天开始对Facebook的点击流写日志起，到现在我们已经收集了超过400GB的数据。对该数据集的加载、索引和聚集操作对Oracle数据库的负载很重。虽然做了很多优化操作，但是我们还是无法在24小时内完成对一天的点击流的聚集操作。很显然，我们需要把日志文件聚集到数据库外，只在数据库中保存摘要信息供后期查询。

　　幸运的是，一个来自某大型网站的顶尖工程师加入了我们团队，他有过处理大规模Web点击流的经验。仅仅几周的时间，该工程师就构建了一个名为Cheetah（猎豹）的并发日志处理系统，该系统能够在两个小时内处理一天的点击流。这实在太让人振奋了。

　　但是，Cheetah存在一些不足：首先，在处理完点击流数据后，原始数据还是以归档方式保存，不能够被再次查询。此外，Cheetah是从一个共享的NetApp归档数据中获取点击流数据，而NetApp归档数据的读带宽受限。每个日志文件的“模式”是嵌入在处理脚本中，而不是保存为可查询格式。我们没有收集进程信息，而是通过Unix基础工具cron来调Cheetah任务，因此无法应用复杂的加载共享逻辑。最重要的是，Cheetah不是开源的。我们团队很小，资源有限，无法分配更多的资源来开发、维护和给新用户培训使用Cheetah系统。

　　Apache的Hadoop项目，由Doug Cutting和Mike Cafarella于2005年末启动，是我们取代Cheetah的最佳选择。以Doug的孩子的玩具大象命名，Hadoop项目的目标是实现遵从Apache2.0许可的G公司的分布式文件系统和MapReduce技术。雅虎在2006年1月聘用了Doug Cutting，并投入了大量的工程资源来开发Hadoop。在2006年4月，该软件使用188台服务器，能够在47小时内，对1.9TB的数据进行排序。虽然Hadoop的设计在很多方面优于Cheetah，但它在那时还太慢了，不能够满足我们的需求。在2008年4月，Hadoop用910台服务器，可以在209秒内对1TB的数据进行排序。由于Hadoop性能的改进，我说服了运行组团队利用60台Web服务器和3台500GB的SATA驱动器，开始在Facebook第一次部署Hadoop集群。

　　在最开始， 我们通过流方式在Hadoop和Cheetah中都导入一部分日志。Hadoop增强的编程能力加上其能够查询历史数据，从而推动了一些其他有趣的项目。其中一个应用是对所有Facebook用户交互的有向对进行打分来确定这些用户的亲密程度；这个分数可以被用于搜索和新闻订阅的排序。过了一段时间，我们把所有的Cheetah工作流都迁移到Hadoop上，废弃了前者。后来，事务数据库收集程序也都迁移到了Hadoop。

　　有了Hadoop，Facebook的基础设施可以支持对无结构化和结构化的数据的大规模分析。随着平台扩展为每天几百TB的数据规模，可以执行成千上万个任务，我们发现由于现在系统能够存储和检索的数据规模很大，我们可以构建新的应用，探索新问题的答案。

　　当Facebook向所有的用户开放注册，用户数在一些国家增长迅猛。但是在那时，我们无法根据国家执行点击流粒度分析。自从有了Hadoop集群，我们可以通过加载所有的历史访问日志到Hadoop，写一些简单的MapReduce任务来重新分析Facebook在一些国家，如加拿大和挪威增长迅猛的原因。

　　Facebook的用户每天都有几百万半公开的对话。据一次内部估算，留言板的数据量是博客的10倍！但是，这些对话的内容还是无法进行访问用来数据分析。在2007年，一个对语言学和统计学有强烈兴趣的暑期实习生Roddy Lindsay加入了数据组。通过Hadoop，Roddy能够独立构建一个强大的趋势分析系统，该系统名为Lexicon，每天晚上能够处理TB级别的留言板数据。

　　在为Facebook应用构建信誉积分系统时，我们证明了把不同系统的数据存储到相同的存储库中会导致严重的问题。在2007年5月启动了Facebook平台后不久，我们的用户就被“淹没”在添加应用的请求中。我们很快意识到需要添加一个工具来识别有用的应用和用户认为是spam的应用。通过收集API服务器的数据、用户信息以及来自网站本身的行为数据，系统能够构建一个模型对应用进行打分，这使得系统可以分发我们认为对用户最有用的应用邀请。

　　新工具和应用研究

　　在Facebook，绝大部分Hadoop集群的早期用户都是渴望追求新兴技术的工程师。为了使企业的更多人可以访问信息，我们在Hadoop上构建了一个数据仓库框架，并称为Hive。

　　Hive的查询语言类似于SQL，支持嵌入MapReduce逻辑、表分区、抽样和处理任意序列化数据的能力。最后一个特征至关重要，因为收集到Hadoop的数据在结构上不断变化；允许用户指定自己的序列化模式，可以使我们把为数据指定结构问题转为把数据加载到Hive。此外，我们还实现了一个简单的用户界面来构建Hive查询，名为Hipal。使用这些新的工具，市场、产品管理、销售和客户服务的非工程师都能够在几TB的数据上自己执行查询。经过几个月的内部使用后，在Apache2.0许可下，Hive成为Hadoop的官方子系统，现在仍然在积极地开发中。

　　除了Hive，我们构建了分享图表和图形的门户Argus（受IBM的Many Eyes 项目启发） 、工作流管理系统Databee、用Python写MapReduce脚本的框架PyHive、为终端用户提供结构化数据服务的存储系统Cassandra（现在作为开源，在Apache孵化器中）。

　　随着这些新系统的稳定，我们最终构建了由单一Hadoop集群管理的多层模式的数据。企业中的所有数据，包括应用日志、事务数据库和Web爬虫，都以原始数据格式，定期收集到Hadoop分布式文件系统中。夜间执行的几万个Databee进程将把一部分数据转化为结构化格式，把它放入由Hive管理的HDFS文件目录中。在Hive中执行下一步聚集操作，用来生成Argus服务报表。此外，在HDFS内，在自己的home目录下维护“沙盒”的工程师可以运行原型任务。

　　目前，Hadoop包含了将近2.5PB的数据，而且以每天15TB的数量级增加。每天都有3000个以上的MapReduce任务在运行，处理55TB的数据。为了适应这些运行在集群上的任务的不同优先级，我们构建了作业调度器，实现在多个队列上的资源共享。

　　除了支持内部和外部的报表、a/b测试管道和很多不同的数据密集型产品和服务，Facebook的Hadoop集群可以实现一些有趣的应用研究项目。

　　由数据科学家Itamar Rosenn 和Cameron Marlow主持的一个纵向研究项目用于预测长期的用户参与的最重要的因素是什么。我们使用信息平台来选择一些用户的样本，删除游离点，并对参与度的不同尺度使用一些最小角度回归技术来生成大量的特性。有些特性能够通过Hadoop生成，包含计算好友网络密度的各种尺度和基于信息特性的用户范围。

　　另一个探索激励新用户贡献内容的动机的内部研究，在2009年CHI 会议的论文“Feed Me: Motivating Newcomer Contribution in Social Network Sites”中有描述。Fa c ebook数据组的一个更新的研究是查看信息流是如何在Facebook的社会图中流动，该研究的标题为“Gesundheit! Modeling Contagion through Facebook News Feed”，已被2009 ICWSM会议接收。

　　在Facebook，每天收集证据、测试假设、构建应用和使用共享的信息平台生成新的洞察。而在Facebook之外，其他公司也同时构建了类似的系统。

　　数据科学家

　　在最近的访谈中，G公司首席经济学家Hal Varian强调了员工需要能够从之前描述的信息平台中抽取信息。正如Varian所言：“找到能够为一些变得普遍且廉价的东西提供稀缺、互补的服务。那么，是什么变得普遍且廉价？数据。是什么与数据相辅相成？分析。”

　　在Facebook，我们发现传统的头衔如商业分析师、统计学家、工程师和研究科学家都不能确切地定义我们团队的角色。该角色的工作是变化多样的：在任意给定的一天，团队的一个成员可以用Python实现一个多阶段的处理管道流、设计假设检验、用工具R在数据样本上执行回归测试、在Hadoop上为数据密集型产品或服务设计和实现算法，或者把我们分析的结果以清晰简洁的方式展示给企业的其他成员。为了掌握完成这多方面任务需要的技术，我们创造了“数据科学家”这种角色。