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