Facebook背后的数据团队
发表于 18:32|
来源Wired|
作者Cade Metz
摘要：一次路透数据服务崩溃的经历，让Jeff Hammerbacher意识到数据管理工具与运维工程师同等重要，随后他成为Facebook数据服务的奠基人，创建了许多搜集和处理数据的工具，Scuba、Prism、Corona等工具已经或计划开源。Wired记者Cade Metz对Facebook的数据业务的领头人进行了深度采访。
【CSDN编译】Jay Parikh是Facebook基础设施工程部的副总裁。他负责监视支撑Facebook的全部硬件和软件，一旦在几秒内没有收到监控信息，他就要设法找到原因。这项工作的挑战在于，Facebook的基础设施部署在四个数据中心，它们坐落在世界各地不同的地方，那里有数以万计的服务器，以及一口气都无法罗列出的各种软件工具。当无法获得监控信息时，将可能意味着某些大型项目面临崩溃的危险。
图：Facebook的Jay Parikh（摄：Ariel Zambelich/Wired）
这就是Parikh和他的团队开发
这类工具的原因。Scuba是新一代的软件平台，它可以帮助Facebook的工程师时刻分析数据，并描述出公司大量基础设施的使用状态。很多时候，当你需要获得大量的繁杂的信息时，总存在延迟，你可能需要几个小时来处理这些数据。但Scuba是内存数据库，它将所有数据运行在数以百计的服务器的内存中，这意味着你可以几乎实时的查询数据。
“Scuba能够动态的显示我们的基础设施的状态——服务器工作的怎么样，网络工作怎么样，不同的软件系统的协同如何，”Parikh说，“所以，当我的助理（通过Facebook）在我的图片打标签后，这一操作需要几秒钟才能看到，但是我们却可以通过Scuba提前发现。”
自9年前Mark Zuckerberg创立Facebook开始，也逐渐产生了在这个星球上最复杂的运维工程。Facebook要面对独一无二的困难——如何给十亿用户提供个性化的页面，要处理十亿组不同的消息、图片、视频和其它数据，这需要大量的科技天才。
是的，Facebook的目标是笼络包括Lars Rasmussen这样创立
的工程师，也包括其它开发各种用于测试、部署应用的流行的工具和小组件的工程师。当今，还包括像
、存储设备以及整个数据中心的硬件工程师。
来自各个部门的工程师组成了管理数据的团队，以应对快速增长的现代化在线运维模式。Scuba只是Facebook众多大数据软件平台中的一个，大数据软件平台把Facebook打造成通过在线运维提供指导信息的平台。在线运维平台通过一个进程就能艺术的管理者数百甚至数以千计的计算机。
这些工具是Raghu Murthy、Avery Ching、Josh Metzler等工程师的成果，它们不仅帮助Facebook定位数据中心中的故障，而且还可以帮助数据科学家
，在一些情况下，它们甚至可以将数据直接提供给Facebook的用户。
，然而Facebook正在努力扩张自己的互联网帝国，与Google差距并不大，Facebook意图向世界各地的用户分享更多软件。Google在去年分享了最新的成果——Google
，而Facebook也分享了代码，并希望用户们喜欢。“作为一家企业，我们的使命是让世界更加开放、更多连接，”Parihk表示，“我们在建设基础设施的同时，也完成了我们的使命。”
从一次事故开始建立数据团队
Facebook的数据团队由
创立，他和Mark Zuckerberg曾同时在哈佛就学，攻读数学，在2006年春季加入Facebook之前，他在纽约贝尔斯登商行做一名数据科学家。
Hammerbacher喜欢谈起Facebook的数据运维的起源，这要回到在贝尔斯登的一个下午，当时路透数据服务突然中断，数据无法采集，致使所有交易被迫中止，系统瘫痪了整整一个小时，调查发现故障是由一个人疯狂的运行了某个程序引起的。Hammerbacher从这次教训学到了：数据工具与数据专家同样重要。
“我意识到，相对于在路透数据服务崩溃的两小时期产生的损失，我创建的数据模型和另一家公司数学家们建立的数据模型的付出就显得微不足道，”Hammerbacher回忆道。“我感觉我们有机会创建一个完整的系统，最初先获取数据，然后再过渡到数据模式创建——并尝试从每个点对系统进行优化。”
这也是他在Facebook时所做的。他入职的身份是数据分析师——这一职位可通过信息分析对公司运营起到辅助作用——但是由于他难以抹去脑中路透数据服务崩溃的记忆，所以他走得更远一点。他创建了一支可以控制公司数据的团队。这个团队不仅可以分析数据，还可以创建可用于收集和处理这些数据的工具。
他刚加入Facebook的时候，公司仍很保守的使用甲骨文的数据仓库。但是这类软件的数据处理能力并不能跟上Facebook的步伐。Hammerbacher的加入，促进了公司使用Hadoop的进程，
在利用机器的强大收集能力把数据转化成有用信息之前，Hadoop通过海量商用服务器传输数据。它之所以如此具有吸引力，是因为商用服务器比较便宜，而且你只需增加服务器数量来满足不断增长的数据。
Yahoo使用Hadoop为其网页搜索引擎创建索引，但是Hammerbacher和Facebook则将其视为公司数据科学家的助手——把它作为分析大量信息的方式，而不是把数据塞进甲骨文数据仓库。公司借助Hive——该工具可以让分析师在Hadoop之上快速处理大量数据，作用类似于80年代以来被广泛使用的SQL——很快这一工具就成为了雅虎分析在线广告等性能的主要工具。
图：Raghu Murty与Santosh Janardhan（摄：Ariel Zambelich/Wired）
Hammerbacher在2008年秋季离开Facebook，协助创建了Cloudera。Cloudera是一家致力于将Hadoop带入商业超越网络的初创公司。
这是大势所趋。在他离开之前，Hammerbacher甚至自创
为Facebook数据团队打气。
未来的Hadoop
现在，Hadoop的明星用户在不断增加，从Twitter、eBay到LinkedIn，再到Facebook，都在把自己的平台推向极致。据Jay
Parikh透露，Facebook管理着世界上最大的Hadoop集群。其中一个集群就拥有4000台机器，存储的数据量超过100PB。
一个这样的集群已如此庞大，已经不得不分散到四个数据中心，Facebook工程师Raghu Murthy说。在四个独立的环境下，由于要处理激增的网页数据，Facebook将数据中心的资源分配给Hadoop服务器，每一次都被迫寻找新设备。“我们每次设计的容量上限都似乎永远不会被超越，”Murthy（Jeff
Hammerbacher约四年前从斯坦福博士项目中雇佣来，此后成为Facebook大数据业务的奠基人）称，“但是很快又不得不把所有的数据搬去其他地方。”
但是，自从上次转移数据后，公司就发誓不再转移，并且计划创建一个跨越多个数据中心的Hadoop集群。这个项目由Murthy领导，他在Yahoo创建Hadoop分布式计算预备系统的时候引起了Hammerbacher的注意，而且已经参与过包括Hive在内的Facebook的多个重要项目。不过这次情况不太一样。Hadoop不是要跨设备运行。通常，由于它非常依赖于服务器之间的通信，所以集群被限制在一个单独的数据中心。
采用的解决方案是
，这个平台由Murthy及其团队在Facebook架构上推出。一个典型的Hadoop集群由一个单独的“命名空间”（name
space）控制，其中包含用于每项工作的运算资源列表，但是Prism开设了多个命名空间，创建了多个在相同物理集群之上运作的“逻辑集群”。
这些命名空间被多个Facebook团队分组——每个团队获取一个自己的命名空间——但是所有团队都需要访问一个通用数据集，这个数据集可以跨多个数据中心。巧妙之处在于，团队运行一项工作的时候，就可以对此项工作所需的特殊数据进行复制，再将其转移到一个单独的数据中心里。“我们把容量计划细分到单个团队，”Murthy说。“他们更了解网页的实际需求。
据Murthy透露，该系统的服务器数量可以无限制的扩张——至少理论上如此。这意味着，公司不再需要担心数据中心容量告急的问题。但对于Santosh
Janardhan而言——他是数据团队的操作者——则意味着他需要确保这个架构运行流畅。“将Hadoop集群放到一个数据中心里面简直吓死我了，”他说。“Prism帮了大忙。”
Prism只是改进和扩展Hadoop的一个方面。由另一名前Yahoo员工Avery Ching领导的第二支工程师团队最近部署了一个名为
的新平台，这个平台可以让多项工作运行于一个单独Hadoop集群之上，且不会造成崩溃。Murthy还在帮助推广
工具，这款工具可以让你更快速地检索Hadoop数据。Hadoop被设计成一个“批量系统”，意味着你要在工作运行时进行等待，与Hammerbacher打造的
一样，Peregrine使平台检索更贴近实时情况。
图：Facebook的数据基础设施核心团队，Avery Ching、Ravi Murthy、Raghu Murthy、Jay Parikh、Sameet
Agarwal、Santosh Janardhan、Josh Metzler、Subbu Submaranian。（摄：Ariel Zambelich/Wired）
Facebook暂未与外界完全分享Prism，但是已经分享了Corona，如果依照惯例，不久后就会进一步开放该软件的分享了。这也是雇佣Avery
Ching这类工程师的原因之一。“在Facebook，我们率先面对问题，”他说。“其他人可以从中受益。他们不需要重蹈覆辙。”
数据藏在糖果岛
Hadoop是Facebook数据运营的基础——虽需假以时日，但有了Scuba等工具的帮助，公司仍是沿着新方向在发展。
Scuba由有着Josh Metzler（在
编程竞赛中经常名列前茅）在内的工程师团队创建，是致力于提高信息分析速度的内存数据数据库。运行于Facebook数据中心的微型软件客户端会手机基础架构的状态变化等信息，然后由Scuba把这些日志数据压缩到存储系统。之后就可以立即查询这些数据了。
“就好像Excel透视表”Parikh提到常用数据表时说，“除非你要处理的数据行有几百万，否则你就可以以次秒级响应时间来处理数据。”
这个项目似乎与Peregrine有重复——至少部分如此。但正如Jeff Hammerbacher指出，“Facebook的创建方式是找最快的解决办法。”“Facebook不会创建一个庞大的万能系统作为解决方案。”和很多Facebook项目一样，Scuba是公司发展的结果。工程师遇到问题解决问题，不会等到另一个项目批复才解决。
这些问题处处可见。Santosh Janardhan要处理PayPal和YouTube的数据，但他认为和Facebook的数据比起来，这些工作相形之下显得微不足道。如果你是一个技术控，这里就是你的糖果岛。（译/
责编/仲浩）
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章Facebook的增长团队负责什么，有那些产出？ - 推酷
Facebook的增长团队负责什么，有那些产出？
编者按，Andy Johns，年在 Facebook 工作，曾是脸书用户增长团队核心成员。Andy 写这个回答的时间是 2012年，目前 Facebook 的月活已经突破17亿，增长团队在其中起了很大的作用。
用户增长团队的任务是确定如何将 Facebook 的月活规模扩大到每月10亿活跃用户，这是很长一段时间内的明确目标，但不是唯一目标。增长团队本身并不单独对 Facebook 目前已有的超过9亿月活用户负责。实际上，公司里每个人都以这样或那样的方式促进用户增长，然而，增长团队负责具体化整个公司对增长的理解和优化。增长团队作为水平层存在于产品的大部分或所有部分，因此在公司内有巨大的影响。以下是增长团队负责的核心专业领域的总结：
分析/数据科学：必须有大量的数据消耗才适合建立增长团队。用户增长的大部分工作与不断测试，调整和重复有关。该过程通过消耗和分析大量的数据来实现。用户增长团队与数据科学团队紧密配合，就什么驱动增长提出疑问，从服务器日志记录收集可能回答这个问题的数据，然后分析数据，定义以改善/操作数据集合，衡量测试结果，并不断重复以上过程。
直接获得营销：增长团队里有子团队，专注于 SEO 、 PPC 和邮件营销等网络营销渠道，并为了用户和广告客户的获取和留存，严格优化这些渠道。
产品开发：增长团队也对产品的关键部分产生影响，帮助影响或推动用户增长和参与，例如大多数或所有的产品注销（因为注销页面可以视为用户获取渠道），新用户流程/体验，注册/登陆流程，现场商品化等都会经过大量的A/B测试。基本上，Facebook&（包括移动端 web/Apps + 平台 + 信用体系）上你能想到的任何事情都可能受到增长团队这样那样的影响，无论是开发新的实验产品或者帮助优化其他团队建立的产品。
文化：建立一个有增长意识的组织也很重要。如果公司内部数据驱动部分和非数据驱动团队之间没有建立解决问题或设计产品的共同框架，那么会很容易养成“科学 vs. 宗教”的战斗。这些“相反”的意识形态需要找到能一起工作的方式，这样才能爆发惊人的创造力。相反，如果他们不能互相配合就会造成公司内部的关系紧张。增长团队在公司扮演的角色，代表了数据驱动方法和对风险积极可接受的愿望，朝着大方向快速移动，以及利用数据帮助解释公司能不能在任何给定节点上及时成长。
雇佣：间接的用户增长团队对招聘至关重要，当你能证明你的产品有快速爆发的潜力时，邀请顶尖人才离开其他公司会变得更容易。不是每个人都会接受离开一个好工作加入创业公司的风险，更多人愿意离开稳定工作加入一个拥有5000万以上用户规模的团队。（更不用说拥有5亿及以上用户规模）
商业和移动化：广告客户获取和留存以及移动用户增长也受到用户增长团队的影响。在推动用户增长和商业化之间有许多相似之处。用户增长主要是一种心态和方法论，你可以把这种心态和方法论应用到其他相关问题。
到目前为止，用户增长团队已经在 Facebook 官网，移动网页，App 和这些产品的各种组件上运行了数百个测试（可能多达数千次测试）。要理解增长团队的影响，从财务/投资角度考虑也是很重要的。
增长关乎你的产品（原始主要价值）及优化它所产生的复利。
现在如果你设计了一个新的退出登录页面，并从这个页面提升了5%的注册率，那么你就在原始的线性轨迹上添加了一点复合收益。
增长中很大一部分都是致力于寻找可以随着时间拉动复利增加的杠杆。当谈到增长，很少有（如果有的话）捷径，但你可以做很多微小的优化。认识到今天所做的10个5%的优化的价值在3年后比今天你认为的价值要大得多，这一点很重要。
但请记住，从5$增长到1000000$是很难很难实现的，所以如果你的原始价值很小，你需要专注于提升原始价值。简而言之，持续地增长一个糟糕的产品是很艰难的（比如 Myspace）。
我在 Facebook 用户增长团队的工作结束于2010年7月，那时候它刚刚超过5亿激活用户。要我说目前有多少活跃用户是由于增长优化的作用，我会说这个数字有几亿。
本文由 Zoran @
（微信：appadhoc） 编译自：
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致