1.Beam前世今生

分布式数据处理发展迅猛—> 新分布式数据处理技术越来越多 —>Hadoop MapReduce，Apache Spark，Apache Storm，Apache Flink，Apache Apex —>新技术高性能 , 受欢迎,人们喜新厌旧 —> 业务的迁移 —>迁移条件: 学习新技术,重写业务逻辑—> 懒 —> 怎么办 ??

Apache Beam 应运而生

继MapReduce，GFS和BigQuery之后，Google在大数据处理领域对开源社区的又一个超级大的贡献

Apache Beam前身是Google Dataflow SDK，DataFlow是谷歌的提供大数据计算平台。在DataFlow之前，谷歌的批处理和流处理(流计算，实时处理)使用了不同系统，流处理有MillWheel、FlumeJava等，批处理有MapRedude，不同的平台使用了不同的Api，无疑提升了开发的难度，所以DataFlow横空出世，提出了一套统一批处理和流处理的模型。

通过上图，我们可以很清晰的看到整个技术的发展流向；一部分是谷歌派系，另一部分则是Apache派系。在开发大数据应用时，我们有时候使用谷歌的框架，API，类库，平台等，而有时候我们则使用Apache的，比如：HBase，Flink，Spark等。而我们要整合这些资源则是一个比较头疼的问题，Apache Beam 的问世，整合这些资源提供了很方便的解决方案。

那Apache Beam到底是什么呢？

Beam官网文档

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

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

2.应用场景

Beam 高版本改进了用户体验，重点在于框架跨环境的无缝移植能力，这些执行环境包括执行引擎、操作系统、本地集群、云端以及数据存储系统。Beam 的其他特性还包括如下几点：

<1>API 稳定性和对未来版本的兼容性。

<2>有状态的数据处理模式，高效的支持依赖于数据的计算。

<3>支持用户扩展的文件系统，支持 Hadoop 分布式发文件系统及其他。

<4>提供了一个度量指标系统，可用于跟踪管道的执行状况。

以下为应用场景的几个例子：

（1）Beam 可以用于 ETL Job 任务

Beam 的数据可以通过 SDKs 的 IO 接入，通过管道可以用后面的 Runners 做清洗。

（2）Beam 数据仓库快速切换、跨仓库

由于 Beam 的数据源是多样 IO，所以用 Beam 可以快速切换任何数据仓库。

（3）Beam 计算处理平台切换、跨平台

Runners 目前提供了 3-4 种可以切换的平台，随着 Beam 的强大应该会有更多的平台提供给大家使用。

3.运行流程

Apache Beam 大体运行流程分成三大部分，如图所示：（参考Apache Beam 实战指南之基础入门）

运行流程

（1）Modes

Modes 是 Beam 的模型或叫数据来源的 IO，它是由多种数据源或仓库的 IO 组成，数据源支持批处理和流处理。

（2）Pipeline

Pipeline 是 Beam 的管道，所有的批处理或流处理都要通过这个管道把数据传输到后端的计算平台。这个管道现在是唯一的。数据源可以切换多种，计算平台或处理平台也支持多种。需要注意的是，管道只有一条，它的作用是连接数据和 Runtimes 平台。

（3）Runtimes

Runtimes 是大数据计算或处理平台，目前支持 Apache Flink、Apache Spark、Direct Pipeline 和 Google Clound Dataflow 四种。其中 Apache Flink 和 Apache Spark 同时支持本地和云端。Direct Pipeline 仅支持本地，Google Clound Dataflow 仅支持云端。除此之外，后期 Beam 国外研发团队还会集成其他大数据计算平台。由于谷歌未进入中国，目前国内开发人员在工作中对谷歌云的使用应该不是很多，主要以前两种为主。

4.Beam Model 及其工作流程

Beam的编程模型是Google的工程师从MapReduce, FlumeJava和Millwheel等多个大数据处理项目中抽象出来的，如果想详细了解可以参考相关的论文（Streaming 101，Streaming 102 和The Dataflow Model）。

