Apache Beam简介

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的进化历程

Apache Beam是什么

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

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

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

图2. Apache Beam概念架构

图3. Apache Beam生态

Beam将开发和运行进行了剥离和抽象，使得Beam支持多种语言的开发，目前提供了Java和Python的开发。
Apache Beam的核心围绕着4个问题：

• What要计算什么结果?
• Where在哪儿切分数据?
• When什么时候计算数据?
• How 如何持续的修正结果?

关于这4个问题可以参考Streaming 102 批处理之外的流处理世界

Apache Beam抽象模型

计算机最简单的抽象模型是输入+计算+输出。对于数据处理类的应用来说，将计算的部分展开，变成了数据输入+数据集+数据处理+数据输出=数据处理流程。

图4. 数据处理流程

      在Apache Beam中对应如下：

• IO Source/Sink数据输入/输出
  Input和Output对应于Beam中的Source和Sink。
  
  Source从外部数据源读入数据，例如数据库、NoSql、文件系统、消息中间件等。读取完的数据被表示为PCollection。
  
  Sink将处理的结果PCollection输出到外部数据存储中，或者其他的应用系统。

      Beam内置的Java数据源清单：

文件型 消息系统 数据库 Apache Hadoop File System
AvroIO
TextIO
TFRecordIO
XML
Amazon Kinesis
AMQP
Apache Kafka
Google CloudPubSub
JMS
MQTT
Apache Cassandra
Apache Hadoop InputFormat
Apache HBase
Apache Hive(HCatalog)
Apache Solr
Elasticsearch (v2.x)
GoogleBigQuery
Google Cloud Bigtable
Google Cloud Datastore
JDBC
MongoDB

Beam内置的Python数据源清单：

文件型 消息系统 数据库 avroio
textio
tfrecordio 无 Google BigQuery
Google Cloud Datastore

• PCollection数据集

      PCollection是Apache Beam中数据的不可变集合，可以是有限的数据集合也可以是无限的数据集合。

有限数据集，这种一般对应的是批处理，无限数据集数据持续不断的产生，只要系统不停止数据就持续产生下去，无法知道数据在什么时候结束，对应的是流处理。PCollection是将两种数据集统一的一种数据表达方式，PCollection还是一种分布式的数据集，其中的P表示数据集可以被并行处理。

      在Apache Beam中PCollection的特点：

1. 不可变性：PCollection不能被修改
2. 不可随机读取：PCollection只能顺序读取，且只能读取1次。
3. 时间戳：PCollection的数据，每一条都带有时间。

• PTransform数据处理

      PTransform对PCollection进行并行处理，每次处理1条，例如Filter过滤、Groupby分组、Combine统计、Join关联等等，还允许根据业务逻辑编写ParDo。Apache Beam借鉴了函数式编程的不可变性，PTransform不会改变原始的数据集PCollection，而是生成一个新的PCollection。看起来似乎是低效的一种做法，但是带来了容易测试、容易优化、容易并行计算的好处。

• Pipeline 数据处理流水线

      Pipeline将Source PCollection ParDo、Sink组织在一起形成了一个完整的数据处理的过程。

Apache Beam中的函数式编程理念

Apache Beam的编程范式借鉴了函数式编程的概念，从工程和实现角度向命令式妥协。

      编程的领域里有三大流派：函数式、命令式、逻辑式。

      此处的函数不是编程语言中的函数，而是数学中的函数。现代计算的理论模型是图灵机，冯诺依曼体系是图灵机的实现，所以命令式变成本质上是冯诺依曼体系下的操作指令序列。函数式来自于lambda演算，lambda演算与图灵机是等价的，本质上函数也可以完全表达计算。

      C、C++、Java等都属于命令式编程，是从计算机的视角编写代码，告诉计算机操作步骤，计算机执行操作步骤。

      Scala、Haskell等属于函数式编程，是从解决问题的视角出发编写代码，解决问题需要哪些步骤，然后由编译器翻译为计算机可执行的操作步骤。
      
      函数式的最主要的好处主要是不可变性带来的。好处如下：

• 函数即不依赖外部的状态也不修改外部的状态，无论在什么状态下调用函数，只要输入参数是相同的，输出的结果必然是相同的，这样写的代码容易进行推理，不容易出错。这使得单元测试和调试都更容易。

• 由于不共享状态，不会造成资源争用，也就不需要用锁来保护可变状态，也就不会出现死锁，这样可以更好地并发起来，在多处理器、分布式的情况下可以提供更好的并行计算。

      锁是并行计算的天敌，对于分布式计算来说，尤其要注意在不同的机器之间共享资源，因为访问另一个机器的资源需要跨越网络，耗时非常高，会导致整个数据处理的过程不得不处于等待状态。不共享状态意味着不会在机器之间共享资源，可以很好的优化执行策略。所以函数式的思想天然适合于分布式计算。
也许有人会说，函数式的不可变性会带来内存不断重复申请释放的开销，对于Java这样依赖垃圾回收的系统，会带来GC的问题。这个问题需要分开两个角度来看：

• 技术角度

      不可变性确实带来了一些Jvm堆的开销，但是在Flink、Spark这样的系统中，现在已经开始自主管理内存，使用Java的Unsafe的堆外内存，可以避免GC带来的JVM停顿的问题。

• 工程角度

      工程是时间、性能、能力要求之间的妥协。时间是工程进度，性能是软件的执行性能，能力是对开发人员的要求。时间总是越短越好，成本越低，但是要保证软件的质量，很多情况下时间和质量是相互冲突的。性能总是越高越好，越高的性能意味着更大的吞吐能力，需要更巧妙的设计，更好的编码能力，对开发人员更高的要求。
      技术是为业务服务的，随着互联网的逐渐深化，想传统产业渗透，世界处于剧烈的变革之中，业务创新日渐加快，所以时间变得越来越重要，快速实现往往是第一目标，如果有什么方式能够更快的实现业务支持，且能够让软件更可靠，稍微牺牲一点性能是值得的。

全文完！