首页 文章

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

提问于
浏览
30

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

看看Beam word count example,它感觉它与原生的Spark / Flink等价物非常相似,可能有一个稍微冗长的语法 .

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

  • Pro:对不同执行后端的抽象 .

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

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

请注意,我并不是要求在流方面存在差异,这些差异部分在this question中进行了介绍,并在this article中进行了总结(由于Spark 1.X而过时) .

1 回答

  • 46

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

    • Unifying batch and streaming. 许多系统都可以处理批处理和流式处理,但它们通常通过单独的API来处理 . 但在Beam中,批量和流媒体只是延迟,完整性和成本的两个点 . 's no learning/rewriting cliff from batch to streaming. So if you write a batch pipeline today but tomorrow your latency needs change, it'非常容易调整 . 你可以在Mobile Gaming examples看到这种旅程 .

    • APIs that raise the level of abstraction :Beam 's APIs focus on capturing properties of your data and your logic, instead of letting details of the underlying runtime leak through. This is both key for portability (see next paragraph) and can also give runtimes a lot of flexibility in how they execute. Something like ParDo fusion (aka function composition) is a pretty basic optimization that the vast majority of runners already do. Other optimizations are still being implemented for some runners. For example, Beam' s Source APIs专门用于避免过度指定管道中的分片 . 相反,它们为跑步者提供了正确的钩子,可以跨越可用的机器动态地重新 balancer 工作 . 通过基本上消除落后者碎片,这可以在性能上产生巨大的差异 . 总的来说,我们可以在跑步者身上 Build 起来越聪明,我们就会越好 . 当数据,代码和环境发生变化时,即使最仔细的手动调整也会失败 .

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

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

    • Keyed State是各种引擎中存在的功能的一个很好的例子,并且启用了有趣和常见的用例,但是没有't originally expressible in Beam. We recently expanded the Beam model to include a version of this functionality according to Beam' s design principles .

    • 反之亦然,我们希望Beam也会影响各种发动机的路线图 . 例如,Flink的DataStreams的语义是Beam(néeDataflow)模型的influenced .

    • 这也意味着在给定时间点不同的Beam跑步者的能力并不总是完全相同 . 所以's why we'重新使用capability matrix来尝试清楚地传达事物的状态 .

相关问题