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

Question

Apache Beam支持多个运行后端,包括Apache Spark和Flink.我熟悉Spark/Flink,我试图看到Beam的批处理优缺点.

看一下Beam字数统计示例,它感觉它与原生的Spark/Flink等价物非常相似,可能有一个稍微冗长的语法.

我目前没有看到为这样的任务选择Beam over Spark/Flink的一大好处.到目前为止我能做的唯一观察:

• Pro:不同执行后端的抽象.
• Con:这种抽象的代价是对Spark/Flink中执行的内容的控制较少.

是否有更好的例子突出了梁模型的其他优点/缺点？是否有关于失控如何影响性能的信息？

请注意,我并不是要求在流方面存在差异,这些问题在本文中已部分涵盖并在本文中进行了总结(由于Spark 1.X而过时).

Answer 1

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

• 统一批量和流式传输.许多系统可以处理批处理和流式处理,但它们通常通过单独的API来处理.但在Beam中,批量和流媒体只是延迟,完整性和成本的两个点.从批处理到流媒体,没有学习/重写的悬崖.因此,如果您今天编写批处理管道,但明天您的延迟需求会发生变化,那么调整非常容易.您可以在移动游戏示例中看到这种旅程.

• 提高抽象级别的API:Beam的API专注于捕获数据和逻辑的属性,而不是让底层运行时的细节泄漏.这对于可移植性来说都很关键(参见下一段),并且还可以为运行时的执行方式提供很大的灵活性.像ParDo融合(又称函数组合)这样的东西是绝大多数跑步者已经做过的非常基本的优化.其他优化仍在为一些跑步者实施.例如,Beam的Source API专门用于避免过度规范管道中的分片.相反,它们为跑步者提供了正确的钩子,可以跨越可用的机器动态地重新平衡工作.通过基本上消除落后者碎片,这可以在性能上产生巨大的差异.总的来说,我们可以在跑步者身上建立起来越聪明,我们就会越好.当数据,代码和环境发生变化时,即使最仔细的手动调整也会失败.

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

将Beam模型设计为对许多不同引擎的有用抽象是棘手的.Beam既不是所有引擎功能的交集(太有限了!),也不是联盟(太多的厨房水槽!).相反,Beam试图站在数据处理的最前沿,将功能推入运行引擎并从中拉出模式.

• Keyed State是各种引擎中存在的功能的一个很好的例子,它启用了有趣和常见的用例,但最初并未在Beam中表达.我们最近根据Beam的设计原则扩展了Beam模型,以包含此功能的一个版本.
• 反之亦然,我们希望Beam也会影响各种发动机的路线图.例如,Flink的DataStreams的语义受 Beam(néeDataflow)模型的影响.
• 这也意味着在给定时间点不同的Beam跑步者的能力并不总是完全相同.这就是为什么我们使用能力矩阵来尝试清楚地传达事物的状态.

Answer 2

我有一个缺点，而不是一个优点。我们遇到了一个抽象漏洞问题Beam：当需要调试问题时，我们需要了解底层运行器及其 API，Flink在这种情况下，才能理解问题。这使得学习曲线加倍，必须同时学习 Beam 和 Flink。我们最终将后来开发的管道切换到Flink.