本文讲的是Facebook的海量数据架构演变过程,作为世界上最大的社交网络，Facebook公司一天积聚的数据比很多大公司一年产生的数据还要多。 据2010年3月的博客显示，Facebook公司的Hadoop集群成为世界上最大的计算机集群。这个集群由2000台计算机，800台16核系统和1200台8核系统组成。集群中每个系统存储了大概12万亿到24万亿字节的数据。

▲全球系统架构师大会现场报道

　　一年前，Facebook的集群存储了30千万亿字节的数据，大概是美国国会图书馆存储信息数量的3000倍。Facebook数据中心在过去一年里增长了三分之一还多。 今年4月份，Facebook耗资4.5亿美金建设的新数据中心也已经投入使用。

　　从2007年到2011年，Facebook的大数据处理架构是如何演变的?在一个变动异常频繁，并且快速增长的环境里，都要面临哪些挑战?Facebook使用了一些组件和技术，让公司大部分部门都可以根据不同的目的访问、分析、使用数据，背后的驱动力是什么?前Facebook数据基础设施团队主管、Apache Hive项目联合创始人，Qubole创始人兼CEO Ashish Thusoo在本演讲中给我们一一解答了这些问题，同时介绍了从Facebook的经验中的一些重要收获。

▲前Facebook数据基础设施团队主管Qubole创始人兼CEO Ashish Thusoo

　　以下是精彩演讲实录：

　　今天跟大家谈一下在Facebook大数据的基础架构演变，讲得都是我在Facebook的经验和项目。从中也许有一些经验跟大家分享。

　　我目前是Qubole公司的联合创办人和CEO，在Facebook以前是管理基础设施团队的，简单介绍一下，我在这段时间学习到的一些经验。07到2011年在Facebook公司的经验，同时在Apache Hive07年到08年项目我也是创办人。

　　首先谈一下在Facebook大数据的范围与规模。我们的规模有多庞大?做了哪些事情和应用?同时，把这些工具和应用用在哪一类上面。

　　第二，Facebook架构的演变，07到11年的演变过程。

　　最后，简单介绍一下在Qubole的工作。

　　Facebook大数据的规模

　　现在看到的是2011年的数据，当时有25PB的压缩数据在集群当中，如果解压是150PB这么多，是非常庞大规模的数据量，从新数据的增量来说，每天有400TB的数据，150PB的数据，人类历史所有数据的三倍，人类历史上所有数据加起来我们大三倍。400TB是每天的增量，不知道能够换算成多少，可以想象一下，这么多集群这么多的量，可以从中理解一下面临这个问题多么大的规模。在Facebook处理的数据海量是一个什么样的概念。

　　除此以外，在使用海量数据，用数据进行大量的分析工作，平均每秒钟有一个新增的研究项目启动。同时，对于海量数据还有非常快速的研究，所以我们有许多的应用，也有简单的数据，比如说简单的报告应用，一些统计功能，比如说页面的浏览量有多少，用户都有哪些数据。用一些比较先进的方法，比如说模型的建立，我们应该在市场营销的时候针对哪些用户?或者我们怎样让某种用户增加兴趣，怎么吸引某一类的用户?我们可以做这种临时的分析和数据科学。也就是说，从数据当中寻找一些规律，比如说通过这种规律来看一下我们该怎样去接触我们的用户，怎样让用户提高对我们的内容的兴趣，在数据集群上，也会做这样分析的工作。另外，还有一些应用，比如说一些用户的推荐，你可能认识某些人，可以推荐它来推荐应用。

　　有许多有用的用地被用于海量数据上。包括扫描这么多的数据进行分析、进行数据的工程、数据的科学，这是现在大数据的范围。

　　举一个具体的例子，现在Facebook也在做这种A/B测试，这个例子向我们表明了数据可以带来多么大的威力。很多时候我们做决定之前会根据这个分析来做决定。

　　还有一些时候发现数据可以告诉我们一些东西，比如说在具体的案例里面，有一个A/B测试，发了一个电子邮件给用户参与网络，这个邮件里面有非常多的内容，有图片以及这个领域的相关信息。

　　第二封邮件里面是简单的一句话，希望用户采取行动。看上去第一个邮件给别人更多的信息，告诉他们我们这个项目价值在哪里，能够感兴趣。希望能够参加这个项目。但是，我们却发现这些用户他们在使用邮件之后，发现第二个电子邮件吸引用户参与效率方面是第一封邮件的三倍。这是一个具体的用户的案例，用在用户身上影响到用户使用的参与程度。不仅仅讲得传统工作，还有其他的应用。

