面對海量資料儲存，如何保證HBase叢集的高效以及穩定
內容來源： 2018 年 09 月 15 日，平安科技資料平臺部大資料高階工程師鄧傑在“中國HBase技術社群第五屆MeetUp ——HBase應用與發展”進行《HBase應用與實踐》的演講分享。IT 大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數： 3315 | 9分鐘閱讀
觀看嘉賓完整演講視訊及PPT ，請點選：t.cn/E23igdc。
摘要
本次演講首先給大家介紹一下平安科技使用HBase的現狀，以及給使用者解決了哪些問題，然後是如何保證HBase叢集的高效以及它的穩定的。
平安科技HBase的使用現狀
我們這邊HBase的使用現狀，可以從以下兩個方面來講，第一個是HBase的叢集規模以及資料量。第二個是它的應用場景。HBase叢集方面現在是由300多臺物理機組成，資料量大概有兩個P兩個pb左右。
解決了使用者哪些問題
HBase的應用上，使用者可能首先要面臨的是海量資料的儲存問題，然後是對效能和可靠性的關注。最後一個可能是資料的遷移問題。
從使用者層面來講，他們在使用傳統資料庫的時候，由於無法預估業務應用場景，造成無法判斷接下來會面臨多大的資料量。所以我們建議使用者將資料接入到HBase叢集裡面，HBase是支援線上擴容的，即使後續使用的過程中，某段時間資料出現爆炸式增長，我們也可以通過HBase進行橫向擴容來滿足需求。
在使用傳統的DB時候，其實在維護和擴充套件方面都會遇到很多問題，而如果遷移到HBase上，進行擴容和維護就會很方便的。
客戶端優化
效能和高可用問題也是使用者關注的重點，效能方面主要在於應用程式對HBase叢集的呼叫。
先講下客戶端優化的方案，上圖列出了幾個常見的優化點，首先第一個是基於應用層面的scan操作，此時客戶端向HBase的請求後，資料並不是一次性全部返回，而是通過多次的RPC請求互動得到資料。在這方面如果請求的資料量很大，可以通過去調整一下引數來減少RPC的互動，從而降低耗時。
另一個優化點是在get方面的，在HBase既可以一次性get整個資料，也可以進行批量的get操作。我們一般建議批量的使用get，其原理主要是為了去減少使用者RPC的互動次數。
接下來是列簇及列的優化。HBase中相同的列簇資料是存在一個目錄的，不同列簇資料分開進行儲存。在有多個列簇的情況下進行檢索，如果只是用key檢索，而沒有指定列簇，索引是要獨立去檢索的。這種情況相比指定列簇檢索，效率是比較低的，也就是列簇越多影響就會越大。
第四個是禁止快取，我們在寫資料的時候，如果客戶端突然載入了大量的資料，而沒有禁止快取，可能就會把熱資料會擠壓出去。
擠壓出去的後果會導致其他業務檢索HBase的時候，需要到HDFS裡面去重新的去載入，這就造成了延時。
服務端層面優化
這裡服務端層面也列舉了幾種比較常見的優化手段。首先是均衡的優化，在HBase中均衡操作有兩種方式，一種是通過balance_switch，它後面會跟一個引數，如果是true的話，就開啟自動均衡。如果指定為false的話，就關閉當前的自動均衡。
另一種是使用balancer，這種方式可能需要去手動的執行，比如HBase節點掛了之後重啟了，其中間隔的時間內Region又不均衡。還有一種情況是擴容新的HBase節點後，Region沒有均衡。此時如果開啟balance_switch沒有效果，就要通過手動的方式，強制的讓它均衡。
第二個優化是在Blockce，在快取命中率不高的時候，可以開啟對外記憶體，然後來提高它的命中率，同時該操作對GC也是有好處的。
第三個是Compaction的操作，它可以保證的資料的本地性唯一。在實際的應用的場景下，我們會避免自動執行Compaction操作，因為自動執行可能會影響叢集的IO，從而對使用者的應用讀寫產生影響。所以我們需要改為手動的定義執行。在週末或者訪問量不是的時候，執行Compaction操作。
執行Compaction操作的時候，有兩個屬性是可以優化的。由於預設情況下，執行緒數是1，因此在資料量很大的時候，耗時會長一些 。我們可以根據叢集的規模，或者叢集應用的影響度，來適當的調整引數，以提高Compaction執行的速度。
另外一個優化點可能是使用者比較關心的可靠性。因為HBase是高可用的叢集，可以做主備切換，所以不用擔心單點問題。master掛了之後，可以立即切換到BackUpMaster，然後BackUpMaster會將角色狀態切換成可用並對外提供服務。
資料遷移
資料遷移有幾種情況。一種是HBase叢集之間的遷移，一種是將Hive資料遷移到HBase。
首先分析第一種情況，兩個叢集之間遷移的話，由於它們的資料格式是一樣，所以可以直接使用distcp的方式來進行遷移。這裡因為要用到mapreduce，所以要指定佇列名。
遷移過程當中需要注意以下四項。
-
開啟YARN，distcp使用Mapreduce來傳輸資料，因此遷移之前需要確保叢集資源可用。
-
防火牆，兩個HBase叢集之間埠要能正常訪問telnet，例如NN、DN的埠。
-
使用HBase Hbck修復元資料資訊
上圖為跨叢集遷移的一個案例，產生這種問題的原因是HDFS中的檔案沒有關閉，處於寫狀態，而每次distcp時會校驗檔案長度，如果檔案處於關閉狀態，就會出現這種異常。
對於這種情況，我們可以先檢測檔案的狀態，然後關閉該檔案，重新進行資料遷移。 在關閉的時候可能會出現異常導致關閉失敗，對此可以重複執行關閉操作直到成功，
將Hive的資料遷移到HBase有兩種方案，第一種方案不需要寫程式碼，直接在叢集A中生成HFile檔案，然後使用distcp將HFile檔案遷移到叢集B，最後使用HBase的BulkLoad的方式將資料匯入到HBase表。
另一種比較高階的方式，使用API介面，直接通過BulkLoad的方式進行資料遷移，以應用程式的形式來實現資料遷移。
如何保證HBase叢集的高效及穩定
要保證HBase叢集的高效和穩定，監控系統和修復機制是必不可少的，在實質上還有一些特殊的處理。
首先來看一下監控系統。只要將HBase的全部指標都採集到，就相當於是掌握了整個HBase叢集的健康狀態。我們可以通過regionserver提供的相應解碼介面對HBase節點上的指標進行採集，然後將核心的指標繪製出來。
關於修復機制這塊，需要監控系統和修復系統聯合起來，由監控系統發現問題並反饋問題，然後再由修復系統去自動修復，例如叢集程序可用性、存在性、負載均衡修復等。
最後還有一些特殊處理，HBase裡遇到比較多的就是永久RIT的問題，一般情況下，RIT都是瞬時的，但是有些情況會讓其進入永久RIT狀態，所帶來的不良後果就是管理員無法干預Region均衡操作，從而影響叢集的負載均衡。
對於如何解決這種問題，我們先來看個案例。在該案例中合併Region操作時，發現RIT一直顯示MERGING NEW狀態，檢視HBase JIRA發現這是觸發了HBASE-17682的BUG，需要打補丁進行修復。
我們來分析這種情況產生的原因，首先客戶端發起合併請求的命令，然後由master組織一個RegionServer上面的兩個region進行去合併，在合併操作之前，它會生成一個初始化的MERGING NEW的狀態，並存在master的記憶體裡面。
這樣我們就清楚了，當前的master有MERGING NEW狀態，而BackUpMaster裡沒有該狀態，直接進行主備切換就可以解決問題。
以上為今天的分享內容，謝謝大家！
編者：IT大咖說，轉載請標明版權和出處