Google Cloud Dataflow 简单理解

看了两篇文章，Sneak peek: Google Cloud Dataflow, a Cloud-native data processing service 和 Cloud Dataflow ：云计算时代的新计算模式 ，以及Google I/O 2014视频, 对 Cloud Dataflow的总结是：

Cloud Dataflow 是从 Flume 和 MillWheel 进化来的，它针对批量数据和流数据提供了统一的API。Cloud Dataflow 支持两种运行模式，批量处理模式(batch mode)和流式处理模式(real-time processing mode)，主要取决于输入的数据源类型。当数据源是由 cloud storage 提供的完整数据时，用批量处理模式处理；当数据源是以pub/sub 模式提供的流式数据，则用流式处理模式。(pipeline can run in parallel batch mode against data in Cloud Storage or in distributed real-time processing mode against data coming in via a Pub/Sub topic.

)

以下是一些更具体的个人理解和点评。

后端的执行引擎，既然 cloud dataflow 是从 flume 和 millwheel 进化而来，我认为cloud dataflow 本质上就是把这两套系统包装了一下，对外提供了统一的API，因此，后端的执行引擎，有两个，就是flume和millwheel。用户用cloud dataflow的API写的程序，根据输入的数据源，要么翻译到flume，要么翻译到millwheel上执行。

怎么判断用批量处理模式还是流式处理模式？很简单，在程序的一开始就已经确定了，当创建Pipeline时要给定一个input数据源，这个数据源如果是来自Cloud Storage，就用批量处理模式，如果是来自Pub/Sub，则用流式处理模式。这两种数据源的区分很简单，就是数据能否预先知道大小。流式处理中，数据是一直流动的的，永远不知道何时停止，批量处理中，数据可以看做是静态的，预先知道的。

API貌似跟Spark很像？ Cloud Dataflow的API，看起来跟Spark很像，其实不然，看Spark核心思想的那篇论文，Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing，多次提到了FlumeJava，所以是Spark借鉴了FlumeJava并发扬光大了，Spark用上了scala这种高大上的函数式语言，使得spark的API更加简洁统一了，但是二者的核心思想是一样的，都是来自Google FlumeJava。从API上看，Cloud Dataflow尽管已经做到了极致，但由于Java语言本身缺乏闭包等特性，还是比不上Spark的API简洁漂亮。那二者的区别呢？Cloud dataflow后端多了一个millwheel，因此在流式处理方面应该比Spark强。