apache beam
Hadoop及其相关生态系统的出现就像寒武纪爆发的开源工具和框架一样，可以处理大量数据。 但是早期投资大数据的公司发现了一些挑战。 例如，他们需要的工程师不仅具有分布式系统和数据处理方面的专业知识，而且还具有Java和基于JVM的相关语言和工具的专业知识。 另一个问题是，随着新系统似乎支持内存中处理和连续数据处理（流式传输），当时的系统约束在不断发展。
便宜的计算和存储价格以及云的兴起使大量数据的存储和分析民主化。 具有不同技能的人需要更简单，更友好的方式来处理这些数据。 大多数项目都增加了对类似于SQL的语言的支持，但是像数据科学家这样的更高级的用户要求对他们最喜欢的语言，更重要的是他们最喜欢的库和工具（在Java / Scala世界中不一定可用）提供支持。 例如，Python已被确立为数据科学的通用语言，而大多数现代机器学习框架（如Tensorflow和Keras）都以该语言为目标。
Apache Beam是一个统一的编程模型，旨在提供高效且可移植的数据处理管道。 Beam模型在语义上很丰富，并且使用统一的API涵盖批处理和流传输，跑步者可以将其翻译为在多个系统（例如Apache Spark，Apache Flink和Google Dataflow）上执行。
图1. Apache Beam愿景。 图片由Tyler Akidau和Frances Perry 授权使用。
Beam还解决了语言级别的可移植性问题。 但是此功能带来了一系列有趣的设计挑战：
- 我们如何才能以一种特定于各自语言的方式来定义Beam模型（SDK）的特定语言版本？
- 我们如何以与语言无关的方式表示数据和数据转换？
- 我们如何保证隔离执行不同的数据转换？
- 鉴于我们正在谈论不同语言的代码，我们如何控制，跟踪和跟踪作业执行的进度并确保其可靠性？
- 我们如何才能高效地完成所有这些工作？
为了解决所有这些设计问题，Beam创建了一个架构，该架构具有一组称为Portability API的API 。 它们允许使用与协议缓冲区无关的语言来表示数据处理管道，并可以通过gRPC从不同的语言定义和使用一组服务。
图2是Beam可移植性架构的简化视图。
在便携式体系结构（图2）中，管道构造与实际执行环境本身是分离的。 用户使用本地语言的SDK定义数据管道。 该表示形式转换为协议缓冲区版本，然后发送到作业服务器，该服务器使用运行程序将管道转换为本机作业。 作业是在本地系统中通过将Docker容器映像与用户代码以及负责执行用户代码并与一组称为Fn API的服务交互的SDK工具束组合使用的，该服务集合提供了不同的平面来控制用户代码。用户定义函数的执行以及如何在本机系统之间来回传输数据以及如何在容器中进行状态管理和日志记录。
可移植性体系结构的一个很好的结果是用户代码被容器隔离，避免了可能导致此类工作负担的依赖关系冲突。 我们最终可以定义包含不同语言转换的管道，例如，Java管道可以受益于使用一些用Python编写的特定于机器学习的转换，或者Python管道可以利用重用已经编写的现有输入/输出（IO）连接器在Java中。
这是大数据世界中一个令人振奋的新发展：现代RPC和数据序列化框架和容器与现有数据处理引擎一起使用以释放多语种数据处理的功能。 这些还处于初期，这是Apache Beam社区中一项正在进行的工作。 基于这种方法的对新语言（如Go）的支持正在开发中。
