Cloud Dataflow比原生的Map-Reduce強在哪兒？
Google Cloud Dataflow是一種構建、管理和優化復雜數據處理流水線的方法，集成了許多內部技術，如用于數據高效并行化處理的Flume和具有良好容錯機制流處理的MillWheel。Dataflow當前的API還只有Java版本（其實Flume本身是提供Java/C++/Python多種接口的，MillWheel也提供Java/C++的API）。
相比原生的map-reduce模型，Dataflow有幾個優點：
1.可以構建復雜的pipeline，在這不妨引用Google云平臺的產品營銷總監Brian Goldfarb的話:
| Cloud Dataflow可以用于處理批量數據和流數據兩種。在一個世界性事件（比如演講當中的世界杯事件）中，實時分析上百萬twitter數據。在流水線的一 個部階段責讀取tweet，下一個階段負責抽取標簽。另一個階段對tweet分類（基于情感，正面負面或者其他方面）。下一個階段過濾關鍵詞等等。相比之 下，Map/Reduce這個用來處理大數據的較早模型，處理這種實時數據已經力不從心，而且也很難應用到這種很長很復雜的數據流水線上。 |
2.不需手工配置和管理MapReduce集群。自動進行代碼優化和資源調度，使得開發者的主要精力可以放在業務邏輯本身。
3.支持從Batch到Streaming模式的無縫切換:
假設我們要根據用戶在twitter上產生的內容，來實現一個hashtags自動補全的功能:
- Example: Auto completing hashtags
- Prefix Suggestions
- ar #argentina, #arugularocks, #argylesocks
- arg #argentina, #argylesocks, #argonauts
- arge #argentina, #argentum, #argentine
4.Dashboard:
5.生態系統:
BigQuery作為存儲系統是Dataflow的一個補充，經過Dataflow清洗和處理過的數據，可以在 BigQuery中存下來，同時Dataflow也可以讀取BigQuery以進行表連接等操作。如果想在Dataflow上使用一些開源資源（比如說 Spark中的機器學習庫），也是很方便的
為了配合Dataflow，Google Cloud Platform還為開發者提供了一系列工具，包括云保存，云調試，云追蹤和云監控。
比較
1.Cascading/Twitter Scalding：
- 傳統Map-reduce只能處理單一的流，而Dataflow可以構建整個pipeline，自動優化和調度，Dataflow乍一聽感覺非常像Hadoop上的Cascading(Java)/Scalding(Scala)。
- 它們的編程模型很像，Dataflow也可以很方便做本地測試，可以傳一個模擬集合，在上面去迭代計算結果，這一點是傳統Map-reduce望塵莫及的。
2.Twitter Summingbird：
將批處理和流處理無縫連接的思想又聽起來很像把Scalding和Strom無縫連接起來的twitter summingbird(Scala).
3.Spark：
- Spark也有可以構建復雜的pipeline做一代碼優化和任務調度的好處，但目前還需要程序員來配置資源分配。
- Spark在設計分布式數據集API時，模擬了Scala集合的操作API，使得額外的語法學習成本比Dataflow要低。
- 不過Dataflow似乎并沒有提內存計算的事兒，而這一點可以說是Spark最本質的特征。不過它支持將parSk作為Open Source工具，連入Cloud框架作為補充。
- 分布式計算中除了Batch和Streaming，Graph也是一個重要的問題，Spark在這方面有GraphX，Dataflow在未來也會將處理Graph處理(Pregel)這塊整合進去。
原文鏈接：http://www.open-open.com/lib/view/open1420689003765.html
