Apache Beam -- 简介

水深无声 2022-03-20 13:22 332阅读 0赞

## **概述** ##

在大数据的浪潮之下，技术的更新迭代十分频繁。受技术开源的影响，大数据开发者提供了十分丰富的工具。但也因为如此，增加了开发者选择合适工具的难度。在大数据处理一些问题的时候，往往使用的技术是多样化的。这完全取决于业务需求，比如进行批处理的MapReduce，实时流处理的Flink，以及SQL交互的Spark SQL等等。而把这些开源框架，工具，类库，平台整合到一起，所需要的工作量以及复杂度，可想而知。这也是大数据开发者比较头疼的问题。而今天要分享的就是整合这些资源的一个解决方案，它就是 Apache Beam。

Beam是一个统一的编程框架，支持批处理和流处理，并可以将用Beam编程模型构造出来的程序，在多个计算引擎（[Apache Apex][], [Apache Flink][], [Apache Spark][], [Google Cloud Dataflow][]等）上运行。

## Apache Beam 是什么？ ##

Apache Beam是大数据的编程模型，定义了数据处理的编程范式和接口，它并不涉及具体的执行引擎的实现，但是，基于Beam开发的数据处理程序可以执行在任意的分布式计算引擎上，目前Dataflow、Spark、Flink、Apex提供了对批处理和流处理的支持，GearPump提供了流处理的支持，Storm的支持也在开发中。

综上所述，Apache Beam的目标是：

1.  提供统一批处理和流处理的编程范式
2.  能运行在任何可执行的引擎之上

为无限、乱序、互联网级别的数据集处理提供简单灵活、功能丰富以及表达能力十分强大的SDK。

那 Apache Beam到底能解决哪些问题，它的应用场景是什么，下面我们可以通过一张图来说明，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0Nzc3NjAw_size_16_color_FFFFFF_t_70][]

通过上图，我们可以很清晰的看到整个技术的发展流向；一部分是谷歌派系，另一部分则是Apache派系。在开发大数据应用时，我们有时候使用谷歌的框架，API，类库，平台等，而有时候我们则使用Apache的，比如：HBase，Flink，Spark等。而我们要整合这些资源则是一个比较头疼的问题，Apache Beam 的问世，整合这些资源提供了很方便的解决方案。

## **Beam构成** ##

下面，我们通过一张流程图来看Beam的运行流程，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0Nzc3NjAw_size_16_color_FFFFFF_t_70 1][]

通过上图，我们可以清楚的知道，执行一个流程分以下步骤：

1.  End Users：选择一种你熟悉的编程语言提交应用
2.  SDK Writers：该编程语言必须是 Beam 模型支持的
3.  Library Writers：转换成Beam模型的格式
4.  Runner Writers：在分布式环境下处理并支持Beam的数据处理管道
5.  IO Providers：在Beam的数据处理管道上运行所有的应用
6.  DSL Writers：创建一个高阶的数据处理管道

## Beam编程模型 ##

Beam的编程模型是Google的工程师从[MapReduce][], [FlumeJava][], 和[Millwheel][]等多个大数据处理项目中抽象出来的，如果想详细了解可以参考相关的报考和论文，[Streaming 101][]，[Streaming 102][] 和[VLDB 2015 paper][].。这个编程模型主要包括如下几个核心概念：

1.  PCollection：数据集，代表了将要被处理的数据集合，可以是有限的数据集，也可以是无限的数据流。
2.  PTransform：计算过程，代表了将输入数据集处理成输出数据集中间的计算过程，
3.  Pipeline：管道，代表了处理数据的执行任务，可视作一个有向无环图（DAG），PCollections是节点，Transforms是边。
4.  PipelineRunner：执行器，指定了Pipeline将要在哪里，怎样的运行。

其中PTransform还包括很多操作，如：

*  ParDo：通用的并行处理的PTranform， 相当于Map/Shuffle/Reduce-style 中的Map，可用于过滤 、类型转换 、抽取部分数据 、 对数据中的每一个元素做计算等
 *  GroupByKey：用来聚合key/value对，相当于Map/Shuffle/Reduce-style中的Shuffle, 聚合那些拥有同一个key的value
 *  CoGroupByKey：用来聚合多个集合，功能和GroupByKey类似
 *  Combine：处理集合里的数据，如sum, min, and max(sdk预定义)，也可以自建新类
 *  Flatten：用来把多个数据集合并成一个数据集
 *  Partition：用来把一个数据集分割成多个小数据集

