hbase緩存

⑴ hbase 的數據存儲及Region變化（flush compaction spilt）和性能調優

1. 對表做預分區處理（即在建表時指定Region數量和拆分邊界）；

2.配置hbase.hregion.max.filesize為50GB

以fileServer為例，在使用默認的split策略-- 的情況下，16個預分區Region, 則單個Resion容量達到 min(32,50),即32GB時分裂。

3.修改Linux最大文件句柄數

因為hbase是以文件的形式存儲數據，最大文件句柄數影響著hbase的並發量。

用root許可權修改/etc/security/limits.conf文件，增加以下內容（前面的*不能忽略）：

*              soft    nproc          10240

*              hard    nproc          10240

*              soft    nofile          10240

*              hard    nofile          10240 

編輯/etc/pam.d/common-session，加入一行

session required  pam_limits.so

編輯/etc/profile，加入

ulimit -SHn 51200

重新登陸，生效

4.HRegionServer掛掉異常和解決：

is not online on......

常規解決方案：

  刪除zk中hbase的緩存

  重啟hbase

使用上述解決方案後本次異常依舊存在，並且HMaster和HRegionServer都不斷的自動掛掉。

HMaster報錯：

解決方案：

新增配置（看情況決定使用不使用，建議在HMaster不能啟動時排除錯誤使用）（讓啟動hbase時只讓HMaster去進行日誌split，缺點是恢復數據時候速度慢）：

<property>

<name>hbase.master.distributed.log.splitting</name>

<value>false</value>

</property>

   刪除WAL文件（會丟數據）：

6. RPC請求的最大線程數

hbase.regionserver.handler.count  默認是10，在伺服器測試時建議設置到50（經測試在單個Region Server時無用，單個RegionServer 最多在6個線程put時保持穩定）

7.日誌分割（hbase出錯後恢復數據）

MemStore中大量更新丟失時，對數據進行恢復時會做日誌分割

hbase.regionserver.hlog.splitlog.writer.threads 日誌分割的線程數， 默認為3 ，建議設定為10

8.Region Server頻繁掉線

出現Hbase Region Server頻繁掉線的情況，表現為在多線程put的情況下，忽然Hbase Region Server掉線

猜測是GC或者split過程中沒有及時和ZK通信，導致與ZK連接時間超時，zk返回dead region到master，當Hbase Region恢復正常後，找不到wal,產生如下報錯。

zookeeper.session.timeout ：默認值是3分鍾

但是 hbase regionserver和zookeeper的timeout不是單方面決定的，是取決於hbase的zookeeper.session.timeout和zookeeper的MaxSessionTimeout中的最小值

配置hbase:

zookeeper.session.timeout

600000

配置zookeeper:

tickTime=30000

9.內存及GC優化

在測試的過程中依舊出現Hbase Region Server掉線的情況，報錯如下

2021-02-0318:49:14,091INFO[sync.0]wal.FSHLog: Slow sync cost:1955ms, current pipeline: []

2021-02-0318:49:14,091WARN[regionserver/botsc/192.168.0.107:16020.append-pool5-t1]wal.MetricsWAL: regionserver/botsc/192.168.0.107:16020.append-pool5-t1 took1953ms appending an edit to wal; len~=109

2021-02-0318:49:14,106ERROR[sync.3]wal.FSHLog:Errorsyncing, request close of WAL

java.io .IOException:io.grpc.StatusRuntimeException: CANCELLED: Failed to stream message

    at seaweed.hdfs.SeaweedOutputStream.(SeaweedOutputStream.java:78)

    at seaweed.hdfs.SeaweedOutputStream.(SeaweedOutputStream.java:263)

    at seaweed.hdfs.SeaweedOutputStream.flushInternalAsync(SeaweedOutputStream.java:243)

    at seaweed.hdfs.SeaweedOutputStream.flush(SeaweedOutputStream.java:129)

at java.io .FilterOutputStream.flush(FilterOutputStream.java:140)

at java.io .DataOutputStream.flush(DataOutputStream.java:123)

    at org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter.sync(ProtobufLogWriter.java:170)

    at org.apache.hadoop.hbase.regionserver.wal.FSHLog$SyncRunner.run(FSHLog.java:1286)

    at java.lang.Thread.run(Thread.java:748)

修改hbase的配置文件hbase-env.sh，GC優化如下：

export HBASE_HEAPSIZE=21384

export master_heapsize=8292

export regionserver_heapsize=21384

export HBASE_OPTS="$HBASE_OPTS -XX:+UseConcMarkSweepGC -XX:=60 -XX:+UseParNewGC -XX:ParallelGCThreads=6"

export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx8g -Xms8g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:=70"

export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx20g -Xms20g -Xmn1g -XX:+UseParNewGC

-XX:+UseConcMarkSweepGC -XX:=70"

⑵ HBase 寫性能優化

上一篇文章主要介紹了HBase讀性能優化的基本套路，本篇文章來說道說道如何診斷HBase寫數據的異常問題以及優化寫性能。和讀相比，HBase寫數據流程倒是顯得很簡單：數據先順序寫入HLog，再寫入對應的緩存Memstore，當Memstore中數據大小達到一定閾值（128M）之後，系統會非同步將Memstore中數據flush到HDFS形成小文件。

