Hadoop 及其相关生态系统的出现，就像是开源工具和框架处理大数据的寒武纪大爆发。但是，早期投资于大数据的公司发现了一些挑战。例如，他们需要具备分布式系统和数据处理专业知识的工程师，还需要具备 Java 和相关的基于 JVM 的语言和工具的专业知识。另一个问题是，当时的系统约束不断发展，因为新的系统不断涌现，以支持内存处理和连续数据处理（流式传输）。
今天的情况并没有太大变化。一旦项目想要迁移到新的大数据执行引擎以利用一些新功能，重用的机会就很低。这些项目中的大多数都具有不同的 API 和许多不兼容的旋钮，从而阻碍了轻松的可移植性和重用。
更便宜的计算和存储价格以及云的兴起，使海量数据的存储和分析大众化。具有不同技能的人们要求更简单、更友好的方式来处理这些数据。大多数项目都增加了对类似 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 创建了一个包含一组 API 的架构，统称为 Portability API。它们允许使用协议缓冲区以与语言无关的方式表示数据处理管道，以及一组可以通过gRPC 从不同语言定义和使用的服务。
图 1. Apache Beam 的愿景。图片由 Tyler Akidau 和 Frances Perry 提供。经 授权 使用。
在可移植架构（图 2）中，管道构建与实际执行环境本身是分离的。用户使用其本机语言的 SDK 定义数据管道。此表示形式被转换为协议缓冲区版本，并发送到作业服务器，该服务器使用运行器将管道转换为本机作业。作业在本机系统中执行，由包含用户代码的 Docker 容器映像和 SDK harness 组成，SDK harness 负责执行用户代码并与一组统称为 Fn API 的服务进行交互，这些服务提供不同的平面来控制用户定义函数的执行以及数据如何在本机系统和容器之间来回传输，以及状态管理和日志记录。
可移植架构的一个 不错的 结果是，用户代码由容器隔离，避免了可能成为此类作业负担的依赖项冲突。我们最终可以定义包含不同语言转换的管道，例如，Java 管道可以受益于使用一些用 Python 编写的特定于机器学习的转换，或者 Python 管道可以利用重用已用 Java 编写的现有输入/输出 (IO) 连接器。
这是大数据世界中一个令人兴奋的新发展：现代 RPC 和数据序列化框架以及容器与现有数据处理引擎一起使用，以释放多语言数据处理的潜力。这些仍然是早期阶段，并且是 Apache Beam 社区正在进行的工作。基于这种方法的新语言（如 Go）的支持正在进行中。如果您对这些想法感兴趣并希望关注并为其进展做出贡献，请加入我们的 Beam 社区，并查看 可移植性网页，并且如果您碰巧要参加 KubeCon Europe，请不要犹豫，来参加 我的演讲，时间是 5 月 2 日星期三，以了解有关 Beam 及其可移植性功能的更多信息。
评论已关闭。