一、概況
集羣環境如下表：
| 集羣 | 機器 | 存儲 | 內存 | CPU | 每日數據 | ||||
| HW大數據平臺 | 160臺 | 6PB | 10TB | 8000 | 10億 |
數據存儲在kafka中，130個分區，採用sparkstreaming將數據清洗後，通過phoneix批量寫入hbase。
二、kafka原因排查
sparkstreaming拉取kafka的時候，卡死在這一步，如下圖所示：
sparkstreaming讀取kafka的數據採用Direct 模式讀取kafka數據，檢查點在客戶端維護offset，任務運行不是很穩定，偶爾會出現延遲幾分鐘。
- 推測執行
- kafka客戶端版本
- offset跳躍
三、hbase原因排查
hbase寫入慢的時候，查看線程堆棧，發現卡在這一步，如圖所示：
- 寫熱點
- hbase的處理線程數
- hbase的memstore大小
- hbase的flush、合併、split
- 代碼頻繁創建連接
四、規律蒐集
上述問題排查了已經一個月了，各種辦法都試過了，期間kafka端的阻塞已經解決了，寫入hbase慢。各種百度，以及hbase的原理也看了一遍又一遍，大數據平臺上的監控也一直盯着看，也沒有解決寫入慢的問題。
到這一步基本可以確定是hbase寫入延遲導致sparkstreaming任務延遲越來越高。
10s鍾一個批次的任務，5*26個處理core，基本從下午4點半到第二天早上9點半都很快，在3s中左右處理完成，期間雖然寫入有波動，但是基本都可以很快平穩，但是9點半以後基本每個批次都要10s以上，sparkstreaming延遲越來越高，每個批次寫入的數量和之前並無變化，也沒有數據傾斜。
因爲sparkstreaming的日誌都比較散，很艱難的發現了。
#1, waiting for 2 actions to finish on table: WIFI_MAC_FAST_QUERY
Left over 2 task(s) are processed on server(s): [xlhd-b1805-hbase41,21302,1568195573413]
客戶端寫等待，這不是很正常嘛，可能是服務端內部活動，導致的吧？唉，於是想收集一下，看看是不是寫等待多的時候，導致sparkstreaming，這怎麼統計？？？？。
幸好，現場之前基於elk做過日誌蒐集，採用擴展logback的插件，將數據直接從服務接引到es，並且成功集成了sparkstreaming，tomcat，springboot等框架，於是將o.a.h.h.c.AsyncProcess類打的日誌採集到es，去尋找規律。
上圖真是來的太及時了，蒐集了sparkstreaming散開的日誌，聚合在一起，發現寫等待還是比較大的，但是最重要的發現是寫等待的regionserver居然都是hbase41這個節點，難道有熱點寫，去大數據平臺查看，沒有發生熱點寫，每個regionserver的請求很平穩，於是登陸這臺機器進行一通linux命令，top，iostat，sar，ifconfig，ping等，發現丟包，哈哈。
-
於是將該節點的regionserver停掉，發現基本每個批次3s左右都可以處理完，通知運維去機房解決網絡問題。