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