美国时间 2017年1 月 10 日，Apache 软件基金会对外宣布，万众期待的 Apache Beam 在经历了近一年的孵化之后终于毕业。这一顶级 Apache 开源项目终熟。这是大数据处理领域的又一大里程碑事件——仅仅在上个月，腾讯宣布将在 2017 年一季度开源其大数据计算平台 Angel 。现在看来，生不逢时的 Angel 可能迎来它最大的对手。至此，谷歌终于也完成了对其云端大数据平台 Cloud Dataflow 开源的承诺。

　　要说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模型的方向发展。

它针对什么问题提供了解决方案：

　　大数据处理领域的一大问题是：开发者经常要用到很多不同的技术、框架、API、开发语言和 SDK。雷锋网(公众号：雷锋网)获知，取决于需要完成的是什么任务，以及在什么情况下进行，开发者很可能会用 MapReduce 进行批处理，用 Apache Spark SQL 进行交互请求（ interactive queries），用 Apache Flink 实时流处理，还有可能用到基于云端的机器学习框架。

　　近两年开启的开源大潮，为大数据开发者提供了十分富余的工具。但这同时也增加了开发者选择合适的工具的难度，尤其对于新入行的开发者来说。这很可能拖慢、甚至阻碍开源工具的发展：把各种开源框架、工具、库、平台人工整合到一起所需工作之复杂，是大数据开发者常有的抱怨之一，也是他们支持专有大数据平台的首要原因。

谷歌开源 Cloud Dataflow 背后的算盘是：

　　Apache Beam 的用户基础越大，就会有更多人用谷歌云平台运它。相应地，他们会转化为谷歌云服务的客户。腾讯开放 Angel 的动机与之类似。

背景

　　2016 年 2 月份，谷歌及其合作伙伴向 Apache 捐赠了一大批代码，创立了孵化中的 Beam 项目（ 最初叫 Apache Dataflow）。这些代码中的大部分来自于谷歌 Cloud Dataflow  SDK——开发者用来写流处理和批处理管道（pipelines）的库，可在任何支持的执行引擎上运行。当时，支持的主要引擎是谷歌 Cloud Dataflow，附带对 Apache Spark 和 开发中的 Apache Flink 支持。如今，它正式开放之时，已经有五个官方支持的引擎。除去已经提到的三个，还包括 Beam 模型和 Apache Apex。

　　雷锋网获知，Apache Beam 的官方解释是：“Beam 为创建复杂数据平行处理管道，提供了一个可移动（兼容性好）的 API 层。这层 API 的核心概念基于 Beam 模型（以前被称为 Dataflow 模型），并在每个 Beam 引擎上不同程度得执行。”

谷歌工程师、Apache Beam 项目的核心人物 Tyler Akidau 表示：

“当我们（谷歌和几家公司）决定把  Cloud Dataflow SDK 和相关引擎加入  Apache Beam 孵化器项目时，我们脑海里有一个目标：为世界提供一个易于使用、但是很强大的数据并行处理模型，支持流处理和批处理，兼容多个运行平台。”

前景

　　对于 Apache Beam 的前景，Tyler Akidau 说道：

“一般来讲，在孵化器毕业只是一个开源项目生命周期中的一个里程碑——未来还有很多在等着我们。但成为顶级项目是一个信号：Apache Beam 的背后已经有为迎接它的黄金时间准备就绪的开发者社群。

这意味着，我们已经准备好向前推进流处理和批处理的技术边界，并把可移动性（兼容多平台）带到可编程数据处理。 这很像 SQL 在陈述性数据（declarative data）分析领域起到的作用。相比不开源、把相关技术禁锢在谷歌高墙之内，我们希望借此创造出前者所无法实现的东西。”

　　另外，Tyler Akidau 信心十足地强调：“流处理和批处理的未来在于 Apache Beam，而执行引擎的选择权在于用户。”

　　最后，我们来看看谷歌在去年早些时候发布的 “Apache Beam 技能矩阵”，用它可以看出每一个兼容引擎执行 Beam 模型的效果。换句话说，它展示了 Apache Beam 管道在不同平台执行的兼容能力。

　　 Apache Beam（原名Google DataFlow）是Google在2016年2月份贡献给Apache基金会的Apache孵化项目，被认为是继MapReduce，GFS和BigQuery等之后，Google在大数据处理领域对开源社区的又一个非常大的贡献。Apache Beam的主要目标是统一批处理和流处理的编程范式，为无限，乱序，web-scale的数据集处理提供简单灵活，功能丰富以及表达能力十分强大的SDK。Apache Beam项目重点在于数据处理的编程范式和接口定义，并不涉及具体执行引擎的实现，Apache Beam希望基于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定义的时间窗口来说，可能存在时间靠前的消息在时间靠后的消息之后到达的情况，这在分布式的数据源中可能非常常见。对于这种情况，如何确定迟到数据，以及对于迟到数据如何处理通常是很棘手的问题。

 友商的看法

　　随着分布式数据处理不断发展，新的分布式数据处理技术也不断被提出，业界涌现出了越来越多的分布式数据处理框架，从最早的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。

本文转自大数据躺过的坑博客园博客，原文链接：http://www.cnblogs.com/zlslch/p/7609417.html，如需转载请自行联系原作者