　　另外一个例子，有一张图片来自于集群里面的数据，现在看到的这个图不是做的影射，而是通过不同连接产生的。这个图上看到这个人Facebook上面朋友之间的联系强度怎样，可以把这些联系放在一起，看上去像世界地图一样。从现在架构能够实现这样的连接，原来使用过去的架构完全做不到这一点的。可以上博客上看这方面的信息，把Facebook的人脉进行出来。

　　这样的案例里面基础架构怎么发挥作用

　　这个架构2007年到2011年之间是怎样不断演进的。下面先请大家看这副图，从测量的角度来看演进，一开始为什么要做，为什么要推动变革?是因为我们接触的数据越来越多，回到2007年，我们分析用的数据也不过15个TB左右，2015年增长了2.5万个TB，这种数据非常惊人，看有没有什么机制可以解决数据的膨胀爆炸，满足这种成长给我们带来的压力。

　　接下来回到2007年看看当时的情况怎样。当时我们的架构从收集到数据分析转变的初级阶段，要收集数据有两个主要的来源：

　　Facebook通过wap的集群，网络的日志，人们所采取的行动。比如说发了一个信息给你或者加了一个人做好友，具体来自于网络的集群信息。另外一个来自于MySQL的集群，不仅是关于用户的信息，还关于广告信息，以及广告针对的用户年龄阶段怎样、推出广告时机怎样，这些人是哪些类型的人?广告哪些内容具体怎么描述，怎么来分析受众。这是两类数据的来源。很多时候是两种信息的来源放在一起，比如说在应用上面要把这里的数据以及在应用里面具体的数据结合在一起才行，给我们很多的洞察，了解情况。

　　有了这两个来源的数据，所有的数据必须要到后端的数据库，2007年主要用的甲骨文单节点的数据服务器，确实是有自己的一些限制，稍候会给大家讲一讲限制在哪里。

　　该怎样收集数据呢?如果要收集数据的话，使用的是一种开源项目，Facebook开源项目的日志系统，收集不同来自于网络集群的日志。比如说，用的是阿帕奇架构也会形成一些应用的日志，或者其他的架构会生成一些日志，这些日志通过Scribe收集起来，我们使用它来存储日志。日志被存储了，数据被收进来了，放在NAS的存储器里面。NAS是所做一切的基础，从网络集群到中间的日志收集系统，一直到NAS，要在NAS文件存储器里面对所有的信息做一览式的回顾，接着做汇总。在自主、自己的机器上自己研发出来的装载在服务器的基础上进行汇总和归集，最后存储在数据仓库里面，这就是我们的基础架构。NAS主要是把还没有用的或者重复的信息把它丢弃掉。我们会有一些Summarization帮助总结。很小一部分在线上的，很大一部分是线下的，线上的存储器里面没有太多的数据。

　　问题在哪呢?

　　左边转到右边我们的用户群无法有效的应对这么大的关于用户的数据。因此，我们每天对于数据抽取、转换以及装载超过24小时了，时间很少但是做得事情好像又不是那么多。不断对工作进行调试，不断建索引，必须垂直的方式来确保处理这么多数据。

　　用RTBM(音)的时候有其他的限制，模式转换、数据转换有很多工作，非常耗时。能不能让我们更有效的读取数据?毋庸置疑，这些情况限制了我们的发展，也找到了问题，通过了汇总集群来从一定程度上解决了问题。对我们来讲，所发挥的作用非常有限，这是早期的影射和化解，说实话还远远谈不上影射和化解发挥的作用。

　　我们具体的数据不可能放在线上，这些数据放在线下，汇总资料在线上。

　　第二限制，我们用了很多的使用案例都是商业的指标，比如数据科学，具体绩效、表现性能。不可能用数据科学或者建模的方式进行评判。RDS在规模和性能方面都给我们带来很多的限制。

　　考虑到07年的限制，08年开始Hadoop，用这个系统，Hadoop发展两年半了，一开始是雅虎一个孵化器企业，提升拓展可用性。2008年的时候，在数据超市前面加上数据仓库。原来用的汇总集群去掉变正Hadoop的数据库，把我们的数据全部放到线上。当然，我们还是做了一些汇总的工作，有汇总的脚本，RDMS的作为也从数据仓库变成书记集市。转变从一开始讲确实带来很多的帮助，有效提升了更多的使用案例，比如说可以大规模使用数据科学，可以在实验室里面来使用影射以及化简的方式分析数据，仍然是不但想象的。而且有史以来，第一次在线上放出经过收集以及编写的数据。

