三、hbase--調優

這里主要講hbase調優相關內容

一、Hmaster高可用

在HBase中Hmaster負責監控RegionServer的生命周期，均衡RegionServer的負載，如果Hmaster掛掉了，那么整個HBase集群將陷入不健康的狀態，并且此時的工作狀態并不會維持太久。所以HBase支持對Hmaster的高可用配置。
首先在 $HBASE_HOME/conf 下創建一個 backup-masters 名稱的文件，注意，一定得是這個名字。文件內容是備Hmaster的主機名或者ip

vim backup-masters
bigdata122

接著把這個文件復制其他hbase節點的hbase的conf目錄下

scp backup-masters bigdata122:/opt/modules/hbase-1.3.1/conf/
scp backup-masters bigdata123:/opt/modules/hbase-1.3.1/conf/

接著重啟整個hbase集群

stop-hbase.sh
start-hbase.sh

接著通過 http://bigdata121:16010 可以看到備節點的情況
這會在zk的 hbase/backup-masters/節點下面以節點信息為名，創建一個節點，例如：

[zk: localhost:2181(CONNECTED) 6] ls /hbase/backup-masters 
[bigdata122,16000,1564564196379]

二、hadoop通用性優化

2.1 namenode元數據存儲使用SSD
2.2 定時備份namenode上的元數據（如果配置了高可用就不需要了）

2.3 為namenode數據目錄指定多個元數據目錄
使用dfs.name.dir或者dfs.namenode.name.dir指定多個同樣的元數據目錄。這樣可以提供元數據的冗余和健壯性，以免發生故障。具體配置可以看“namenode工作機制”這篇文章

2.4 NameNode的dir自恢復
設置dfs.namenode.name.dir.restore為true，允許嘗試恢復之前失敗的dfs.namenode.name.dir目錄，在創建checkpoint時做此嘗試，如果設置了多個磁盤，建議允許。

2.5 HDFS保證RPC調用會有較多的線程數
hdfs是使用rpc進行訪問通信的，所以rpc調用的線程數決定了并發性能

hdfs-site.xml
屬性：dfs.namenode.handler.count
解釋：該屬性是NameNode服務默認線程數，的默認值是10，根據機器的可用內存可以調整為50~100

屬性：dfs.datanode.handler.count
解釋：該屬性默認值為10，是DataNode的處理線程數，如果HDFS客戶端程序讀寫請求比較多，可以調高到15~20，設置的值越大，內存消耗越多，不要調整的過高，一般業務中，5~10即可。

2.6 hdfs副本數

hdfs-site.xml
屬性：dfs.replication
解釋：如果數據量巨大，且不是非常之重要，可以調整為2~3，如果數據非常之重要，可以調整為3~5。

2.7 hdfs文件塊大小調整

hdfs-site.xml
屬性：dfs.blocksize
解釋：塊大小定義，該屬性應該根據存儲的大量的單個文件大小來設置，如果大量的單個文件都小于100M，建議設置成64M塊大小，對于大于100M或者達到GB的這種情況，建議設置成256M，一般設置范圍波動在64M~256M之間。

2.8 MapReduce Job任務服務線程數調整

mapred-site.xml
屬性：mapreduce.jobtracker.handler.count
解釋：該屬性是Job任務線程數，默認值是10，根據機器的可用內存可以調整為50~100

2.9 http服務器工作線程數

mapred-site.xml
屬性：mapreduce.tasktracker.http.threads
解釋：定義HTTP服務器工作線程數，默認值為40，對于大集群可以調整到80~100

2.10 文件排序合并優化

mapred-site.xml
屬性：mapreduce.task.io.sort.factor
解釋：文件排序時同時合并的數據流的數量，這也定義了同時打開文件的個數，默認值為10，如果調高該參數，可以明顯減少磁盤IO，即減少文件讀取的次數。在merge過程中，同時打開的文件數量越多，可以減少對磁盤的多次調用。

2.11 設置任務并發

mapred-site.xml
屬性：mapreduce.map.speculative
解釋：該屬性可以設置任務是否可以并發執行，如果任務多而小，該屬性設置為true可以明顯加快任務執行效率，但是對于延遲非常高的任務，建議改為false，這就類似于迅雷下載。

