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

http://www.csdn.net/article/2015-11-06/2826137

allowtransparency="true" frameborder="0" scrolling="no" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-11-06%2F2826137&type=3&count=&appkey=&title=%E5%9C%A82012%E5%B9%B4%EF%BC%8C%E7%99%BE%E5%BA%A6%E5%BC%80%E5%A7%8B%E7%A0%94%E5%8F%91%E8%87%AA%E5%AE%B6%E7%9A%84%E5%88%86%E5%B8%83%E5%BC%8F%E8%AE%A1%E7%AE%97%EF%BC%8C%E4%B8%BB%E8%A6%81%E6%98%AF%E4%BA%91%E8%AE%A1%E7%AE%97%E7%B3%BB%E7%BB%9F%E5%92%8C%E5%B9%B3%E5%8F%B0%E3%80%82%E7%9B%AE%E5%89%8D%EF%BC%8C%E6%9C%B1%E5%86%A0%E8%83%A4%E5%9B%A2%E9%98%9F%E6%9C%8D%E5%8A%A1%E4%BA%86%E6%95%B4%E4%B8%AA%E7%99%BE%E5%BA%A6%E5%85%AC%E6%9C%89%E4%BA%91%E7%9A%84%E9%9B%86%E7%BE%A4%EF%BC%8C%E6%89%BF%E6%8B%85%E5%A4%A7%E6%95%B0%E6%8D%AE%E5%88%86%E6%9E%90%E7%9B%B8%E5%85%B3%E7%9A%84%E5%B9%B3%E5%8F%B0%E5%92%8C%E6%9C%8D%E5%8A%A1%E5%B7%A5%E4%BD%9C%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1446821754140" width="22" height="16"> 摘要:在2012年,百度开始研发自家的分布式计算,主要是云计算系统和平台。目前,朱冠胤团队服务了整个百度公有云的集群,承担大数据分析相关的平台和服务工作。

【编者按】作为国内搜索巨头,百度收录全世界超过一万亿的网页,每天响应中国网民大约几十亿次的请求。那么,在面对如此庞大的数据处理时,百度是如何构建并优化分布式计算平台,又如何完成一次次系统构架的演进呢?在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、深度学习等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值