Beam Model 指的是 Beam 的编程范式，即 Beam SDK 背后的设计思想。在介绍 Beam Model 之前，先简要介绍一下 Beam Model 要处理的问题域与一些基本概念。

1.数据源类型。分布式数据来源类型一般可以分为两类，有界的数据集和无界的数据流。有界的数据集，比如一个 Ceph 中的文件，一个 Mongodb 表等，特点是数据已经存在，数据集有已知的、固定的大小，一般存在磁盘上，不会突然消失。而无界的数据流，比如 Kafka 中流过来的数据流，这种数据的特点是数据动态流入、没有边界、无法全部持久化到磁盘上。Beam 框架设计时需要针对这两种数据的处理进行考虑，即批处理和流处理。

2.时间。分布式框架的时间处理有两种，一种是全量计算，另一种是部分增量计算。举个栗子：例如玩“王者农药”游戏，游戏的数据需要实时地流向服务器，掉血情况会随着时间实时变化，但是排行榜的数据则是全部玩家在一定时间内的排名，例如一周或一个月。Beam 针对这两种情况都设计了对应的处理方式。

3.乱序。对于流处理框架处理的数据流来说，数据到达大体分两种，一种是按照 Process Time 定义时间窗口，这种不用考虑乱序问题，因为都是关闭当前窗口后才进行下一个窗口操作，需要等待，所以执行都是有序的。而另一种，Event Time 定义的时间窗口则不需要等待，可能当前操作还没有处理完，就直接执行下一个操作，造成消息顺序处理但结果不是按顺序排序了。例如我们的订单消息，采用了分布式处理，如果下单操作所属服务器处理速度比较慢，而用户支付的服务器速度非常快，这时最后的订单操作时间轴就会出现一种情况，下单在支付的后面。对于这种情况，如何确定迟到数据，以及对于迟到数据如何处理通常是很麻烦的事情。

Beam Model 处理的目标数据是无界的时间乱序数据流，不考虑时间顺序或有界的数据集可看做是无界乱序数据流的一个特例。Beam Model 从下面四个维度归纳了用户在进行数据处理的时候需要考虑的问题：

What。如何对数据进行计算？例如，机器学习中训练学习模型可以用 Sum 或者 Join 等。在 Beam SDK 中由 Pipeline 中的操作符指定。

Where。数据在什么范围中计算？例如，基于 Process-Time 的时间窗口、基于 Event-Time 的时间窗口、滑动窗口等等。在 Beam SDK 中由 Pipeline 的窗口指定。

When。何时输出计算结果？例如，在 1 小时的 Event-Time 时间窗口中，每隔 1 分钟将当前窗口计算结果输出。在 Beam SDK 中由 Pipeline 的 Watermark 和触发器指定。

How。迟到数据如何处理？例如，将迟到数据计算增量结果输出，或是将迟到数据计算结果和窗口内数据计算结果合并成全量结果输出。在 Beam SDK 中由 Accumulation 指定。

Beam Model 将“WWWH”四个维度抽象出来组成了 Beam SDK，用户在基于 Beam SDK 构建数据处理业务逻辑时，每一步只需要根据业务需求按照这四个维度调用具体的 API，即可生成分布式数据处理 Pipeline，并提交到具体执行引擎上执行。“WWWH”四个维度只是从业务的角度看待问题，并不是全部适用于自己的业务。做技术架构一定要结合自己的业务使用相应的技术特性或框架。Beam 做为“一统”的框架，为开发者带来了方便。

5.Beam SDKs

Beam SDK 给上层应用的开发者提供了一个统一的编程接口，开发者不需要了解底层的具体的大数据平台的开发接口是什么，直接通过 Beam SDK 的接口就可以开发数据处理的加工流程，不管输入是用于批处理的有界数据集，还是流式的无界数据集。对于这两类输入数据，Beam SDK 都使用相同的类来表现，并且使用相同的转换操作进行处理。Beam SDK 拥有不同编程语言的实现，目前已经完整地提供了 Java 的 SDK，Python 的 SDK 还在开发中，相信未来会发布更多不同编程语言的 SDK。

