實習四個來月，gui專案幾乎沒什麼大改了，即使有，也是重構的活兒，多數是js的整合，後台**命名再改規範了。。這個慢慢來吧。。
於是這幾天在mentor指導下看oozie邏輯，做一些hive上的優化，實際上是尼瑪在hue上看log，分析效能。。無聊
分析：問題出現的可能性估計有兩個：
一是採用了預設的hashpartitioner從map端分發到reduce，也沒改預設設定，導致了hash到同乙個reducer上，由於vm是global shared的，一堆人在用，這麼多資料塞到乙個reducer不爆才怪。
二是產生了資料傾斜，group by 或者distribute by的key用得不好，被hash到同乙個reducer裡了。
stackoverflow, google, duniaing到幾個可能的切入點，準備嘗試下：
乙個是直接改hive的配置，有***.bytes.pre.reduce, ***.reduce.tasks, ***.skewindata=true，主要是測試硬配置能不能讓reducer適應當前的資料量
另乙個方法是用totalorderpartitioner這個東西去分發，這個比較有意思，簡單講下。
回來後累成狗，繼續刷了幾道leetcode,狀態還不錯，試著提交了兩次就ac了，另幾道也很順利，開心～
洗個頭。。睡覺。。明天還有個英語分享會，你妹夫夫夫夫夫。。睡一覺起來看有什麼好的話題吧。。。。晚安麼麼噠
hive的資料傾斜
1.資料傾斜的解決方案 1.1引數調節 hive.map.aggr true map 端部分聚合，相當於combiner hive.groupby.skewindata true 有資料傾斜的時候進行負載均衡，當選項設定為 true，生成的查詢計畫會有兩個 mr job。第乙個 mr job 中，m...
HIVE的資料傾斜
由於資料分布不均勻，造成資料大量的集中到一點，造成資料熱點 回到頂部 a 不怕資料大，怕資料傾斜 b jobs 數比較多的作業執行效率相對比較低，如子查詢比較多 c sum,count,max,min 等聚集函式，通常不會有資料傾斜問題 回到頂部 任務進度長時間維持在 99 或者 100 的附近，檢...
cajviewer的 linux折騰和吐槽
無營養的吐糟，只為求道友或者貴人，能夠幫助小弟或者共渡難關 qiodevice write device not open你搞個deb包，或者原始碼make不香嗎？唉。現在你好不容易開發個linux客戶端，我卻用不了，你知道我有多痛苦嘛？你還不如告訴我，根本沒有linux客戶端 還好，有經驗的我試了...