赞
踩
美国时间 2017年1 月 10 日,Apache 软件基金会对外宣布,万众期待的 Apache Beam 在经历了近一年的孵化之后终于毕业。这一顶级 Apache 开源项目终于成熟。
这是大数据处理领域的又一大里程碑事件——仅仅在上个月,腾讯宣布将在 2017 年一季度开源其大数据计算平台 Angel 。现在看来,生不逢时的 Angel 可能迎来了它最大的对手。至此,谷歌终于也完成了对其云端大数据平台 Cloud Dataflow 开源的承诺。
统一了数据批处理(batch)和流处理(stream)编程范式,
能在任何执行引擎上运行。
它不仅为模型设计、更为执行一系列数据导向的工作流提供了统一的模型。这些工作流包括数据处理、吸收和整合。
大数据处理领域的一大问题是:开发者经常要用到很多不同的技术、框架、API、开发语言和 SDK。雷锋网(公众号:雷锋网)获知,取决于需要完成的是什么任务,以及在什么情况下进行,开发者很可能会用 MapReduce 进行批处理,用 Apache Spark SQL 进行交互请求( interactive queries),用 Apache Flink 实时流处理,还有可能用到基于云端的机器学习框架。
近两年开启的开源大潮,为大数据开发者提供了十分富余的工具。但这同时也增加了开发者选择合适的工具的难度,尤其对于新入行的开发者来说。这很可能拖慢、甚至阻碍开源工具的发展:把各种开源框架、工具、库、平台人工整合到一起所需工作之复杂,是大数据开发者常有的抱怨之一,也是他们支持专有大数据平台的首要原因。
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开发的数据处理程序可以执行在任意的分布式计算引擎上。本文主要介绍Apache Beam的编程范式-Beam Model,以及通过Beam SDK如何方便灵活的编写分布式数据处理业务逻辑,希望读者能够通过本文对Apache Beam有初步的了解,同时对于分布式数据处理系统如何处理乱序无限数据流的能力有初步的认识。
随着分布式数据处理不断发展,新的分布式数据处理技术也不断被提出,业界涌现出了越来越多的分布式数据处理框架,从最早的Hadoop MapReduce,到Apache Spark,Apache Storm,以及更近的Apache Flink,Apache Apex等。新的分布式处理框架可能带来的更高的性能,更强大的功能,更低的延迟等,但用户切换到新的分布式处理框架的代价也非常大:需要学习一个新的数据处理框架,并重写所有的业务逻辑。解决这个问题的思路包括两个部分,首先,需要一个编程范式,能够统一,规范分布式数据处理的需求,例如,统一批处理和流处理的需求。其次,生成的分布式数据处理任务应该能够在各个分布式执行引擎上执行,用户可以自由切换分布式数据处理任务的执行引擎与执行环境。Apache Beam正是为了解决以上问题而提出的。
Apache Beam主要由Beam SDK和Beam Runner组成,Beam SDK定义了开发分布式数据处理任务业务逻辑的API接口,生成的的分布式数据处理任务Pipeline交给具体的Beam Runner执行引擎。Apache Beam目前支持的API接口是由Java语言实现的,Python版本的API正在开发之中。Apache Beam支持的底层执行引擎包括Apache Flink,Apache Spark以及Google Cloud Platform,此外Apache Storm,Apache Hadoop,Apache Gearpump等执行引擎的支持也在讨论或开发当中。其基本架构如下图所示:
图1 Apache Beam架构图
需要注意的是,虽然Apache Beam社区非常希望所有的Beam执行引擎都能够支持Beam SDK定义的功能全集,但是在实际实现中可能并不一定。例如,基于MapReduce的Runner显然很难实现和流处理相关的功能特性。目前Google DataFlow Cloud是对Beam SDK功能集支持最全面的执行引擎,在开源执行引擎中,支持最全面的则是Apache Flink。
Beam Model指的是Beam的编程范式,即Beam SDK背后的设计思想。在介绍Beam Model之前,先简要介绍一下Beam Model要处理的问题域与一些基本概念。
Beam Model处理的目标数据是无限的时间乱序数据流,不考虑时间顺序或是有限的数据集可看做是无限乱序数据流的一个特例。Beam Model从下面四个维度归纳了用户在进行数据处理的时候需要考虑的问题:
Beam Model将”WWWH“四个维度抽象出来组成了Beam SDK,用户在基于Beam SDK构建数据处理业务逻辑时,在每一步只需要根据业务需求按照这四个维度调用具体的API即可生成分布式数据处理Pipeline,并提交到具体执行引擎上执行。“WWWH”四个维度的抽象仅仅关注业务逻辑本身,和分布式任务如何执行没有任何关系。
不同于Apache Flink或是Apache Spark,Beam SDK使用同一套API表示数据源,输出目标以及操作符等。下面介绍4个基于Beam SDK的数据处理任务,通过这四个数据处理任务,读者可以了解通过Beam Mode是如何统一灵活的描述批处理和流处理任务的,这4个任务用来处理手机游戏领域的统计需求,包括:
注:示例代码来自Beam的源码,具体地址参见:apache/incubator-beam。部分分析内容参考了Beam的官方文档,详情请参见引用链接。
下面基于Beam Model的“WWWH”四个维度,分析业务逻辑,并通过代码展示如何通过Beam SDK实现“WWWH”四个维度的业务逻辑。
统计每个用户的历史总得分数是一个非常简单的任务,在这里我们简单的通过一个批处理任务实现,每次需要新的用户分数数据的时候,重新执行一次这个批处理任务即可。对于用户分数任务,“WWWH”四维度分析结果如下:
通过“WWWH”的分析,对于用户分数这个批处理任务,通过Beam Java SDK实现的代码如下所示:
- gameEvents
-
- [... input ...]
-
- [... parse ...]
-
- .apply("ExtractUserScore", new ExtractAndSumScore("user"))
-
- [... output ...];
ExtractAndSumScore实现了“What”中描述的逻辑,即按用户分组,然后累加分数,其相关代码如下:
- gameInfo
-
- .apply(MapElements
-
- .via((GameActionInfo gInfo) -> KV.of(gInfo.getKey(field), gInfo.getScore()))
-
- .withOutputType(
-
- TypeDescriptors.kvs(TypeDescriptors.strings(), TypeDescriptors.integers())))
-
- .apply(Sum.<String>integersPerKey());
通过MapElements确定Key与Value分别是用户与分数,然后Sum定义按key分组,并累加分数。Beam支持将多个对数据的操作合并成一个操作,这样不仅可以支持更清晰的业务逻辑实现,同时也可以在多处重用合并后的操作逻辑。
按照小时统计每个团队的分数,获得最高分数的团队可能获得奖励,这个分析任务增加了对窗口的要求,不过我们依然可以通过一个批处理任务实现,对于这个任务的“WWWH”四个维度的分析如下:
相对于第一个用户分数任务,只是在Where部分回答了“数据在什么范围中计算?”的问题,同时在What部分“如何计算数据?”中,分组的条件由用户改为了团队,这在代码中也会相应的体现:
- gameEvents
-
- [... input ...]
-
- [... parse ...]
-
- .apply("AddEventTimestamps", WithTimestamps.of((GameActionInfo i)
-
- -> new Instant(i.getTimestamp())))
-
- .apply("FixedWindowsTeam", Window.<GameActionInfo>into(
-
- FixedWindows.of(Duration.standardMinutes(windowDuration))))
-
- .apply("ExtractTeamScore", new ExtractAndSumScore("team"))
-
- [... output ...];
“AddEventTimestamps”定义了如何从原始数据中抽取EventTime数据,“FixedWindowsTeam”则定义了1小时固定窗口,然后重用了ExtractAndSumScore类,只是将分组的列从用户改成了团队。对于每小时团队分数任务,引入了关于“Where”部分窗口定义的新业务逻辑,但是从代码中可以看到,关于“Where”部分的实现和关于“What”部分的实现是完全独立的,用户只需要新加两行关于“Where”的代码,非常简单和清晰。
前面两个任务均是基于有限数据集的批处理任务,对于排行榜来说,我们同样需要统计用户分数以及每小时团队分数,但是从业务角度希望得到的是实时数据。对于Apache Beam来说,一个相同处理逻辑的批处理任务和流处理任务的唯一不同就是任务的输入和输出,中间的业务逻辑Pipeline无需任何改变。对于当前示例的排行榜数据分析任务,我们不仅希望他们满足和前两个示例相同的业务逻辑,同时也可以满足更定制化的业务需求,例如:
上述两个问题正是通过回答“When”和“How”两个问题来定义用户的数据分析需求。“When”取决于用户希望多常得到计算结果,在回答“When”的时候,基本上可以分为四个阶段:
对于每小时团队得分的流处理任务,本示例希望的业务逻辑为,基于Event Time的1小时时间窗口,按团队计算分数,在一小时窗口内,每5分钟输出一次当前的团队分数,对于迟到的数据,每10分钟输出一次当前的团队分数,在窗口结束2小时后迟到的数据一般不可能会出现,假如出现的话,直接抛弃。“WWWH”表达如下:
在基于Beam SDK的实现中,用户基于“WWWH” Beam Model表示的业务逻辑可以分别独立直接的实现出来:
- gameEvents
- [... input ...]
- .apply("LeaderboardTeamFixedWindows", Window
- .<GameActionInfo>into(FixedWindows.of(
- Duration.standardMinutes(Durations.minutes(60))))
- .triggering(AfterWatermark.pastEndOfWindow()
- .withEarlyFirings(AfterProcessingTime.pastFirstElementInPane()
- .plusDelayOf(Durations.minutes(5)))
- .withLateFirings(AfterProcessingTime.pastFirstElementInPane()
- .plusDelayOf(Durations.minutes(10))))
- .withAllowedLateness(Duration.standardMinutes(120)
- .accumulatingFiredPanes())
- .apply("ExtractTeamScore", new ExtractAndSumScore("team"))
- [... output ...]
LeaderboardTeamFixedWindows对应“Where”定义窗口,Trigger对应“Where”定义结果输出条件,Accumulation对应“How”定义输出结果内容,ExtractTeamScore对应“What”定义计算逻辑。
Apache Beam的Beam Model对无限乱序数据流的数据处理进行了非常优雅的抽象,“WWWH”四个维度对数据处理的描述,非常清晰与合理,Beam Model在统一了对无限数据流和有限数据集的处理模式的同时,也明确了对无限数据流的数据处理方式的编程范式,扩大了流处理系统可应用的业务范围,例如,Event-Time/Session窗口的支持,乱序数据的处理支持等。Apache Flink,Apache Spark Streaming等项目的API设计均越来越多的借鉴或参考了Apache Beam Model,且作为Beam Runner的实现,与Beam SDK的兼容度也越来越高。本文主要介绍了Beam Model,以及如何基于Beam Model设计现实中的数据处理任务,希望能够让读者对Apache Beam项目能够有一个初步的了解。由于Apache Beam已经进入Apache Incubator孵化,所以读者也可以通过官网或是邮件组了解更多Apache Beam的进展和状态。
2. https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101
3. The world beyond batch: Streaming 102
4. https://cloud.google.com/dataflow/blog/dataflow-beam-and-spark-comparison
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。