回顧·網易HBase實踐

文根據網易杭州研究院技術專家範欣欣在中國HBase技術社區第3屆 MeetUp 杭州站分享的《網易HBase實踐》編輯整理而成。

回顧·網易HBase實踐


今天主要從四個方面和大家分享HBase,HBase是整個Hadoop裡面非常重要的組件,首先講一下HBase在大數據領域的定位,第二個方面就是網易在HBase方面都有哪些應用場景,接下來講一下HBase中經常會出現的RIT問題,以及用HBCK解決問題的套路。最後講一下我們遇到HBase問題的一些排查思路,在遇到一些相似的問題應該應用哪種方式去解決。

回顧·網易HBase實踐


做Hadoop或者大數據經常會遇到一個問題就是在很多組件或者系統裡面有沒有一種系統能夠解決所有問題呢,後續會繼續探討。HBase組件無所不能,是一個k-v數據庫,通過K查v是沒問題的,通過row-k去查一行數據也是沒問題的。無論是小數據的scan,還是大數據的scan都能運行。那既然HBase啥都能幹為啥還要NoSQL數據庫等其他數據庫,這就衍生出另一個問題HBase適合幹啥。

作為一個K-V數據庫,本能就是通過K來查V;第二個就是根據rowKey去查一行的數據;第三個就是小規模的scan。

回顧·網易HBase實踐


接下來介紹下網易大數據體系整個系統架構。數據來源方面,業務數據來源於MYSQL這類關係型數據庫,還有一個重要來源是日誌系統,另外還有外部APP或者web直接產生的一些打點數據,最後一個數據來源就是sensor,如工業設備監控產生的數據、CPU或者IO的一些指標數據。這些數據經過數據採集器進入數據存儲,數據採集器比如sqoop、datastream(採集日誌數據),還有APP的一些sdk。

這些數據採集器可以將數據取出來通過kafka、sparkstreaming、flink流到存儲系統。存儲系統有些是帶計算功能有些是不帶計算功能,最上面是離線存儲系統,中間是在線存儲、還有個時序存儲系統。

離線存儲系統底層存儲使用HDFS,基於HDFS之上的數據格式有很多種,比如ORC、Parquet、CarbonData等,在其之上可以跑hive、spark、impala。離線存儲系統還有一個比較重要的存儲成員Kudu。除此之外,GP是另一種支持離線存儲計算的數倉系統。在線存儲系統就只有HBase和Phoenix,HBase主要做存儲功能,Phoenix可以做很多計算功能,其中比較重要的是SQL能力和倒排索引能力。另外,除過傳統意義上的離線存儲和在線存儲之外,還有一類存儲系統是時序數據庫,這類系統比如OpenTSDB、Druid、InfluxDB等。當然,不同模式的存儲系統適用於不同的業務場景,比如用離線數據做一些數倉報表、機器學習模型訓練等,HBase主要做交易訂單、商品優惠券、用戶畫像等,時序系統最重要就是監控、廣告營銷系統以及物聯網等。因此可以看出HBase在大數據平臺是一個很重要的組件,在在線存儲平臺佔很重要的地位。

回顧·網易HBase實踐


第二部分講一下網易HBase主要的應用場景,HBase在網易應用時間很久遠,有300+物理機,3PB數據量。應用的業務也非常多,有網易考拉、網易雲音樂、網易新聞客戶端,還包括很多雲服務、大數據服務都是用HBASE做存儲。

回顧·網易HBase實踐


我們通常有很多用戶原始數據,用戶點擊行為、瀏覽信息等數據蒐集會將其流入HDFS中,在結合MR和spark做一些機器學習的工作,訓練一些模型,這些模型數據通過bulkload導入HBase的HDFS中,然後通過HBase提供在線服務。這類業務有新聞推薦,比如通過客戶端看一條新聞,接下來往下看系統就會推薦很多其他相關的新聞,這種數據需要實時產生。實現原理是Hadoop通過前期特徵模型訓練將數據放到HBase裡面,用戶再打開新聞客戶端時模型就會實時推薦出你想要的其他一些新聞。

回顧·網易HBase實踐


第二個應用場景就是內部哨兵系統,監控幾萬臺服務器。監控系統是自研系統,其底層也是用HBase,為什麼不用OpenTSDB?其一是它聚合能力比較差,只能做一些基本的聚合。還有一個就是OpenTSDB的數據採集能力比較弱,因此用HBASE做了哨兵系統。類似OpenTSDB的用法很多,如Kylin,其底層也是用HBase。還有很多圖數據庫底層也是用HBase,HBase在很多通用的查詢底層系統應用很多。

還有一些應用如電商訂單,電商曆史訂單數據都是用HBase存儲,內部消息系統歷史信息也是存在HBase裡面,雲音樂的私信通知,以及網易新聞客戶端APP Push通知都是存在HBase中。還有一些炫酷大屏,因為HBase延遲很小。貨品上下架操作記錄、搜索歷史紀錄、日誌明細歸檔、cdn流量及帶寬數據、信息安全用戶軌跡等等。

