apache-spark - 与 Spark/Flink 相比，Apache Beam 在批处理方面有哪些优势？

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 专注于捕获数据和逻辑的属性，而不是让底层运行时的详细信息泄漏。这既是可移植性的关键(参见下一段)，也可以为运行时的执行方式提供很大的灵 active 。像 ParDo 融合(又名函数组合)这样的东西是一种非常基本的优化，绝大多数运行者已经这样做了。一些运行者仍在实现其他优化。例如，Beam 的 Source APIs专门为避免管道内的分片过度规范而构建。相反，它们为运行者提供了正确的方法，可以在可用机器上动态地重新平衡工作。通过从本质上消除掉队碎片，可以在性能上产生巨大的差异。一般来说，我们为运行者培养的智慧越多，我们的表现就会越好。随着数据、代码和环境的变化，即使是最仔细的手工调整也会失败。

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

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

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