Apache Beam支持多个运行程序后端，包括Apache Spark和Flink。我熟悉Spark / Flink，并试图了解Beam用于批处理的优点/缺点。
看一下Beam的字数示例，感觉它与本机Spark / Flink等效项非常相似，也许语法稍微冗长。
我目前看不到选择Beam代替Spark / Flink来实现此任务有什么好处。到目前为止，我只能做的观察：
是否有更好的示例来突出Beam模型的其他优点/缺点？是否有失去控制如何影响性能的信息？
请注意，我并不是在要求流传输方面的差异，该问题已部分涵盖在本文中，并在本文中进行了概述（由于Spark 1.X已过时）。
Answers:
Beam在许多现有引擎上添加了一些东西。
统一批处理和流。许多系统可以同时处理批处理和流处理，但是它们通常通过单独的API进行处理。但是在Beam中，批处理和流传输只是延迟，完整性和成本方面的两点。从批处理到流式传输，没有学习/重写的障碍。因此，如果您今天写了一个批处理管道，但是明天您的延迟需求发生了变化，则调整起来非常容易。您可以在“移动游戏”示例中看到这种旅程。
提升抽象水平的API：Beam的API专注于捕获数据和逻辑的属性，而不是让底层运行时的详细信息泄漏出去。这不仅是可移植性的关键（请参阅下一段），还可以为运行时提供如何执行的灵活性。诸如ParDo融合（也称为函数组合）之类的东西是绝大多数跑步者已经做的相当基本的优化。某些跑步者仍在进行其他优化。例如，Beam的Source API专为避免对管道内的分片进行规范而构建。相反，它们为跑步者提供了正确的选择，可以在可用计算机之间动态地重新平衡工作。通过从根本上消除散乱的碎片，可以在性能上产生巨大的差异。总的来说，我们可以在运动员中培养更多的聪明才智，我们会取得更好的成绩。随着数据，代码和环境的变化，即使是最仔细的手动调整也会失败。
跨运行时的可移植性。：由于数据形状和运行时要求完全分开，所以可以以多种方式运行同一管道。这意味着当您必须从内部部署迁移到云中，或者从久经考验的真实系统迁移到最前沿时，最终不必重写代码。您可以轻松地比较各种选项，以找到最适合您当前需求的环境和性能的组合。这可能是多种多样的事情-使用开源运行程序在内部处理敏感数据，并在云中的托管服务上处理其他数据。
将Beam模型设计为对许多不同引擎有用的抽象是棘手的。梁既不是所有引擎功能的交叉点（太有限了！）也不是联合体（太多的厨房水槽！）。相反，Beam试图站在数据处理的最前沿，既将功能推入运行时引擎，又将模式从运行时引擎中拉出。