2.12 MR輸出數據的壓縮

mapred-site.xml
屬性：mapreduce.map.output.compress、    這是map輸出mapreduce.output.fileoutputformat.compress   這是reduce輸出
解釋：對于大集群而言，建議設置Map-Reduce的輸出為壓縮的數據，而對于小集群，則不需要。

2.13 優化Mapper和Reducer的個數

mapred-site.xml
屬性：
mapreduce.tasktracker.map.tasks.maximum
mapreduce.tasktracker.reduce.tasks.maximum
解釋：以上兩個屬性分別為一個單獨的Job任務可以同時運行的Map和Reduce的數量。
設置上面兩個參數時，需要考慮CPU核數、磁盤和內存容量。假設一個8核的CPU，業務內容非常消耗CPU，那么可以設置map數量為4，如果該業務不是特別消耗CPU類型的，那么可以設置map數量為40，reduce數量為20。這些參數的值修改完成之后，一定要觀察是否有較長等待的任務，如果有的話，可以減少數量以加快任務執行，如果設置一個很大的值，會引起大量的上下文切換，以及內存與磁盤之間的數據交換，這里沒有標準的配置數值，需要根據業務和硬件配置以及經驗來做出選擇。
在同一時刻，不要同時運行太多的MapReduce，這樣會消耗過多的內存，任務會執行的非常緩慢，我們需要根據CPU核數，內存容量設置一個MR任務并發的最大值，使固定數據量的任務完全加載到內存中，避免頻繁的內存和磁盤數據交換，從而降低磁盤IO，提高性能。

大概估算公式：
map = 2 + ?cpu_core
reduce = 2 + ?cpu_core

三、Linux優化

3.1開啟文件系統的預讀緩存可以提高讀取速度

sudo blockdev --setra 32768 /dev/sda

ra是readahead的縮寫

3.2 關閉進程睡眠池
即不允許后臺進程進入睡眠狀態，如果進程空閑，則直接kill掉釋放資源

sudo sysctl -w vm.swappiness=0

3.3 禁用Linux文件的atime
文件每次訪問會更新atime（access time），而hdfs底層是一個block存儲為一個文件，所以文件的數量是很多的，如果每次訪問一次都刷新一次atime，其實沒什么必要，可以將存儲hdfs文件的設備的atime關閉掉。

vim /etc/fstab
UUID=6086522b-3bc7-44a2-83f4-fd79a8c4afa1 / ext4 errors=remount-ro,noatime,nodiratime 0 1

在工作參數中，添加noatime就是表示禁用atime

3.4 調整ulimit上限，默認值為比較小的數字

ulimit -n 查看允許最大進程數
ulimit -u 查看允許打開最大文件數

vi /etc/security/limits.conf 修改打開文件數限制
末尾添加：
*                soft    nofile          1024000
*                hard    nofile          1024000
Hive             -       nofile          1024000
Hive             -       nproc           1024000 

vi /etc/security/limits.d/20-nproc.conf 修改用戶打開進程數限制
修改為：
#*          soft    nproc     4096
#root       soft    nproc     unlimited
*          soft    nproc     40960
root       soft    nproc     unlimited

3.5 開啟集群時間同步
集群時間如果不同步，在節點心跳檢查的時候，可能會有問題。

四、zookeeper優化

優化Zookeeper會話超時時間

hbase-site.xml
參數：zookeeper.session.timeout
解釋：In hbase-site.xml, set zookeeper.session.timeout to 30 seconds or less to bound failure detection (20-30 seconds is a good start).該值會直接關系到master發現服務器宕機的最大周期，默認值為30秒（不同的HBase版本，該默認值不一樣），如果該值過小，會在HBase在寫入大量數據發生而GC時，導致RegionServer短暫的不可用，從而沒有向ZK發送心跳包，最終導致認為從節點shutdown。一般20臺左右的集群需要配置5臺zookeeper。

五、hbase優化

5.1 預分區

? 每一個region維護著startRowKey與endRowKey，如果加入的數據符合某個region維護的rowKey范圍，則該數據交給這個region維護。那么依照這個原則，我們可以將數據索要投放的分區提前大致的規劃好，以提高HBase性能。盡量將讀寫請求均衡地分發到不同分區的region中，這才是我們想要的。

