Apache Beam是什么？

 

 

　　不多说，直接上干货！

 

 

 

以下是Apache Beam的官网 ：

https://beam.apache.org/

 

 

 

 

 

 

 

Apache Beam的前世今生

      Apache Beam前身是Google Dataflow SDK，DataFlow是谷歌的提供大数据计算平台。在DataFlow之前，谷歌的批处理和流处理(流计算，实时处理)使用了不同系统，流处理有MillWheel、FlumeJava等，批处理有MapRedude，不同的平台使用了不同的Api，无疑提升了开发的难度，所以DataFlow横空出世，提出了一套统一批处理和流处理的模型。

      Google在2016年2月贡献给Apache基金会的Apache孵化项目，2017年2月从孵化器毕业，成为Apache Beam的顶级项目。

 　　

   　　图1　　 Apache Beam的进化历程

 

 

 

 

　　1月10日，Apache软件基金会宣布，Apache Beam成功孵化，成为该基金会的一个新的顶级项目，基于Apache V2许可证开源。

　　2003年，谷歌发布了著名的大数据三篇论文，史称三驾马车：Google FS、MapReduce、BigTable。虽然谷歌没有公布这三个产品的源码，但是她这三个产品的详细设计论文开启了全球的大数据时代！从Doug Cutting大神根据谷歌的论文实现出Hadoop+MapReduce的雏形，到Hadoop生态圈各种衍生产品的蓬勃发展，再到后来的Spark、流式计算等等，所有的一切都要归功于、源自这三篇论文。可惜谷歌虽然开启了这个伟大的时代，却始终仅仅满足于偶尔发表一两篇论文以强调自己在理论和工程上的领导地位，从来没有亲身参与进来，尤其是没有为开源生态做出什么贡献，因而一直没有从大数据市场获得什么实在的好处。

　　痛定思痛，谷歌开始走开源之路，将自己的标准推广给社区。从众所周知的Kubernetes，到2016年2月谷歌高调宣布将Apache Beam（原名Google DataFlow）贡献给Apache基金会孵化，再到最近大热的Tensorflow等等，动作不断。Apache Beam被认为是继MapReduce，GFS和BigQuery等之后，谷歌在大数据处理领域对开源社区的又一个非常大的贡献。

　　也就是说，在大数据处理的世界里，谷歌一直在内部闭源，开发并使用着BigTable、Spanner、Millwheel等让大家久闻大名而又无缘一见的产品，开源世界演进出了Hadoop、Spark、Apache Flink等产品，现在他们终于殊途同归，走到一起来了。

　　　　　　　　　　　　　　

 

 

 

 

 

 

 

 

 为什么要推出开源的Apache Beam？

　　Apache Beam的主要负责人Tyler Akidau在他的博客中提到他们做这件事的理念是：

要为这个世界贡献一个容易使用而又强大的模型，用于大数据的并行处理，同时适用于流式处理和批量处理，而且在各种不同平台上还可以移植。

 

　　那这一次为什么不是又酷酷的发表一篇论文，然后退居一旁静静的观察呢？为什么要联合一众伙伴为大家直接提供可以运行的代码了呢？原因主要有两点：

• 尽管在过去谷歌一直是闭源的，但在为云客户服务的过程中，谷歌已经认识到了开源软件的的巨大价值，比如基于谷歌三篇论文产生的Hadoop社区就是一个非常好的例子。思想上的转变使Apache Beam的诞生成为可能；

• 就Beam这个项目而言，要成功的必要条件之一是，必须有已经开源的Runner为Beam模型提供充分的支持，这样它才会在自建云和非谷歌云的场景下成为一个非常有竞争力的备选方案。去年Apache Flink在他们的系统内采用了Beam模型，这一条件也得到了满足；

　　无利不起早，谷歌这样做也是有着直接商业动机的，就是希望能有尽可能多的Apache Beam数据处理流水线可以运行在谷歌的Cloud Dataflow上，别忘了这是Apache Beam的原型。进一步说，采用开源的方式来引导这件事，也是有许多直接好处的：

• 支持Apache Beam的Runner越多，它作为一个平台的吸引力就越大；

• 使用Apache Beam的用户越多，想在谷歌云平台上运行Apache Beam的用户也就越多；

• 开发Apache Beam过程中吸引到的伙伴越多，那对这样的数据处理模型的推广就越有利；

　　而且，好处也不会全都归于谷歌，Apache Beam项目中的所有参与方都会受益。如果在构建数据处理流水线时存在着这样一个可移植的抽象层，那就会更容易出现新的Runner，它们可以专注于技术创新，提供更高的性能、更好的可靠性、更方便的运维管理等。换句话说，消除了对API的锁定，就解放了处理引擎，会导致更多产品之间的竞争，从而最终对整个行业起到良性的促进作用。

　　谷歌坚信Apache Beam就是数据批量处理和流式处理的未来。这么做会为各种不同的Runner营造一个健康的生态系统，让它们之间相互竞争，而最后可以让用户得到实在的好处。

 

 

 

 

 

 

 

 

Apache Beam是什么？

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

      综上所述，Apache Beam的目标是提供统一批处理和流处理的编程范式，为无限、乱序、互联网级别的数据集处理提供简单灵活、功能丰富以及表达能力十分强大的SDK，目前支持Java和Python两种SDK。

      如果类比一下的话，大数据领域的Apace Beam相当于Java，提供了跨语言、跨平台的大数据开发标准。 

　　　　　　　　　　　　　　　　

 　　

图2         Apache Beam概念架构

 

　　我这里，给大家补充一个更完善的图。

 

 

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

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

 

 

 

 

 

 

 

　　

图3      Apache Beam生态圈

 

 

  

 

　　美国时间 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。