前言
前段時間，imppala資源告警，各種任務失敗，查詢堵塞，因此公司集群公升級。
這次遷移的確必須，因為當時的集群規模很小，資源太緊張了。
遷移集群後，今天集群再次出問題，導致乙個下午沒什麼事都沒乾，查了一下午的錯誤。
事件發展
1.階段一：下午2點17分
資料組反映集群崩潰，hue介面不能登入，登入之後刷不出來表，當然也不能提交資料。
檢視各種log日誌、任務資訊，發現事件發生前後有兩個現象：
有乙個admin使用者每隔一分鐘提交一次insert任務，一次任務的資料量主要分兩個個等級：500m、900m，他們分別需要30s和1分鐘左右能完成操作。該使用者每隔幾次操作，會執行一次 invalidate metadata操作 資料分析的小夥伴提交了很多個重複的任務，比如select *from tablename limit 100,而且有幾個我很佩服的十多行的sql(目前我是寫不出來)。具體的情況就是，資料分析組的三個人同時對一張表執行各種不同複雜程度的select查詢，因為反映慢了點，所以反覆提交了很多次，包括hue和shell端。
初步分析1： 大量任務 + 反覆提交複雜查詢。單個原因基本不會造成效能瓶頸，極有可能是復合原因。
2.階段二：下午3點1分
正在排查錯誤，還沒完全定位。集群再次罷工。這次不是很嚴重，是有些任務執行十分慢，以前秒出結果，這次要十幾分鐘。
這次從資料分析的小夥伴那裡得知，他們經常做一件很厲害的事：如果乙個查詢結果沒有很快的出來，他們會重新整理頁面再次提交一次，如果還沒出來，會開啟shell，登入集群再次提交。笑臉。
這個時候我驚奇地發現，我們cdh集群的日誌時間是保留30分鐘，我再扭頭看我們的歷史任務記錄，找不到了哎。
與篩選器匹配的查詢超過了能夠顯示的數量。嘗試縮小您的搜尋篩選器或者縮短您要搜尋的時間範圍。
嗯，我愣是沒找到怎麼來規定時間的範圍，根據限制條件來減少搜尋結果不是我想要的。我想要從幾點幾分到幾點幾分的資料。
繼續找，繼續找問題。
3.階段三：下午4點
經過這半個小時的排查，我驚奇地發現乙個問題，上次集群出問題的時候，有很多資料上的異常，比如io、任務數、單機任務壓力。biubiubiu，好幾個引數。
但是!在有些時間段，io、任務數什麼的比這個還要嚴重，但是就是沒出問題。這說明什麼，說明任務失敗是偶然?
初步分析2： hue連線了其中一台impala機器，這樣任務都會通過這台機器來分發，當任務多的時候肯定出問題。
4.階段四：下午4點30
impala集群再次崩潰。
我很開心，因為歷史重演，那我就可以再次拿到錯誤資訊。乾死它我會很開心。
重要：比較重要的是，在出問題的時間，我正好在任務大量提交的那台機器上執行了top命令，而且正好在一直盯著看，可以保證，impala占用記憶體十分小，不超過20%。在cm介面看到的記憶體使用情況上也一直保持穩定，沒有記憶體不夠的現象。
正要開始各種截圖，各種小夥伴來找我了，好，幫忙kill任務，幫他們恢復任務。我這次狠心，把時間超過20分鐘的任務全部kill掉，admin使用者的任務，從服務端kill掉，乙個都別跑。
然後看看乙個複雜sql多久能出來，ok，基本算是秒出。
然後系統基本執行正常。
總結1
這次問題出現的原因總結如下：
乙個使用者大量執行操作(可能會導致任務分發和**時造成io堵塞)各種複雜查詢反覆提交(由於是對同一張表進行的操作，很有可能會對錶造成鎖)導致存放元資料的mysql鎖住 hue提交機的效能瓶頸
其實，單獨任意乙個原因來說，是不足以導致集群在乙個下午出現兩次幾乎不能正常使用的情況。而且即使出問題了，集群的各種效能指數還是比較正常的，至少記憶體絕對夠用。
比如說乙個使用者執行大量的insert操作，其實這些任務本身是能正常執行的，但是當這種任務大量地執行時，很有可能會對整個集群的io造成一定的影響，這時候正好又有一定數量複雜查詢的反覆提交，綜合起來會使集群在某個時間段內出現io或者某些表被鎖住。
還有一種出錯的可能：大量的insert操作或者select操作，會導致對impala的元資料庫進行大量的讀寫，這種頻繁的讀寫操作會造成mysql的鎖表。
總結2
上乙個總結是表象一點的總結。
個人感覺目前系統暴露的問題以及需要做的東西：
任務提交佇列，沒有乙個像yarn那樣管理佇列的功能，導致大家很high地提交自己的任務，無節制啊!許可權，目前沒有許可權管理，大家隨意提交。出問題也難定位。 impala集群負載均衡，這個主要體現在大量任務的提交時導致某台機器崩潰。
就目前的調研結果來看，cdh和impala自帶的一些功能能滿足一定的需求(比如負載均衡和佇列控制)，但是完成力度不夠，比如使用者反覆提交沒法控制(hue沒做什麼處理)，佇列這塊使用起來不是那麼順暢(和yarn整合與否是個問題)，加了haproxy後對現有的業務是否有影響(比如提交impala查詢是不是都要改變?)。
暫考慮先有乙個暫時解決的方案。後期可能需要重新開發一些控制系統。
Impala實踐之十五 Impala使用文件
由於前期大家使用impala的時候都比較隨意，再加上對impala的原理不清楚，因此在使用的過程中對impala帶來了很大的壓力。經過前段時間的研究和實驗。我整理了乙份impala使用文件，供組內小夥伴使用。只有通過hdfs增加或刪除分割槽中檔案後，才需要人為更新元資料，其餘情況依賴impala自帶...
Impala實踐之十三 Impala建表時的關鍵字
由於經常要幫資料分析抽表，因此自己寫了個自動生成impala和sqoop指令碼的工具，結果今天發現乙個庫中17張表，只成功匯入了12張。仔細檢查才發現是是由於impala建表時候字段使用了location關鍵字的原因。建表語句 impala shell i ip 25004 q drop table...
Impala實踐之十一 parquet效能測試
之前一直考慮更換impala的檔案儲存格式為parquet，但是沒有立即使用，最近又做了一些測試，看看parquet是否真的有用。在測試的時候順便測了一下compute語句的效果，一起作為參考。下面抽出乙個小業務的部分測試結果來展示。庫名和表名當然不是真的。表名行數 字段數物理儲存大小 ain342...