Beam 2.0 的 SDKs 目前有：

Amqp：高级消息队列协议。

Cassandra：Cassandra 是一个 NoSQL 列族（column family）实现，使用由 Amazon Dynamo 引入的架构方面的特性来支持 Big Table 数据模型。

Elasticesarch：一个实时的分布式搜索引擎。

Google-cloud-platform：谷歌云 IO。

Hadoop-file-system：操作 Hadoop 文件系统的 IO。

Hadoop-hbase：操作 Hadoop 上的 Hbase 的接口 IO。

Hcatalog：Hcatalog 是 Apache 开源的对于表和底层数据管理统一服务平台。

Jdbc：连接各种数据库的数据库连接器。

Jms：Java 消息服务（Java Message Service，简称 JMS）是用于访问企业消息系统的开发商中立的 API。企业消息系统可以协助应用软件通过网络进行消息交互。JMS 在其中扮演的角色与 JDBC 很相似，正如 JDBC 提供了一套用于访问各种不同关系数据库的公共 API，JMS 也提供了独立于特定厂商的企业消息系统访问方式。

Kafka：处理流数据的轻量级大数据消息系统，或叫消息总线。

Kinesis：对接亚马逊的服务，可以构建用于处理或分析流数据的自定义应用程序，以满足特定需求。

Mongodb：MongoDB 是一个基于分布式文件存储的数据库。

Mqtt：IBM 开发的一个即时通讯协议。

Solr：亚实时的分布式搜索引擎技术。

xml：一种数据格式。

6.Beam Pipeline Runners

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 2.0 的 Runners 框架如下：

Apex

诞生于 2015 年 6 月的 Apache Apex，其同样源自 DataTorrent 及其令人印象深刻的 RTS 平台，其中包含一套核心处理引擎、仪表板、诊断与监控工具套件外加专门面向数据科学家用户的图形流编程系统 dtAssemble。主要用于流处理，常用于物联网等场景。

Direct-java

本地处理和运行 runner。

Flink_2.10

Flink 是一个针对流数据和批数据的分布式处理引擎。

Gearpump

Gearpump 是一个基于 Akka Actor 的轻量级的实时流计算引擎。如今流平台需要处理来自各种移动端和物联网设备的海量数据，系统要能不间断地提供服务，对数据的处理要能做到不丢失不重复，对各种软硬件错误能平滑处理，对用户的输入要能实时响应。除了这些系统层面的需求外，用户层面的接口还要能做到丰富而灵活，一方面，平台要提供足够丰富的基础设施，能最简化应用程序的编写；另一方面，这个平台应提供具有表现力的编程 API，让用户能灵活表达各种计算，并且整个系统可以定制，允许用户选择调度策略和部署环境，允许用户在不同的指标间做折中取舍，以满足特定的需求。Akka Actor 提供了通信、并发、隔离、容错的基础设施，Gearpump 通过把抽象层次提升到 Actor 这一层，屏蔽了底层的细节，专注于流处理需求本身，能更简单而又高效地解决上述问题。

Dataflow

2016 年 2 月份，谷歌及其合作伙伴向 Apache 捐赠了一大批代码，创立了孵化中的 Beam 项目（最初叫 Apache Dataflow）。这些代码中的大部分来自于谷歌 Cloud Dataflow SDK——开发者用来写流处理和批处理管道（pipelines）的库，可在任何支持的执行引擎上运行。当时，支持的主要引擎是谷歌 Cloud Dataflow。

Spark

Apache Spark 是一个正在快速成长的开源集群计算系统。Apache Spark 生态系统中的包和框架日益丰富，使得 Spark 能够执行高级数据分析。Apache Spark 的快速成功得益于它的强大功能和易用性。相比于传统的 MapReduce 大数据分析，Spark 效率更高、运行时速度更快。Apache Spark 提供了内存中的分布式计算能力，具有 Java、Scala、Python、R 四种编程语言的 API 编程接口。