为什么 Google 用 Apache Beam 彻底替换掉 MapReduce

“神说，要有光，就有了光”。——《圣经》

1 月 10 日，Apache 软件基金会宣布， Apache Beam 成功孵化，成为该基金会的一个新的顶级项目，基于 Apache V2 许可证开源。

2003 年，谷歌发布了著名的大数据三篇论文，史称三驾马车：Google FS、MapReduce、BigTable。虽然谷歌没有公布这三个产品的源码，但是她这三个产品的详细设计论文开启了全球的大数据时代！从 Doug Cutting 大神根据谷歌的论文实现出 Hadoop+MapReduce 的雏形，到 Hadoop 生态圈各种衍生产品的蓬勃发展，再到后来的 Spark、流式计算等等，所有的一切都要归功于、源自这三篇论文。可惜谷歌虽然开启了这个伟大的时代，却始终仅仅满足于偶尔发表一两篇论文以强调自己在理论和工程上的领导地位，从来没有亲身参与进来，尤其是没有为开源生态做出什么贡献，因而一直没有从大数据市场获得什么实在的好处。

痛定思痛，谷歌开始走开源之路，将自己的标准推广给社区。从众所周知的 Kubernetes，到 2016 年 2 月谷歌高调宣布将 Apache Beam（原名 Google DataFlow）贡献给 Apache 基金会孵化，再到最近大热的 Tensorflow 等等，动作不断。Apache Beam 被认为是继 MapReduce，GFS 和 BigQuery 等之后，谷歌在大数据处理领域对开源社区的又一个非常大的贡献。

也就是说，在大数据处理的世界里，谷歌一直在内部闭源，开发并使用着 BigTable、Spanner、Millwheel 等让大家久闻大名而又无缘一见的产品，开源世界演进出了 Hadoop、Spark、Apache Flink 等产品，现在他们终于殊途同归，走到一起来了。

为什么要推出开源的 Apache Beam？

Apache Beam 的主要负责人 Tyler Akidau 在他的博客中提到他们做这件事的理念是：

要为这个世界贡献一个容易使用而又强大的模型，用于大数据的并行处理，同时适用于流式处理和批量处理，而且在各种不同平台上还可以移植。

那这一次为什么不是又酷酷的发表一篇论文，然后退居一旁静静的观察呢？为什么要联合一众伙伴为大家直接提供可以运行的代码了呢？原因主要有两点：

• 尽管在过去谷歌一直是闭源的，但在为云客户服务的过程中，谷歌已经认识到了开源软件的的巨大价值，比如基于谷歌三篇论文产生的 Hadoop 社区就是一个非常好的例子。思想上的转变使 Apache Beam 的诞生成为可能；
• 就 Beam 这个项目而言，要成功的必要条件之一是，必须有已经开源的 Runner 为 Beam 模型提供充分的支持，这样它才会在自建云和非谷歌云的场景下成为一个非常有竞争力的备选方案。去年 Apache Flink 在他们的系统内采用了 Beam 模型，这一条件也得到了满足；

无利不起早，谷歌这样做也是有着直接商业动机的，就是希望能有尽可能多的 Apache Beam 数据处理流水线可以运行在谷歌的 Cloud Dataflow 上，别忘了这是 Apache Beam 的原型。进一步说，采用开源的方式来引导这件事，也是有许多直接好处的：

• 支持 Apache Beam 的 Runner 越多，它作为一个平台的吸引力就越大；
• 使用 Apache Beam 的用户越多，想在谷歌云平台上运行 Apache Beam 的用户也就越多；
• 开发 Apache Beam 过程中吸引到的伙伴越多，那对这样的数据处理模型的推广就越有利；

而且，好处也不会全都归于谷歌，Apache Beam 项目中的所有参与方都会受益。如果在构建数据处理流水线时存在着这样一个可移植的抽象层，那就会更容易出现新的 Runner，它们可以专注于技术创新，提供更高的性能、更好的可靠性、更方便的运维管理等。换句话说，消除了对 API 的锁定，就解放了处理引擎，会导致更多产品之间的竞争，从而最终对整个行业起到良性的促进作用。

谷歌坚信 Apache Beam 就是数据批量处理和流式处理的未来。这么做会为各种不同的 Runner 营造一个健康的生态系统，让它们之间相互竞争，而最后可以让用户得到实在的好处。

Apache Beam 是什么？

要说 Apache Beam，先要说说谷歌 Cloud Dataflow。Dataflow 是一种原生的谷歌云数据处理服务，是一种构建、管理和优化复杂数据流水线的方法，用于构建移动应用、调试、追踪和监控产品级云应用。它采用了谷歌内部的技术 Flume 和 MillWhell，其中 Flume 用于数据的高效并行化处理，而 MillWhell 则用于互联网级别的带有很好容错机制的流处理。该技术提供了简单的编程模型，可用于批处理和流式数据的处理任务。她提供的数据流管理服务可控制数据处理作业的执行，数据处理作业可使用 DataFlow SDK 创建。

Apache Beam 本身不是一个流式处理平台，而是一个统一的编程框架，它提供了开源的、统一的编程模型，帮助你创建自己的数据处理流水线，实现可以运行在任意执行引擎之上批处理和流式处理任务。Beam 对流式计算场景中的所有问题重新做了一次归纳，然后针对这些问题提出了几种不同的解决模型，然后再把这些模型通过一种统一的语言给实现出来，最终这些 Beam 程序可以运行在任何一个计算平台上（只要相应平台——即 Runner 实现了对 Beam 的支持）。它的特点有：

• 统一的：对于批处理和流式处理，使用单一的编程模型；
• 可移植的：可以支持多种执行环境，包括 Apache Apex 、 Apache Flink 、 Apache Spark 和谷歌 Cloud Dataflow 等；
• 可扩展的：可以实现和分享更多的新 SDK、IO 连接器、转换操作库等；

Beam 特别适合应用于并行数据处理任务，只要可以将要处理的数据集分解成许多相互独立而又可以并行处理的小集合就可以了。Beam 也可以用于 ETL 任务，或者单纯的数据整合。这些任务主要就是把数据在不同的存储介质或者数据仓库之间移动，将数据转换成希望的格式，或者将数据导入一个新系统。

Beam 主要包含两个关键的部分：

• Beam SDK

Beam SDK 提供一个统一的编程接口给到上层应用的开发者，开发者不需要了解底层的具体的大数据平台的开发接口是什么，直接通过 Beam SDK 的接口，就可以开发数据处理的加工流程，不管输入是用于批处理的有限数据集，还是流式的无限数据集。对于有限或无限的输入数据，Beam SDK 都使用相同的类来表现，并且使用相同的转换操作进行处理。Beam SDK 可以有不同编程语言的实现，目前已经完整地提供了 Java，python 的 SDK 还在开发过程中，相信未来会有更多不同的语言的 SDK 会发布出来。

• Beam Pipeline Runner

Beam Pipeline Runner 将用户用 Beam 模型定义开发的处理流程翻译成底层的分布式数据处理平台支持的运行时环境。在运行 Beam 程序时，需要指明底层的正确 Runner 类型。针对不同的大数据平台，会有不同的 Runner。目前 Flink、Spark、Apex 以及谷歌的 Cloud DataFlow 都有支持 Beam 的 Runner。

需要注意的是，虽然 Apache Beam 社区非常希望所有的 Beam 执行引擎都能够支持 Beam SDK 定义的功能全集，但是在实际实现中可能并不一定。例如，基于 MapReduce 的 Runner 显然很难实现和流处理相关的功能特性。就目前状态而言，对 Beam 模型支持最好的就是运行于谷歌云平台之上的 Cloud Dataflow，以及可以用于自建或部署在非谷歌云之上的 Apache Flink。当然，其它的 Runner 也正在迎头赶上，整个行业也在朝着支持 Beam 模型的方向发展。

