BigData | Apache Beam的诞生与发展

最新推荐文章于 2023-11-01 16:25:47 发布

Pysamlam

最新推荐文章于 2023-11-01 16:25:47 发布

阅读量249

点赞数

本文链接：https://blog.csdn.net/Pysamlam/article/details/100976913

版权

? 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，意味着这是一个统一了批处理和流处理的框架。

640?wx_fmt=png

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

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

? Apache Beam的编程模式

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

640?wx_fmt=png

图来自极客时间

第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点来展开阐述：