　　原来只是这么多数据，汇总一下，把最重要的挑出来放在线下，现在把所有的东西都放在线下，甚至可以放更多的东西，是开源的数据系统，可以放更好的信息。就像打开闸门一样，更多的数据、更多的使用案例涌进来，是发展过程中重要的战略。

　　说08年的时候有聚合的想法，从集群到文件处理器到数据仓库最后到数据集市。在09年对数据进行民主化的构思，但是我们要面对一个现实，本身系统不是很多人能用，也做了Hive，但是还是有一定的局限性，很多人不理解怎么使用。调整了是进行。后来怎么民主化我们的数据，发挥我们平台的作用，所有人享受到我们的威力，不同的工具帮助不同的人利用到数据。所以我们围绕这个平台创建了很多的项目和工具来帮助别人使用。大概分为四类项目，一方面让数据的收集测量更加的容易。另一方面，通过工具和项目使得他们从(英文)收集数据比较简单。经营数据之前还要管理数据流、数据传送、数据改善，进行数据管道的框架。同时，考虑到一些不同商业的场景，像Hadoop的项目就是特别发现的工具。

　　比如说Nectar的项目做了一个系统，让数据测量变得更加简单。当时面临比较大的问题，怎么样让架构随着数据的膨胀更加容易的使用。因为数据不断增加，应用不断改变，要收集不同的数据、收集不同的属性和特性，这个过程中，怎样使数据有足够的弹性和灵活性，所以必须要应对庞大的数据变化。

　　Nectar是专门针对这种格式的数据。所有的数据存储起来，能够很简单很方便的收集，同时要确保存储的数据可以进行高度的编码。Nectar的ETI应用在某一段时间之内，从前端到后端产生数据表，不需要考虑怎么设置数据搜寻的机制，这个管道会自动产生数据表。用很简单的日志方法就可以进行评估了，最后观察报告就知道结果了。

　　另外有很多的工具，我们做了HiPal工具，帮我们进行数据发现的。在数据发现做了工作，所有用户当中，我们要找出谁在用哪个表?谁在用哪个数据?把新的用户新的使用挂钩，另外有一些图表制作和仪表板制作的工具。Databee和Chronos工具可以进行配置，给工作流的框架，可以进行工作流的编排。所有的项目必须要考虑一点，如果人们用这数据可以分析数据、去除数据就要小心，因为这个人用工具这么容易就可以删掉数据、清除数据有可能会造成破坏。不小心做了研究项目，就可能把客户所有的记忆和时间摸掉了。我怎样分析不同的集群?确保资源共同的使用?哪些工具?哪些研究优先?公平性也要考虑。所以我们做数据的民主化，确保回应这些问题。怎样能够保护数据库不受潜在危险研究项目的影响。

　　我们要控制不出现一些混乱，我们实施了一些功能，做一些错误的隔离，出现错误，得到隔离后不会影响系统。同时有些系统减少运营的负荷。如果打开了这个研究海量数据的大门，可能就会不断的增加研究压力，对此要做出一些限制，而降低整个系统运作的负担。怎么样做或者用哪些项目来不断优化系统，同一时间帮助它做好工作。同时，还要做很多的资源利用调配，进行各种衡量、测量、责任制和问责制的考量。所以我们讲的这些问题，以及通过一些方法解决这些问题。其中一些是比较创新的，有些做法是比较传统的。

　　2010年之后，作为单一集群进行存储了，所有的数据都是在同一个集群当中存储。如果在这个集群当中做了非常有潜在危险的操作，会对数据仓库造成威胁。所以2010年进行隔离操作。分裂了两个数据仓库，一个是白金仓库，一个是白银仓库。所有生产的是白金仓库，另外再单列一个白银仓库。白银仓库实际上就是一些非生产性的操作，可以在白银上操作，但白金不能碰。这对于研究项目的安全级别要进行分析的，我们一些应用层进行隔离和过滤。所有这些来自于NAS的文件储存器，首先会把NAS网络存储器的数据放在白金的仓库当中，再复制到白银仓储。这是在隔离方面所做的。

