怎麼評價Google發布的Cloud Dataflow雲數據分析工具？

2014谷歌I/O上的Google Cloud Platform和Cloud Dataflow-CSDN.NET

相比原生的map-reduce模型，Dataflow有幾個優點：

1. 可以構建複雜的pipeline

2. 不需手工配置和管理MapReduce集群。自動進行代碼優化和資源調度，使得開發者的主要精力可以放在業務邏輯本身

3. 支持從Batch到Streaming模式的無縫切換

4. 可以在developer console中了解流水線中每個環節執行的情況

5. 有Google cloud platform這個完整的生態系統

比較

1. Cascading/Twitter Scalding： 1) 傳統Map-reduce只能處理單一的流，而Dataflow可以構建整個pipeline，自動優化和調度，Dataflow乍一聽感覺非常像Hadoop上的Cascading(Java)/Scalding(Scala)。 2) 它們的編程模型很像，Dataflow也可以很方便做本地測試，可以傳一個模擬集合，在上面去迭代計算結果，這一點是傳統Map-reduce望塵莫及的。
2. Twitter Summingbird： 而將批處理和流處理無縫連接的思想又聽起來很像把Scalding和Strom無縫連接起來的twitter summingbird(Scala).
3. Spark： 1) Spark也有可以構建複雜的pipeline做一代碼優化和任務調度的好處，但目前還需要程序員來配置資源分配。 2) Spark在設計分散式數據集API時，模擬了Scala集合的操作API，使得額外的語法學習成本比Dataflow要低。 3) 不過Dataflow似乎並沒有提內存計算的事兒，而這一點可以說是Spark最本質的特徵。不過它支持將Spark作為Open Source工具，連入Cloud框架作為補充。 4) 分散式計算中除了Batch和Streaming，Graph也是一個重要的問題，Spark在這方面有GraphX，Dataflow在未來也會將處理Graph處理這塊整合進去。

如果感興趣，這裡有詳細的分析：

相比原生的map-reduce模型，Dataflow有幾個優點：
可以構建複雜的pipeline
不需手工配置和管理MapReduce集群。自動進行代碼優化和資源調度，使得開發者的主要精力可以放在業務邏輯本身
支持從Batch到Streaming模式的無縫切換
可以在developer console中了解流水線中每個環節執行的情況
有Google cloud platform這個完整的生態系統

比較
1、Cascading/Twitter Scalding：
1) 傳統Map-reduce只能處理單一的流，而Dataflow可以構建整個pipeline，自動優化和調度，Dataflow乍一聽感覺非常像Hadoop上的Cascading(Java)/Scalding(Scala)。
2) 它們的編程模型很像，Dataflow也可以很方便做本地測試，可以傳一個模擬集合，在上面去迭代計算結果，這一點是傳統Map-reduce望塵莫及的。

2、Twitter Summingbird：
而將批處理和流處理無縫連接的思想又聽起來很像把Scalding和Strom無縫連接起來的twitter summingbird(Scala).

3、Spark：
1) Spark也有可以構建複雜的pipeline做一代碼優化和任務調度的好處，但目前還需要程序員來配置資源分配。
2) Spark在設計分散式數據集API時，模擬了Scala集合的操作API，使得額外的語法學習成本比Dataflow要低。
3) 不過Dataflow似乎並沒有提內存計算的事兒，而這一點可以說是Spark最本質的特徵。不過它支持將Spark作為Open Source工具，連入Cloud框架作為補充。
4) 分散式計算中除了Batch和Streaming，Graph也是一個重要的問題，Spark在這方面有GraphX，Dataflow在未來也會將處理Graph處理這塊整合進去。
我個人認為如此，希望能為大家提供服務與幫助，我為大家說一下我經常使用的;

CloudIn雲英 - 專業的雲主機，雲伺服器，雲硬碟，雲安全等IaaS及PaaS服務提供商。