朱冠胤：百度大规模数据处理架构之“不平凡之路”

【编者按】作为国内搜索巨头，百度收录全世界超过一万亿的网页，每天响应中国网民大约几十亿次的请求。那么，在面对如此庞大的数据处理时，百度是如何构建并优化分布式计算平台，又如何完成一次次系统构架的演进呢？在 “OneAPM 技术公开课 ”中，百度的基础架构部高级技术经理朱冠胤根据自己的实践经历，对以上问题进行了详细阐述。

以下为演讲整理

百度从2009年开始做大规模计算相关的工作，主要的应用领域是大规模集群组建。在2012年，百度开始研发自家的分布式计算，主要是云计算系统和平台。目前，我们团队服务了整个百度公有云的集群，主要承担大数据分析相关的平台和服务工作。

其实，如果涉及到“大数据”，不得不提百度最大的业务——搜索。百度搜索已经收录全世界超过一万亿的网页，每天响应中国网民大约几十亿次的请求。除此之外，百度还有另外20多个用户过亿的产品线，而且各个产品底层的大规模数据处理，都需要使用我们团队维护的大数据处理平台。接下来就跟大家分享一下百度底层的分布式计算平台，以及2012年至今，我们对整个平台的优化思路。

掘金——离线引擎优化

关于MapReduce

掘金是百度分布式计算平台系统的总称，想了解掘金，首先需要了解目前主要的离线计算服务器——MapReduce。百度从2007年开始引进Hadoop 0.1，然后应用于百度5.1。2011年百度的MR单集群规模达到5000台，到2013年已经多达1.3万台，这也是截止到目前为止全世界最大的单集群。Hadoop总的集群业务大概在10万的量级，单集群最大是1.3万台，日均的作业量也达到了百万量级。除了在规模方面不断扩大，百度一直在Hadoop性能分析方面进行了大量的优化。2013年的测试结果显示，相比于开源社区，在Hadoop系统层面性能提升了30%。主要系统集成的点包括Sable，团队将其做成一个统一的Sable serves，不在占MR的位。比如对关键的热点、卡数采用SS1限量化，这是30%的性能集群背后主要依赖的一些技术问题。

2014年，继续对搜索引擎做了大幅度的优化， 先是NativeC++DAG引擎上线，然后再通过4轮MR Job实现的一个完整的业务流的过程。在我们的代理引擎上线之后，可以看到通过MR的引擎和业务优化代理引擎，避免了3次Reduce写HDFS IO，以及写在过程中额外产生的网络IO。通过把它们优化成一个DAG Job，可以明显看到性能的提升。

下图是Seker翻译的过程，基于MR引擎时，Seker会翻译成25个MR JOB，如果我们把它优化成DAG，能够避免很多次磁盘IO操作。在优化之后，运行时间直接缩减到1个小时，优化前后的差异非常显著。

内存流式Shuffle

2013年，百度在Shuffle方面进行了优化，整个团队一起利用Shuffle做出一个Demo，该Demo还在大数据技术国际大赛中夺取冠军。2015年，这个Demo真正开始大规模的上线。熟悉Hadoop的人很清楚，Hadoop默认的Intule是采用Reduce到Web端的过程，因为Reduce到达的时机不一致，所以在Web会产生大量的随机IO。除此之外，在执行Mapper时，Shuffle将MAP的结果分发给Reduce。那么整个流程是，先执行BAP，然后跑Shuffle，之后才是Reduce，这一过程中有典型的Shuffle时间。特别是在500G大量级下，实际过程中Web、Shuffle交互的时间非常长。如果所有的Web一起跑的话，所节省的时间显而易见。

所以，我们主要的优化工作，是将原来Hadoop默认的Reduce版本模式，优化成基于内存的流式Shuffle的模式。什么是内存的流式Shuffle？比如说，Web4在处理256M的数据，优化完之后进入到100条进度，直接通过内存推入到US端，这样就相当于一个流水线。关键的是，直接将Web接入US端，而 Web端是直接将数据发送到Reduce端的。

目前，团队已经实现多功能的Shuffle组件，百度内部正在试图用Spark替换Shuffle，现在 Spark是百度内部的主要执行引擎。Spark主要的业务是Sparp（Sesmer）类，第二类是通过（Pansin）接口使用Spark。目前百度在Spark上做了很多的改进，比如将Spark融入到基本的生态里，也就从系统底层融入到完整的系统架构中。

百度分布式计算平台：掘金——系统架构演进

