现在，有用的Apache大数据项目似乎每日更新。相比于每次都重新学习的方式，如果可以通过一个统一的API如何呢?

长期开玩笑说Hadoop生态系统是那种如果你不喜欢一个为特定系统的API，等待五分钟，两个新的Apache项目将出现随之而来崭新的API可供学习。

有很多要赶着学习。更糟糕的是，它会导致很多工作迁移到不同的项目仅仅为了保持通用性。“我们已经在暴风雨中实现了流媒体解决方案!现在我们已经快速地重做了!我们目前正在重写pache Flink(或Apex)的核心…我们已经忘记了起初我们试图解决的业务用例。

输入Apache Beam，一个试图统一数据处理框架有核心API的新项目，允许简单的执行引擎之间的移植。

现在,我知道你正在思考抛出另一个API。但Beam有很强的继承性。它来自谷歌并且其研究成果在Millwheel FlumeJava论文上，在多年的运营经验后其出版。它定义了一个有些熟悉的有向无环图数据处理引擎，可以处理无序传递成为常态的情况下的无限数据流，毫无例外。

但是稍等,我听到了你在叫喊。这不是谷歌云数据流吗?是的!也不是。谷歌云数据流是一个完全托管服务,你使用数据流SDK编写应用程序，然后将它们提交到Google的服务器上运行。Apache Beam，在另一方面，仅仅是数据流SDK和一组“运动者”就是SDK元素映射到一个特定的执行引擎。是的，你可以在谷歌云数据流运行Apache Beam应用程序,但你还可以使用Apache Spark或Apache Flink，代码几乎没有变化。

搭乘Apache Beam

关于Apache Beam SDK有四个主要的概念：

1、Pipeline：如果你曾经用过Spark，这有点类似于SparkContext。你所有的操作将开始于调度对象,你会用它来建立数据流从输入源,应用转换,并将结果写入输出下沉。

2、PCollection: PCollections类似于原始的Spark的弹性分布式数据集(RDD),它们包含一个潜在的无限数据流。这些信息都来源于输入源，然后应用转换。

3、Transforms: 一个操作PCollection处理步骤执行数据操作。典型的传递途径可能会在一个输入源有多个转换操作 (例如,将一组日志条目传入的字符串转换成一个键/值对,关键是IP地址和值是日志消息)。Beam SDK附带的一系列标准聚合建成的,当然,你可以定义根据自己的处理需求自定义。

4、I/O sources and sinks：最后，源和汇为你的数据提供输入和输出端点。

让我们来看一个完整的Beam项目。为此，我们将使用Python still-quite-experimental SDK和完整的文本莎士比亚的《李尔王》:

import re

import google.cloud.dataflow as df

p = df.Pipeline('DirectPipelineRunner')

(p

| df.Read('read',

df.io.TextFileSource(

'gs://dataflow-samples/shakespeare/kinglear.txt'))

| df.FlatMap('split', lambda x: re.findall(r'w+', x))

| df.combiners.Count.PerElement('count words')

| df.Write('write', df.io.TextFileSink('./results')))

p.run()

导入正则表达式和数据流库之后，我们构造一个管道对象并将其传递给我们希望使用的送货员(在本例中,我们使用的是DirectPipelineRunner,本地测试运行器)。

从那，我们从一个文本文件读取(位置指向谷歌云存储)和执行两个转换。第一个是flatMap,我们通过一个正则表达式把每个字符串分成词，并返回一个PCollection，其中所有单独的词都来自于“李尔王。”然后我们应用内置的计数操作计数我们的单词。

最后一部分管道将计数操作的结果写入磁盘。一旦管道被定义，它调用run()方法。在这种情况下,管道被提交到本地测试运行器，但通过改变流道类型,我们可以向谷歌云数据流，Flink，Spark或任何其他的可用Apache Beam。

运行拨零

一旦我们准备好应用程序，它可以被提交运行在谷歌云数据流没有任何困难，因为它只是使用数据流SDK。

我们的想法是，跑步者将提供其他执行引擎。Beam目前包括Apache Flink和Apache Spark，分别由DataArtisans和Cloudera维护。这就是当前的一些Beam的褶皱可以发挥的作用，因为数据流模型并不总是容易映射到其他平台上的。

在Beam网站可用的能力矩阵束上显示你的特性，这不被支持。特别地，在代码应用运行在Spark上您需要有额外的制约。只有几行额外的代码，但它不是一个无缝过渡。

很有趣的是Spark 流转目前使用Spark原始的RDD而不是DataFrames。这绕过Spark催化剂优化器,几乎可以肯定，Beam工作运行在Spark上将低于运行一个DataFrame版本。我想当Spark 2.0发布这将会改变，但它绝对是一个限制Spark 运行并且超过了能力矩阵所呈现的所有。

目前，Beam只包括谷歌云数据流的运行，Apache Spark，Apache Flink以及本地出于测试目的的运行。但有谈论为框架新建运行的比如Storm和MapReduce。在MapReduce的情况下,任何运行最终将能够支持一个子集Apache Beam所提供的，因为它只能为底层系统提供工作。

巨大的野心

Apache Beam是一个雄心勃勃的项目。它的最终目标是统一所有的数据处理引擎在一个API下，使它非常简单的迁移。也就是说，Beam应用程序运行在自托管Flink集群到谷歌云数据

人来开发这些应用程序是伟大的。很明显,谷歌花了数年时间精炼Beam模型覆盖大部分我们中的许多人需要实现的数据处理模式。但是请注意，Beam目前是一个Apache“孵化”项目，所以在把它投入生产之前注意练习。Beam值得密切关注是因为它包含更多的运行者——以及Beam SDK更多的语言端口。

原文链接:

http://www.infoworld.com/article/3056172/application-development/apache-beam-wants-to-be-uber-api-for-big-data.html