MapReduce 計算模式

聲明：本文摘錄自《大數據日知錄——架構與算法》一書。

較常見的計算模式有4類，實際應用中大部分ETL任務均可以歸結爲這些計算模式或者變體。

1.求和模式

　　a.數值求和

　　好比咱們熟悉的單詞計數，即便該模式的一個應用。求最大最小值，求平均值皆屬此類。

　　b.記錄求和

　　非數值內容的累加，造成隊列。好比將包含某個key的網頁添加到一個列表當中。

 

2.過濾模式

　　不對數據進行轉換，只是從大量數據中篩選。

　　a.簡單過濾

　　這類應用不須要對數據進行聚合（緣由不復雜），因此無需reduce階段。

　　b.Top 10

　　和簡單過濾的差別在於：簡單過濾的條件判斷只涉及當前記錄，而Top k計算模式須要在記錄之間進行比較，並得到全局最大的子集。

　　思路：map =>local top k =>reduce =>overall top k

 

3.組織數據模式

　　a.數據分片

　　重點在partitioner策略的設計上，經過改變partitioner來將相同標準的數據通過Shuffle過程放到一塊兒，由同一個reducer 來輸出。

　　問題來了，這該如何實現呢？

　　考慮到partitioner是能夠自定義的（這TM不廢話麼），那麼，咱們能夠在partitioner內部實現對數據的分析，而後將其輸出到不一樣的partition中。

　　b.全局排序

　　能夠直接利用內置排序過程，也就是說，mapper只須要將要排序的字段做爲key，記錄內容做爲value輸出便可。

　　reducer其實也不須要作額外的任務，由於sort過程已經排好序了。（有一個問題，假如我對排序算法不滿意怎麼辦？一個辦法是自定義key，也就是自定義一個WritableComparable接口的類，而且根據需求實現裏面的compareTo方法）

　　若是有不止一個reducer怎麼辦？若是不作額外的處理，排序結果就會成爲局部排序。

　　有辦法：Partitioner，能夠將處於不一樣區間的key放在不一樣的Partition，相同區間的Key放在同一Partition。

4.Join模式

　　a.Reduce-Side Join

　　這個過程對於筆者而言比較複雜，因此這個主題會耗費較多文字。

　　在選定外鍵以後，全部相同外鍵的數據分配到了同一個Reducer。須要注意的是如何區分來自不一樣數據集合的記錄？一個顯而易見的辦法是在Mapper階段動動手腳：給記錄作標記，放在Value中。

　　而後，將reducer的Value list根據集合的不一樣整合成2個列表（或者哈希表，其實就是一個查詢效率的問題，想怎麼搞就怎麼搞），而後再將這些數據進行Join。

　　多說一句：整個過程須要通過數輪磁盤的讀寫，shuffle階段的網絡傳輸，以及Reduce階段的排序，因此計算效率比較低。（意思就是Mapper幾乎什麼事都沒幹，卻由於IO的問題而致使時間效率低）

　　b.Map-Side Join

　　好了，效率低的解決辦法來了；不過有前提條件：數據集合一個大一個小，而且小的那個徹底能夠放入內存。

　　讀者朋友，讀到這裏你應該想明白Map-side Join是怎麼回事了吧！

 

這個問題到此告一段落！