网易HBase实践
文根據(jù)網(wǎng)易杭州研究院技術專家范欣欣在中國HBase技術社區(qū)第3屆 MeetUp 杭州站分享的《網(wǎng)易HBase實踐》編輯整理而成。
今天主要從四個方面和大家分享HBase，HBase是整個Hadoop里面非常重要的組件，首先講一下HBase在大數(shù)據(jù)領域的定位，第二個方面就是網(wǎng)易在HBase方面都有哪些應用場景，接下來講一下HBase中經(jīng)常會出現(xiàn)的RIT問題，以及用HBCK解決問題的套路。最后講一下我們遇到HBase問題的一些排查思路，在遇到一些相似的問題應該應用哪種方式去解決。
做Hadoop或者大數(shù)據(jù)經(jīng)常會遇到一個問題就是在很多組件或者系統(tǒng)里面有沒有一種系統(tǒng)能夠解決所有問題呢，后續(xù)會繼續(xù)探討。HBase組件無所不能，是一個k-v數(shù)據(jù)庫，通過K查v是沒問題的，通過row-k去查一行數(shù)據(jù)也是沒問題的。無論是小數(shù)據(jù)的scan，還是大數(shù)據(jù)的scan都能運行。那既然HBase啥都能干為啥還要NoSQL數(shù)據(jù)庫等其他數(shù)據(jù)庫，這就衍生出另一個問題HBase適合干啥。
作為一個K-V數(shù)據(jù)庫，本能就是通過K來查V；第二個就是根據(jù)rowKey去查一行的數(shù)據(jù)；第三個就是小規(guī)模的scan。
接下來介紹下網(wǎng)易大數(shù)據(jù)體系整個系統(tǒng)架構(gòu)。數(shù)據(jù)來源方面，業(yè)務數(shù)據(jù)來源于MYSQL這類關系型數(shù)據(jù)庫，還有一個重要來源是日志系統(tǒng)，另外還有外部APP或者web直接產(chǎn)生的一些打點數(shù)據(jù)，最后一個數(shù)據(jù)來源就是sensor，如工業(yè)設備監(jiān)控產(chǎn)生的數(shù)據(jù)、CPU或者IO的一些指標數(shù)據(jù)。這些數(shù)據(jù)經(jīng)過數(shù)據(jù)采集器進入數(shù)據(jù)存儲，數(shù)據(jù)采集器比如sqoop、datastream（采集日志數(shù)據(jù)），還有APP的一些sdk。
這些數(shù)據(jù)采集器可以將數(shù)據(jù)取出來通過kafka、sparkstreaming、flink流到存儲系統(tǒng)。存儲系統(tǒng)有些是帶計算功能有些是不帶計算功能，最上面是離線存儲系統(tǒng)，中間是在線存儲、還有個時序存儲系統(tǒng)。
離線存儲系統(tǒng)底層存儲使用HDFS，基于HDFS之上的數(shù)據(jù)格式有很多種，比如ORC、Parquet、CarbonData等，在其之上可以跑hive、spark、impala。離線存儲系統(tǒng)還有一個比較重要的存儲成員Kudu。除此之外，GP是另一種支持離線存儲計算的數(shù)倉系統(tǒng)。在線存儲系統(tǒng)就只有HBase和Phoenix，HBase主要做存儲功能，Phoenix可以做很多計算功能，其中比較重要的是SQL能力和倒排索引能力。另外，除過傳統(tǒng)意義上的離線存儲和在線存儲之外，還有一類存儲系統(tǒng)是時序數(shù)據(jù)庫，這類系統(tǒng)比如OpenTSDB、Druid、InfluxDB等。當然，不同模式的存儲系統(tǒng)適用于不同的業(yè)務場景，比如用離線數(shù)據(jù)做一些數(shù)倉報表、機器學習模型訓練等，HBase主要做交易訂單、商品優(yōu)惠券、用戶畫像等，時序系統(tǒng)最重要就是監(jiān)控、廣告營銷系統(tǒng)以及物聯(lián)網(wǎng)等。因此可以看出HBase在大數(shù)據(jù)平臺是一個很重要的組件，在在線存儲平臺占很重要的地位。
第二部分講一下網(wǎng)易HBase主要的應用場景，HBase在網(wǎng)易應用時間很久遠，有300+物理機，3PB數(shù)據(jù)量。應用的業(yè)務也非常多，有網(wǎng)易考拉、網(wǎng)易云音樂、網(wǎng)易新聞客戶端，還包括很多云服務、大數(shù)據(jù)服務都是用HBASE做存儲。
我們通常有很多用戶原始數(shù)據(jù)，用戶點擊行為、瀏覽信息等數(shù)據(jù)搜集會將其流入HDFS中，在結(jié)合MR和spark做一些機器學習的工作，訓練一些模型，這些模型數(shù)據(jù)通過bulkload導入HBase的HDFS中，然后通過HBase提供在線服務。這類業(yè)務有新聞推薦，比如通過客戶端看一條新聞，接下來往下看系統(tǒng)就會推薦很多其他相關的新聞，這種數(shù)據(jù)需要實時產(chǎn)生。實現(xiàn)原理是Hadoop通過前期特征模型訓練將數(shù)據(jù)放到HBase里面，用戶再打開新聞客戶端時模型就會實時推薦出你想要的其他一些新聞。
?
第二個應用場景就是內(nèi)部哨兵系統(tǒng)，監(jiān)控幾萬臺服務器。監(jiān)控系統(tǒng)是自研系統(tǒng)，其底層也是用HBase，為什么不用OpenTSDB？其一是它聚合能力比較差，只能做一些基本的聚合。還有一個就是OpenTSDB的數(shù)據(jù)采集能力比較弱，因此用HBASE做了哨兵系統(tǒng)。類似OpenTSDB的用法很多，如Kylin，其底層也是用HBase。還有很多圖數(shù)據(jù)庫底層也是用HBase，HBase在很多通用的查詢底層系統(tǒng)應用很多。
還有一些應用如電商訂單，電商歷史訂單數(shù)據(jù)都是用HBase存儲，內(nèi)部消息系統(tǒng)歷史信息也是存在HBase里面，云音樂的私信通知，以及網(wǎng)易新聞客戶端APP?Push通知都是存在HBase中。還有一些炫酷大屏，因為HBase延遲很小。貨品上下架操作記錄、搜索歷史紀錄、日志明細歸檔、cdn流量及帶寬數(shù)據(jù)、信息安全用戶軌跡等等。
?
第三部分講一下HBCK和RIT相關的知識，HBCK有兩部分工作，第一部分工作是做數(shù)據(jù)表的檢查，另一部分工作是表的修復。檢查部分分為兩部分，一部分是一致性的檢查，第二部分是完整性的檢查。HBCK修復方面有很多命令，一種是局部修復一種是高級修復。
HBase?Region一致性有兩個含義，其一是說集群中所有region都被assign，而且deploy到唯一一臺RegionServer上。其二是region的狀態(tài)在內(nèi)存中、hbase:meta表中以及zookeeper這三個地方需要保持一致。表的完整性就是一個rowkey只能存在于一個region里面。HBCK常見的檢查命令就是./bin/hbase?hbck、./bin/hbase?hbck?–details、./bin/hbase?hbck?TableFoo?TableBar，建議做到表級別，如果集群級別的話，HBCK效率會比較低。
HBCK局部低危修復，80%問題都可以用-fixAssignments、-fixMeta修復。第一個主要修復沒有assign、assign不正確或者同時assign到多臺RegionServer的問題region。第二個是修復元數(shù)據(jù)，主要修復.regioninfo文件和hbase:meta元數(shù)據(jù)表的不一致。
修復的原則是以HDFS文件為準：如果region在HDFS上存在，但在hbase.meta表中不存在，就會在hbase:meta表中添加一條記錄。反之如果在HDFS上不存在，而在hbase:meta表中存在，就會將hbase:meta表中對應的記錄刪除。
region區(qū)間overlap相關問題的修復屬于高危修復操作，因為這類修復通常需要修改HDFS上的文件，有時甚至需要人工介入。對于這類高危修復操作，建議先執(zhí)行hbck?-details詳細了解更多的問題細節(jié)，再執(zhí)行相應的修復命令。但是現(xiàn)實中又很多-repair|、-fix命令導致的，如會導致一個rowkey存在多個region里面去，因此強烈不建議生產(chǎn)線使用。
?
有時集群會出現(xiàn)region沒有deploy到任何regionserver上，出現(xiàn)這種情況不要慌，90%只要執(zhí)行./hbase?hbck?–fixAssignments就可以解決。如果實在解決不了，再去看打印的信息。第二種就是region沒有deploy到任何regionserver上且元數(shù)據(jù)表中對應記錄為空，如果在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”這樣的信息先不用處理，執(zhí)行完上述修復命令再執(zhí)行HBCK檢查是否還有不一致現(xiàn)象。
總結(jié)下有幾個套路，第一個套路如果狀態(tài)是pending_open（或pending_close）狀態(tài)的region通常可以使用hbck命令修復，套路二如果是failed_open?（或failed_close）狀態(tài)的region通常無法使用hbck命令修復，這個時候應該去檢查日志。套路三failed_open?（或failed_close）狀態(tài)的region需檢查日志確認region無法打開關閉的具體原因，套路四：region處于RIT狀態(tài)但hbck顯示正常，把zk上的region-in-transaction節(jié)點相關region刪除，重啟master就解決了。
?
最后介紹下HBase問題排查思路，出現(xiàn)問題先做指標監(jiān)控分析，再做日志分析，實在不行而且又很緊急的去網(wǎng)絡求助，如果不是很緊急的一定要通過源碼分析，最后建議一定要將問題從頭到尾復盤一遍。
一旦業(yè)務讀寫響應變慢，寫入阻塞，RS宕機…，第一反應都應該去看監(jiān)控！?就像發(fā)生一起交通事故，第一反應是去看攝像頭。第二個監(jiān)控做好了，幾乎所有的異常都可以及時反映出來！資源使用情況，隊列使用情況，業(yè)務相互干擾情況，Compaction情況，GC情況。
?
監(jiān)控的方面有很多方面，如環(huán)境的監(jiān)控、機器的監(jiān)控（CPU、IO、網(wǎng)卡、內(nèi)存），這些基本監(jiān)控能夠大致告訴你大方向所在，如IO打滿會導致讀或者寫延遲較高。具體是什么還要去排查下regionserver監(jiān)控，如regionserver隊列長度、rpc等情況，需要真正排查regionserver的狀態(tài)。其狀態(tài)能夠告訴你regionserver是否工作正常，而前面是告訴你這臺機器是否工作正常。有時一個regionserver會服務很多表，想知道問題到底是那個表產(chǎn)生的，這個時候就需要表級別的監(jiān)控。如表級別的讀寫，GPS等，這種就知道是那種業(yè)務導致請求量上去，可以找對應業(yè)務方進行溝通。
?
監(jiān)控只會告訴你發(fā)生問題但是不能告訴你為什么。這時就需要日志分析，master日志負責DDL操作：表的分布式創(chuàng)建、刪除、修改，balance操作：集群范圍負載均衡，snapshot操作，分布式快照創(chuàng)建、刪除等，集群宕機恢復調(diào)度。Regionserver日志，region打開關閉操作，用戶讀寫請求記錄，region?flush操作等。如果實在解決不了就只能網(wǎng)絡求助，通過搜索引擎，技術論壇群組或者社區(qū)郵件等。
作者介紹：
范欣欣，網(wǎng)易杭州研究院技術專家，就職于網(wǎng)易研究院后臺技術中心數(shù)據(jù)庫技術組，專注于HBase的開發(fā)運維，熱衷于MySQL等相關數(shù)據(jù)庫技術
文章來源：https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247486139&idx=1&sn=f2ce610769781d6df0bb7471b2b97985&chksm=fbd4b8d7cca331c1d220c0159358e44cf192ebf68c831fcf6d1969f83c1fa059ace44dfa239a&mpshare=1&scene=1&srcid=0925eHpPMOgKUPM5qmLa0Vr7#rd
總結(jié)
- 上一篇： html象棋开题报告设计要求,C++游戏
- 下一篇： kotlin的map