那大家可以怎样与 Beam 做亲密接触呢？

如上图所示，主要有三个方面：

• 数据处理：直接使用已有的自己熟悉语言的 SDK，根据 Beam 模型去定义并实现自己的数据处理流程；
• SDK 实现：用新的编程语言去根据 Beam 概念实现 SDK，这样大家以后在编程语言方面就可以有更多选择了；
• Runner 实现：将已有的分布式数据处理平台作为一种新的 Runner，接入 Beam 模型；

Beam 是怎么做的？

在任何一个设计开始之前，都先要确定问题，Beam 也不例外。

1. 数据。分布式数据处理要处理的数据类型一般可以分为两类，有限的数据集和无限的数据流。有限的数据集，比如一个 HDFS 中的文件，一个 HBase 表等，特点是数据提前已经存在，一般也已经持久化，不会突然消失，不会再改变。而无限的数据流，比如 kafka 中流过来的系统日志流，或是从 Twitter API 拿到的 Twitter 流等等，这类数据的特点是，数据动态流入，无穷无尽，无法全部持久化。一般来说，批处理框架的设计目标是用来处理有限的数据集，流处理框架的设计目标是用来处理无限的数据流。有限的数据集可以看做是无限的数据流的一种特例，但是从数据处理逻辑的角度，这两者并无不同之处。
2. 时间。Process Time 是指数据进入分布式处理框架的时间，而 Event-Time 则是指数据产生的时间。这两个时间通常是不同的，例如，对于一个处理微博数据的流计算任务，一条 2016-06-01-12:00:00 发表的微博经过网络传输等延迟可能在 2016-06-01-12:01:30 才进入到流处理系统中。批处理任务通常进行全量的数据计算，较少关注数据的时间属性，但是对于流处理任务来说，由于数据流是无情无尽的，无法进行全量的计算，通常是对某个窗口中得数据进行计算，对于大部分的流处理任务来说，按照时间进行窗口划分，可能是最常见的需求。
3. 乱序。对于流处理框架处理的数据流来说，其数据的到达顺序可能并不严格按照 Event-Time 的时间顺序。如果基于 Process Time 定义时间窗口，数据到达的顺序就是数据的顺序，因此不存在乱序问题。但是对于基于 Event Time 定义的时间窗口来说，可能存在时间靠前的消息在时间靠后的消息之后到达的情况，这在分布式的数据源中可能非常常见。对于这种情况，如何确定迟到数据，以及对于迟到数据如何处理通常是很棘手的问题。

Beam 模型处理的目标数据是无限的时间乱序数据流，不考虑时间顺序或是有限的数据集可看做是无限乱序数据流的一个特例。

如上图，其中虚线是最理想的，表示处理时间和事件时间是相同的，红线是实际上的线，也叫水位线（Watermark），它一般是通过启发式算法算出来的。

接下来从问题中抽象出四个具体的问题：

A：What are you computing，对数据的处理是哪种类型，数据转换、聚合或者是两者都有。例如，Sum、Join 或是机器学习中训练学习模型等。在 Beam SDK 中由 Pipeline 中的操作符指定。如图：

B：Where in event time，数据在什么范围中计算？例如，基于 Process-Time 的时间窗口？基于 Event-Time 的时间窗口？滑动窗口等等。在 Beam SDK 中由 Pipeline 中的窗口指定：

C：When in processing time，何时将计算结果输出？在这里引入了一个 Trigger 机制，Trigger 决定何时将计算结果发射出去，发射太早会丢失一部分数据，丧失精确性，发射太晚会导致延迟变长，而且会囤积大量数据，何时 Trigger 是由水位线来决定的，在 Beam SDK 中由 Pipeline 中的水位线和触发器指定。

