朱冠胤：百度开放云大数据分析 BMR 和 BML 架构演进之“不平凡之路”

朱冠胤：百度开放云大数据分析 BMR 和 BML 架构演进之“不平凡之路”

以下为演讲整理：

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

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

关于MapReduce

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

内存流式 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年，百度正式决定将服务内部业务多年的云计算技术正式对外提供服务。百度开放云大数据方面，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等；