Apache Beam支持多个亚军后端，包括Apache Spark和Flink。我熟悉Spark/Flink，我正在尝试查看Beam的批处理优点/缺点。Apache Beam对Spark/Flink进行批处理有什么好处？
看着Beam word count example，它感觉它与本机的Spark/Flink等价物非常相似，可能稍微有些冗长的语法。
我目前没有看到选择Beam作为Spark/Flink这种任务的好处。目前为止唯一的观察结果是：
是否有更好的例子来突出梁模型的其他优点/缺点？有没有关于失控如何影响性能的信息？
请注意，我并不是要求在流式方面存在差异，部分在this question中进行了介绍，并在this article（归因于Spark 1.X）中进行了总结。
Beam增加了许多现有的引擎。
Unifying batch and streaming。许多系统可以同时处理批处理和流式处理，但他们经常通过单独的API来处理。但是在Beam中，批处理和流式传输只是延迟，完整性和成本范围上的两点。没有学习/重写从批处理到流式处理的悬崖。所以如果你今天写了一个批处理管道，但是明天你的延迟需要改变，那么调整起来非常容易。你可以在Mobile Gaming examples中看到这种旅程。
的API，提高抽象水平：梁的API，集中于捕捉您的数据和逻辑性，而不是通过让潜在的运行时泄漏的详细信息。这对于可移植性来说是关键（参见下一段），并且还可以为运行时在执行方式上提供很大的灵活性。类似ParDo融合（又名函数合成）是绝大多数跑步者已经做的基本优化。其他优化仍在为一些跑步者实施。例如，Beam的Source APIs专门为避免流水线内的分片过分指定而构建。相反，他们为跑者提供了正确的机会，以动态平衡可用机器上的工作。这可以通过基本消除零散碎片来实现巨大的性能差异。一般来说，我们可以在跑步者身上建立的智慧越多，我们就会越好。随着数据，代码和环境的变化，即使是最仔细的手部调整也会失败。
跨运行时的可移植性。：由于数据形状和运行时需求是整齐分开的，因此可以通过多种方式运行相同的管道。这意味着，当您必须从内部部署转移到云端时，或者从经过验证的真正系统转移到最前沿时，最终不会重写代码。您可以非常轻松地比较各种选项，找到最适合当前需求的环境和性能组合。这可能是一个混合的事情 - 在开放源代码运行器的前提下处理敏感数据，并在云中管理服务上处理其他数据。
将Beam模型设计成对许多不同引擎有用的抽象是棘手的。梁既不是所有引擎的功能（太有限！）的交集，也不是联合（太多的厨房水槽！）。相反，Beam试图走在数据处理的最前沿，既能将功能推入运行时引擎，又能将模式拉出运行引擎。