數據傾斜查看：
在hbase的web頁面中，可以點擊每個table，然后進去查看表的在不同region的狀態，其中有一列“request”，表示該表的不同的region接收到的請求個數。由此可以判斷出不同region間是否存在數據傾斜。

分區方式：
（1）手動設定預分區

hbase> create 'staff','info','partition1',SPLITS => ['1000','2000','3000','4000']

這會分為5個區：
小于1000
1000~2000
2000~3000
3000~4000
大于4000

可以在hbase的web頁面的table detials中點擊對應的表，進去查看到每個表的分區情況。
也可以通過以下命令查看分區：

hbase(main):011:0> get_splits 'staff'
Total number of splits = 5

=> ["1000", "2000", "3000", "4000"]

（2）生成16進制序列預分區

create 'staff2','info','partition2',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

（3）根據文件設置的規則預分區
創建文件如下：
split.txt

aaaa
bbbb
cccc
dddd

創建表：

create 'staff3','partition3',SPLITS_FILE => 'splits.txt'

分區創建如下：
....~aaaa
aaaa~bbbb
bbbb~cccc
cccc~dddd
dddd~....

5.2 rowkey設計

一條數據的唯一標識就是rowkey，那么這條數據存儲于哪個分區，取決于rowkey處于哪個一個預分區的區間內，設計rowkey的主要目的 ，就是讓數據均勻的分布于所有的region中，在一定程度上防止數據傾斜。接下來我們就談一談rowkey常用的設計方案。而且rowkey的設計越隨機越好，越沒有規律越好，這樣才能更加隨機的分布到不同region中，從而均衡讀寫壓力

5.2.1 生成隨機數、hash、散列值

比如：
原本rowKey為1001的，SHA1后變成：dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本rowKey為3001的，SHA1后變成：49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本rowKey為5001的，SHA1后變成：7b61dec07e02c188790670af43e717f0f46e8913
在做此操作之前，一般我們會選擇從數據集中抽取樣本，來決定什么樣的rowKey來Hash后作為每個分區的臨界值。

5.2.2 字符串反轉

常用一些有規律的數據，將其變為較弱規律的數據，常見的比如電話號碼、identification card號碼、日期時間等。這些數據都是有規律，而將他們反轉后，就相對隨機一些了。

這樣也可以在一定程度上散列逐步put進來的數據。

5.2.3 字符串拼接

rowkey本身有規律，也可以在前面或者后面添加一些隨機字符，將rowkey規律打亂，變成較為隨機的數據

5.3 內存優化

因為hbase 作為一款內存型的nosql，對內存的使用量是很大的，那么如果規劃內存與hbase的性能密切相關。內存優化這方面主要集中在3個方面：compact、flush以及內存區域規劃

5.3.1 compact

compact操作就是將多個storefile合并，主要是為了壓縮存儲空間，提高讀寫速度。根據合并的規模，分為 Minor Compaction 和 Major Compaction
Minor Compaction：

是指選取一些小的、相鄰的StoreFile將他們合并成一個更大的StoreFile，在這個過程中不會處理已經Deleted或Expired的Cell。一次Minor Compaction的結果是更少并且更大的StoreFile。

Major Compaction

是指將所有的StoreFile合并成一個StoreFile，這個過程還會清理三類無意義數據：被刪除的數據、TTL過期數據、版本號超過設定版本號的數據。另外，一般情況下，Major Compaction時間會持續比較長，整個過程會消耗大量系統資源，對上層業務有比較大的影響。因此線上業務都會將關閉自動觸發Major Compaction功能，改為手動在業務低峰期觸發

minor compaction通常會由memstore flush，線程定期檢查觸發。major compaction通常會由手動觸發，可以通過參數，hbase.hregion.majorcompaction設置為0即可，默認時間為一天86400000。

手動compact操作：
Minor Compaction

compact 'namespace:table','cf'
如果不指定cf，就會合并整個region

Major Compaction

major_compact 'namespace:table','cf'   用法和上面類似

5.3.2 flush

