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

作为国内搜索巨头,百度收录全世界超过一万亿的网页,每天响应中国网民大约几十亿次的请求。那么,在面对如此庞大的数据处理时,百度是如何构建并优化分布式计算平台,又如何完成一次次系统构架的演进呢?

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

以下为演讲整理

大家好! 我来自百度开放云大数据团队,2008年1月加入百度,一直在从事大数据分析和挖掘相关工作。目前我们将服务百度内部核心业务多年的Hadoop服务BMR(BaiduMapReduce)、大规模机器学习服务BML(Baidu MachineLearning)等正式对外开放。接下来我就跟大家分享一下BMR和BML为代表的百度大数据分析和挖掘平台演进历程以及在该领域的最新思考。

其实,如果涉及到“大数据”,不得不提百度最大的业务——搜索。百度搜索已经收录全世界超过一万亿的网页,每天响应中国网民大约几十亿次的请求。除此之外,百度还有另外20多个用户过亿的产品线,而且各个产品底层的大规模数据处理,都需要使用我们团队维护的大数据处理平台。

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

百度分布式计算平台:离线引擎优化

关于MapReduce

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

首先介绍主要的离线计算模型——MapReduce,百度从2007年开始引进Hadoop 0.15.1,随后快速发展,2011年百度的MR单集群规模达到5000台,到2013年已经多达1.3万台,这也是截止到目前为止全世界最大的单集群。Hadoop全集群规模为10万量级, 作业量达到了百万量级,日均CPU利用率超过80%,远超业界同行,百度开放云(http://cloud.baidu.com)底层依赖的大规模集群调度、资源隔离等技术能力世界领先。除了在规模方面不断扩大,我们一直在Hadoop性能分析方面进行了大量的优化。2013年的测试结果显示,百度内部MR实现相比于开源Hadoop性能提升30%。典型优化,例如Hadoop中的Shuffle,我们将其做成一个统一的shuffle服务,不再占用Map或Reduce槽位。比如对关键热点函数采用SSE向量化等。

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

2014年,我们继续对计算引擎做了大幅优化, Native C++实现的DAG引擎正式上线。下图是一个 4轮MR Job实现的典型业务流示例,DAG引擎上线后,可以优化成一个DAG作业,可以避免3次Reduce写多副本引入的磁盘IO及网络IO,还可以规避2次Map读HDFS的IO以及处理耗费。

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

下图是一个真实业务由SQL计算表示层翻译下来的,基于MR引擎时,SQL会翻译成25个MR JOB,如果我们把它优化成DAG,能够避免很多次磁盘IO操作。在优化之后,运行时间直接缩减到1个小时,优化前后的差异非常显著。

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

内存流式Shuffle

2014年,我们对Shuffle进行重大重构,初期实习生同学完成的Demo以BaiduSort名义参与了2014年Sort BenchMark大数据排序国际大赛,并获得冠军(2015年百度没再参加,国内其他公司以同样技术通过更大规模集群刷新记录)。2015年,新Shuffle技术完成全面上线。Hadoop默认Shuffle实现为基于磁盘Pull模式,计算过程显式分成Map、Shuffle、Reduce过程;Baidu研发的新Shuffle采用内存流式Push模式,Map端完成部分记录处理后直接从内存中将计算结果推送给下游。

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

举例来说,Map处理256MB输入数据,在内存流式Shuffle模式下,处理完100条记录以后,直接通过内存推送到下游,这样就形成流水线方式处理。不再有显式的Shuffle阶段。

目前,该Shuffle组件为通用组件,正逐步推广到其他分布式计算平台中。

百度分布式计算平台:系统架构演进

前面重点介绍了百度开放云BMR服务中涉及到的规模、性能方面优化思路和效果,接下来跟大家一起分享一下,我们遇到的整体架构方面挑战以及优化思路。

2012年系统架构中,最主要的两个离线计算平台,左边是以MapReduce模型为主的批量计算平台BMR,右边是MPI /BSP模型为主的大规模机器学习平台BML。从最下面可以看到,MapReduce和MPI模型底层硬件就有较大差异。Hadoop分布式文件系统多副本以及强大的故障处理机制,使得Raid卡完全没有必要,采用多块超大容量SATA硬盘非常适合。

而MPI差别较大,MPI是一个消息传输框架,它在设计之初就没有考虑太多异常处理,因此它对底层系统可靠性要求非常高。百度采用了非常高配置的服务器,例如带Raid卡的sas硬盘,超大内存、万兆互联等。

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

BMR Hadoop由大量SATA硬盘的服务器构成,存储系统为HDFS,资源调度层面百度有自研的调度器ARK(与社区Yarn比较类似)。而BML大规模机器学习平台上,支持的业务样本超过数百亿计量级,特征规模也远超百亿。我们在运行机器学习时,需要先启动MapReduce,然后再将数据从HDFS分发到各个MPI节点,这种方式对网络带宽的要求很高。

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

系统部同事持续改进内网带宽的同时,BML平台层面也在思考应该如何解决跨MR和MPI俩大集群间的日益严重的网络带宽问题。

另外还有一个需求:MPI是一种事务性调度模型,比如一个业务需要200台机器,如果平台此时只有199台机器空闲,实际也很难用起来(除非修改提交参数,但涉及输入数据重新分块处理等比较复杂)。另外MPI计算往往显式分为计算、传输、计算等阶段(即BSP模型),因此资源利用波动性较大,例如CPU计算阶段,网络空闲;网络传输或全局同步阶段,CPU空闲。为解决这个问题,我们在MPI集群中引入IDLE计算,IDLE业务资源占用充分可控,典型的IDLE任务如MapReduce任务,而执行MR任务又会进一步加剧MR集群和MPI集群间网络带宽问题。

基于以上考虑,我们正式讲MPI底层硬件替换为替换成高配置存储型服务器,硬盘同构,文件系统都采用HDFS,BML算法输入和输出均通过HDFS,不再是本地文件系统。

BML机器学习执行引擎层面,我们基于MPI封装了DVCE(Distributed VectorComputingEngine)分布式向量计算引擎,屏蔽MPI过于低层的编程接口,通过高层抽象自动翻译为MPI任务,这就是百度第二代专门针对“并行计算”开发的系统框架。

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

2014年,BML机器学习执行引擎迁移到ELF第三代并行计算框架, ELF采用ParameterServer架构,大幅降低机器学习算法开发代价,对比于百度的第二代框架DVCE,在开发效率方面有大幅度的提升。离线计算方面,完成了Native C++ DAG引擎上线,百度内部叫DCE(Distributed ComputingEngine)。

2014年BMR和BML底层都采用Matrix完成资源分配与隔离,其他平台如小批量计算系统TaskManager和毫秒级计算延迟的Dstream系统,都基于业务需求特殊性,采用独立的资源隔离和调度系统。

2015年的架构改进,主要是将所有的计算模型均迁移到Matrix+Normandy架构。Normandy兼容社区Yarn调度接口,开源社区新型兴计算平台可以很轻松的接入到百度的计算生态里。

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

我们已经介绍了百度大数据分析和挖掘平台主要的底层引擎和架构,接下来谈一下最新思考。

系统底层是IDC硬件,接着是Matrix,再是Normandy,然后是几个主要的引擎。之前介绍底层架构的统一,比如在硬件、调度、存储等方面的统一。实际上各个系统对外的结果,都有自己的接口,如果要使用MR,很多人写MR程序都是直接调用Hadoop原生接口,配置涉及到的多个参数。部分业务还需要流式系统完成日志清洗,在经过MapReduce模型批量预处理,随后通过ELF完成机器学习模型训练,最后再通过MapReduce模型完成模型评估,可见一个业务需要跨越多个模型,需要业务线同学同时熟悉很多模型和平台,而每一个模型又有各自特点和接口。只有足够了解模型的细节和接口后,才能真正的利用好该模型。

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

于是我们正式立项BigFlow项目(原项目名DataFlow,图片未来及修改),将模型的细节屏蔽。平台自动决定选择合适的并发度,甚至智能选择应该把这个翻译到哪个计算模型。BigFlow可以支持多个不同的计算引擎(每个引擎在其适合的领域做到极致),充分发挥各引擎性能和功能。所以用户使用同一套接口,便能对应到不同的任务。由于采用高层抽象,业务开发效率获得大幅提升,代码量大幅减少,其维护成本也大幅降低。BigFlow集成常见优化手段,因此将大幅提升平台有效资源占用。

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

最后,向大家简要介绍百度开放云。2014年,百度正式决定将服务内部业务多年的云计算技术正式对外提供服务,即百度开放云,对应官网http://cloud.baidu.com。百度开放云大数据方面,BMR已经对外开放,而更多的大数据分析和服务都还未对外开放。BMR集群上可以做到按需部署,用户专享,更关键的是完全兼容开源的Hadoop/Spark平台,开放云客户基于Hadoop、Spark、Hbase等已经实现的大数据业务几乎不用修改就可以平滑迁移到云上。多维分析服务Palo,它完全兼容MySQL网络协议,因此,客户朋友们熟悉的Mysql Client的工具均可使用。

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

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

最后再介绍机器学习云服务BML,BML中提供的深度学习技术,曾获得2014年百度最高奖。BML提供端到端的解决方案,里面提供的算法均服务百度内部业务多年,典型如网页搜索、百度推广(凤巢、网盟CTR预估等)、百度地图、百度翻译等。

使用开放云BMR和BML、Palo等,就可以立刻、直接享用与百度搜索同等品质的大数据分析和挖掘服务!

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

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

作者简介

朱冠胤

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

本文采用「CC BY-SA 4.0 CN」协议转载自互联网、仅供学习交流,内容版权归原作者所有,如涉作品、版权和其他问题请给「我们」留言处理。

(0)
上一篇 2015-11-07 20:35
下一篇 2015-11-08 19:33

相关文章

关注我们
关注我们
分享本页
返回顶部