如何看待Google向Apache基金会提交的Beam(Dataflow)提案？ 举报 理由 举报 取消 https://wiki.apache.org/incubator/BeamProposal你如何看待此提议，该项目前景如何？ 2017年11月25日 9 条回复 1354 次浏览 Apache,Google,分布式,开源,数据,计算,谷歌
回复 ( 9 )
你知道Google Cloud Platform上加入Bigtable服务时，写了兼容Hadoop API，是多屈辱的一件事情吗？所以有好东西很重要，更重要的是要把标准把握在自己手里。
自己提问几个月后自己来回答一下。我认为Google CloudDataflow的思路是好的，它代表着社区的一个发展方向，即使用一套高层抽象的API屏蔽多种计算引擎的区别。社区现在有许多系统都在尝试做，但大部分之前的项目都只是做到了流式与批量的接口比较类似，而没做到完全的统一，如Flink/Spark 1.x； 有部分系统实现了一套代码可同进运行于批量与流式的系统之上，但却适用范围较小，比较专用于特定的使用场景，如Twitter的SummingBird。
而Google CloudDataflow则是第一个真正的做到可统一流式与批量代码的通用型分布式计算引擎。
Google设计出此接口之后，是希望能够在自己的公有云上发力，卖个好价钱的。但是，他们知道，如果该项目不开源，则很难有人愿意使用它，因为使用它就相当于绑定了谷歌的云服务，如果未来谷歌涨价了，就很难迁移走了，但此项目底层实现时，依赖了太多谷歌内部不开源的库，于是难以开源出来，他们便把API接口开源，并开始推进社区搞Beam。
对于Beam的设计思路，即使用一种接口覆盖多种计算引擎，我认为是大有可为的（我在公司内部就是搞这个的），但我对Beam的接口(其实也是CloudDataflow的接口)并不看好，主要是因为其接口的易用性太差：
1. 相较于Spark的接口，Beam的接口中有各种各样的Context传递，学习成本高。
2. 不能很好的使用lambda来使书写变得方便，导致用户代码量较大。
3. CloudDataflow的设计中，数据的timestamp是隐含的一个字段，用户如果想要读取或修改这个字段，就需要调用一些很特殊的接口来处理它，理解起来不像Spark Dataset中那样，把时间作为一个看似普通的字段那样容易让用户使用。不过明确字段的设计就要求API接口本身要支持字段功能，这也会加大用户理解的成本（想想为什么Spark Dataframe没有Spark RDD容易推广）。
4. 窗口的使用较难理解，例如，Bounded/Unbouned的概念略为抽象，较难直观理解；调用完窗口操作，没有调用GroupBy操作的时候，如果调用了一个parallelDo，那么这个parallelDo拿到的每个Batch的数据到底是什么样的粒度的，是每个窗口下都算一个Batch还是全局所有数据算一个Batch，第一感觉是因为调用过了窗口操作，这里应该拿到的是每个窗口下的算一个Batch，但实际上则不是，只有在GroupBy之后窗口操作才生效。而Spark Dataset接口，则强制的绑定了Window必须作为groupBy的一个字段，和groupBy一起使用，就避免了出现window操作过后未groupBy的状态，使接口较为容易理解，但这种设计使得Spark Dataset丧失了CloudDataflow里一大优势：将窗口操作与Transformation分离，使得窗口改变时Transformation内部不需要发生变化。例如，一个Transformation本来是批量引擎上执行，后来该Transformation需要应用于流式计算引擎，只需要在调用Transforation前添加一句Window操作即可。而在Spark Dataset中，则需要个性Transformation内部所有调用groupBy的代码，使其多groupBy一个Window的字段。
原先有一个类似的项目Apache Crunch ，从Apache Beam proposal上看和这个项目的初衷非常类似，都是类FlumeJava的设计，而且pmc也都是同一拨人，比如 Josh Wills，Tom White.
统一的API layer确实有一定的意义，但是API设计往往又是这些框架非常重要的一部分，比如说Spark的RDD DataSet/Dataframe，API设计与内部设计相辅相成（dataframe与project tungsten），第三方的unify API往往做不到这一点。而且现在DataSet API已经把batch和streaming统一了。所以Apache Beam之后能发展成怎么样不好说。
（理解有误请多指教）
在大家热火朝天的玩着各种引擎实现的时候，Google 颇有大将风度的说，我在玩标准了……
强烈建议看看 Tyler Akidau 的两篇高质量文章：
Beam 的推出，个人觉得是大数据分析开始从阳春白雪到下里巴人的进一步推进。
想想之前的 web 开发，在 Java 世界里，Servlet 标准一出，剩下的就是各种容器的实现，以及各个公司对各种容器的评估了。
Beam 就是这样的标准，只不过具体的实现比较复杂，需要一些高级运维人员了。
另外再说一下，感觉 Flink 理念上要和 dataFlow 跟接近，只是目前的生态还不行……
实践经验太少了，不说了。
感觉谷歌要把自家的AI以及云计算做成一个平台了（android，chrome之后的又一个生态），为了更好的普及，贡献一部分给开源社区并且采取开放合作的姿态，对它推广做大自己的平台以及对外界都有好处，双赢。
DataFlow是一层API层的模型，统一了批和流，是新一代计算的思路。具体实现和api好不好理解不重要，思想最重要。
实时领域不一定要使用它这个架构，但是可以借用这个框架，尤其是在一些细分的场景上。
一个简单的场景是提供一套API可以在Storm和Flink上切换引擎。不过自从Flink问世后，开源Storm的使用价值已经不大了，除了360携程等厂使用自己改造的Storm或者JStorm，新上线的业务一般还是走了Spark Streaming 或者Flink.
另一个场景是从Spark Streaming 切Flink，唯一能想到的原因是随着实时计算的逐渐流行，产品级（实时推荐/热点/用户行为分析/安全风控）的东西里面会对实时反馈实时统计的一些延迟要求更加高。Spark Streaming 受制于伪实时的微批次架构，不能够做到秒级或者更低的实时计算，未来一定会有一些Spark Streaming无法满足的低延迟场景需求，要由Flink来完成。
google的引擎（dataflow）不开源，仅仅开源一个sdk（beam），说这个是标准。估计大部分的引擎是不认的。 再者，每个api都跟引擎之间或多或少有不少的关联，感觉很难单独独立，这个跟web的servlet不能雷同。
我只是不看好，但是也不一定。
跟AWS Lambda有异曲同工之妙：不过Beam是把batch和streaming计算模型抽象出来并定义逻辑层次较高的接口，方便规范开发者的思路。
不过Flink、Spark等提供runner的项目很可能会借鉴思路来提供自己的类似封装接口，需要看哪边动作更快了。