Apache Beam：下一代的数据处理标准.docx

《Apache Beam：下一代的数据处理标准.docx》由会员分享，可在线阅读，更多相关《Apache Beam：下一代的数据处理标准.docx（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Apache Beam：下一代的数据处理标准Apache Beam （原名 Google DataFlow）是 Google在 2016 年 2 月份贡献给 Apache 基金 会的孵化项目，被认为是继MapReduce、GFS和BigQuery等之后，Google在大数据处理 领域对开源社区的又一贡献。Apache Beam的主要目标是统一批处理和流处理的编程范式, 为无限、乱序，Web-Scale的数据集处理提供简单灵活、功能丰富以及表达能力十分强大 的SDK。Apache Beam项目重点在于数据处理的编程范式和接口定义，并不涉及具体执行 引擎的实现。本文主要介绍Apache Beam的

2、编程范式Beam Model,以及通过BeamSDK如何方便灵活地编写分布式数据处理业务逻辑，希望读者能够通过本文对Apache Beam有初步了解，同时对于分布式数据处理系统如何处理乱序无限数据流的能力有初步认 识。Apache Beam基本架构随着分布式数据处理不断发展，业界涌现出越来越多的分布式数据处理框架，从最早的 Hadoop MapReduce,至ij Apache Spark Apache Storm 以及更近的 Apache Flink Apache Apex等。新的分布式处理框架可能带来更高性能，更强大功能，更低延迟等，但用户切换 到新分布式处理框架的代价也非常大：需要学习一

3、个新的数据处理框架，并重写所有业务逻 辑。解决这个问题的思路包括两部分，首先，需要一个编程范式，能够统一规范分布式数据 处理的需求，例如统一批处理和流处理的需求。其次，生成的分布式数据处理任务应该能够 在各个分布式引擎上执行，用户可以自由切换执行引擎与执行环境。Apache Beam正是为 了解决以上问题而提出的。它主要由Beam SDK和Beam Runner组成，Beam SDK定义 了开发分布式数据处理任务业务逻辑的API接口，生成的的分布式数据处理任务Pipeline 交给具体的Beam Runner执行引擎。Apache Beam目前支持的API接口由Java语言实现, Python

4、版本的API正在开发之中。它支持的底层执行引擎包括Apache FlinkApache Spark 以及 Google Cloud Platform,止匕夕卜 Apache Storm、Apache Hadoop Apache Gearpump 等执行引擎的支持也在讨论或开发中。其基本架构如图1。图1 Apache Beam架构图需要注意的是，虽然Apache Beam社区非常希望所有的Beam执行引擎都能够支持Beam SDK定义的功能全集，但在实际实现中可能并不一定。例如，基于MapReduce的Runner 显然很难实现和流处理相关的功能特性。目前Google DataFlow Clou

5、d是对Beam SDK功 能集支持最全面的执行引擎，在开源执行引擎中，支持最全面的则是Apache Flink。Beam ModelBeam Model指Beam的编程范式，即Beam SDK背后的设计思想。在介绍Beam Model 前，先介绍下Beam Model要处理的问题域与基本概念。数据。要处理的数据一般可以分为两类，有限的数据集和无限的数据流。对于前者,比如一个HDFS中的文件，一个HBase表等，特点是数据提前已经存在，一般也己经 持久化，不会突然消失。而无限的数据流，比如Kafka中流过来的系统日志流，或是 从Twitter API拿到的Twitter流等，这类数据的特点是动态

6、流入，无穷无尽，无法全部 持久化。一般来说，批处理框架的设计目标是用来处理有限的数据集，流处理框架的 设计目标是用来处理无限的数据流。有限的数据集可以看做无限数据流的一种特例， 但是从数据处理逻辑角度，这两者并无不同之处。例如，假设微博数据包含时间戳和 转发量，用户希望按照每小时的转发量统计总和，此业务逻辑应该可以同时在有限数 据集和无限数据流上执行，并不应该因为数据源的不同而对业务逻辑的实现产生任何 影响。 时间。Process Time是指数据进入分布式处理框架的时间，而Event-Time则是指 数据产生的时间。这两个时间通常是不同的，例如，对于一个处理微博数据的流计算 任务，一条201

7、6-06-01-12:00:00发表的微博经过网络传输等延迟可能在 2016060112:01:30才进入到流处理系统中。批处理任务通常进行全量的数据计算， 较少关注数据的时间属性，但是对于流处理任务来说，由于数据流是无穷无尽的，无 法进行全量计算，通常是对某个窗口中的数据进行计算。对于大部分的流处理任务来 说，按照时间进行窗口划分，可能是最常见的需求。 乱序。对于流处理框架的数据流来说，其数据的到达顺序可能并不严格按照 Event-Time的时间顺序。如果基于Process Time定义时间窗口，数据到达的顺序就是 数据的顺序，因此不存在乱序问题。但对于基于Event Time定义的时间窗口

