當前位置 > 首頁 > 技術熱點 > 如何避免HBase寫入過快引起的各種問題

一起来捉妖活动cdk:如何避免HBase寫入過快引起的各種問題

一起来捉妖苹果安卓互通吗 www.webzs.icu 來源:中國數據分析行業網 | 時間:2018-04-10 | 作者:數據委

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

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

整個寫入流程從客戶端調用API開始,數據會通過protobuf編碼成一個請求,通過scoket實現的IPC??楸凰痛飐erver的RPC隊列中。最后由負責處理RPC的handler取出請求完成寫入操作。寫入會先寫WAL文件,然后再寫一份到內存中,也就是memstore???,當滿足條件時,memstore才會被flush到底層文件系統,形成HFile。

667

當寫入過快時會遇見什么問題?

寫入過快時,memstore的水位會馬上被推高。

你可能會看到以下類似日志:

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

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

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

或者這樣的日志:

  1. 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
  2. regionserver.MemStoreFlusher:?Memstore?is?above?high?water?mark?and?block?528ms

這是所有region的memstore內存總和開銷超過配置上限,默認是配置heap的40%,這會導致寫入被阻塞。目的是等待flush的線程把內存里的數據flush下去,否則繼續允許寫入memestore會把內存寫爆

  1. hbase.regionserver.global.memstore.upperLimit=0.4??#?較舊版本,新版本兼容
  2. hbase.regionserver.global.memstore.size=0.4?#?新版本

當寫入被阻塞,隊列會開始積壓,如果運氣不好最后會導致OOM,你可能會發現JVM由于OOM crash或者看到如下類似日志:

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

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

如何避免RS OOM?

一種是加快flush速度:

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

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

同樣的道理,如果flush加快,意味這compaction也要跟上,不然文件會越來越多,這樣scan性能會下降,開銷也會增大。

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

增加compaction線程會增加CPU和帶寬開銷,可能會影響正常的請求。如果不是導入數據,一般而言是夠了。好在這個配置在云HBase內是可以動態調整的,不需要重啟。

上述配置都需要人工干預,如果干預不及時server可能已經OOM了,這時候有沒有更好的控制方法?

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

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

來源:51CTO