-
- 網絡不好，導致RegionServer 和 HMaster通信超時，RegionServer被認爲已經掛掉，從而退出集羣 --網絡問題，無法從軟件方面解決，關於通信超時的設置下面做個簡單介紹
- Java full GC ，這個過程會block所有的線程，如果此事件過長，導致Session expired 會話過期，導致退出集羣--下文會闡述
- 各節點時間不一致，導致RegionServer 退出。-- hbase.master.maxclockskew 增大容忍度，默認是30s，但不要太大，畢竟時間不一致是不正常現象，可將所有節點和同一服務器時間做同步，也可以和時間服務器同步。
-
- HQuorumPeer.main 方法中會調用 writeMyID(zkProperties) ，而就在此方法中已經將 maxSessionTimeout設置爲 zookeeper.session.timeout 的時長。
- 調用HQuorunPeer.runZKServer
- 調用QuorumPeerMain.runFromConfig
- 設置quorumPeer.setMaxSessionTimeout(config.getMaxSessionTimeout());
- 由此可看此件並沒有直接和tickTime對比的機會。倒是minSessionTimeout沒有設置，默認是2*ticktime
-
- 適度增大守護進程的HeapSize
- 調整內存回收參數
-
- export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx2000m -Xms2000m -Xmn750m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"
-
- export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx6000m -Xms6000m -Xmn2250m -XX:+UseParNewGC
-
- export HBASE_THRIFT_OPTS="$HBASE_THRIFT_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"
- export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS $HBASE_JMX_BASE -Xms100m -Xmx2000m"
當然，上述是在hbase-env.sh中對jvm的調優，還需要在hbase-site.xml中注意一些配置項
上面這張圖不是一太清晰，我後面給個單獨的連接
這裏的HBase的優化主要從三個大的維度來進行分析
1、系統硬件
採用普通的PC Server即可，Master要求高一點(比如8 CPU，48G內存，SAS raid)，Regionserver(如8CPU，24G內存，1T*12 SATA JBOD)
對於存儲regionserver節點採用JBOD，master採用sas raid1+0
數據的存儲在hdfs中本身考慮到了冗餘，一般情況下replication設置爲3，所以不用做raid；需要考慮的是每個節點的可用的存儲空間的大小，所以這裏用磁盤簇的方式。
網卡千兆的，做網卡bond，並且管理網段和請求網段分開，對於大的混合集羣來說，可以設計多個vlan。
2、客戶端client
a、 scan cache：順序讀的場景中，比如mapreduce做計算，可以設置在regionserver中的一次緩存的數量，可以加快scan的進度，
不過考慮到regionserver的內存限制，需要注意regionserver併發線程的控制。
b、在插入數據時，最好用批量插入操作，效率會更高一些。
c、auto flush最好disable掉
對於client來說，有一個writebuffer的緩衝，buffer滿了之後，自動的發送數據到regionserver端
可以在某個時間點，手動調用flush的操作進行flush數據
調用close操作，會隱含調用flush操作
3、regionserver
a、對於插入操作，不要集中在一個region中插入，需要考慮rowkey的設計(rowkey如果是順序設計的，這樣會集中插入到一個region中)，以及最好預先創建好split region
b、對於查詢操作時，又分爲兩種情況，一種是順序讀，一種是隨機讀。
順序讀，最好rowkey是連續的設計的，這樣可以從一個region中批量讀數據；並且關閉block cache（客戶端調用setBlockCache(false)）。
隨機讀，打開block cache（設置cache合理大小，hfile.block.cache.size）；採用booleam filter，提供隨機查詢的效率。
當然HFile塊的大小設計很重要，隨機讀的情況下，可以設置小一點，順序讀的情況下，設計大一下。
c、對於compact&split操作，建議禁止major compact(hbase.hregion.majorcompaction設爲0)，該爲手動方式，每天不忙的時候進行。
設置單個region的合理的大小(hbase.hregion.max.filesize)，超過這個值，就自動進行split操作。
d、手動進行balancer操作
e、內存大小的相關考慮
1） 對於region column family 的buffer，設置合理的checkpoint百分比，減少硬盤IO的操作；對buffer memstore設計合理大小，防止內存溢出。
主要有這三個參數，hbase.regionserver.global.memstore.upperLimit，hbase.regionserver.global.memstore.lowerLimit，memstore.flush .size
2）regionserver JVM參數設置
設置最大合理內存大小
垃圾回收策略，併發CMS的設置，比如-XX:CMSInitiatingOccupancyFraction=70，memstore limit 40%，block cache 20%，
防止promted fail（new區S區域放不下，放到舊生代，而舊生代空間不足），防止CMS的同時 ，對象遷移到舊生代，而舊生代空間不足。
爲了避免CMS帶來的碎片，可以考慮採用MSLAB
3） block cache，創建表時，設置該表對應的塊是cache的，通過LRU算法淘汰；不過塊中的數據索引dataIndex是放在內存中的。
f、HFile的設置
1）可以壓縮存儲，減少磁盤和網絡IO，有GZIP、LZO、Snappy，一般採用LZO或者Snappy。
2）對於HFile中塊的大小設置，可以根據順序讀和隨機讀的比重，來考慮（順序讀，塊設置大，隨機讀，塊設置小一點）
g、regionserver併發處理線程handler的的數量（payload大，建議handler數量小一些，反之，建議handler數量大一些）
h、可以把一些操作，放在regionserver端執行，避免來回數據交互（filter,coprocessor,count）
相關參數設置參考
client
Scan Caching（默認是1條，設置成20條）
Scan Attribute Selection
Close ResultScanners
AutoFlush（默認是true，設置成false）
Bloom Filter
regionserver
內存
JVM（CMS GC，24G heap，-XX:CMSInitiatingOccupancyFraction=70）
hbase.regionserver.global.memstore.upperLimit（默認0.4）
hbase.regionserver.global.memstore.lowerLimit（默認0.3）
hbase.hregion.memstore.flush.size（64M,如果region的數量不多，可以設置的大一些，假如有1000個region*200M）
hbase.hregion.memstore.block.multiplier（默認是2）
hfile.block.cache.size（默認是0.2，場景中是讀多寫少，建議開大一些，0.4）
hbase.hregion.memstore.mslab.enabled
文件大小
hbase.hregion.max.filesize（默認256M，實際環境中爲1G，每天手動split,compact）
hbase.hstore.blockingStoreFiles（默認7），通常情況下，一個storeFile大概在200M的樣子，當進行major compact時，會合併成一個
線程設置
hbase.regionserver.handler.count（默認是10，設置成100，和內存大小有關係）
【注：如果hbase出現不穩定現象，還可能是以下原因】hadoop的 namenode重新格式化以後，重啓hbase，發現它的hmaster進程啓動後馬上消失，查看一大堆日誌，最後在zookeeper的日誌裏發現如下問題
Unable to read additional data from client sessionid 0x14e86607c850007, likely client has closed socket
解決 方法：刪除掉hbase的hbase-site.xml中一下內容所配置路徑下的目錄，重啓zookeeper集羣，再重啓hbase讓該目錄重新生成即可
<property>
<name>hbase.zookeeper.property.dataDir</name>
<value>/home/infocenter/zookeeper/data</value>
</property>
接下來貼上hbase的配置項簡介：
Hbase配置項（1）
hbase.tmp.dir：本地文件系統的臨時目錄，默認是java.io.tmpdir/hbase?{user.name}；
hbase.rootdir：hbase持久化的目錄，被所有regionserver共享，默認${hbase.tmp.dir}/hbase，一般設置爲hdfs://namenode.example.org:9000/hbase類似，帶全限定名；
hbase.cluster.distributed：hbase集羣模式運作與否的標誌，默認是false，開啓需要設置爲true，false時啓動hbase會在一個jvm中運行hbase和zk；
hbase.zookeeper.quorum：重要的也是必須設置的，啓動zk的服務器列表，逗號分隔，cluster模式下必須設置，默認是localhost，hbase客戶端也需要設置這個值去訪問zk；
hbase.local.dir：本地文件系統被用在本地存儲的目錄，默認${hbase.tmp.dir}/local/；
hbase.master.port：hbase master綁定的端口，默認是60000；
hbase.master.info.port：hbase master web 界面的端口，默認是60010，設置爲-1可以禁用ui；
hbase.master.info.bindAddress：master web界面的綁定地址，默認是0.0.0.0；
hbase.master.logcleaner.plugins：清理日誌的插件列表，逗號分隔，被LogService調用的LogCleanerDelegate，可以自定義，順序執行，清理WAL和HLog；默認org.apache.hadoop.hbase.master.cleaner.TimeToLiveLogCleaner
hbase.master.logcleaner.ttl：HLog在.oldlogdir目錄中生存的最長時間，過期則被Master起線程回收，默認是600000；
hbase.master.hfilecleaner.plugins：HFile的清理插件列表，逗號分隔，被HFileService調用，可以自定義，默認org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner
hbase.master.catalog.timeout：Catalog Janitor從master到META的超時時間，我們知道這個Janitor是定時的去META掃描表目錄，來決定回收無用的regions，默認是600000；
fail.fast.expired.active.master：如果master過期，那麼不需要從zk恢復，直接終止，默認是false；
hbase.master.dns.interface：master的dns接口，向該接口提供ip，默認是default；
hbase.master.dns.nameserver：master使用的dns主機名或者ip，默認是default；
hbase.regionserver.port：regionserver綁定的端口，默認是60020；
hbase.regionserver.info.port：regionserver的web界面端口，-1取消界面，默認是60030；
hbase.regionserver.info.bindAddress：regionserver的web綁定，默認是0.0.0.0；
hbase.regionserver.info.port.auto：master或者regionserver是否自動搜索綁定的端口，默認是false；
hbase.regionserver.handler.count：regionserver上rpc listener的個數，http://kenwublog.com/hbase-performance-tuning把這個配置稱爲io線程數，其實雷同，就是說在regionserver上一個處理rpc的handler，默認是30；
hbase.regionserver.msginterval：regionserver向master發消息的間隔，默認3000毫秒；
hbase.regionserver.optionallogflushinterval：如果沒有足夠的entry觸發同步，那麼過了這個間隔後HLog將被同步到HDFS，默認是1000毫秒；
hbase.regionserver.regionSplitLimit：regionsplit的最大限額，默認是MAX_INT=2147483647，設置這個限制後，在到達限制時region split就不會再進行；
hbase.regionserver.logroll.period：不管有多少版本，直接roll掉commit log的週期，也就是說一個固定的時間週期，到期就roll，默認是3600000毫秒；
hbase.regionserver.logroll.errors.tolerated：可接受的WAL關閉錯誤個數，到達後將觸發服務器終止；設置爲0那麼在WAL writer做log rolling失敗時就停止region server，默認是2；
hbase.regionserver.hlog.reader.impl：HLog 文件reader的實現類，默認是org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader；
hbase.regionserver.hlog.writer.impl：HLog 文件writer的實現類，默認是org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter；
hbase.regionserver.global.memstore.upperLimit：memstore在regionserver內存中的上限，屆時新的update被阻塞並且flush被強制寫，默認是0.4就是堆內存的40%；阻塞狀態持續到regionserver的所有memstore的容量到達hbase.regionserver.global.memstore.lowerLimit；
hbase.regionserver.global.memstore.lowerLimit：memstore在regionserver內存中的最大上限，到達時flush就被強制寫，默認是0.38等價於38%的內存容量；
hbase.regionserver.optionalcacheflushinterval：一個edit版本在內存中的cache時長，默認3600000毫秒，設置爲0的話則禁止自動flush；
hbase.regionserver.catalog.timeout：regionserver的Catalog Janitor訪問META的超時時間，默認是600000；
hbase.regionserver.dns.interface：同master類似~~不講
hbase.regionserver.dns.nameserver：同master類似
zookeeper.session.timeout：這是個值得說道一下的配置，首先ZK客戶端要用，Hbase使用zk的客戶端聯繫總體，同時也被用來啓動一個zk server，作爲zk的maxSessionTimeout，總的來說就是regionserver與zk的關鍵參數，如果連接超時，master會重新的balance，regionserver也會被從集羣名單中清除，默認是90000；一個問題是如果zk 由hbase自己維護，那麼該參數作爲regionserver連接是一個值，如果zk在另外的集羣，那麼zk自己的maxSessionTimeout參數將優先於Hbase的該參數，屆時可能會發生超時時間不同的問題；
zookeeper.znode.parent：znode存放root region的地址，默認是root-region-server；
zookeeper.znode.acl.parent：root znode的acl，默認acl；
hbase.zookeeper.dns.interface：zk的dns接口，默認default；
hbase.zookeeper.dns.nameserver：zk的dns服務地址，默認default；
hbase.zookeeper.peerport：zk的peer之間的通訊端口，默認是2888；
hbase.zookeeper.leaderport：zk選leader的通訊端口，默認是3888；
hbase.zookeeper.useMulti：zk支持多重update，要求zk在3.4版本以上，默認是false；
hbase.config.read.zookeeper.config：讓hbaseconfig去讀zk的config，默認false，也不支持開啓，這個功能很搞笑~~個人觀點；
hbase.zookeeper.property.initLimit：zk的配置，同步的屬性個數限制，默認10個~~沒用；
hbase.zookeeper.property.syncLimit：zk的配置，同步時的每次請求的條數，默認5個；
hbase.zookeeper.property.dataDir：zk的配置，snapshot存放的目錄，默認是${hbase.tmp.dir}/zookeeper；
hbase.zookeeper.property.clientPort：zk的配置，client連zk的端口，默認2181；
hbase.zookeeper.property.maxClientCnxns：zk的配置，允許接入zk的最大併發連接數的限制，按ip分配，默認300；
Hbase配置項（2）
hbase的配置接上篇
hbase.client.write.buffer：htable客戶端寫緩衝區大小，默認是2097152BYTE，這個緩衝區就是爲了寫數據的臨時存放，設置大了，浪費客戶端和服務端的存儲，設置小了，如果寫的數據多，太多的RPC又帶來網絡開銷，官方給的一個服務端存儲耗費評估計算是：hbase.client.write.buffer*hbase.regionserver.handler.count，服務端的rs的處理handler個數也很關鍵；
hbase.client.pause：pause時長，在hbase發生get或其他操作fail掉的時候進行pause的時間長度，默認是100；
hbase.client.retries.number：發生操作fail時的重試次數，結合上一個指標一起來控制總的重試時間，默認是35；
hbase.client.max.total.tasks：一個HTable實例可以提交給集羣的最大併發任務數，默認是100；
hbase.client.max.perserver.tasks：一個HTable實例給一臺regionserver提交的最大併發任務數，默認是5；
hbase.client.max.perregion.tasks：客戶端連接一臺region的最大連接數，換句話說，當你有這麼多個連接在region時，新的操作不被髮送直到有操作完成，默認是1；
hbase.client.scanner.caching：做scanner的next操作時（如果再本地client沒找到）緩存的數據行數，這個值的設置也需要權衡，緩存的多則快，但吃內存，緩存的少則需要多的拉數據，需要注意的事項是如果兩次調用的時間差大於scanner的timeout，則不要設置該值，默認是100；
hbase.client.keyvalue.maxsize：一個KeyValue實例的最大大小，這是存儲文件中一個entry的容量上限，合理的設置這個值可以控制regionserver的split，split不會拆keyvalue，所以把keyvalue的大小設置爲regionserver大小的一個比例分數（可除）是個不錯的選擇，默認是10485760；
hbase.client.scanner.timeout.period：結合剛纔的caching做的一個，scanner的超時時間，默認是60000毫秒；
hbase.client.localityCheck.threadPoolSize：做localityCheck的線程池大小，默認是2；
hbase.bulkload.retries.number：做bulk load的最大重試次數，默認是0，即代表不斷重試；
hbase.balancer.period：Master運行balancer的週期，默認是300000毫秒；
hbase.regions.slop：如果有regionserver的region數目超過average+(average*slop)，則rebalance，默認是0.2；
hbase.server.thread.wakefrequency：服務線程的sleep時間，默認10000毫秒，比如log roller；
hbase.server.versionfile.writeattempts：退出前寫 version file的重試次數，默認3，每次嘗試的間隔由上一個參數控制；
hbase.hregion.memstore.flush.size：Memstore寫磁盤的flush閾值，超過這個大小就flush，默認是134217728；
hbase.hregion.preclose.flush.size：如果一個region的memstore的大小等於或超過這個參數的量，在關閉region時（放置關閉flag），要提前flush，然後region關閉下線，默認大小是5242880；
hbase.hregion.memstore.block.multiplier：如果memstore的大小滿足hbase.hregion.block.memstore * hbase.hregion.flush.size個byte，那麼阻塞update，這個配置可以避免不必要的長時間split或者compact，甚至是OOME，默認是2；
hbase.hregion.memstore.mslab.enabled：開啓MemStore-Local Allocation Buffer，這個配置可以避免在高寫入的情況下的堆內存碎片，可以降低在大堆情況下的stop-the-world GC頻率，默認是true；
hbase.hregion.max.filesize：HStoreFile的最大尺寸，換句話說，當一個region裏的列族的任意一個HStoreFile超過這個大小，那麼region進行split，默認是10737418240；
hbase.hregion.majorcompaction：一個region的所有HStoreFile進行major compact的時間週期，默認是604800000 毫秒（7天）；
hbase.hregion.majorcompaction.jitter：major compaction的發生抖動範圍，這麼理解比較容易，就是說上一個參數不是一個嚴格週期，會有個抖動，這個參數就是這個抖動的比例，默認是0.5；
hbase.hstore.compactionThreshold：一個HStore存儲HStoreFile的個數閾值，超過這個閾值則所有的HStoreFile會被寫到一個新的HStore，需要平衡取捨，默認是3；
hbase.hstore.blockingStoreFiles：一個HStore存儲HStoreFile阻塞update的閾值，超過這個閾值，HStore就進行compaction，直到做完才允許update，默認是10；
hbase.hstore.blockingWaitTime：一個更強力的配置，配合上一個參數，當HStore阻塞update時，超過這個時間限制，阻塞取消，就算compaction沒有完成，update也不會再被阻塞，默認是90000毫秒；
hbase.hstore.compaction.max：每個minor compaction的HStoreFile個數上限，默認是10；
hbase.hstore.compaction.kv.max：在flushing或者compacting時允許的最大keyvalue個數，如果有大的KeyValue或者OOME的話則配置一個小的值，如果行數多且小則配置大值，默認是10；
hbase.storescanner.parallel.seek.threads：如果並行查找開啓的線程池大小，默認是10；
hfile.block.cache.size：一個配置比例，允許最大堆的對應比例的內存作爲HFile和HStoreFile的block cache，默認是0.4，即40%，設置爲0則disable這個比例，不推薦這麼做；
hfile.block.index.cacheonwrite：在index寫入的時候允許put無根（non-root）的多級索引塊到block cache裏，默認是false；
hfile.index.block.max.size：在多級索引的樹形結構裏，如果任何一層的block index達到這個配置大小，則block寫出，同時替換上新的block，默認是131072；
hfile.format.version：新文件的HFile 格式版本，設置爲1來測試向後兼容，默認是2；
hfile.block.bloom.cacheonwrite：對於組合布隆過濾器的內聯block開啓cache-on-write，默認是false；
io.storefile.bloom.block.size：一個聯合布隆過濾器的單一塊（chunk）的大小，這個值是一個逼近值，默認是131072；
hbase.rs.cacheblocksonwrite：當一個HFile block完成時是否寫入block cache，默認是false；
Hbase配置項（3）
HBase的配置 完結篇：
hbase.rpc.server.engine：hbase 做rpc server的調度管理類，實現自org.apache.hadoop.ipc.RpcServerEngine，默認是org.apache.hadoop.hbase.ipc.ProtobufRpcServerEngine；
hbase.rpc.timeout：Hbase client發起遠程調用時的超時時限，使用ping來確認連接，但是最終會拋出一個TimeoutException，默認值是60000；
hbase.rpc.shortoperation.timeout：另一個版本的hbase.rpc.timeout，控制短操作的超時時限，比如region server 彙報master的操作的超時時限可以設置小，這樣有利於master的failover，默認是10000；
hbase.ipc.client.tcpnodelay：默認是true，具體就是在tcp socket連接時設置 no delay；
hbase.master.keytab.file：kerberos keytab 文件的全路徑名，用來爲HMaster做log，無默認值；
hbase.master.kerberos.principal：運行HMaster進程時需要kerberos的principal name，這個配置就是這個name的值，形如：hbase/[email protected]；
hbase.regionserver.keytab.file：kerberos keytab 文件的全路徑名，用來爲HRegionServer做log，無默認值；
hbase.regionserver.kerberos.principal：運行HRegionServer進程時需要kerberos的principal name，這個配置就是這個name的值，形如：hbase/[email protected]；
hadoop.policy.file：RPC服務器做權限認證時需要的安全策略配置文件，在Hbase security開啓後使用，默認是habse-policy.xml；
hbase.superuser：Hbase security 開啓後的超級用戶配置，一系列由逗號隔開的user或者group；
hbase.auth.key.update.interval：Hbase security開啓後服務端更新認證key的間隔時間：默認是86400000毫秒；
hbase.auth.token.max.lifetime：Hbase security開啓後，認證token下發後的生存週期，默認是604800000毫秒；
hbase.ipc.client.fallback-to-simple-auth-allowed：client使用安全連接去鏈接一臺非安全服務器時，服務器提示client切換到SASL SIMPLE認證模式（非安全），如果設置爲true，則client同意切換到非安全連接，如果false，則退出連接；
hbase.coprocessor.region.classes：逗號分隔的Coprocessores列表，會被加載到默認所有表上。在自己實現了一個Coprocessor後，將其添加到Hbase的classpath並加入全限定名。也可以延遲加載，由HTableDescriptor指定；
hbase.rest.port：Hbase REST服務器的端口，默認是8080；
hbase.rest.readonly：定義REST服務器啓動的模式，有兩種方式，false：所有http方法都將被通過-GET/PUT/POST/DELETE，true：只有get方法ok。默認值是false；
hbase.rest.threads.max：REST服務器線程池的最大線程數，池滿的話新請求會自動排隊，限制這個配置可以控制服務器的內存量，預防OOM，默認是100；
hbase.rest.threads.min：同上類似，最小線程數，爲了確保服務器的服務狀態，默認是2；
hbase.rest.support.proxyuser：使REST服務器支持proxy-user 模式，默認是false；
hbase.defaults.for.version.skip：是否跳過hbase.defaults.for.version的檢查，默認是false；
hbase.coprocessor.master.classes：由HMaster進程加載的coprocessors，逗號分隔，全部實現org.apache.hadoop.hbase.coprocessor.MasterObserver，同coprocessor類似，加入classpath及全限定名；
hbase.coprocessor.abortonerror：如果coprocessor加載失敗或者初始化失敗或者拋出Throwable對象，則主機退出。設置爲false會讓系統繼續運行，但是coprocessor的狀態會不一致，所以一般debug時纔會設置爲false，默認是true；
hbase.online.schema.update.enable：設置true來允許在線schema變更，默認是true；
hbase.table.lock.enable：設置爲true來允許在schema變更時zk鎖表，鎖表可以組織併發的schema變更導致的表狀態不一致，默認是true；
hbase.thrift.minWorkerThreads：線程池的core size，在達到這裏配置的量級後，新線程纔會再新的連接創立時創建，默認是16；
hbase.thrift.maxWorkerThreads：顧名思義，最大線程數，達到這個數字後，服務器開始drop連接，默認是1000；
hbase.thrift.maxQueuedRequests：Thrift連接隊列的最大數，如果線程池滿，會先在這個隊列中緩存請求，緩存上限就是該配置，默認是1000；
hbase.thrift.htablepool.size.max：Thrift服務器上table pool的最大上限，默認是1000；
hbase.offheapcache.percentage：JVM參數-XX:MaxDirectMemorySize的百分比值，默認是0，即不開啓堆外分配；
hbase.data.umask.enable：開啓後，文件在regionserver寫入時會有權限相關設定，默認是false不開啓；
hbase.data.umask：開啓上面一項配置後，文件的權限umask，默認是000；
hbase.metrics.showTableName：是否爲每個指標顯示錶名前綴，默認是true；
hbase.metrics.exposeOperationTimes：是否進行關於操作在使用時間維度的指標報告，比如GET PUT DELETE INCREMENT等，默認是true；
hbase.snapshot.enabled：是否允許snapshot被使用、存儲和克隆，默認是true；
hbase.snapshot.restore.take.failsafe.snapshot：在restore過程中，如果失敗則啓用snapshot替換，成功則刪除掉snapshot，默認開啓true；
hbase.snapshot.restore.failsafe.name：剛纔所說過程中snapshot的名字，默認是hbase-failsafe-{snapshot.name}-{restore.timestamp}；
hbase.server.compactchecker.interval.multiplier：檢查是否需要compact的時間間隔，一般情況是在比如memstore flush後或者其他事件觸發compact的，但是有時也需要不同的compact策略，所以需要週期性的檢查具體間隔=hbase.server.compactchecker.interval.multiplier * hbase.server.thread.wakefrequency，默認1000；
hbase.lease.recovery.timeout：在dfs 租約超時時限，超時則放棄，默認是900000；
hbase.lease.recovery.dfs.timeout：dfs恢復租約調用的超時時限，默認是64000；