其实，Shuffle是在可扩展性的性能上实现的优化，接下来跟大家一起分享这个阶段的业务模式下，其中遇到的一些挑战以及优化思路。当然，百度拥有很多常见的业务场景，Reduce的量级也达到十万的规模。在与社区的方案沟通之后，考虑到时间以及其他因素，逐渐形成现在的这种优化思路。

2012年两个主要的基础，即是两个主要离线计算平台，左边是以Reduce为主要典型的演进计算的引擎，右边是MPI /BSP的模型。从最下面可以看到，Hadoop跟MPI的业务在底层平台方面，在采用的硬件上较大的差异。大部分人都知道，百度采用的硬件就是Hadoop，实际上Hadoop的IS本就是一个分布式的软件系统，它支持在相对便宜的服务器上运行。但如果效果非常卡顿，就完全没必要。所以百度Hadoop在很久以前就取消了这种方式。

另外一个就提到MPI，MPI是一个消息传输的框架，这个框架由很多做高性能计算的，由它们实现一个高性能的基本框架。在提出MPI时，底层的可靠性非常高，而且采用的也是非常高配置的服务器。当时百度的底层是HDFS硬盘，我们将大规模的机器学习，直接放在ReSaaS平台里，然后结合它的高可用性来支持各个业务应用。

Hadoop是由大量Sat硬盘的服务器在支撑。在存储方面Hadoop是以HDFS为主，后面有社区在PDS思路上引进出来的一个基于Open PDS发展成开源的资源核心。在2013年，因为处理大数据的机器学习，比如百度大数据集群往往用的样本容量都是在数百亿计的量级，样本的数量上也达到五千亿到万亿。我们在运行机器学习时，[]需要先启动MapReduce，然后再将数据从IBS分发到各个MPI节点，这种方式对于网络带宽的要求是比较高的。百度使用的是自研交换机，用大量的内部专线来解决集群的带宽问题。

即使系统的模式持续在改进内网，但通过ITCD不同技术带宽的情况，实际还是不能满足线上业务需求的要求。那么在业务层面、系统层面应该如何解决这些问题？

MPI是一种社会性调用，比如一个业务需要200个机器人，而百度内部用到的平台一般是在数百台服务器的量级，这个业务在执行过程中，可以进行机器学习线上大量的并行计算，一个MPI的集群可能在数千台量级。所以为了解决这个问题，充分利用MPI，于是我们在MPI服务器中引入Iler计算， Iler可以将CPU内存限制在一定的范围内。另一个解决的问题是机器， MPI集群的同时支持可以跑一些以MR为代表的典型，这种处理有利于离线处理的业务。所以在存储方面，我们将MPI底层非常高可靠的SaaS服务器，替换成高配置的存储性服务器，使得GPU的计算能力变得更强。

众所周知，如果Hadoop平台都配120G的内存，这的确是明显的优势，但资源浪费较大。因为底层的受益不大，或者说投入产出比并没有那么高。所以当Hadoop平台是32G或者64G时，MPI服务器一般是128，可以将存储部署到MPI。我们在服务器硬盘层面上，可以看到单机的计算能力，在MPI没有执行时可以调用一些随时被Q的MR。2014年我们在MPI上分装出来一个计算机引擎，一个专门针对云计算领域的引擎，可以大幅度降低MPI中非常低Level的编程接口。实际上底层自动做的是多极分布式，用户可以完全不用关心底层的数据，这就是百度第二代专门针对“并行计算”开发的系统框架。

2014年在并行计算里的ELF，在左边以MR、DAG为云计算引擎中，引入了NetiveC++引擎，在百度内部叫ECE。在并行计算方面，我们研发了第三代并行计算的框架。底层的实现基于一个Parameter Server架构，对比于百度的第二代框架DVC，在开发效率方面有大幅度的提升。

2014年百度底层是Manager系统，Matrix将MPI和并行计算层面统一。实际上在我们的另外一套系统，比如TaskManager，是百度内部的一个Queue worker，这种Queue worker的模型可以很轻松实现非常复杂的业务。模块可以通过一个存储器解耦，解耦是在上一级任务完成很多后，将其放置于一个Queue里，下一级模块可以到服务里领取。因为每一级的模块是有多个不同并发的worker，这种worker从上一级的Queue里领取过来的PaaS，处理完了之后交给下一级的Queue。然后这个worker再到Manager这里去获取一个新的计算分片。通过这样一个很简洁很优雅的Queue worker模型，将一个非常复杂的系统进行解耦。