此外还有一些核心概念，如：

*  Windowing：把PCollections数据集中元素通过时间戳分成多个子集
 *  Watermark：标记了多久时间后的延迟数据直接抛弃
 *  Triggers：用来决定什么时候发送每个window的聚合结果

Beam的编程模型可简单概括为

\[Output PCollection\] = \[Input PCollection\].apply(\[Transform\])

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0Nzc3NjAw_size_16_color_FFFFFF_t_70 2][]

数据输入+数据集+数据处理+数据输出=数据处理流程。

## 核心问题 ##

Apache Beam的核心围绕着4个问题：

*  What **计算的结果是什么？**  
    Pipeline中的转换来决定结果。例如计算总和，构建直方图，训练机器学习模型等等。它也是经典批处理回答的问题。对应的抽象概念为PTransform。
 *  Where **在事件时间中的哪个位置计算结果？**  
    这个问题是通过在Pipeline中使用事件时间窗口来回答的。这包括从Streaming 101（固定，滑动和会话）窗口的常见示例，似乎没有窗口概念的用例（例如，Streaming 101中描述的时间不可知处理;经典批处理也通常属于此类别）和其他更复杂的窗口类型，如时间有限的拍卖。还要注意，它可以包括处理时间窗口，如果在记录到达系统时将入口时间指定为记录的事件时间。对应的抽象概念为Window。
 *  When **在处理时间中的哪个时刻触发计算结果？**  
    通过使用Watermark和触发器来回答的这个问题。这个主题有无穷的变化，但最常见的模式是在给定窗口的输入完成时使用Watermak来描绘，触发器允许提前计算结果（对于在窗口完成之前发出的推测性的、部分的结果）和延迟计算结果（Watermark只是预估窗口的数据全部到达,并不是100%确定，在Watermark声明给定窗口的全部到达之后，也有可能会有隶属于该窗口的数据到达）。对应的抽象概念为Watermarks和Triggers。
 *  How **如何修正结果？**  
    这个问题由所使用的累积类型回答：丢弃（其中结果是相互独立和不同的），累加（后来的结果建立在先前的结果上），累加和撤销（当前的累加值和上次触发的值撤销一起发送）。对应的抽象概念为Accumulation。

## 总结 ##

Apache Beam 主要针对理想并行的数据处理任务，并通过把数据集拆分多个子数据集，让每个子数据集能够被单独处理，从而实现整体数据集的并行化处理。当然，也可以用 Beam 来处理抽取，转换和加载任务和数据集成任务（一个ETL过程）。进一步将数据从不同的存储介质中或者数据源中读取，转换数据格式，最后加载到新的系统中。

--------------------

**End**

[Apache Apex]: https://en.wikipedia.org/wiki/Apache_Apex
[Apache Flink]: https://en.wikipedia.org/wiki/Apache_Flink
[Apache Spark]: https://en.wikipedia.org/wiki/Apache_Spark
[Google Cloud Dataflow]: https://en.wikipedia.org/w/index.php?title=Google_Cloud_Dataflow&action=edit&redlink=1
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0Nzc3NjAw_size_16_color_FFFFFF_t_70]: /images/20220320/d678fbed271d45edb8984f2b1b4103c2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0Nzc3NjAw_size_16_color_FFFFFF_t_70 1]: /images/20220320/06b2c74769d840d5bacbfb2cd24c246b.png
[MapReduce]: http://research.google.com/archive/mapreduce.html
[FlumeJava]: http://research.google.com/pubs/pub35650.html
[Millwheel]: http://research.google.com/pubs/pub41378.html
[Streaming 101]: https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101
[Streaming 102]: https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102
[VLDB 2015 paper]: http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0Nzc3NjAw_size_16_color_FFFFFF_t_70 2]: /images/20220320/bbb8aba273aa43acaebd28c136a53f5b.png