Apache Beam: Google一统大数据处理的野心？

1月10日，Apache 软件基金会宣布，Apache Beam 已经成功地从孵化毕业，成为基金会的一个新的顶级项目。虽然简单来说，这里只是开源了一个SDK，但却显示了Google在统一大数据处理方面的野心。

一. Apache Beam是什么？

Apache Beam 是 Google 在2016年2月份贡献给 Apache 基金会孵化的项目。项目的名称表明了其设计：结合了批处理（Batch）模式和数据流（strEAM）处理模式。

Apache Beam 的主要目标是统一批处理和流处理的编程范式，为无限、乱序、web-scale的数据集处理提供简单灵活，功能丰富以及表达能力十分强大的SDK。它基于一种统一模式，用于定义和执行数据并行处理Pipeline。项目包含构架于各个底层平台Runner之上的Adapter，希望基于 Beam 开发的数据处理程序可以执行在任意的分布式计算引擎上。

那么，这种模式是否存在呢？Stream和Batch是否可以统一？和Lamda架构有什么区别？

Beam的核心就在两篇文章上：Streaming 101和Streaming 102。

Beam Model从下面四个维度归纳了用户在进行数据处理的时候需要考虑的问题：

• What：如何对数据进行计算？例如，Sum、Join或是机器学习中训练学习模型等。在Beam SDK中由Pipeline中的操作符指定。
  

• Where：数据在什么范围中计算？例如，基于Process-Time的时间窗口，基于Event-Time的时间窗口、滑动窗口等。在BeamSDK中由Pipeline中的窗口指定。
  

• When：何时将计算结果输出？例如，在1小时的Event-Time时间窗口中，每隔1分钟，将当前窗口计算结果输出。在Beam SDK中由Pipeline中的Watermark和Trigger指定。
  

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

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

虽然看上去很复杂，但在实际的大数据处理实践中，可以说我们或多或少都已经在部分使用这个模型，只是没有像Google那样总结归纳出一个模型（并且还发了VLDB的paper）。

比如，我们知道在数据处理中，一个数据从发生到开始处理是有延迟的，Processing time（处理时间）和event time（事件发生时间）是不相等的，有的时候延迟会非常大。那么在实际处理中，我们可能就直接用processing time作为event time来分析；或者仍然使用event time，当老数据过来的时候进行更新，当过老的数据过来的时候直接丢弃的方式。而这些不同的处理方式，其实都已经包含在Bean Model中了。

二. Google为什么要开发Beam，并且开源？

Tyler Akidau, Staff Software Engineer & Apache Beam PPMC，在16年5月份的一个blog里，给出了Google的回答。

当我们决定把Google Cloud Dataflow SDK和runner作为Apache Beam项目来孵化的时候，我们脑海中有这样一个目标：提供一个易于使用，但又功能强大的并行数据分析模型，同时支持流式和批处理，兼容多个运行平台。

Google以前都是用lob-a-paper-over-the-wall 的方式来把创新分享给开源社区，但最近不打算这么做了。

Apache Beam支持的runner越多，作为一个平台就越有吸引力。 越多用户使用Beam，就有越多用户可能在Google Cloud Platform上使用Beam。 我们参与开发 Apache Beam 的人越多，我们就越能推进数据处理领域的顶尖技术

如果在构建一个数据处理的pipeline时有一个可移植的抽象层，那么各个runner就可以专注在技术创新上，去提供更好的性能、可靠性、易于管理性上。消除API的壁垒，有助于促进竞争，提供更好的结果。

Google关于MapReduce的论文发表于2004年，再那之后Google和开源社区就渐行渐远了。一方面是Hadoop的蓬勃发展，完整的开源的大数据处理的生态系统；另一方面是Google的很多内部项目，这里就包括FlumeJava和Millwheel，同时Google也继续用一些Paper来介绍他们的技术。当然非Google的人可以读到这些Paper，只是无法实际使用。

现在Google开源Beam这套SDK，就是为了消除各个Runner之间的使用差异，缩小切换Runner的开销，最终还是希望更多的人可以使用Google自己的service。

三. Google的野心能实现吗？

Beam模型很复杂，但并非空中楼阁，Google Cloud Platform已经基本支持了整个Model，同时Flink、Apex、Spark等runner也已经进到了Beam项目里。下面就是Beam“贴心“总结的各个Runner的capability matrix。

如果你还没有开始大数据处理，可以直接考虑GCP，或者是支持Beam比较好的Flink；但是如果已经使用了Spark Streaming，或者Storm，或者其他技术，其实没必要马上切换。因为切换也是需要开发和维护成本的，再就是虽然这些技术不完全支持Beam，但作为数据处理和分析，只要够用就行。

技术选型就是这样，往往选的不是最强大的，而是最适合的。可能在多种相似技术中选择某个，只是因为团队内正好有一位这个技术的专家而已。不过，对业内最新的技术有足够的了解，不固步自封，是技术决策人必须具备的。