本文要点
Apache Beam 是一种统一了批处理和流处理的编程模型，在今年年初成为了 Apache 软件基金会的顶级项目。Beam 最初是作为Google Cloud Platform 中 DataFlow 服务的一个组件。自去年年初以来，Beam 在被搜索频次上逐渐取得了稳步增长，其社区电子邮件的分发列表也在同步增长。对Beam 的搜索主要针对一些反复出现的问题，这些问题被频繁提及。
对于选用Beam 的理由，有一系列的帖子、技术演讲和会议讨论已经给出了解释。其中，Beam 的可移植性和良好的发展前途，使得Beam 比其它任何新的数据流水线项目都更胜任于普遍存在并不断增加的流数据，这也是Beam 项目被广泛采用的最重要动机之一。针对Beam 的编程模型以及为什么要选用Beam 构建新数据流水线等问题，InfoQ 对Beam 项目管理委员会（PMC，Project Management Committee）顾问和Google DataFlow 工程师 Frances Perry 进行了一次深度采访。
InfoQ：从理念上看，如果仅是根据 Beam 的语义和概念性术语，感觉 Beam 在考虑数据流水线问题时，应是采用了一种“数据分析优先”的方法。您能从 Beam 的核心理念和语言与之前产品的差异上，介绍一下对 Beam 的考虑过程与设计吗？
Frances Perry：我很喜欢“Beam”一词！Beam 在设计上就是要将用户的数据和程序与底层运行时的细节分离开来。这意味着用户在使用 Beam 时，可以聚焦于数据的属性（受限的，或是非受限的？还是潜在无序的？），以及想要在数据上执行的算法（求和、连接、过滤、直方图等）。用户无需指定底层运行时的相关信息，例如，应如何对数据进行分片以获得更好的性能，当前数据延迟情况如何等。这的确十分重要，因为上述事情并非一成不变的。数据、代码和环境会发生改变，这会使最为细致的手工调优也可能失败。
InfoQ：Beam 核心项目主要关注于对 Python API 的完全支持。即便是在 Beam 开源前，Python API 是否一直是项目的焦点？提供对 Python 的支持，对底层的 Java API 有着怎样的影响？
Frances Perry： Python 一直是 Beam 项目的关注点。我们一直谨记需要去满足开发人员的最新需求，尤其是对各种语言的喜好。在项目早期，我们得到的经验教训就是，如果你力图在多种语言上证实同一系列的概念，这就变成了一个十分微妙的平衡协调问题。你需要做抽象，以对齐跨语言的特性，否则在细微差异的追踪、概念的理解等问题上完全是一场噩梦。但是从另一方面看，需要让开发人员认为每个 SDK 是原生的。Python 开发人员想要类似于 Python 那样的 API，而非看上去像是由 Java 开发人员编写的。
InfoQ：Beam 在不断的成熟，添加了对更多处理后端的支持，您以及其他的项目主管是如何看待这一过程中所存在的长期挑战？
Frances Perry： Beam 是一个“胶水”项目，其核心抽象表达了这样一种理念，就是通过让多个复杂项目共同工作的方式，将各个项目连接在一起。这样的多点集成不仅是一种关键能力，而且表现了一种真实的挑战。我们自项目起始时，就将 Beam 设计为可扩展的。我们一开始就给出了多个 Runner（译者注：Runner 的中文可理解为“执行引擎”或“计算引擎”）这一理念，此后我们也认识到需要提供针对多种 SDK、多种 IO 连接器和多种文件系统的选项。但是正如大家都知道的，没有必要为概化一件事情而构建一个 API，正确的做法是给出多个工作实现。虽然多个 Runner 所做的事情非常相似，但是各个 Runner 实现上略有不同。因此，解决如何构建能在可移植性和表现力间取得平衡的正确抽象这一问题并非易事。这正是各个社区中的大众经验的最有价值之处。
InfoQ：Beam 所支持的后端在不断的增加，这对 Beam 核心抽象的可用性提出了挑战。例如，在 Beam 的核心语义中，各处理引擎间存在着重叠的特性集。那么该项目是否存在着扇出（Fan-out）风险？
Frances Perry：我们多次听说了这样的担心，即 Beam 将最终演化为各种后端引擎的最小公共特性集，进而变为一个索然无味的项目。但是，我们意在使 Beam 不仅担当所有引擎的功能交集（这个交集规模非常有限！），而且成为它们功能的合集（即使是这些功能中的“无用之物”）。不仅如此，Beam 力图立于数据处理的潮头，不仅将功能推送到运行时引擎中，而且从运行时引擎中拉取回模式。 Keyed State 就是一个很好的例子，虽然它是一个存在于各种引擎中的功能，并提供了有趣的和常见的用例，但是它先前是不能在 Beam 中表达的。因此，我们最近扩展了 Beam 模型，并根据 Beam 的设计原则，加入了该功能的一个实现版本。反过来说，我们希望 Beam 将同样会对各种引擎的发展路线图产生应用。例如，Flink 的 DataStreams 的语义就受到了 Beam 模型（née DataFlow）的影响。
InfoQ：现在 Beam 已经具有了第一个稳定版本。对于那些已采用了颇具规模的 Spark、FLink 或 Hadoop 流水线的企业，什么能促使它们从现有的系统迁移到使用 Beam？
Frances Perry：我认为相对于其它系统而言，有三个原因导致 Beam 颇为引人关注。
统一的批处理和流处理：虽然有部分系统也同时支持批处理和流处理，但是这些系统通常是通过独自的 API 分别实现的。在 Beam 中，批处理和流处理处理在机制上是相同的，只是在延迟、完整性和代价上存在着一些差异。在 Beam 中，不存在从批处理转到流处理的陡峭学习和重写曲线。因此，如果用户今天编写了一个批处理流水线，但是第二天就需要对延迟做更改，这在 Beam 中是非常易于调整的。我们可以从 Mobile Gaming 例子中看到这一过程。
提升了抽象等级的 API： Beam 的 API 聚焦于捕获用户数据和逻辑的属性，而非泄漏低层运行时的细节。这不仅是可移植性（参见下一特性）的关键所在，而且还赋予了运行时大量灵活的执行方式。大部分 Runner 已经做到了相当基本的 ParDo Fusion（也称为函数组合）之类的优化。对部分 runner，其它的优化依然正在实现中。例如，Beam 的 Source API 是特定构建的，以避免过度声明流水线中的数据切片。相反，他们赋予 Runner 以正确的钩子（Hook），动态地重平衡工作。这从根本上消除了低性能的数据切片问题，会在性能上产生很大的差异。总而言之，如果我们在 Runner 中构建了更多的智能，我们就能更好地从底层细节中抽身出来。当数据、代码和环境发生变化时，即便是最为细致的手工调优也会发生失败。
运行时之间的可移植性：由于在 Beam 中数据的形状和运行时的需求这两者基本上是分离的，同一流水线可以用多种方式运行。这意味着，当用户不得不从本地部署（on-premise）迁移到云端时，或是不得不从一个经验证运行良好的系统迁移到一个最新的环境上时，不必重写代码。用户可以很容易地从各种选项中做出选取，找出最适合当前工作需求的、综合考虑了环境及性能因素的系统。并可综合地考虑使用开源 Runner 在本地部署中处理敏感数据，并在云管理的服务上处理其它的数据。
InfoQ：您是否看到过这样的用例，就是为了使用 Beam，需要以另一种方式重新实现底层处理引擎？
Frances Perry：当然有。正如前面所提及的，这毫不令人惊奇，甚至是鼓舞人心。但同时，我们正努力去十分现实地解决如何处理这些不匹配的问题。我们已运用能力矩阵（Capability Matrix）去清晰地追踪每个 Runner 支持的 Beam 模型部分。一旦有可能，我们就会设计出以可选形式提供的额外功能，如果没有更为简单和正确的实现，添加这样的功能将会改进 Runner 的性能。
InfoQ：Beam 项目下一步将会如何发展？
Frances Perry：在我看来，有三个关键的领域：可移植的架构、准备好用于生产环境，以及项目集成。
我们将可移植性置入了 Java SDK，可以在多个 Runner 上运行同一流水线。但是我们还必须要做更多的工作，以使所有 Beam SDK 具有这一功能。我迫切期待着有朝一日 Python SDK 也同样可移植。
其次，已经有用户将 Beam 用于生产环境。Beam 的用户越多，我们就能更好地精雕细琢。要改进每个用户的体验，与社区交互是非常关键的。
最后一点，我们正在不断寻求新的方法去集成 Beam 与其它的开源项目。我们不仅添加了 Apache Apex 等的新 Runner，而且也创建了与 Apache Calcite 等项目的集成，使得 Beam 对新类型用户更加开放。
被访者简介
Frances Perry 是一位软件工程师，工作兴趣在于让大规模数据处理更为简化、直观和高效。在 Google 内部数据处理栈上工作多年后，她加入了 Cloud Dataflow 团队，致力于使技术对外部云用户可用。她曾领导了 Dataflow 的统一流处理 / 批处理编程模型的早期工作，现在是 Apache Beam 项目管理委员会的一名成员。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论