HBase數據寫入通常會遇到兩類問題，一類是寫性能較差，另一類是數據根本寫不進去。這兩類問題的切入點也不盡相同，如下圖所示：

優化原理：數據寫入流程可以理解為一次順序寫WAL+一次寫緩存，通常情況下寫緩存延遲很低，因此提升寫性能就只能從WAL入手。WAL機制一方面是為了確保數據即使寫入緩存丟失也可以恢復，另一方面是為了集群之間非同步復制。默認WAL機制開啟且使用同步機制寫入WAL。首先考慮業務是否需要寫WAL，通常情況下大多數業務都會開啟WAL機制（默認），但是對於部分業務可能並不特別關心異常情況下部分數據的丟失，而更關心數據寫入吞吐量，比如某些推薦業務，這類業務即使丟失一部分用戶行為數據可能對推薦結果並不構成很大影響，但是對於寫入吞吐量要求很高，不能造成數據隊列阻塞。這種場景下可以考慮關閉WAL寫入，寫入吞吐量可以提升2x~3x。退而求其次，有些業務不能接受不寫WAL，但可以接受WAL非同步寫入，也是可以考慮優化的，通常也會帶來1x～2x的性能提升。

優化推薦：根據業務關注點在WAL機制與寫入吞吐量之間做出選擇

其他注意點：對於使用Increment操作的業務，WAL可以設置關閉，也可以設置非同步寫入，方法同Put類似。相信大多數Increment操作業務對WAL可能都不是那麼敏感～

優化原理：HBase分別提供了單條put以及批量put的API介面，使用批量put介面可以減少客戶端到RegionServer之間的RPC連接數，提高寫入性能。另外需要注意的是，批量put請求要麼全部成功返回，要麼拋出異常。

優化建議：使用批量put進行寫入請求

優化原理：業務如果可以接受異常情況下少量數據丟失的話，還可以使用非同步批量提交的方式提交請求。提交分為兩階段執行：用戶提交寫請求之後，數據會寫入客戶端緩存，並返回用戶寫入成功；當客戶端緩存達到閾值（默認2M）之後批量提交給RegionServer。需要注意的是，在某些情況下客戶端異常的情況下緩存數據有可能丟失。

優化建議：在業務可以接受的情況下開啟非同步批量提交

使用方式：setAutoFlush(false)

優化原理：當前集群中表的Region個數如果小於RegionServer個數，即Num(Region of Table) < Num(RegionServer)，可以考慮切分Region並盡可能分布到不同RegionServer來提高系統請求並發度，如果Num(Region of Table) > Num(RegionServer)，再增加Region個數效果並不明顯。

優化建議：在Num(Region of Table) < Num(RegionServer)的場景下切分部分請求負載高的Region並遷移到其他RegionServer；

優化原理：另一個需要考慮的問題是寫入請求是否均衡，如果不均衡，一方面會導致系統並發度較低，另一方面也有可能造成部分節點負載很高，進而影響其他業務。分布式系統中特別害怕一個節點負載很高的情況，一個節點負載很高可能會拖慢整個集群，這是因為很多業務會使用Mutli批量提交讀寫請求，一旦其中一部分請求落到該節點無法得到及時響應，就會導致整個批量請求超時。因此不怕節點宕掉，就怕節點奄奄一息！

優化建議：檢查RowKey設計以及預分區策略，保證寫入請求均衡。

KeyValue大小對寫入性能的影響巨大，一旦遇到寫入性能比較差的情況，需要考慮是否由於寫入KeyValue數據太大導致。KeyValue大小對寫入性能影響曲線圖如下：

圖中橫坐標是寫入的一行數據（每行數據10列）大小，左縱坐標是寫入吞吐量，右坐標是寫入平均延遲（ms）。可以看出隨著單行數據大小不斷變大，寫入吞吐量急劇下降，寫入延遲在100K之後急劇增大。

說到這里，有必要和大家分享兩起在生產線環境因為業務KeyValue較大導致的嚴重問題，一起是因為大欄位業務寫入導致其他業務吞吐量急劇下降，另一起是因為大欄位業務scan導致RegionServer宕機。

案件一：大欄位寫入導致其他業務吞吐量急劇下降

部分業務反饋集群寫入忽然變慢、數據開始堆積的情況，查看集群表級別的數據讀寫QPS監控，發現問題的第一個關鍵點：業務A開始寫入之後整個集群其他部分業務寫入QPS都幾乎斷崖式下跌，初步懷疑黑手就是業務A。

下圖是當時業務A的寫入QPS（事後發現腦殘忘了截取其他表QPS斷崖式下跌的慘象），但是第一感覺是QPS並不高啊，憑什麼去影響別人！

於是就繼續查看其他監控信息，首先確認系統資源（主要是IO）並沒有到達瓶頸，其次確認了寫入的均衡性，直至看到下圖，才追蹤到影響其他業務寫入的第二個關鍵點：RegionServer的handler（配置150）被殘暴耗盡：