8、来说，可 能存在时间靠前的消息在时间靠后的消息后到达的情况，这在分布式的数据源中可能 非常常见。对于这种情况，如何确定迟到数据，以及对于迟到数据如何处理通常是很 棘手的问题。Beam Model处理的目标数据是无限的时间乱序数据流，不考虑时间顺序或是有限的数据集 可看做是无限乱序数据流的一个特例。Beam Model从下面四个维度归纳了用户在进行数据 处理的时候需要考虑的问题： Whato如何对数据进行计算？例如，Sum、Join或是机器学习中训练学习模型等。 在Beam SDK中由Pipeline中的操作符指定。 Where。数据在什么范围中计算？例如，基于Process-Time的时间窗口

9、，基于 Event-Time的时间窗口、滑动窗口等。在BeamSDK中由Pipeline中的窗口指定。 Wheno何时将计算结果输出？例如，在1小时的Event-Time时间窗口中，每隔1 分钟，将当前窗口计算结果输出。在BeamSDK中由Pipeline中的Watermark和触发 器指定。 Howo迟到数据如何处理？例如，将迟到数据计算增量结果输出，或是将迟到数据 计算结果和窗口内数据计算结果合并成全量结果输出。在Beam SDK中由 Accumulation 指定。Beam Model将“WWWH”四个维度抽象出来组成了 Beam SDK,用户在基于它构建数据处 理业务逻辑时，在每一步只

10、需要根据业务需求按照这四个维度调用具体的API即可生成分 布式数据处理Pipeline,并提交到具体执行引擎上。“WWWH”四个维度的抽象仅关注业务逻 辑本身，和分布式任务如何执行没有任何关系。Beam SDK不同于Apache Flink或是Apache Spark, Beam SDK使用同一套API表示数据源、输出目 标以及操作符等。下面介绍4个基于Beam SDK的数据处理任务，通过它们，读者可以了 解Beam Model是如何统一灵活地描述批处理和流处理任务的，这3个任务用来处理手机 游戏领域的统计需求，包括： 用户分数：批处理任务，基于有限数据集统计用户分数。 每小时团队分数：批处理

11、任务，基于有限数据集统计每小时，每个团队的分数。 排行榜：流处理任务，2个统计项，每小时每个团队的分数以及用户实时的历史总得分数。下面基于Beam Model的“WWWH”四个维度，分析业务逻辑，并通过代码展示如何通过 BeamSDK实现“WWWH”四个维度的业务逻辑。用户分数统计每个用户的历史总得分数是一个非常简单的任务，在这里我们简单地通过一个批处理任 务实现，每次需要新的用户分数数据，重新执行一次这个批处理任务即可。对于用户分数任 务，“WWWH”四维度分析结果如下：维度要求What分数累加.按用户分组。Where默认,全局窗口。When默认,窗口内全部数据到齐后。How默认,不会出现迟

