這里主要講hbase調優(yōu)相關內容
創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務,包含不限于網(wǎng)站設計、網(wǎng)站建設、樺甸網(wǎng)絡推廣、重慶小程序開發(fā)、樺甸網(wǎng)絡營銷、樺甸企業(yè)策劃、樺甸品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等,從售前售中售后,我們都將竭誠為您服務,您的肯定,是我們最大的嘉獎;創(chuàng)新互聯(lián)建站為所有大學生創(chuàng)業(yè)者提供樺甸建站搭建服務,24小時服務熱線:028-86922220,官方網(wǎng)址:www.cdcxhl.com
在HBase中Hmaster負責監(jiān)控RegionServer的生命周期,均衡RegionServer的負載,如果Hmaster掛掉了,那么整個HBase集群將陷入不健康的狀態(tài),并且此時的工作狀態(tài)并不會維持太久。所以HBase支持對Hmaster的高可用配置。
首先在 $HBASE_HOME/conf 下創(chuàng)建一個 backup-masters 名稱的文件,注意,一定得是這個名字。文件內容是備Hmaster的主機名或者ip
vim backup-masters
bigdata122
接著把這個文件復制其他hbase節(jié)點的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 可以看到備節(jié)點的情況
這會在zk的 hbase/backup-masters/節(jié)點下面以節(jié)點信息為名,創(chuàng)建一個節(jié)點,例如:
[zk: localhost:2181(CONNECTED) 6] ls /hbase/backup-masters
[bigdata122,16000,1564564196379]
2.1 namenode元數(shù)據(jù)存儲使用SSD
2.2 定時備份namenode上的元數(shù)據(jù)(如果配置了高可用就不需要了)
2.3 為namenode數(shù)據(jù)目錄指定多個元數(shù)據(jù)目錄
使用dfs.name.dir或者dfs.namenode.name.dir指定多個同樣的元數(shù)據(jù)目錄。這樣可以提供元數(shù)據(jù)的冗余和健壯性,以免發(fā)生故障。具體配置可以看“namenode工作機制”這篇文章
2.4 NameNode的dir自恢復
設置dfs.namenode.name.dir.restore為true,允許嘗試恢復之前失敗的dfs.namenode.name.dir目錄,在創(chuàng)建checkpoint時做此嘗試,如果設置了多個磁盤,建議允許。
2.5 HDFS保證RPC調用會有較多的線程數(shù)
hdfs是使用rpc進行訪問通信的,所以rpc調用的線程數(shù)決定了并發(fā)性能
hdfs-site.xml
屬性:dfs.namenode.handler.count
解釋:該屬性是NameNode服務默認線程數(shù),的默認值是10,根據(jù)機器的可用內存可以調整為50~100
屬性:dfs.datanode.handler.count
解釋:該屬性默認值為10,是DataNode的處理線程數(shù),如果HDFS客戶端程序讀寫請求比較多,可以調高到15~20,設置的值越大,內存消耗越多,不要調整的過高,一般業(yè)務中,5~10即可。
2.6 hdfs副本數(shù)
hdfs-site.xml
屬性:dfs.replication
解釋:如果數(shù)據(jù)量巨大,且不是非常之重要,可以調整為2~3,如果數(shù)據(jù)非常之重要,可以調整為3~5。
2.7 hdfs文件塊大小調整
hdfs-site.xml
屬性:dfs.blocksize
解釋:塊大小定義,該屬性應該根據(jù)存儲的大量的單個文件大小來設置,如果大量的單個文件都小于100M,建議設置成64M塊大小,對于大于100M或者達到GB的這種情況,建議設置成256M,一般設置范圍波動在64M~256M之間。
2.8 MapReduce Job任務服務線程數(shù)調整
mapred-site.xml
屬性:mapreduce.jobtracker.handler.count
解釋:該屬性是Job任務線程數(shù),默認值是10,根據(jù)機器的可用內存可以調整為50~100
2.9 http服務器工作線程數(shù)
mapred-site.xml
屬性:mapreduce.tasktracker.http.threads
解釋:定義HTTP服務器工作線程數(shù),默認值為40,對于大集群可以調整到80~100
2.10 文件排序合并優(yōu)化
mapred-site.xml
屬性:mapreduce.task.io.sort.factor
解釋:文件排序時同時合并的數(shù)據(jù)流的數(shù)量,這也定義了同時打開文件的個數(shù),默認值為10,如果調高該參數(shù),可以明顯減少磁盤IO,即減少文件讀取的次數(shù)。在merge過程中,同時打開的文件數(shù)量越多,可以減少對磁盤的多次調用。
2.11 設置任務并發(fā)
mapred-site.xml
屬性:mapreduce.map.speculative
解釋:該屬性可以設置任務是否可以并發(fā)執(zhí)行,如果任務多而小,該屬性設置為true可以明顯加快任務執(zhí)行效率,但是對于延遲非常高的任務,建議改為false,這就類似于迅雷下載。
2.12 MR輸出數(shù)據(jù)的壓縮
mapred-site.xml
屬性:mapreduce.map.output.compress、 這是map輸出mapreduce.output.fileoutputformat.compress 這是reduce輸出
解釋:對于大集群而言,建議設置Map-Reduce的輸出為壓縮的數(shù)據(jù),而對于小集群,則不需要。
2.13 優(yōu)化Mapper和Reducer的個數(shù)
mapred-site.xml
屬性:
mapreduce.tasktracker.map.tasks.maximum
mapreduce.tasktracker.reduce.tasks.maximum
解釋:以上兩個屬性分別為一個單獨的Job任務可以同時運行的Map和Reduce的數(shù)量。
設置上面兩個參數(shù)時,需要考慮CPU核數(shù)、磁盤和內存容量。假設一個8核的CPU,業(yè)務內容非常消耗CPU,那么可以設置map數(shù)量為4,如果該業(yè)務不是特別消耗CPU類型的,那么可以設置map數(shù)量為40,reduce數(shù)量為20。這些參數(shù)的值修改完成之后,一定要觀察是否有較長等待的任務,如果有的話,可以減少數(shù)量以加快任務執(zhí)行,如果設置一個很大的值,會引起大量的上下文切換,以及內存與磁盤之間的數(shù)據(jù)交換,這里沒有標準的配置數(shù)值,需要根據(jù)業(yè)務和硬件配置以及經(jīng)驗來做出選擇。
在同一時刻,不要同時運行太多的MapReduce,這樣會消耗過多的內存,任務會執(zhí)行的非常緩慢,我們需要根據(jù)CPU核數(shù),內存容量設置一個MR任務并發(fā)的最大值,使固定數(shù)據(jù)量的任務完全加載到內存中,避免頻繁的內存和磁盤數(shù)據(jù)交換,從而降低磁盤IO,提高性能。
大概估算公式:
map = 2 + ?cpu_core
reduce = 2 + ?cpu_core
3.1開啟文件系統(tǒng)的預讀緩存可以提高讀取速度
sudo blockdev --setra 32768 /dev/sda
ra是readahead的縮寫
3.2 關閉進程睡眠池
即不允許后臺進程進入睡眠狀態(tài),如果進程空閑,則直接kill掉釋放資源
sudo sysctl -w vm.swappiness=0
3.3 禁用Linux文件的atime
文件每次訪問會更新atime(access time),而hdfs底層是一個block存儲為一個文件,所以文件的數(shù)量是很多的,如果每次訪問一次都刷新一次atime,其實沒什么必要,可以將存儲hdfs文件的設備的atime關閉掉。
vim /etc/fstab
UUID=6086522b-3bc7-44a2-83f4-fd79a8c4afa1 / ext4 errors=remount-ro,noatime,nodiratime 0 1
在工作參數(shù)中,添加noatime就是表示禁用atime
3.4 調整ulimit上限,默認值為比較小的數(shù)字
ulimit -n 查看允許最大進程數(shù)
ulimit -u 查看允許打開最大文件數(shù)
vi /etc/security/limits.conf 修改打開文件數(shù)限制
末尾添加:
* soft nofile 1024000
* hard nofile 1024000
Hive - nofile 1024000
Hive - nproc 1024000
vi /etc/security/limits.d/20-nproc.conf 修改用戶打開進程數(shù)限制
修改為:
#* soft nproc 4096
#root soft nproc unlimited
* soft nproc 40960
root soft nproc unlimited
3.5 開啟集群時間同步
集群時間如果不同步,在節(jié)點心跳檢查的時候,可能會有問題。
優(yōu)化Zookeeper會話超時時間
hbase-site.xml
參數(shù):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發(fā)現(xiàn)服務器宕機的最大周期,默認值為30秒(不同的HBase版本,該默認值不一樣),如果該值過小,會在HBase在寫入大量數(shù)據(jù)發(fā)生而GC時,導致RegionServer短暫的不可用,從而沒有向ZK發(fā)送心跳包,最終導致認為從節(jié)點shutdown。一般20臺左右的集群需要配置5臺zookeeper。
? 每一個region維護著startRowKey與endRowKey,如果加入的數(shù)據(jù)符合某個region維護的rowKey范圍,則該數(shù)據(jù)交給這個region維護。那么依照這個原則,我們可以將數(shù)據(jù)索要投放的分區(qū)提前大致的規(guī)劃好,以提高HBase性能。盡量將讀寫請求均衡地分發(fā)到不同分區(qū)的region中,這才是我們想要的。
數(shù)據(jù)傾斜查看:
在hbase的web頁面中,可以點擊每個table,然后進去查看表的在不同region的狀態(tài),其中有一列“request”,表示該表的不同的region接收到的請求個數(shù)。由此可以判斷出不同region間是否存在數(shù)據(jù)傾斜。
分區(qū)方式:
(1)手動設定預分區(qū)
hbase> create 'staff','info','partition1',SPLITS => ['1000','2000','3000','4000']
這會分為5個區(qū):
小于1000
1000~2000
2000~3000
3000~4000
大于4000
可以在hbase的web頁面的table detials中點擊對應的表,進去查看到每個表的分區(qū)情況。
也可以通過以下命令查看分區(qū):
hbase(main):011:0> get_splits 'staff'
Total number of splits = 5
=> ["1000", "2000", "3000", "4000"]
(2)生成16進制序列預分區(qū)
create 'staff2','info','partition2',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
(3)根據(jù)文件設置的規(guī)則預分區(qū)
創(chuàng)建文件如下:
split.txt
aaaa
bbbb
cccc
dddd
創(chuàng)建表:
create 'staff3','partition3',SPLITS_FILE => 'splits.txt'
分區(qū)創(chuàng)建如下:
....~aaaa
aaaa~bbbb
bbbb~cccc
cccc~dddd
dddd~....
一條數(shù)據(jù)的唯一標識就是rowkey,那么這條數(shù)據(jù)存儲于哪個分區(qū),取決于rowkey處于哪個一個預分區(qū)的區(qū)間內,設計rowkey的主要目的 ,就是讓數(shù)據(jù)均勻的分布于所有的region中,在一定程度上防止數(shù)據(jù)傾斜。接下來我們就談一談rowkey常用的設計方案。而且rowkey的設計越隨機越好,越?jīng)]有規(guī)律越好,這樣才能更加隨機的分布到不同region中,從而均衡讀寫壓力
比如:
原本rowKey為1001的,SHA1后變成:dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本rowKey為3001的,SHA1后變成:49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本rowKey為5001的,SHA1后變成:7b61dec07e02c188790670af43e717f0f46e8913
在做此操作之前,一般我們會選擇從數(shù)據(jù)集中抽取樣本,來決定什么樣的rowKey來Hash后作為每個分區(qū)的臨界值。
常用一些有規(guī)律的數(shù)據(jù),將其變?yōu)檩^弱規(guī)律的數(shù)據(jù),常見的比如電話號碼、identification card號碼、日期時間等。這些數(shù)據(jù)都是有規(guī)律,而將他們反轉后,就相對隨機一些了。
這樣也可以在一定程度上散列逐步put進來的數(shù)據(jù)。
rowkey本身有規(guī)律,也可以在前面或者后面添加一些隨機字符,將rowkey規(guī)律打亂,變成較為隨機的數(shù)據(jù)
因為hbase 作為一款內存型的NOSQL,對內存的使用量是很大的,那么如果規(guī)劃內存與hbase的性能密切相關。內存優(yōu)化這方面主要集中在3個方面:compact、flush以及內存區(qū)域規(guī)劃
compact操作就是將多個storefile合并,主要是為了壓縮存儲空間,提高讀寫速度。根據(jù)合并的規(guī)模,分為 Minor Compaction 和 Major Compaction
Minor Compaction:
是指選取一些小的、相鄰的StoreFile將他們合并成一個更大的StoreFile,在這個過程中不會處理已經(jīng)Deleted或Expired的Cell。一次Minor Compaction的結果是更少并且更大的StoreFile。
Major Compaction
是指將所有的StoreFile合并成一個StoreFile,這個過程還會清理三類無意義數(shù)據(jù):被刪除的數(shù)據(jù)、TTL過期數(shù)據(jù)、版本號超過設定版本號的數(shù)據(jù)。另外,一般情況下,Major Compaction時間會持續(xù)比較長,整個過程會消耗大量系統(tǒng)資源,對上層業(yè)務有比較大的影響。因此線上業(yè)務都會將關閉自動觸發(fā)Major Compaction功能,改為手動在業(yè)務低峰期觸發(fā)
minor compaction通常會由memstore flush,線程定期檢查觸發(fā)。major compaction通常會由手動觸發(fā),可以通過參數(shù),hbase.hregion.majorcompaction設置為0即可,默認時間為一天86400000。
手動compact操作:
Minor Compaction
compact 'namespace:table','cf'
如果不指定cf,就會合并整個region
Major Compaction
major_compact 'namespace:table','cf' 用法和上面類似
flush就是從memstore將數(shù)據(jù)刷寫到storefile中,hbase寫數(shù)據(jù),先寫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,會占用大量磁盤和網(wǎng)絡IO。
如何分配合適的內存給regionserver,以及regionserver內部不同功能性內存的大小需要是很考究的。可以大致分為以下幾個區(qū)域的內存:
CombinedBlockCache:
負責讀緩存,分為 LRUBlockCache和BucketCache。前者一般用來緩存數(shù)據(jù)的元數(shù)據(jù),而且屬于堆內內存,后者用來緩存原始數(shù)據(jù),屬于堆外內存.
memstore:
負責寫緩存,用來存儲可以直接修改的數(shù)據(jù)的
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
推薦以下規(guī)劃:
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參數(shù)配置:
-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中的配置
由上述定義可知,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大小排序,并按照由大到小的順序依次執(zhí)行flush,直至所有MemStore內存總大小小于hbase.regionserver.global.memstore.lowerLimit,一般lowerLimit比upperLimit小5%。
hbase.regionserver.global.memstore.upperLimit
0.45
hbase.regionserver.global.memstore.lowerLimit
0.40
hfile.block.cache.size
0.3
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參數(shù)設置
-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相關:
根據(jù)upperLimit參數(shù)的定義,結合上述內存規(guī)劃數(shù)據(jù)可計算出 upperLimit = 20G / 30G = 66%。因此upperLimit參數(shù)設置為0.66,lowerLimit設置為0.60
hbase.regionserver.global.memstore.upperLimit
0.66
hbase.regionserver.global.memstore.lowerLimit
0.60
CombinedBlockCache相關:
設置為堆外內存
hbase.bucketcache.ioengine
offheap
堆外內存大小
hbase.bucketcache.size
34816
bucketcache的比例
hbase.bucketcache.percentage.in.combinedcache
0.90
更加詳細的請看:http://hbasefly.com/2016/06/18/hbase-practise-ram/ 寫的超好。
1、允許hdfs文件中追加內容
hdfs-site.xml、hbase-site.xml
屬性:dfs.support.append
解釋:開啟HDFS追加同步,可以優(yōu)秀的配合HBase的數(shù)據(jù)同步和持久化。默認值為true。
2、優(yōu)化DataNode允許的最大文件打開數(shù)
hdfs-site.xml
屬性:dfs.datanode.max.transfer.threads
解釋:HBase一般都會同一時間操作大量的文件,根據(jù)集群的數(shù)量和規(guī)模以及數(shù)據(jù)動作,設置為4096或者更高。默認值:4096
3、優(yōu)化延遲高的數(shù)據(jù)操作的等待時間
hdfs-site.xml
屬性:dfs.image.transfer.timeout
解釋:如果對于某一次數(shù)據(jù)操作來講,延遲非常高,socket需要等待更長的時間,建議把該值設置為更大的值(默認60000毫秒),以確保socket不會被timeout掉
4、優(yōu)化DataNode存儲
屬性:dfs.datanode.failed.volumes.tolerated
解釋: 默認為0,意思是當DataNode中有一個磁盤出現(xiàn)故障,則會認為該DataNode shutdown了。如果修改為1,則一個磁盤出現(xiàn)故障時,數(shù)據(jù)會被復制到其他正常的DataNode上,當前的DataNode繼續(xù)工作。
5、設置regionserver的RPC監(jiān)聽數(shù)量
hbase-site.xml
屬性:hbase.regionserver.handler.count
解釋:默認值為30,用于指定RPC監(jiān)聽的數(shù)量,可以根據(jù)客戶端的請求數(shù)進行調整,讀寫請求較多時,增加此值。
6、優(yōu)化HStore文件大小
屬性:hbase.hregion.max.filesize
解釋:默認值10737418240(10GB),如果需要運行HBase的MR任務,可以減小此值,因為一個region對應一個map任務,如果單個region過大,會導致map任務執(zhí)行時間過長。該值的意思就是,如果HFile的大小達到這個數(shù)值,則這個region會被切分為兩個。
7、優(yōu)化hbase客戶端緩存
hbase-site.xml
屬性:hbase.client.write.buffer
解釋:用于指定HBase客戶端緩存,增大該值可以減少RPC調用次數(shù),但是會消耗更多內存,反之則反之。一般我們需要設定一定的緩存大小,以達到減少RPC次數(shù)的目的。
8、指定scan.next掃描HBase所獲取的行數(shù)
hbase-site.xml
屬性:hbase.client.scanner.caching
解釋:用于指定scan.next方法獲取的默認行數(shù),值越大,消耗內存越大。