flush就是從memstore將數據刷寫到storefile中，hbase寫數據，先寫wal的hlog，成功后才寫memstore，每個列只有多有一個memstore，當一個region所有cf的memstore大小之和達到hbase.regionserver.global.memstore.size設置的大小時，這個值默認是128M，就會flush。當前單個cf 的memstore達到這個值也會flush的，這種非實時的flush操作主要是為了較好的寫性能，避免每次寫都要flush到hdfs中。在hbase2.0版本中，memstore其實是由一個可變的memstore和許多不可變的memstore組成，直接在內存中進行compaction，如果flush成HFile，再compaction，會占用大量磁盤和網絡IO。

5.3.3 內存規劃

如何分配合適的內存給regionserver，以及regionserver內部不同功能性內存的大小需要是很考究的。可以大致分為以下幾個區域的內存：

CombinedBlockCache：
負責讀緩存,分為 LRUBlockCache和BucketCache。前者一般用來緩存數據的元數據，而且屬于堆內內存，后者用來緩存原始數據，屬于堆外內存.

memstore：
負責寫緩存，用來存儲可以直接修改的數據的

other:
用于存儲hbase工作過程中的對象

jvm_heap：
就是減去BucketCache后的大小。一般就是 memstore+LRUBlockCache+other

有一個硬性要求：LRUBlockCache + MemStore < 80% * JVM_HEAP
不滿足這個條件，rs直接無法啟動

分為兩種場景：讀少寫多，讀多寫少。
1、讀少寫多

一般用 LRUBlockCache 模式，也就是 LRUBlockCache + memstore + other的模式。
都在堆內內存中。

以機器內存為96G為例，一般分配給rs的 2/3的內存，也就是64G。
首先memstore要比LRUBlockCache大，且LRUBlockCache + MemStore < 80% * JVM_HEAP
推薦以下規劃：
MemStore = 45% * JVM_HEAP = 64G * 45% = 28.8G ，LRUBlockCache = 30% * JVM_HEAP = 64G * 30% = 19.2G；默認情況下Memstore為40% * JVM_HEAP，而LRUBlockCache為25% * JVM_HEAP

jvm參數配置：

-XX:SurvivorRatio=2  -XX:+PrintGCDateStamps  -Xloggc:$HBASE_LOG_DIR/gc-regionserver.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=512M -server -Xmx64g -Xms64g -Xmn2g -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:MaxTenuringThreshold=15  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

其中 -Xmx64g -Xms64g 設置堆內存為 64g

hbase-stie.xml中的配置

<!--memstore的配置-->
由上述定義可知，hbase.regionserver.global.memstore.upperLimit設置為0.45，hbase.regionserver.global.memstore.lowerLimit設置為0.40
hbase.regionserver.global.memstore.upperLimit表示RegionServer中所有MemStore占有內存在JVM內存中的比例上限。如果所占比例超過這個值，RS會首先將所有Region按照MemStore大小排序，并按照由大到小的順序依次執行flush，直至所有MemStore內存總大小小于hbase.regionserver.global.memstore.lowerLimit，一般lowerLimit比upperLimit小5%。
<property>
    <name>hbase.regionserver.global.memstore.upperLimit</name>
    <value>0.45</value>
</property>
<property>
    <name>hbase.regionserver.global.memstore.lowerLimit</name>
    <value>0.40</value>
</property>

<!--LRUBlockCache的配置-->
<property>
    <name>hfile.block.cache.size</name>
    <value>0.3</value>
</property>

2、讀多寫少

一般用BucketCache，也就是讀內存包括 BucketCache和 LRUBlockCache。兩者共同構成CombinedBlockCache
采用以下內存分布：
堆內內存：LRUBlockCache + memstore + other
堆外內存：BucketCache