　　如何衡量对数据的使用情况

　　在不同的研究项目用了多少的资源，比如说会不会用了太多的资源。所以我们监控对数据使用情况加以测量和衡量。比如说对于影射器和化简器的测量。第二件事情就是进一步优化，提高效率。

　　这张图有NAS的储存器，本身没有什么样的扩展性，过了某个程度可能就有空间的问题。而且每一次增加新的NAS存储系统，有可能会增加新的一些更多的一些运作的负担。所以2011年也希望能够把我们文件处理器进行一个HDFS的转移，我们用HDFS的系统。影响到了操作的有效性，因为我们不断的增加新的节点到集群当中。

　　要进行数据的扩展，很多信息储在这个处理器上，所以要进行投资，在HDFS的试点项目，用了一些使用界面。从效率上来说，提高了我们的效率。2010年的工作也是提高工作率和效率。现在资源利用率、CPU利用率都要考虑。考虑这个数据系统到底能承担多大啊的容量。我们有HDFS，还有RCFile，是一个竖式格式化的工具，把横式纵向排列进行压缩。用这种方法使到我们磁盘使用率得到效率的提升。

　　在CPU资源利用率方面开始连续式的复制或装载器，每天要进行处理，用大量CPU的处理能力。如果你是连续进行复制和装载，可以腾出很多运算能力。

　　同时，我们创建更快的Hive的优化，可以节省CPU的运算能力。很多的重点放在节省CPU运算能力上。

　　首先我们必须考虑，CPU非常关键的，很多的工作都排着队，接受CPU的处理。如果这里有问题，将是灾难性的后果。我们花了很多的时间，同时要去衡量对这个数据的工作，去测量研究对数据的使用。谁使用了哪些数据，或者哪些数据集很少被人使用，这些都需要测量。所以我们要监控对数据使用的情况。我们用简单的统计，比如说每个研究项目的统计数据到按不同的责任组或者工作组的统计和汇总。

　　以上是2010年的工作，这时系统已经非常稳定强大了。

　　同时收到一些新的要求，进一步提升。Facebook希望能够更加实时的获得研究的结合，希望对数据达到实时的要求，获得实时的结果。我们做了一些投资，今天可能用不到，但是所有的优化和实施要求是面向未来，对未来进行铺垫。

　　2011有两个系统：Puma 和Peregrine

　　Peregrine开展简单快速的数据查询，结果不一定非常精确，大约的结果就可以了。这个搜索和查询的时候，不是要制造非常准确、精准的，而是大概了解一个趋势就可以。

　　接下来看一下Puma，在Puma项目中，我们首先把所有的数据全部放在HDFS里面，做一个实时的数据分析。我们里面做得非常简单，比如说广告点击率多少、有多少人浏览你的广告。还有选用模糊的单一用户测量。

　　我讲了我们发展的演进过程，也面对了一些其他的挑战。在这四年里，我们的数据中心大概搬了四到五次了，每次用的数据中心都用不下去换一个，希望找到合适的方法、合适的流程以及合适的策略帮助我们做到这些，以可持续、快速的方式发展。

　　现在看到的是所采取的三个主要的行动，两个是相对小的举措。09到2011年把数据又搬了一次，把800个TB的数据搬到新的数据中心里面。2010年大概8个PB的数据搬到另外一个数据中心。到2011年把15个TB搬到数据中心。

　　另外一个比较大的困难，应对一些问题的时候也在不断的发展，原来要处理简单的数据，现在发现面对的系统越来越复杂，有更为复杂的应用程序的机制和模式。怎样把不同的数据中心结合在一起，又会有新的数据进来，把旧的数据好好的复制。2011年用两个月的时间从一个数据中心转移另外一个数据中心上。

　　最后，简单总结一下。我们做了非常多的工作，来应对大数据的到来，稍候会跟大家讲Qubole，我们在做工作的时候，也意识到解决基础架构的问题非常困难，要运作这些软件发现运行这些软件更困难，很多内容、很多组件不断变化，一会儿来一会儿去，而且要做非常困难的决定，我们学到了几点，从所学的东西里面，希望能够建立在云端下一代的数据处理机制。而我们主要的使命是作为一个数据工程师。会帮助大家运行我们的基础架构，你们可以分析建立自己的数据中心。

作者： 景保玉　

来源： IT168

原文标题：Facebook的海量数据架构演变过程