BigData | Apache Beam的诞生与发展

? Index

• FlumeJava／Millwheel／Dataflow Model的三篇论文
• Apache Beam的诞生
• Apache Beam的编程模式

? FlumeJava／Millwheel／Dataflow Model的三篇论文

这三篇Google发表的论文，分别是：

• 《 FlumeJava：Easy, Efficient Data-Parallel Pipelines 》
• 《 MillWheel：Fault-Tolerant Stream Processing at Internet Scale 》
• 《 The Dataflow Model：A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing》

论文任意门：

Paper1: https://research.google.com/pubs/archive/35650.pdf

Paper2: https://research.google.com/pubs/archive/41378.pdf

Paper3: https://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf

我这里有下载好的，可以在微信公众号：SAMshare ，后台输入beam 获取。

FlumeJava的诞生，起源于对MapReduce的性能优化，在MapReduce计算模型里，数据处理被抽象为Map和Reduce，计算模型从数据源中读取数据，经过用户写好的逻辑后生成一个临时的键值对数据集（Key／Value Set），这一步也叫 Shuffle阶段，并将其发送到下一阶段，进行Reduce操作，生成零个或多个结果。

但我们知道，使用MapReduce需要我们花费大量时间去进行性能调优，不能专注于数据逻辑的处理，因此，FlumeJava就诞生了。

FlumeJava的思想是将所有的数据都抽象为 PCollection的数据结构，这样子的好处就是你的测试代码即可以在分布式环境下运行，也可以在单机内存下运行。FlumeJava从MapReduce框架中抽象出来了4个原始操作，分别是：

• parallelDo
• groupByKey
• combineValues
• flatten

同时，FlumeJava架构用到了Deferred Evaluation技术来优化我们写的逻辑代码。这个Deferred Evaluation可以理解为将我们所写的代码静态遍历一遍，构建出一个可执行的计划，其实就是一个有向无环图，然后就自动帮我们优化代码，而且FlumeJava会根据我们数据集的规模，自行判断代码是要放在内存还是分布式环境下去跑。

当然，FlumeJava也是有弊端的，那就是它只是支持批处理任务，对于无边界数据是不支持的，因此2013年Google专门开发了一个类似于FlumeJava的流处理框架——Millwheel。

再到后来，优秀的Google工程师们觉得可以把上面的FlumeJava以及Millwheel整合在一起，因此提出了Dataflow Model的思想，也推出了基于这个思想开发的平台Cloud Dataflow。

? Apache Beam的诞生

上面说了那么多，感觉好像和Apache Beam一点关系都没有，但其实不然。上面说到，Google开发了一个平台给大家用，但是有些人并不想在这个Cloud Dataflow上去运行自己的程序，想在自己的平台上去运行。

因此，Google就在2016年联合几家大数据公司，基于Dataflow Model的思想开发出了一套SDK，并贡献到了Apache Software Foundation，并且命名为Beam，Beam=Batch+Streaming，意味着这是一个统一了批处理和流处理的框架。

通过以上的发展历史，我们知道了Beam诞生的原因，因此它从诞生那一刻起，就具备了以下的优势：

• 有着一套统一的API去处理两种数据处理模式，让开发者更加注重数据处理的算法，而非维护不同数据处理模式的差异；
• 使得工程师写好的算法逻辑与底层运行环境分隔开，即直接使用Beam提供的API就可以直接放在任何支持Beam API的底层系统上运行。

? Apache Beam的编程模式

在了解Beam的编程模式前，我们先看看beam的生态圈：

图来自极客时间

第1层：现有的各种大数据处理平台，在Beam中被称为Runner；

第2层：可移植的统一模型层，各个Runner将会依据中间抽象出来的这个模型思想，提供一套符合它的API，供上层转换使用；

第3层：SDK层，这里给工程师提供不同语言版本的API来编写数据处理逻辑，这些逻辑会被转换成Runner对应的API运行；

第4层：可扩展层，开发者根据已有的Beam SDK，开发并贡献出自己的SDK；

第5层：应用层，通过SDK层的SDK来实现；

第6层：社区层，提供给大家讨论问题的社区。

Beam的编程模式涉及到4个概念：窗口（Window）、水印（Watermark）、触发器（Triggers）和累加模式（Accumulation），分别解释一下：

• Window：可以直接理解为一个时间范围，窗口可以把数据根据事件时间划分成一个个的有边界的数据集；
• Watermark：表示与数据事件时间相关联的输入完整性的概念，比如，对于事件时间为X的水印，指的是数据处理逻辑已经得到了所有事件时间小于X的无边界数据，所以通常水印可以用来测量数据的处理进度；
• Triggers：触发器表示真正触发数据处理的位置或时间；
• Accumulation：累计模式指的是如果我们在同一窗口得到多个运算结果，我们应如何处理。

Beam的编程模型可以分为4点来展开阐述：

• What results are being calculated？
• Where in event time they are being computed？
• When in processing time they are materialized？
• How earlier results relate to later refinements？

第一点：What

我们需要计算什么数据，得到什么结果？Beam SDK中有各种转换操作可以解决。比如，我们需要统计一篇文章中单词出现的次数，我们需要利用Transform操作将文章转换成以单词为Key，出现次数为Value的集合。

第二点：Where

数据在什么范围内计算？我们可以通过设置合适的时间窗口，Beam会自动为每个窗口创建一个个小的批处理作业任务，分别进行数据处理统计。

第三点：When

何时将计算结果输出？我们可以通过水印以及触发器来完成设置。

第四点：How

后续数据的处理结果如何影响之前的处理结果？这可以用累积模式来解决，常见的累积模式有：丢弃（结果之间是独立且不同的）、累积（后来的结果建立在之前的结果上）等等。

Beam的编程模型将所有的数据处理逻辑都分割成上述的4个维度，所以我们在基于Beam SDK构建数据处理业务逻辑时，只需要根据业务需求，按照这4个维度调用具体的API即可。

? References

• 百度百科
• 蔡元楠-《大规模数据处理实战》22-23 小节 —— 极客时间