12、到数据。通过“WWWH”的分析，对于用户分数这个批处理任务，通过Beam Java SDK实现的代码如 下所示：Java代码1. gameEvents2. . . . input 3. parse 4. .apply(nExtractuserScore,new ExtractAndSumScore(user)5. output .;ExtractAndSumScore实现了“What”中描述的逻辑，即按用户分组然后累加分数，其代码如 下：Java代码1. gameinfo2. apply(MapElements, via(GameActionlnfo glnfo) - KV. of (glnf

13、o.getKey( fiel d ), glnfo.getScore()3. withOutputType(TypeDescriptors. kvs(TypeDescriptors. strings()r TypeDescrip tors , integers()4. .apply(Sum. integersPerKey();通过Map日ements确定Key与Value分别是用户与分数，然后Sum定义按key分组，并 累加分数。Beam支持将多个对数据的操作合并成一个操作，这样不仅可以支持更清晰的业 务逻辑实现，同时也可以在多处重用合并后的操作逻辑。每小时团队分数按照小时统计每个团队的分数，

14、获得最高分数的团队可能获得奖励，这个分析任务增加了对 窗口的要求，不过我们依然可以通过一个批处理任务实现，该任务的“WWWH”四维度分析 如下：维度要求What分数累加.按团队分组。Where基于Event-Time固定的1小时时间窗 When默认,窗口内全部数据到齐后。How默认,不会出现迟到数据。相对于第一个用户分数任务，只是在Where部分回答了“数据在什么范围中计算？ ”的问题, 同时在What部分“如何计算数据？ ”中，分组的条件由用户改为了团队，这在代码中也会相 应体现：Java代码1. gameEvents2. . . . input 3. parse .apply(AddEve

15、ntTimestamps, WithTimestamps.of(GameActionln fo i)4. - new Instant(i.getTimestamp()5. , apply(FixdWindowsTam”, Window.into(FixedWindows.of(Duration.standardMinutes(windowDuratio n)6. .apply(nExtractTeamScorenrnew ExtractAndSumScore(nteamn)7. output .;“AddEventTimestamps”定义了如何从原始数据中抽取EventTime数据，“Fix

16、edWindowsTearrT则定义了 1 小时固定窗口，然后重用了 ExtractAndSumScore类，只 是将分组的列从用户改成了团队。对于每小时团队分数任务，引入了关于“Where”部分窗口 定义的新业务逻辑，但是从代码中可以看到，关于“Where”部分的实现和关于“What”部分的 实现是完全独立的，用户只需要新加两行关于“Where”的代码，非常简单和清晰。排行榜前面两个任务均是基于有限数据集的批处理任务，对于排行榜来说，我们同样需要统计用户 分数以及每小时团队分数，但是从业务角度希望得到的是实时数据。对于Apache Beam来 说，一个相同处理逻辑的批处理任务和流处理任务的唯

17、一不同就是任务的输入和输出，中间 的业务逻辑Pipeline无需任何改变。对于当前示例的排行榜数据分析任务，我们不仅希望他 们满足和前两个示例相同的业务逻辑，同时也可以满足更定制化的业务需求，例如： 流处理任务相对于批处理任务，一个非常重要的特性是，流处理任务可以更加实时地返回计算结果，例如计算每小时团队分数时，对于一小时的时间窗口，默认是在一 小时的数据全部到达后，把最终的计算结果输出，但是流处理系统应该同时支持在一 小时窗口只有部分数据到达时，就将部分计算结果输出，从而使得用户可以得到实时 的分析结果。 保证和批处理任务一致的计算结果正确性。由于乱序数据的存在，对于某一个计算窗口，如何确定

18、所有数据是否到达(Watermark) ?迟到数据如何处理？处理结果如何 输出、总量、增量、并列？流处理系统应该提供机制保证用户可以在满足低延迟性能 的同时达到最终的计算结果正确性。上述两个问题正是通过回答“When”和“How”两个问题来定义用户的数据分析需求。“When” 取决于用户希望多久得到计算结果，在回答“When”的时候，基本上可以分为四个阶段： Earlyo在窗口结束前，确定何时输出中间状态数据。 On-Timeo在窗口结束时，输出窗口数据计算结果。由于乱序数据的存在，如何判断窗口结束可能是用户根据额外的知识预估的，且允许在用户设定的窗口结束后出现 迟到的属于该窗口的数据。 La

19、teo在窗口结束后，有迟到的数据到达，在这个阶段，何时输出计算结果。 FinaL能够容忍迟到的最大限度，例如1小时。到达最后的等待时间后，输出最终的计算结果，同时不再接受之后的迟到数据，清理该窗口的状态数据。对于每小时团队得分的流处理任务，本示例希望的业务逻辑为，基于Event Time的1小时 时间窗口，按团队计算分数，在一小时窗口内，每5分钟输出一次当前的团队分数，对于迟 到的数据，每10分钟输出一次当前的团队分数，在窗口结束2小时后迟到的数据一般不可 能会出现，假如出现的话，直接抛弃。“WWWH”表达如下：维度要求What分数累加.按团队分组。Where基于Event-Time固定的1小

20、时时间窗 When Early:基于Processing Time 每5分钟一次。 On-time:当收到的Watermark 大于窗口结束时间时。 Late:基于Processing Time每 10分钟一次。 Final:当收到的Watermark大 干窗口结束时间2小时后时。How输出到当前时间总量计算结果在基于Beam SDK的实现中，用户基于“WWWH” Beam Model表示的业务逻辑可以独立直 接地实现：Java代码1. gameEvents2. . . . input 3. apply(nLeaderboardTeamFixedWindowsnr Window4. .into

21、(FixedWindows.of(5. Duration.standardMinutes(Durations.minutes(60)6. triggering(AftrWatrmark.pastEndOfWindow(), withEarlyFirings(AfterProcessingTime.pastFirstElementInPane 07. .plusDelayOf(Durations.minutes(5), withLateFirings(AftrProcessingTime.pastFirstElemnt工nPan08. .plusDelayOf(Durations.minutes

22、(10)9. .withAllowedLateness(Duration.standardMinutes(120)1.1, accumulatingFiredPanes()13 . .apply(HExtractTeamScoreHrnew ExtractAndSumScore(nteamn)14 .output LeaderboardTeamFixedWindows 对应“Where”定义窗 口，Trigger 对应“Where”定义结果输 出条件，Accumulation对应“How”定义输出结果内容，ExtractTeamScore对应What”定义 计算逻辑。总结Apache Beam

23、的Beam Model对无限乱序数据流的数据处理进行了非常优雅的抽象， “WWWH”四个维度对数据处理的描述，十分清晰与合理，Beam Model在统一了对无限数 据流和有限数据集的处理模式的同时丁也明确了对无限数据流的数据处理方式的编程范式, 扩大了流处理系统可应用的业务范围。Apache Flink Apache Spark Streaming等项目的 API设计均越来越多地借鉴或参考了 Apache Beam Model,且作为Beam Runner的实现， 与Beam SDK的兼容度也越来越高。此外，由于Apache Beam已经进入Apache Incubator 孵化，读者也可以通过官网或是邮件组了解更多Apache Beam的进展和状态。