以機器內存為96G為例，一般分配給rs的 2/3的內存，也就是64G。也可以更多的
這種情況，讀、寫、其他內存的比例一般為 5:3:2，讀內存中 LRU:BUCKET= 1：9
同時要滿足 LRUBlockCache + MemStore < 80% * JVM_HEAP
CombinedBlockCache 64* 0.5=32
-----LRUBlockCache  32*0.1
-----BucketCache    32*0.9
memstore           64*0.3
heap               64 - 32*0.9
計算之后，LRU + MemStore / JVM_HEAP = 3.2G + 19.2G / 35.2G = 22.4G / 35.2G =  63.6% ，遠小于80%。因此需要調整一下對應的大小。這種情況證明堆內存太大了，適量減少JVM_HEAP值（減少至30G），增大Memstore到20G。因為JVM_HEAP減少了，堆外內存就需要適量增大，因此將BucketCache增大到30G。
調整之后，LRU + MemStore / JVM_HEAP = 3.2G + 20G / 30G = 23.2G / 30G =  77%

jvm參數設置

-XX:SurvivorRatio=2  -XX:+PrintGCDateStamps  -Xloggc:$HBASE_LOG_DIR/gc-regionserver.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=512M -server -Xmx40g -Xms40g -Xmn1g -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:MaxTenuringThreshold=15  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

hbase-site.xml配置

memstore相關：
根據upperLimit參數的定義，結合上述內存規劃數據可計算出 upperLimit =  20G / 30G = 66%。因此upperLimit參數設置為0.66，lowerLimit設置為0.60
<property>
    <name>hbase.regionserver.global.memstore.upperLimit</name>
    <value>0.66</value>
</property>
<property>
    <name>hbase.regionserver.global.memstore.lowerLimit</name>
    <value>0.60</value>
</property>

CombinedBlockCache相關：
<property> 設置為堆外內存
    <name>hbase.bucketcache.ioengine</name>
    <value>offheap</value>
</property>
<property> 堆外內存大小
    <name>hbase.bucketcache.size</name>
    <value>34816</value>
</property>
<property> bucketcache的比例
    <name>hbase.bucketcache.percentage.in.combinedcache</name>
    <value>0.90</value>
</property>

更加詳細的請看：http://hbasefly.com/2016/06/18/hbase-practise-ram/ 寫的超好。

5.4 基礎優化

1、允許hdfs文件中追加內容

hdfs-site.xml、hbase-site.xml
屬性：dfs.support.append
解釋：開啟HDFS追加同步，可以優秀的配合HBase的數據同步和持久化。默認值為true。

2、優化DataNode允許的最大文件打開數

hdfs-site.xml
屬性：dfs.datanode.max.transfer.threads
解釋：HBase一般都會同一時間操作大量的文件，根據集群的數量和規模以及數據動作，設置為4096或者更高。默認值：4096

3、優化延遲高的數據操作的等待時間

hdfs-site.xml
屬性：dfs.image.transfer.timeout
解釋：如果對于某一次數據操作來講，延遲非常高，socket需要等待更長的時間，建議把該值設置為更大的值（默認60000毫秒），以確保socket不會被timeout掉

4、優化DataNode存儲

屬性：dfs.datanode.failed.volumes.tolerated
解釋： 默認為0，意思是當DataNode中有一個磁盤出現故障，則會認為該DataNode shutdown了。如果修改為1，則一個磁盤出現故障時，數據會被復制到其他正常的DataNode上，當前的DataNode繼續工作。

5、設置regionserver的RPC監聽數量

hbase-site.xml
屬性：hbase.regionserver.handler.count
解釋：默認值為30，用于指定RPC監聽的數量，可以根據客戶端的請求數進行調整，讀寫請求較多時，增加此值。

6、優化HStore文件大小

屬性：hbase.hregion.max.filesize
解釋：默認值10737418240（10GB），如果需要運行HBase的MR任務，可以減小此值，因為一個region對應一個map任務，如果單個region過大，會導致map任務執行時間過長。該值的意思就是，如果HFile的大小達到這個數值，則這個region會被切分為兩個。

7、優化hbase客戶端緩存

hbase-site.xml
屬性：hbase.client.write.buffer
解釋：用于指定HBase客戶端緩存，增大該值可以減少RPC調用次數，但是會消耗更多內存，反之則反之。一般我們需要設定一定的緩存大小，以達到減少RPC次數的目的。

8、指定scan.next掃描HBase所獲取的行數

hbase-site.xml
屬性：hbase.client.scanner.caching
解釋：用于指定scan.next方法獲取的默認行數，值越大，消耗內存越大。