對比上面兩張圖，是不是發現出奇的一致，那就可以基本確認是由於該業務寫入導致這台RegionServer的handler被耗盡，進而其他業務拿不到handler，自然寫不進去。那問題來了，為什麼會這樣？正常情況下handler在處理完客戶端請求之後會立馬釋放，唯一的解釋是這些請求的延遲實在太大。

試想，我們去漢堡店排隊買漢堡，有150個窗口服務，正常情況下大家買一個很快，這樣150個窗口可能只需要50個服務。假設忽然來了一批大漢，要定製超大漢堡，好了，所有的窗口都工作起來，而且因為大漢堡不好製作導致服務很慢，這樣必然會導致其他排隊的用戶長時間等待，直至超時。

可回頭一想這可是寫請求啊，怎麼會有這么大的請求延遲！和業務方溝通之後確認該表主要存儲語料庫文檔信息，都是平均100K左右的數據，是不是已經猜到了結果，沒錯，就是因為這個業務KeyValue太大導致。KeyValue太大會導致HLog文件寫入頻繁切換、flush以及compaction頻繁觸發，寫入性能急劇下降。

目前針對這種較大KeyValue寫入性能較差的問題還沒有直接的解決方案，好在社區已經意識到這個問題，在接下來即將發布的下一個大版本HBase 2.0.0版本會針對該問題進行深入優化，詳見 HBase MOB ，優化後用戶使用HBase存儲文檔、圖片等二進制數據都會有極佳的性能體驗。

案件二：大欄位scan導致RegionServer宕機

案件現場：有段時間有個0.98集群的RegionServer經常頻繁宕機，查看日誌是由於」java.lang.OutOfMemoryError: Requested array size exceeds VM limit」，如下圖所示：

原因分析：通過查看源碼以及相關文檔，確認該異常發生在scan結果數據回傳給客戶端時由於數據量太大導致申請的array大小超過JVM規定的最大值（ Interge.Max_Value-2）。造成該異常的兩種最常見原因分別是：

有的童鞋就要提問啦，說如果已經對返回結果大小做了限制，在表列太寬的情況下是不是就可以不對列數量做限制呢。這里需要澄清一下，如果不對列數據做限制，數據總是一行一行返回的，即使一行數據大小大於設置的返回結果限制大小，也會返回完整的一行數據。在這種情況下，如果這一行數據已經超過array大小閾值，也會觸發OOM異常。

解決方案：目前針對該異常有兩種解決方案，其一是升級集群到1.0，問題都解決了。其二是要求客戶端訪問的時候對返回結果大小做限制(scan.setMaxResultSize(2 1024 1024))、並且對列數量做限制(scan.setBatch(100))，當然，0.98.13版本以後也可以對返回結果大小在伺服器端進行限制，設置參數hbase.server.scanner.max.result.size即可

上述幾點主要針對寫性能優化進行了介紹，除此之外，在一些情況下還會出現寫異常，一旦發生需要考慮下面兩種情況（GC引起的不做介紹）：

問題解析：以RegionServer級別flush進行解析，HBase設定一旦整個RegionServer上所有Memstore佔用內存大小總和大於配置文件中upperlimit時，系統就會執行RegionServer級別flush，flush演算法會首先按照Region大小進行排序，再按照該順序依次進行flush，直至總Memstore大小低至lowerlimit。這種flush通常會block較長時間，在日誌中會發現「Memstore is above high water mark and block 7452 ms」，表示這次flush將會阻塞7s左右。

問題檢查點：

問題解析：對於數據寫入很快的集群，還需要特別關注一個參數：hbase.hstore.blockingStoreFiles，此參數表示如果當前hstore中文件數大於該值，系統將會強制執行compaction操作進行文件合並，合並的過程會阻塞整個hstore的寫入。通常情況下該場景發生在數據寫入很快的情況下，在日誌中可以發現」Waited 3722ms on a compaction to clean up 『too many store files「

問題檢查點：

上文已經從寫性能優化以及寫異常診斷兩個方面對HBase中數據寫入可能的問題進行了詳細的解釋，相信在0.98版本的基礎上對寫入來說已經是最好的解決方案了。但是有些業務可能依然覺得不夠快，畢竟」更快」是所有存儲系統活著的動力，那還有提高空間嗎？當然，接下來簡單介紹HBase之後版本對寫性能優化的兩點核心改進：

這個特性意味著可以將WAL單獨置於SSD上，這樣即使在默認情況下（WALSync），寫性能也會有很大的提升。需要注意的是，該特性建立在HDFS 2.6.0+的基礎上，HDFS以前版本不支持該特性。具體可以參考官方jira： https://issues.apache.org/jira/browse/HBASE-12848

該特性也是對WAL進行改造，當前WAL設計為一個RegionServer上所有Region共享一個WAL，可以想像在寫入吞吐量較高的時候必然存在資源競爭，降低整體性能。針對這個問題，社區小夥伴（阿里巴巴大神）提出Multiple WALs機制，管理員可以為每個Namespace下的所有表設置一個共享WAL，通過這種方式，寫性能大約可以提升20%～40%左右。具體可以參考官方jira： https://issues.apache.org/jira/browse/HBASE-14457