大規模數據處理實戰--總體概述

目錄

Map-Reduce淘汰的原因

MapReduce的替代者

大規模電商熱銷榜


 

大規模數據處理工具出現的年代

到2014年穀歌內部沒人用Map-Reduce了
2016年穀歌內部培訓中,把Map-Reduce替換成了FlumJava

 

Map-Reduce淘汰的原因

1.高昂的維護成本
預測美團的股價,其中一個重要特徵是活躍在街頭的美團外賣電動車數量
在真實的環境下,至少需要10個MapReduce任務

首先,需要收集每日的外賣電動車圖片
數據的蒐集往往不是公司獨立完成,許多公司會選擇部分外包或者衆包,在數據收集(Data collection)部分,至少需要4個MapReduce任務
1.數據導入(data ingestion),從來把散落的照片,如衆包公司上傳到網盤的照片,下載到存儲系統
2.數據統一化(compression),用來把不同外包公司提供過來的各式各樣的照片進行格式統一
3.數據壓縮(compression),需要在質量可接受的範圍內保持最小的存儲資源消耗
4.數據備份(backup),大規模的數據處理系統我們都需要一定的數據冗餘來降低風險

第二步需要做數據的質量控制(quality control)流程
1.數據時間有效性驗證(data validation),檢測上傳的圖片是否是你想要的日期的
2.照片對焦檢測(focus detection),需要篩選掉那些因對焦不準而無法使用的照片

最後纔是重頭戲,找到這些圖片裏的外賣電動車
1.數據標註問題上傳(question uploading),上傳你的標註工具,讓你的標註着開始工作
2.標註結果下載(answer downloading),抓取標註完的數據
3.標註異議整合(adjudication),標註異議經常發生,比如爭議一個電動車是美團還是京東的
4.標註結果結構化(structuralization),要讓標註結果可用,需要把可能非結構化的標註結果轉換成存儲系統接受的結構

真實的商業MapReduce場景極端複雜,像上面這樣的10個子任務的MapReduce系統在硅谷很常見

2.時間上不達標

分片,是指把大規模的數據分配給不同的機器/工人

分片函數選擇不好,會導致數據傾斜
比如按年齡段分配用戶,但facebook的20-30歲用戶最多
導致發生掉隊問題(stragglers),別的機器都完成了Reduce階段,一些機器還在工作
通過MapReduce的性能剖析,可以發現掉隊的機器

 

MapReduce的替代者

谷歌等公司對於技術選擇非常嚴格,一個能成爲默認方案的技術至少滿足如下條件
1.經受了衆多產品線,超大規模數據量的考驗
2.自發的被衆多內部開發者採用,簡單易用而受開發者歡迎
3.能夠通過內部領域專家評審
4.比上一代技術提高10%是不夠的,必須有顯著的提高如70%的提高

 

未來的MapRecude設計上需要解決的問題

1.需要一種技術讓多步驟數據處理變得易於維護
這裏可以採用有向無環圖DAG的結構

爲了協調各種Map和Reduce需要做各種檢查,系統不堪重負
採用有向圖建模,圖中每一個節點都可以被抽象的表達成一種通用的數據集
每一條邊都被表達成通用的數據變換
可以用數據集和數據變換描述極爲宏大複雜的數據處理流程

2.不需要複雜的配置,可以自動進行性能優化

3.把數據處理的描述語言,和背後的運行引擎耦合開來
這類似 通過HTTP完成通訊,將兩端的實現解耦

在TensorFlow的設計中,客戶端可以使用任何語言,運行引起理論上可以在任何地方運行

對於數據處理也是一樣,有向圖表達心意數據處理描述語言和運行引協商一致,其他的實現都是可以擴展的

4.統一批處理和流處理的編程模型
流處理是無界連續的數據
批處理是有界離散的數據
MapReduce的侷限是它是爲批處理而設計的,應對流處理就不再得心應手
Apache Strom,Apache Flink也有類似的問題
Flink的批處理數據結構用Data Set,但流處理用DataStream
需要統一API,將這兩個模型統一

5.需要在架構層面提供異常處理和數據監控的能力

通過上述分析,新的數據處理框架基本模型應該是下面這樣的

 

大規模電商熱銷榜

求10億個商品銷售的topK
對於小規模問題,可以先用hash計算每個商品的銷售次數
在用TopK算法計算出銷售的前K名詞

小規模算法如果用到了大規模問題上,會出現兩個問題
1.內存佔用
2.中間結果放到磁盤上的I/O等待問題

大規模處理思路
找1000臺機器,每臺幾次一次處理1W條記錄,這樣每臺機器的處理方式又迴歸到了傳統算法

計算topK,把統計銷量集羣得到的數據輸出,作爲這個處理流的輸入,
把product_id=1的銷量全部疊加

彙總結果因爲數據量不大,可以用單機解決

大規模處理框架有兩個基本需求
1.高度抽象數據處理流程描述語言,作爲框架使用者,最好能用幾行代碼就把業務邏輯描述清楚
2.自動化的任務分配優化,這個框架背後的引擎需要足夠智能,把原來手動配置的系統進行自動任務分配

對於上面的場景,計算銷售統計計算集羣,可以這麼寫代碼

sales_count = sale_records.Count()
top_k_sales = sales_count.TopK(k)


 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章