谷歌军用卫星舆图_谷歌舆图兵舰（谷歌卫星军用地图）

　　作者｜足下编译

　　编辑｜Tina

　　1月10日，Apache软件基金会宣布，Apache Beam成功孵化，成为该基金会的一个新的顶级项目。Google开源的Beam恰逢其时，在各种大数据处置惩罚处罚引擎百花齐放时推出一个统一编程框架，统一批处置惩罚处罚和流处置惩罚处罚，适配各种处置惩罚处罚引擎，将它们推入配景，占领进口。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，先要说说谷歌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模型的偏向成长。

那大家可以奈何与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定义的时间窗口来说，或许存在时间靠前的新闻在时间靠后的新闻之后达到的情况，这在分布式的数据源中或许很是常见。对于这种情况，奈何确定迟到数据，以及对于迟到数据如何处理处罚每每是很棘手的标题。

Beam模型处置惩罚处罚的目的数据是无限的时间乱序数据流，不考虑时间序次或是有限的数据集可看做是无限乱序数据流的一个特例。

如上图，其中虚线是最理想的，表示处置惩罚处罚时间和事故时间是类似的，红线是现实上的线，也叫水位线（Watermark），它日常是通过启发式算法算出来的。

接下来从标题中抽象出四个详细的标题：

A：What are you computing，对数据的处置惩罚处罚是哪种典范，数据转换、聚合或许是两者都有。例如，Sum、Join或是机器进修中操练进修模型等。在Beam SDK中由Pipeline中的利用符指定。如图：

B：Where in event time，数据在什么局限中打定？例如，基于Process-Time的时间窗口？基于Event-Time的时间窗口？滑动窗口等等。在Beam SDK中由Pipeline中的窗口指定：

C：When in processing time，何时将打定成果输出？在这里引入了一个Trigger机制，Trigger决定何时将打定成果发射出去，发射太早会丢失一部门数据，损失正确性，发射太晚会导致延长变长，并且会囤积大量数据，何时Trigger是由水位线来决定的，在Beam SDK中由Pipeline中的水位线和触发器指定。

D：How do refinements relate，迟到数据如何处理处罚？例如，将迟到数据打定增量成果输出，或是将迟到数据打定成果和窗口内数据打定成果合并成全量成果输出。在Beam SDK中由Accumulation指定。

Beam模型将”WWWH“四个维度抽象出来组成了Beam SDK，用户在基于Beam SDK构建数据处置惩罚处罚营业逻辑时，每一步只须要凭据营业需求按照这四个维度挪用详细的API即可生因素布式数据处置惩罚处罚Pipeline，并提交到详细实施引擎上实施。“WWWH”四个维度的抽象仅仅关注营业逻辑自己，和分布式使命奈何实施没有任何干系。

　　友商的见解

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

　　写在最后

“在谷歌公司里已经没人再操纵MapReduce了”！谷歌云的紧张负责人Mete Atamel如是说。谷歌坚信Apache Beam就是数据批处置惩罚处罚和流处置惩罚处罚的未来。Apache Beam的模型对无限乱序数据流的数据处置惩罚处罚进行了很是优雅的抽象，“WWWH”四个维度对数据处置惩罚处罚的描摹很是清晰与合理，Beam模型在统一了对无限数据流和有限数据集的处置惩罚处罚模式的同时，也大白了对无限数据流的数据处置惩罚处罚方式的编程范式，扩大了流处置惩罚处罚系统可应用的营业局限。随着Apache Beam的成功孵化，随着越来越多的编程语言可用、越来越多的分布式数据处置惩罚处罚平台支撑Beam模型，我们的确可以尽情畅想精致的未来。

　　今日荐号

　　大数据杂谈

　　我们专注大数据和机器进修，天天发布高质量文章，技术案例等原创干货绵绵不断。更有社群微讲堂，也渴望你能从这里分享前沿技术，互换深度思索。

　　微信ID:BigdataTina2016

　　今日荐文

　　点击下方图片即可阅读

　　百度第三代 Spider 背后的万亿量级实时数据处置惩罚处罚系统