Apache Beam 在批处理方面比 Spark/Flink 有什么好处？

Question

Apache Beam 支持多个运行器后端，包括 Apache Spark 和 Flink。我熟悉 Spark/Flink，我正在尝试了解 Beam 在批处理方面的优缺点。

看Beam word count example，感觉它和原生的Spark/Flink等价物很相似，可能语法稍显冗长。

我目前认为选择 Beam 而不是 Spark/Flink 来完成这样的任务并没有太大的好处。到目前为止我能做的唯一观察：

• 专业版：不同执行后端的抽象。
• 缺点：这种抽象的代价是对 Spark/Flink 中执行的确切内容的控制较少。

有没有更好的例子来突出 Beam 模型的其他优点/缺点？是否有任何关于失去控制如何影响性能的信息？

请注意，我并不是要求在流方面存在差异，this question 部分介绍了这些内容，this article 对此进行了总结（由于 Spark 1.X 已过时）。

Answer 1

Beam 在许多现有引擎上添加了一些东西。

• 统一批处理和流式处理。许多系统可以同时处理批处理和流式处理，但它们通常通过单独的 API 来处理。但在 Beam 中，批处理和流式处理只是延迟、完整性和成本范围内的两个点。从批处理到流式传输没有学习/重写悬崖。因此，如果您今天编写批处理管道，但明天您的延迟需求发生变化，那么调整起来非常容易。你可以在Mobile Gaming examples看到这样的旅程。

• 提高抽象级别的 API：Beam 的 API 专注于捕获数据和逻辑的属性，而不是让底层运行时的细节泄露出去。这既是可移植性的关键（见下一段），也可以为运行时提供很大的灵活性来执行它们。 ParDo fusion（又名函数组合）之类的东西是绝大多数跑步者已经做过的非常基本的优化。一些跑步者仍在实施其他优化。例如，Beam 的Source APIs 是专门为避免管道内的分片过度指定而构建的。相反，它们为运行者提供了正确的钩子，以便在可用机器之间动态重新平衡工作。通过从根本上消除散乱的碎片，这可以在性能上产生巨大的差异。一般来说，我们可以在跑步者身上培养的智慧越多，我们的表现就会越好。随着数据、代码和环境的变化，即使是最仔细的手动调整也会失败。

• 跨运行时的可移植性。：由于数据形状和运行时要求被巧妙地分开，同一管道可以以多种方式运行。这意味着当您必须从本地迁移到云端或从久经考验的真实系统迁移到尖端技术时，您最终不会重写代码。您可以非常轻松地比较选项，以找到最适合您当前需求的环境和性能组合。这可能是多种因素的混合——使用开源运行程序在本地处理敏感数据，并在云中的托管服务上处理其他数据。

将 Beam 模型设计为对许多不同引擎的有用抽象是很棘手的。 Beam 既不是所有引擎功能的交集（太有限！），也不是联合（太多的厨房水槽！）。相反，Beam 试图站在数据处理的最前沿，将功能推入运行时引擎并将模式从运行时引擎中提取出来。

• Keyed State 是一个很好的例子，展示了各种引擎中存在的功能并启用了有趣和常见的用例，但最初在 Beam 中无法表达。根据 Beam 的design principles，我们最近扩展了 Beam 模型以包含此功能的一个版本。
• 反之亦然，我们希望 Beam 也能影响各种引擎的路线图。例如，Flink 的 DataStreams 的语义是 influenced Beam（née Dataflow）模型。
• 这也意味着在给定的时间点，不同的 Beam runner 的功能并不总是完全相同。这就是为什么我们使用capability matrix 来尝试清楚地传达事物的状态。