回顧·網易HBase實踐


第三部分講一下HBCK和RIT相關的知識,HBCK有兩部分工作,第一部分工作是做數據表的檢查,另一部分工作是表的修復。檢查部分分為兩部分,一部分是一致性的檢查,第二部分是完整性的檢查。HBCK修復方面有很多命令,一種是局部修復一種是高級修復。

HBase Region一致性有兩個含義,其一是說集群中所有region都被assign,而且deploy到唯一一臺RegionServer上。其二是region的狀態在內存中、hbase:meta表中以及zookeeper這三個地方需要保持一致。表的完整性就是一個rowkey只能存在於一個region裡面。HBCK常見的檢查命令就是./bin/hbase hbck、./bin/hbase hbck –details、./bin/hbase hbck TableFoo TableBar,建議做到表級別,如果集群級別的話,HBCK效率會比較低。

回顧·網易HBase實踐


HBCK局部低危修復,80%問題都可以用-fixAssignments、-fixMeta修復。第一個主要修復沒有assign、assign不正確或者同時assign到多臺RegionServer的問題region。第二個是修復元數據,主要修復.regioninfo文件和hbase:meta元數據表的不一致。

修復的原則是以HDFS文件為準:如果region在HDFS上存在,但在hbase.meta表中不存在,就會在hbase:meta表中添加一條記錄。反之如果在HDFS上不存在,而在hbase:meta表中存在,就會將hbase:meta表中對應的記錄刪除。

region區間overlap相關問題的修復屬於高危修復操作,因為這類修復通常需要修改HDFS上的文件,有時甚至需要人工介入。對於這類高危修復操作,建議先執行hbck -details詳細瞭解更多的問題細節,再執行相應的修復命令。但是現實中又很多-repair|、-fix命令導致的,如會導致一個rowkey存在多個region裡面去,因此強烈不建議生產線使用。

回顧·網易HBase實踐


有時集群會出現region沒有deploy到任何regionserver上,出現這種情況不要慌,90%只要執行./hbase hbck –fixAssignments就可以解決。如果實在解決不了,再去看打印的信息。第二種就是region沒有deploy到任何regionserver上且元數據表中對應記錄為空,如果在HBCK輸出的detail中看到“on HDFS,but not listed in hbase :meta or deployed on region server”,可以用./hbase hbck –fixMeta –fixAssignments解決。同樣看到“there is a hole in the region chain”這樣的信息先不用處理,執行完上述修復命令再執行HBCK檢查是否還有不一致現象。

總結下有幾個套路,第一個套路如果狀態是pending_open(或pending_close)狀態的region通常可以使用hbck命令修復,套路二如果是failed_open (或failed_close)狀態的region通常無法使用hbck命令修復,這個時候應該去檢查日誌。套路三failed_open (或failed_close)狀態的region需檢查日誌確認region無法打開關閉的具體原因,套路四:region處於RIT狀態但hbck顯示正常,把zk上的region-in-transaction節點相關region刪除,重啟master就解決了。

回顧·網易HBase實踐


最後介紹下HBase問題排查思路,出現問題先做指標監控分析,再做日誌分析,實在不行而且又很緊急的去網絡求助,如果不是很緊急的一定要通過源碼分析,最後建議一定要將問題從頭到尾覆盤一遍。

一旦業務讀寫響應變慢,寫入阻塞,RS宕機…,第一反應都應該去看監控! 就像發生一起交通事故,第一反應是去看攝像頭。第二個監控做好了,幾乎所有的異常都可以及時反映出來!資源使用情況,隊列使用情況,業務相互干擾情況,Compaction情況,GC情況。

回顧·網易HBase實踐


監控的方面有很多方面,如環境的監控、機器的監控(CPU、IO、網卡、內存),這些基本監控能夠大致告訴你大方向所在,如IO打滿會導致讀或者寫延遲較高。具體是什麼還要去排查下regionserver監控,如regionserver隊列長度、rpc等情況,需要真正排查regionserver的狀態。其狀態能夠告訴你regionserver是否工作正常,而前面是告訴你這臺機器是否工作正常。有時一個regionserver會服務很多表,想知道問題到底是那個表產生的,這個時候就需要表級別的監控。如表級別的讀寫,GPS等,這種就知道是那種業務導致請求量上去,可以找對應業務方進行溝通。

回顧·網易HBase實踐


監控只會告訴你發生問題但是不能告訴你為什麼。這時就需要日誌分析,master日誌負責DDL操作:表的分佈式創建、刪除、修改,balance操作:集群範圍負載均衡,snapshot操作,分佈式快照創建、刪除等,集群宕機恢復調度。Regionserver日誌,region打開關閉操作,用戶讀寫請求記錄,region flush操作等。如果實在解決不了就只能網絡求助,通過搜索引擎,技術論壇群組或者社區郵件等。

範欣欣,網易杭州研究院技術專家,就職於網易研究院後臺技術中心數據庫技術組,專注於HBase的開發運維,熱衷於MySQL等相關數據庫技術。


分享到:


相關文章: