技術最近在做資料溯源重構優化，計畫使用業務方的資料跑資料任務，以解決資料質量問題。
過程中，碰到這樣乙個case：某資料需要join n張hive表提資料，其中有這樣乙個業務邏輯要關聯出mmm文章的mmm賬號資訊，文章表記錄數***億+，賬號表yyy萬+，這種資料關係導致在跑mr任務時資料傾斜，某個reduce要處理大部分資料，任務跑了20多個小時沒有完成
問題原因
hive多表join時，每個join會生成乙個mr任務，並以join on條件作為reduce的hash_key
由於業務上不是所有的文章都是pgc發文，文章表裡就會有大量mmm賬號外鍵值為空的資料，約zz億+
就是說zz億+的資料只能被乙個reduce處理，進而導致任務不能按預期完成
引入隨機id解決資料傾斜：文章表在join賬號表時做判斷，如果賬號外來鍵為空，生成隨機id保證hash_key均勻分布
在問題排查過程中除了通過隨機數解決hash_key分布不均的問題，還有幾個優化點：
1. 只查任務相關的資料
a. 只查詢用到的字段
b. 過濾掉任務無關的資料
2. 按資料儲存從小到大的順序關聯從表
a. 內容詳情表***t
b. 最原始一版hql是先join了內容詳情表，任務執行時間也特別長（並且任務執行過程中從一開始就占用較大的儲存資源）
c. 調整表關聯順序，最後join內容詳情表，任務執行符合預期
3. 關於語句巢狀，很早之前寫hql當時有乙個規範，關聯多個從表時一定要通過巢狀子查詢的方式，在同一層級只join一張表（具體原因暫不詳！！！）
上面提到的2個優化點的本質跟mr實現機制相關：mr過程中m的結果只有落盤後，才能被後續環節獲取到。這就很好解釋了：寬表由n張表的資料join出來，從mr的過程看會生成4個job，如果第乙個job就關聯使用了***t的資料，那麼後面3個job也要處理***t+的資料（網路、磁碟io、shuffle都很耗時）
mapreduce資料傾斜
前言 資料傾斜是日常大資料查詢中 的乙個bug，遇不到它時你覺得資料傾斜也就是書本部落格上的乙個無病呻吟的偶然案例，但當你遇到它是你就會懊悔當初怎麼不多了解一下這個赫赫有名的事故。當然你和資料傾斜的緣分深淺還是看你公司的業務邏輯和資料量有沒有步入資料傾斜的領地。說明 關於資料傾斜的產生原因我將結合 ...
MapReduce如何解決資料傾斜問題
前言 資料傾斜是日常大資料查詢中 的乙個bug，遇不到它時你覺得資料傾斜也就是書本部落格上的乙個無病呻吟的偶然案例，但當你遇到它是你就會懊悔當初怎麼不多了解一下這個赫赫有名的事故。當然你和資料傾斜的緣分深淺還是看你公司的業務邏輯和資料量有沒有步入資料傾斜的領地。說明 關於資料傾斜的產生原因我將結合 ...
用mapreduce處理資料傾斜問題
資料傾斜 map reduce程式執行時，reduce節點大部分執行完畢，但是有乙個或者幾個reduce節點執行很慢，導致整個程式的處理時間很長，這是因為某乙個key的條數比其他key多很多 有時是百倍或者千倍之多 這條key所在的reduce節點所處理的資料量比其他節點就大很多，從而導致某幾個節點...