Apache在Spark/Flink上对批处理有什么好处？

Question

阿帕奇梁支持多个运行程序后端，包括Apache和Flink。我很熟悉Spark/Flink，我正试图看到Beam批量处理的利弊。

从光束字数算例的角度来看，它觉得它非常类似于本机Spark/Flink的等价物，可能有一个稍微冗长一些的语法。

我目前不认为选择梁而不是火花/Flink来完成这样的任务有多大的好处。到目前为止，我能提出的唯一意见是：

• 支持:对不同执行后端的抽象。
• Con:这种抽象的代价是减少了对在Spark/Flink中执行什么的控制。

是否有更好的例子突出梁模型的其他利弊？是否有任何关于失控如何影响性能的信息？

请注意，我并不是在请求流方面的差异，流方面的部分内容在这个问题中进行了介绍，并在这篇文章中进行了总结(由于Spark1.X而过时)。

Answer 1

有一些东西，梁添加到许多现有的引擎。

• 统一批处理和流。许多系统可以同时处理批处理和流，但是它们通常通过不同的API来处理。但是在Beam中，批处理和流仅仅是延迟、完整性和成本的两个方面。没有从批处理到流的学习/重写悬崖。因此，如果您今天编写了一个批处理管道，但是明天您的延迟需要更改，那么调整起来就非常容易。你可以在移动游戏实例中看到这样的旅程。
• 提高抽象级别的API:Beam的API侧重于捕获数据和逻辑的属性，而不是让底层运行时的细节泄漏出去。这是可移植性的关键(请参阅下一段)，并且在它们的执行方式上也可以给予运行时很大的灵活性。类似于ParDo融合(也称为函数组合)是绝大多数跑步者已经做过的一个非常基本的优化。其他优化仍在为一些运行程序实现。例如，Beam的源API是专门构建的，以避免过度规范在管道中的切分。相反，它们为跑步者提供了在可用机器之间动态重新平衡工作的正确钩子。这可以通过从本质上消除散乱的碎片，在性能上产生巨大的差异。一般来说，我们对跑步者越聪明，我们的生活就越好。即使是最仔细的手动调优也会随着数据、代码和环境的变化而失败。
• 跨运行时的可移植性.：由于数据形状和运行时需求之间有很好的分离，所以可以以多种方式运行相同的管道。这意味着，当您不得不从on移动到云端，或者从一个尝试过的、真实的系统转移到最前沿的东西时，您就不会重写代码。您可以非常容易地比较各种选项，以找到最适合您当前需求的环境和性能的组合。这可能是一种混合--在使用开源运行程序的前提下处理敏感数据，以及处理云中托管服务上的其他数据。

设计梁模型是一个有用的抽象，对许多不同的引擎是棘手的。梁既不是所有引擎功能的交集(太有限了！)也不包括工会(厨房水槽太大了！)相反，Beam试图站在数据处理的前沿，将功能推入运行时引擎，并将模式从运行时引擎中提取出来。

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

Answer 2

有用的信息可以在这里找到- https://flink.apache.org/ecosystem/2020/02/22/apache-beam-how-beam-runs-on-top-of-flink.html

-引用

• Beam为批处理和流场景提供了统一的API。
• Beam提供了对不同编程语言的原生支持，比如Python，或者它的所有库，如Numpy、Pandas、Tensorflow或TFX。
• 您可以获得Apache的强大功能，就像它的一次语义、强大的内存管理和健壮性。
• Beam程序运行在您现有的Flink基础设施或基础设施上，供其他受支持的跑步者使用，如Spark或Google。
• 您获得了额外的功能，如边输入和跨语言管道，这些特性在Flink中不受支持，但只有在使用带Flink的Beam时才能得到支持。

Answer 3

我有一个缺点，而不是好处。Beam存在一个漏洞抽象问题:当需要对问题进行调试时，我们需要了解底层运行程序及其API，在本例中是Flink，以了解问题。这使学习曲线加倍，必须同时学习Beam和Flink。最后，我们将后来开发的管道切换到Flink。