阅读 Google 的 Dataflow API,我的印象是它与 Apache Storm 所做的非常相似。通过流水线流进行实时数据处理。除非我完全错过了这里的重点,而不是建立关于如何执行相互编写的管道的桥梁,我希望有一些与谷歌不同的东西,而不是重新发明轮子。Apache Storm 已经很好地适应了任何编程语言。做这样的事情的真正价值是什么?
2 回答
感谢您对 Dataflow 编程模型的关注!诚然,Dataflow 和 Apache Storm 都支持流处理,但有重要区别:
Dataflow 在同一个“窗口”API 下支持批处理和流计算,而据我所知,Storm 是一个专门的流系统。
用于定义计算拓扑的 API 在 Dataflow 和 Storm 中非常不同。Dataflow API 在很大程度上模仿了 FlumeJava:您可以像操作真实集合一样操作逻辑PCollection对象(并行集合;您可以将它们视为逻辑数据集),并根据将不同的可并行化操作(例如ParDo)应用于其他操作的结果构建新集合收藏品。相反,在 Apache Storm 中,您直接从“spouts”和“bolts”构建计算网络;我不知道逻辑数据集或并行操作的明确概念。
Dataflow 中管道的逻辑表示允许框架执行类似于数据库系统中的查询优化器所做的优化,例如避免或引入某些中间结果的具体化,移动或消除分组键操作等。可以在 FlumeJava 论文中看到这些优化的概述。这在批处理模式和流模式下都很有用。
Dataflow 和 Storm 的流计算模型之间的一致性保证是不同的。这实际上是一个有趣的话题!我建议阅读Millwheel论文(这是 Dataflow 的流部分所基于的),以了解流系统中的容错和一致性问题的概述。我相信这篇论文也简要地将 Millwheel 与 Storm 进行了比较。您可以在演讲中找到更广泛的讨论,讨论流式系统中一致性保证的重要性以及 Dataflow 赋予的一致性的力量——进一步消除 Lambda 架构的神话。
作为 Google Cloud Platform 的一部分,Dataflow 的主要价值主张之一是零麻烦:您无需设置集群、设置监控系统等:您只需将管道提交到云 API,然后系统为其分配资源,使用它们执行您的管道,为您监控它。不过,这可能与您关于编程模型相似性的问题无关。
不,这些是完全不同的框架。Dataflow 是 FlumeJava 的继任者,就像 Crunch 一样,在较小程度上是 Spark。它确实映射到 Spark。Spark 的 Streaming 项目映射到 Dataflow 的 Streaming 支持,这两者都是最接近 Storm (+ Trident) 的模拟。但它实际上是一个映射到 Storm 的 Dataflow。
Spark Streaming 和 Dataflow 的流比 Storm + Trident 更像彼此。如果您在线阅读 Spark Streaming 和 Storm 的任何比较,它也将主要适用于 Dataflow。
Dataflow 的流式传输的一个好处是它与非流式传输核心进行了额外集成。数据流大多与流无关;Storm 正在流式传输。