【HBase從入門到精通系列】如何避免HBase寫入過快引發的各類問題

摘要： 首先咱們簡單回顧下整個寫入流程 client api ==> RPC ==> server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to filesystem 整個寫入流程從客戶端調用API開始，數據會經過protobuf編碼成一個請求，經過scoket實現的IPC模塊被送達server的RPC隊列中。

首先咱們簡單回顧下整個寫入流程

client api ==> RPC ==> server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to filesystem

整個寫入流程從客戶端調用API開始，數據會經過protobuf編碼成一個請求，經過scoket實現的IPC模塊被送達server的RPC隊列中。最後由負責處理RPC的handler取出請求完成寫入操做。寫入會先寫WAL文件，而後再寫一份到內存中，也就是memstore模塊，當知足條件時，memstore纔會被flush到底層文件系統，造成HFile。

當寫入過快時會碰見什麼問題？

寫入過快時，memstore的水位會立刻被推高。 

你可能會看到如下相似日誌：

RegionTooBusyException: Above memstore limit, regionName=xxxxx ...

這個是Region的memstore佔用內存大小超過正常的4倍，這時候會拋異常，寫入請求會被拒絕，客戶端開始重試請求。當達到128M的時候會觸發flush memstore，當達到128M * 4還無法觸發flush時候會拋異常來拒絕寫入。兩個相關參數的默認值以下：

hbase.hregion.memstore.flush.size=128M hbase.hregion.memstore.block.multiplier=4

或者這樣的日誌：

regionserver.MemStoreFlusher: Blocking updates on hbase.example.host.com,16020,1522286703886: the global memstore size 1.3 G is >= than blocking 1.3 G size regionserver.MemStoreFlusher: Memstore is above high water mark and block 528ms

這是全部region的memstore內存總和開銷超過配置上限，默認是配置heap的40%，這會致使寫入被阻塞。目的是等待flush的線程把內存裏的數據flush下去，不然繼續容許寫入memestore會把內存寫爆

hbase.regionserver.global.memstore.upperLimit=0.4 # 較舊版本，新版本兼容 hbase.regionserver.global.memstore.size=0.4 # 新版本

當寫入被阻塞，隊列會開始積壓，若是運氣很差最後會致使OOM，你可能會發現JVM因爲OOM crash或者看到以下相似日誌：

ipc.RpcServer: /192.168.x.x:16020 is unable to read call parameter from client 10.47.x.x java.lang.OutOfMemoryError: Java heap space

HBase這裏我認爲有個很很差的設計，捕獲了OOM異常卻沒有終止進程。這時候進程可能已經無法正常運行下去了，你還會在日誌裏發現不少其它線程也拋OOM異常。好比stop可能根本stop不了，RS可能會處於一種僵死狀態。

如何避免RS OOM？

一種是加快flush速度：

hbase.hstore.blockingWaitTime = 90000 ms hbase.hstore.flusher.count = 2 hbase.hstore.blockingStoreFiles = 10

當達到hbase.hstore.blockingStoreFiles配置上限時，會致使flush阻塞等到compaction工做完成。阻塞時間是hbase.hstore.blockingWaitTime，能夠改小這個時間。hbase.hstore.flusher.count能夠根據機器型號去配置，惋惜這個數量不會根據寫壓力去動態調整，配多了，非導入數據多場景也沒用，改配置還得重啓。

一樣的道理，若是flush加快，意味這compaction也要跟上，否則文件會愈來愈多，這樣scan性能會降低，開銷也會增大。

hbase.regionserver.thread.compaction.small = 1 hbase.regionserver.thread.compaction.large = 1

增長compaction線程會增長CPU和帶寬開銷，可能會影響正常的請求。若是不是導入數據，通常而言是夠了。好在這個配置在雲HBase內是能夠動態調整的，不須要重啓。

上述配置都須要人工干預，若是干預不及時server可能已經OOM了，這時候有沒有更好的控制方法？

hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G

直接限制隊列堆積的大小。當堆積到必定程度後，事實上後面的請求等不到server端處理完，可能客戶端先超時了。而且一直堆積下去會致使OOM，1G的默認配置須要相對大內存的型號。當達到queue上限，客戶端會收到CallQueueTooBigException 而後自動重試。經過這個能夠防止寫入過快時候把server端寫爆，有必定反壓做用。線上使用這個在一些小型號穩定性控制上效果不錯。

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：