D：How do refinements relate，迟到数据如何处理？例如，将迟到数据计算增量结果输出，或是将迟到数据计算结果和窗口内数据计算结果合并成全量结果输出。在 Beam SDK 中由 Accumulation 指定。

Beam 模型将”WWWH“四个维度抽象出来组成了 Beam SDK，用户在基于 Beam SDK 构建数据处理业务逻辑时，每一步只需要根据业务需求按照这四个维度调用具体的 API 即可生成分布式数据处理 Pipeline，并提交到具体执行引擎上执行。“WWWH”四个维度的抽象仅仅关注业务逻辑本身，和分布式任务如何执行没有任何关系。

在 QCon 旧金山 2016 上，Apache Beam 的创始人 Tyler Akidau 分享了该项目的设计理念和架构。

友商的看法

随着分布式数据处理不断发展，新的分布式数据处理技术也不断被提出，业界涌现出了越来越多的分布式数据处理框架，从最早的 Hadoop MapReduce，到 Apache Spark、Apache Storm，以及更近的 Apache Flink、Apache Apex 等。新的分布式处理框架可能带来的更高的性能、更强大的功能和更低的延迟，但用户切换到新的分布式处理框架的代价也非常大：需要学习一个新的数据处理框架，并重写所有的业务逻辑。解决这个问题的思路包括两个部分，首先，需要一个编程范式，能够统一、规范分布式数据处理的需求，例如，统一批处理和流处理的需求。其次，生成的分布式数据处理任务应该能够在各个分布式执行引擎上执行，用户可以自由切换分布式数据处理任务的执行引擎与执行环境。Apache Beam 正是为了解决以上问题而提出的。

如 Apache Beam 项目的主要推动者 Tyler Akidau所说：

为了让 Apache Beam 能成功地完成移植，我们需要至少有一个在部署自建云或非谷歌云时，可以与谷歌 Cloud Dataflow 相比具备足够竞争力的 Runner。如 Beam 能力矩阵所示，Flink 满足我们的要求。有了 Flink，Beam 已经在业界内成了一个真正有竞争力的平台。

对此，Data Artisan 的 Kostas Tzoumas 在他的博客中说：

在谷歌将他们的 Dataflow SDK 和 Runner 捐献给 Apache 孵化器成为 Apache Beam 项目时，谷歌希望我们能帮忙完成 Flink Runner，并且成为新项目的代码提交者和 PMC 成员。我们决定全力支持，因为我们认为：1、对于流处理和批处理来说 Beam 模型都是未来的参考架构；2、Flink 正是一个执行这样数据处理的平台。在 Beam 成形之后，现在 Flink 已经成了谷歌云之外运行 Beam 程序的最佳平台。

我们坚信 Beam 模型是进行数据流处理和批处理的最佳编程模型。我们鼓励用户们在实现新程序时采用这个模型，用 Beam API 或者 Flink DataStream API 都行。

目前主流流数据处理框架 Flink、Spark、Apex 以及谷歌的 Cloud DataFlow 等都有了支持 Beam 的 Runner。

结论

“在谷歌公司里已经没人再使用MapReduce 了”！谷歌云的主要负责人Mete Atamel 如是说。谷歌坚信Apache Beam 就是数据批处理和流处理的未来。Apache Beam 的模型对无限乱序数据流的数据处理进行了非常优雅的抽象，“WWWH”四个维度对数据处理的描述非常清晰与合理，Beam 模型在统一了对无限数据流和有限数据集的处理模式的同时，也明确了对无限数据流的数据处理方式的编程范式，扩大了流处理系统可应用的业务范围。随着Apache Beam 的成功孵化，随着越来越多的编程语言可用、越来越多的分布式数据处理平台支持Beam 模型，我们的确可以尽情畅想美好的未来。在今年4 月的QCon 北京2017 上，QCon 将邀请PayPal 架构师、Apache Beam 贡献者及PPMC 成员Amit Sela 来进一步分享Apache Beam 的相关技术。

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。