百度实时计算平台的实现和应用

问题导读
1、百度自主研发了国内哪几种规模最大的实时计算平台？
2、TM平台是如何对RTB实时竞价进行join计算的？
3、Dstream应用的业务场景是什么？

摘要：
当前，业界知名的实时计算系统有Google的MillWheel 、Twitter开源的Storm、Spark Streaming等。百度自主研发了国内规模最大的实时计算平台——Dstream和TM。它们各有千秋，适用于不同的业务场景。

“大数据”在互联网行业中已是普遍现象，一家公司每天累积的用户行为数据甚至已不能用TB来衡量。海量数据对实时分析和计算提出了更高的要求，实时处理程序必须确保在严格的时间内响应，通常以秒为单位，甚至是毫秒。传统的批量计算模型已无法满足这些要求，必须用专门的实时计算系统替代。当前，业界知名的实时计算系统有Google的MillWheel、Twitter开源的Storm、Spark Streaming等。

百度自主研发了国内规模最大的实时计算平台——Dstream和TM。它们各有千秋，适用于不同的业务场景。Dstream旨在面向有向无环的数据处理流，满足高时效性要求的计算业务场景（如实时CTR计算），可达到毫秒级的响应。TM则是queue-worker模式的准实时workflow计算系统，可满足秒级到分钟级响应，并具备transaction语义，流入平台的数据即使在平台发生故障的情况下，也能做到不重不丢。这一系统主要应用于低时延、高吞吐及对数据完整性要求极高的场景，如报表生成系统、计费流计算等。

百度实时计算平台介绍

Dstream立项之初，业界还没有类似的开源系统（Storm尚未正式推出），只能依靠研发团队自己摸索。目前Dstream平台的集群规模已超千台，单集群最大处理数据量超过50TB/天，集群峰值QPS 193W/S，系统稳定性、计算能力已完全满足海量数据时效性处理需求。即使与Storm相比，Dstream在系统成熟度、性能、稳定性等方面仍然优势明显，具体对比数据如表1所示。

TM平台从2013年开始研发，目前集群规模为百台级，单集群最大处理数据量超过30TB/天，最大QPS 20W/S。基于TM平台实现的多路数据流式join解决方案，已具备超大时间窗流式join计算能力，时间窗可到“天”级别，保证数据不丢不重，达到了业界先进水平，并已应用于百度多条业务线的点击日志、展现日志的join计算。

在TM平台上，用户构造一个作业描述文件来阐述各种worker之间的数据流向关系和每个worker所需的资源，通过client将作业提交给TM平台，然后由TM调度并运行。TM平台可利用公司空闲服务器资源进行计算。系统具有以下几个特性。

保证数据完整和时效。数据在处理过程中，保证不会出现重复和丢失，在保证join比例的情况下，最短时间内输出给下游使用。

容忍数据流的长时间跨度。不限制输入数据流的时间延迟和跨度，通过引入可靠存储系统来“存储一种数据流，其余数据流查询”的方式，解决长时间跨度下数据join问题；对于时间跨度小的数据流，提供基于滑动窗口的内存join方式。

通用性。可以同时应对不同时间跨度的join，一般应用既需要时效性较高，又要求数据join比例不同，时效性也有所不同。通过引入多级重试join机制，系统同时满足了这两个需求。

高可靠性和高可运维。通过支持多集群备份、多机房备份等方案，保证系统的高可靠性。另外通过TM平台管理应用拓扑、集群配置，支持配置动态更新、故障自动检测等，增强系统的高可运维性。

实时计算平台应用案例

日志实时ETL

百度内部有统一的用户数据仓库，数据入库的方式有两种：一是通过基于Hadoop的ETL平台批量定期入库，二是直接通过实时计算系统实时入库。其中实时入库系统名为UDW–RT，它基于底层实时计算平台二次开发，致力于为百度提供一个面向流的、实时的数据ETL平台；通过设计和实现一个类SQL、可扩展的流运算系统，UDW–RT系统能为实时数据处理提供基础设施和数据供给。

UDW-RT系统逻辑上可分为以下三层（如图1）。

第一层为RT-importer，其职责是清洗、归并、结构化从pipe系统导入的数据并映射成流，每个流可以被想象成是一个无限长的数据表。

第二层是RT-PE，负责执行流算子。通过应用流类SQL算子（目前只支持部分SQL操作，如union、filtering和projection等），可以生成一个或多个逻辑流；每个逻辑流都可被下游零个或多个数据使用方订阅。

第三层是RT系统的应用程序，被称为RT-EXPORTER；数据使用方通过挂载RT-EXPORTER来进行数据消费。

实时竞价RTB

TM平台对RTB实时竞价产生的两路日志进行join计算，以确定竞价成功的广告，计算后的输出数据成为百度反作弊、CTR计算、计费等多个后端系统的入口。TM流式join架构支撑了RTB竞价模式落地，满足了广告主对于内容投放提出的更精准、实时和程序化的要求。同时，通过TM平台，百度网盟业务实现了前后端架构解耦，提升了系统健壮性和可扩展性，它由以下几个主要部分组成（如图2所示）。

Bigpipe：百度内部分布式消息发送订阅系统，延迟低，并且能保证数据在传输过程中不重不丢。

Bundler：TM平台订阅Bigpipe数据的通用模块，A_bundler和B_bundler表示订阅不同的数据流。

Parser：数据解析模块，主要将目前数据格式从文本转化成PB。

Aggregator：文件聚合模块，主要是将Parser产生的小文件聚合成大文件，减少文件个数。

Joiner：核心模块，负责两种数据流的join。采用基于滑动窗口的方式，保证数据流的流动和延迟，同时数据在窗口内部有序，使得单个joiner在输出数据时有序。另外通过aggregator流控策略，可以保证各个joiner输出数据时间戳相差不大，从而保证整体数据输出乱序有限。

Appender：TM平台向Bigpipe发布数据的模块。这里分了三路，分别表示A、B两种数据流没有join上的结果，以及join上的结果。

总结

基于实时计算平台，百度已具备多种高时效性的数据处理解决方案，这些技术已在越来越多的应用场景中发挥出重要作用。未来，百度将继续投入，深化对大数据实时计算架构及其关键技术的研究，进一步推动大数据实时计算理论、方法、技术与系统的应用与发展，以满足更广泛的市场需求和应用前景。