Apache Beam相对于Spark / Flink的批处理有什么好处？

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

• 统一批处理和流。许多系统可以同时处理批处理和流处理，但是它们通常通过单独的API进行处理。但是在Beam中，批处理和流传输只是延迟，完整性和成本方面的两点。从批处理到流传输，没有学习/重写的障碍。因此，如果您今天写了一个批处理管道，但是明天您的延迟需求发生了变化，则调整起来非常容易。您可以在“ 移动游戏”示例中看到这种旅程。

• 提升抽象水平的API：Beam的API专注于捕获数据和逻辑的属性，而不是让底层运行时的详细信息泄漏出去。这不仅是可移植性的关键（请参阅下一段），还可以为运行时提供如何执行的灵活性。诸如ParDo融合（也称为函数组合）之类的东西是绝大多数跑步者已经做的相当基本的优化。某些跑步者仍在进行其他优化。例如，Beam的Source API专为避免管道中的分片规格过高而构建。相反，它们为跑步者提供了正确的选择，可以在可用计算机之间动态地重新平衡工作。通过从根本上消除散乱的碎片，可以在性能上产生巨大的差异。一般而言，我们可以在跑步者中培养更多的聪明才智，我们会取得更好的成就。随着数据，代码和环境的变化，即使是最仔细的手动调整也会失败。

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

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

Keyed State是各种引擎中存在的功能的一个很好的例子，它启用了有趣且常见的用例，但最初在Beam中无法表达。最近，我们根据Beam的设计原则对Beam模型进行了扩展，以包括该功能的版本。

反之亦然，我们希望Beam也能影响各种引擎的路线图。例如，Flink的DataStreams的语义受到 Beam（néeDataflow）模型的影响。

这也意味着在给定的时间点上，不同Beam的运行能力并不总是完全相同的。这就是为什么我们使用能力矩阵来尝试清楚地传达事物状态的原因。