close
hadoop的使用中，一般只關註運行結果。對於mapper和reducer之間的處理邏輯往往不care。比如key-value對到達reducer的先後順序等
目前接觸到的運用場景有：
1.根據用戶操作時間來整理事件鏈，在網站分析裏比較常用。需要按時間先後順序來處理，如果過億的訪問操作全在reducer裏來排序，對計算能力和內存都是一個挑戰。
2.海量數據處理中，求去重distinct這種操作，往往需要先緩存很大的數據集，對單個reducer的內存要求很高，特別是上億的數據時，很容易就撐爆內存。這裏如果在reducer進入前就排好序，後續處理就簡單的多。
二次排序相當於把一個reducer的負載推給了多個maper。
例子：如果我們要將日誌按用戶的訪問時間排序。
1.map階段輸出key-value對：key是 : uid,sid,time value是url,time
2.進入二次排序。
3.進入reducer的key-valuelist：key是: uid,sid valuelist是： [{url1,time2},{url,time2},……]
其中valuelist是按time來排序的。
這裏說下階段2，以下三個都是可以由用戶定義的：
1.partition： 簡單粗暴的解釋就記錄即將進入的reducer實例的ID
2.group： 群組，一個事件鏈表。所以群組裏的記錄會比較時間，而群組間則不會。
3.key map輸出的key
你要寫這三個類，hadoop會調用這幾個函數來比較。你可以自己定義比較的邏輯，是字典排序還是數字排序，是從大到小，還是從小到大。 具體實現可以看hadoop權威指南。
需要強調的是：
1. 一個群組會在一個reduce函數裏被處理。
例 如：
在配置裏指定30個reducer ，日誌裏根據uidsid會有100個group 。平均1個reducer進程會調多次次reduce函數，處理多個group。所以每次處理一個group後，相關變量要清理。
2.進入reducer時候，key是group裏定義的key ，已經不是map輸出的那個key了，被丟棄了。
所以時間要放到value裏傳遞進來。
全站熱搜
留言列表
