Apache Beam 支持多个执行引擎后端，包括 Apache Spark 和 Flink。我熟悉 Spark/Flink，并试图了解 Beam 在批处理方面的优势和劣势。
通过查看Beam单词计数示例，感觉它与原生的Spark/Flink等价物非常相似，可能语法稍微冗长一些。
目前我并没有看到选择Beam而不选择Spark/Flink带来的太大好处。 我目前能够做出的唯一观察结论是：
是否有更好的例子来突出Beam模型的其他优缺点？有关失去控制权如何影响性能的信息吗？
请注意，我不是在询问流式处理方面的差异，这部分内容在这个问题中部分涵盖，并在这篇文章中总结（由于Spark 1.X而过时）。
Beam相比现有的许多引擎增加了一些功能。
统一批处理和流式处理。许多系统都可以处理批处理和流式处理，但它们通常是通过不同的API来完成的。而在Beam中，批处理和流式处理只是延迟、完整性和成本谱系上的两个点。从批处理到流式处理没有学习/重写的难度崖。因此，如果今天编写的是批处理管道，而明天需要更改延迟需求，那么调整就非常容易。您可以在移动游戏示例中看到这种过渡。
提高抽象级别的API：Beam的API专注于捕捉数据和逻辑属性，而不是让底层运行时的细节泄漏出来。这对于可移植性至关重要（请参见下一段），并且还可以为运行时提供很大的灵活性。例如，ParDo融合（又称函数组合）是绝大多数运行程序已经执行的基本优化。其他优化仍在为某些运行程序实现。例如，Beam的数据源API是专门为避免在管道内过度规定分片而构建的。相反，它们提供给运行程序正确的钩子来动态地在可用机器上重新平衡工作。这可以通过实质上消除拖延片段来极大地改善性能。通常，我们可以将更多智能构建到运行程序中，我们就越好。即使是最小心的手动调整也会因数据、代码和环境的变化而失败。
跨运行时的可移植性。: 由于数据形状和运行时要求被清晰地分离，同一条流水线可以用多种方式运行。这意味着，在从本地到云端或从传统系统到前沿系统的迁移时，您不必重新编写代码。您可以非常容易地比较选项，找到最适合当前需求的环境和性能组合。这可能是一种混合方式--在本地使用开源运行器处理敏感数据，并在云中的托管服务中处理其他数据。
将Beam模型设计成对许多不同引擎的有用抽象是棘手的。Beam既不是所有引擎功能的交集（太有限了！），也不是联合（太庞杂了！）。相反，Beam试图处于数据处理的前沿，同时推动功能进入运行时引擎并拉出模式。
我的劣势并不是优势。我们在使用 Beam 时遇到了一个问题，就是抽象层泄漏：当需要调试问题时，我们需要了解底层运行程序和其API，这种情况下是指 Flink，才能理解问题所在。这样一来学习曲线就加倍了，同时需要学习 Beam 和 Flink 。后来我们把后期开发的管道切换到了 Flink。
这里可以找到有用的信息 - https://flink.apache.org/ecosystem/2020/02/22/apache-beam-how-beam-runs-on-top-of-flink.html
---引用---