2015年的架构改进，主要是将所有的计算模型经营通过Normandy进行调度。所以可以将存储、硬件、资源隔离等全面统一到相同的架构。截止到2015年上半年，掘金底层系统架构已经搭建成功。其本身可以支持社区接口，所以任何一个新兴的平台都可以很轻松的接入到百度的计算生态里。

我们已经介绍了掘金系统主要的底层引擎和架构版本，接下来向大家阐述整个掘金系统的概况：

掘金系统最底层是IDC，接着是Matrix，再是Normandy，然后是几个主要的引擎。之前介绍底层架构的统一，比如在硬件、调度、存储等方面的统一。实际上各个系统对外的结果，都有自己的接口，如果要使用MR，很多人写MR程序都是直接调用doop接口。比如一个MR和另一个MR之间，一个业务里完全通过一个模型设想到整个业务的全方面。比如我们有崭新日志和点击日志，首先会通过一个TM系统，对它进行一个展示和点击的Dstream，之后再交给Arm进行模型训练。训练结束之后，数据需要进行模型评估。因此，一个业务需要熟悉很多模型，而每一个模型又有各自特点和连接接口。只有足够了解模型的细节和接口后，才能真正的利用好该模型。

所以虽说我们平台的CPU很高，但是由于大量的投入不一样，于是我们研发出Data Flow，将模型的细节屏蔽掉。这样一来，平台自动决定下面使用多少个角度，当然也可以智能选择应该把这个翻译到什么位置，类似于Kiper。Data Flow可以支持多个不同的计算引擎，各个模型的细节通过非常一致。所以用户使用了同一套接口，便能对应到不同的任务。对于有一些非常大的服务器依然可行，进行精确控制，这也是掘金系统最主要的优势。

百度开放云——大数据+智能

最后，向大家简要介绍百度开放云的大数据+智能。实际上百度底层跟亚马逊底层也相对应，可以通过访问底层的域名Cloud.baidu.com访问该页面。所以做公有云的厂家都有一个底层IaaS。百度开放云的主要特色，在大数据方面，BMR已经对外开放，而更多的大数据分析和服务都还未对外开放。BMR集群上可以做到按需部署，用户专享。当然更关键的是完全兼容开源的Hadoop/Spark平台。DMR可以完全兼容社区的Hadoop和Spark，这样的话，大家对已经实现的业务就不需要再做任何的改动了。Palo，本身就兼容MySQL的网络协议，所以各种的Mysql Client的工具均可使用。

同时，百度也继续支持JDBC、ODBC的编程接口，如果已有程序采用的是JDBC、ODBC，那么迁移成本几乎为零。最后看到它与业界主流的BI工具商业分析的工具对接的，比如Tableau、Saiku、BIEE、R。

最后再介绍机器学习云服务BML，已经荣获2014年百度最高奖。提供端到端的解决方案，如果大家有兴趣的可以直接访问Cloud.baidu.com。百度机器学习云服务叫BML，直接在这个业务重建上，可能需要经过百度的审核，然后就可以完美适用了。除了在提供这些在百度内部的算法之外，我们在全流程方面也做了以下工作，比如预处理、特征分析、模型训练、模型预测。当然最底层的集群，网络是万兆互联的，192GB，甚至我们用LBDA的集群支持机器学习，通过大规模集群技术来进行支持。

以上是本次演讲的主要内容，再简要跟大家回顾一下，首先与大家一起分享了百度分布式计算平台和战略引擎方面，我们所做的规模和性能方面的一些优化，之后主要探讨了百度在计算的系统架构里的演进。结合以上内容，最后简要介绍了大数据的产品和服务，希望能够帮助大家了解百度开放云平台，感谢大家！

关于朱冠胤

• 2008年硕士毕业于北邮，现任百度开放云大数据负责人，基础架构部高级技术经理；
• 2008年1月加入百度实习，作为国内首批Hadoop研发工程师之一，参与了百度Hadoop平台从无到单集群全球最大整个过程；
• 2009年开始作为负责人开始从无到有建设百度大规模机器学习平台，陆续参与了凤巢CTR预估、网盟CTR预估、大搜索PageRank、机器翻译等核心机器学习项目。2014年8月，与其他部门联合研发的深度学习平台获百度最高奖；
• 2015年8年，带领团队完成的智能服务调度系统-Normandy获得百度最高奖；
• 目前主要负责百度开放云大数据产品研发和推广，已上线国内首个云端全托管的Hadoop/Spark服务BMR，国内首个机器学习云服务BML等；
• 关注领域主要是大数据分析和挖掘技术，包括但不限于Hadoop/Spark、深度学习等。

（整理/ OneAPM 技术编辑王鹏 责编/仲浩）