前言：參數之於軟件系統就像按鈕之於工程系統，絕大多數工程師對於工程系統的認知就是首先從這些按鈕來的，而且通常來說按鈕越多，系統就會越複雜。認知過程無非三個階段，首先弄明白這些按鈕都用來控制神馬，再者是在什麼場景下需要旋轉按鈕、如何旋轉，最後就是弄清楚爲什麼在這種場景下這麼旋轉，在另外一種場景下那樣旋轉。軟件參數亦是一樣。
接下來筆者會將HBase中常見的參數分類整理（版本爲HBase 1.1.2），主要解釋每個參數的實際意義以及在生產線上的配置注意事項，如果關注這些參數背後的運作原理，可以參考之前的HBase原理相關文章，裏面或多或少都有提及。
Region
hbase.hregion.max.filesize：默認10G，簡單理解爲Region中任意HStore所有文件大小總和大於該值就會進行分裂。
解讀：實際生產環境中該值不建議太大，也不能太小。太大會導致系統後臺執行compaction消耗大量系統資源，一定程度上影響業務響應；太小會導致Region分裂比較頻繁（分裂本身其實對業務讀寫會有一定影響），另外單個RegionServer中必然存在大量Region，太多Region會消耗大量維護資源，並且在rs下線遷移時比較費勁。綜合考慮，建議線上設置爲50G～80G左右。
BlockCache
該模塊主要介紹BlockCache相關的參數，這個模塊參數非常多，而且比較容易混淆。不同BlockCache策略對應不同的參數，而且這裏參數配置會影響到Memstore相關參數的配置。筆者對BlockCache策略一直持有這樣的觀點：RS內存在20G以內的就選擇LRUBlockCache，大於20G的就選擇BucketCache中的Offheap模式。接下來所有的相關配置都基於BucketCache的offheap模型進行說明。
file.block.cache.size：默認0.4，該值用來設置LRUBlockCache的內存大小，0.4表示JVM內存的40%。
解讀：當前HBase系統默認採用LRUBlockCache策略，BlockCache大小和Memstore大小均爲JVM的40%。但對於BucketCache策略來講，Cache分爲了兩層，L1採用LRUBlockCache，主要存儲HFile中的元數據Block，L2採用BucketCache，主要存儲業務數據Block。因爲只用來存儲元數據Block，所以只需要設置很小的Cache即可。建議線上設置爲0.05～0.1左右。
hbase.bucketcache.ioengine：offheap
hbase.bucketcache.size：堆外存大小，設置多大就看自己的物理內存大小嘍
Memstore
hbase.hregion.memstore.flush.size：默認128M（134217728），memstore大於該閾值就會觸發flush。如果當前系統flush比較頻繁，並且內存資源比較充足，可以適當將該值調整爲256M。
hbase.hregion.memstore.block.multiplier：默認4，表示一旦某region中所有寫入memstore的數據大小總和達到或超過閾值hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size，就會執行flush操作，並拋出RegionTooBusyException異常。
解讀：該值在1.x版本默認值爲2，比較小，爲了保險起見會將其修改爲5。而當前1.x版本默認值已經爲4，通常不會有任何問題。如果日誌中出現類似”Above memstore limit, regionName = ****, server = ****, memstoreSizse = ****, blockingMemstoreSize = ****”，就需要考慮修改該參數了。
hbase.regionserver.global.memstore.size：默認0.4，表示整個RegionServer上所有寫入memstore的數據大小總和不能超過該閾值，否則會阻塞所有寫入請求並強制執行flush操作，直至總memstore數據大小降到hbase.regionserver.global.memstore.lowerLimit以下。
解讀：該值在offheap模式下需要配置爲0.6～0.65。一旦寫入出現阻塞，立馬查看日誌定位“Blocking update on ***: the global memstore size *** is >= than blocking *** size”。一般情況下不會出現這類異常，如果出現需要明確是不是region數目太多、單表列族設計太多。
hbase.regionserver.global.memstore.lowerLimit：默認0.95。不需要修改。
hbase.regionserver.optionalcacheflushinterval：默認1h（3600000），hbase會起一個線程定期flush所有memstore，時間間隔就是該值配置。
解讀：生產線上該值建議設大，比如10h。因爲很多場景下1小時flush一次會導致產生很多小文件，一方面導致flush比較頻繁，一方面導致小文件很多，影響隨機讀性能。因此建議設置較大值。
Compaction
compaction模塊主要用來合併小文件，刪除過期數據、deleted數據等。涉及參數較多，對於系統讀寫性能影響也很重要，下面主要介紹部分比較核心的參數。
hbase.hstore.compactionThreshold：默認爲3，compaction的觸發條件之一，當store中文件數超過該閾值就會觸發compaction。通常建議生產線上寫入qps較高的系統調高該值，比如5～10之間。
hbase.hstore.compaction.max：默認爲10，最多可以參與minor compaction的文件數。該值通常設置爲hbase.hstore.compactionThreshold的2～3倍。
hbase.regionserver.thread.compaction.throttle：默認爲2G，評估單個compaction爲small或者large的判斷依據。爲了防止large compaction長時間執行阻塞其他small compaction，hbase將這兩種compaction進行了分離處理，每種compaction會分配獨立的線程池。
hbase.regionserver.thread.compaction.large/small：默認爲1，large和small compaction的處理線程數。生產線上建議設置爲5，強烈不建議再調太大（比如10），否則會出現性能下降問題。
hbase.hstore.blockingStoreFiles：默認爲10，表示一旦某個store中文件數大於該閾值，就會導致所有更新阻塞。生產線上建議設置該值爲100，避免出現阻塞更新，一旦發現日誌中打印’*** too many store files ***’，就要查看該值是否設置正確。
hbase.hregion.majorcompaction：默認爲1周（1000*60*60*24*7），表示major compaction的觸發週期。生產線上建議大表major compaction手動執行，需要將此參數設置爲0，即關閉自動觸發機制。
HLog
hbase.regionserver.maxlogs：默認爲32，region flush的觸發條件之一，wal日誌文件總數超過該閾值就會強制執行flush操作。該默認值對於很多集羣來說太小，生產線上具體設置參考HBASE-14951
hbase.regionserver.hlog.splitlog.writer.threads：默認爲3，regionserver恢復數據時日誌按照region切分之後寫入buffer，重新寫入hdfs的線程數。生產環境因爲region個數普遍較多，爲了加速數據恢復，建議設置爲10。
Call Queue
hbase.regionserver.handler.count：默認爲30，服務器端用來處理用戶請求的線程數。生產線上通常需要將該值調到100～200。
解讀：response time = queue time + service time，用戶關心的請求響應時間由兩部分構成，優化系統需要經常關注queue time，如果用戶請求排隊時間很長，首要關注的問題就是hbase.regionserver.handler.count是否沒有調整。
hbase.ipc.server.callqueue.handler.factor :默認爲0，服務器端設置隊列個數，假如該值爲0.1，那麼服務器就會設置handler.count * 0.1 = 30 * 0.1 = 3個隊列。
hbase.ipc.server.callqueue.read.ratio :默認爲0，服務器端設置讀寫業務分別佔用的隊列百分比以及handler百分比。假如該值爲0.5，表示讀寫各佔一半隊列，同時各佔一半handler。
hbase.ipc.server.call.queue.scan.ratio：默認爲0，服務器端爲了將get和scan隔離設置了該參數。
Others
hbase.online.schema.update.enable：默認爲false，表示更新表schema的時候不再需要先disable再enable，直接在線更新。該參數在HBase 2.0之後將會默認爲true。生產線上建議設置爲true。
hbase.quota.enabled：默認爲false，表示是否開啓quota功能，quota功能主要用來限制用戶/表的QPS，起到限流作用。生產線上建議設置爲true。
hbase.snapshot.enabled：默認爲false，表示是否開啓snapshot功能，snapshot功能主要用來備份HBase數據。生產線上建議設置爲true。
zookeeper.session.timeout：默認180s，表示zookeeper客戶端與服務器端session超時時間，超時之後RegionServer將會被踢出集羣。
解讀：有兩點需要重點關注，其一是該值需要與Zookeeper服務器端session相關參數一同設置纔會生效，一味的將該值增大而不修改ZK服務端參數，可能並不會實際生效。其二是通常情況下離線集羣可以將該值設置較大，在線業務需要根據業務對延遲的容忍度考慮設置。
hbase.zookeeper.useMulti：默認爲false，表示是否開啓zookeeper的multi-update功能，該功能在某些場景下可以加速批量請求完成，而且可以有效防止部分異常問題。生產線上建議設置爲true。注意設置爲true的前提是Zookeeper服務端的版本在3.4以上，否則會出現zk客戶端夯住的情況。
hbase.coprocessor.master.classes：生產線上建議設置org.apache.hadoop.hbase.security.access.AccessController，可以使用grant命令對namespace\table\cf設置訪問權限。
hbase.coprocessor.region.classes：生產線上建議設置org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.AccessController，同上。
HBase系統中存在大量參數，大部分參數並不需要修改，只有一小部分核心參數需要根據集羣硬件環境、網絡環境以及業務類型進行調整設置。本文主要將這些核心參數的意義進行了簡單說明並給出了生產線上的調整方案，方便HBase新同學能夠更加容易入手（筆者還是建議有興趣的同學能夠了解這些參數背後的故事）。需要注意的是上述參數可能並不完整，比如kerberos、replication、rest、thrift、hdfs client等相關模塊參數並沒有涉及，如有需要可以參考其他資料進行配置。
本文來自網易實踐者社區，經作者範欣欣授權發佈，可點擊閱讀原文查看。
往期推薦 點擊標題跳轉
3、MapReduce Shuffle 和 Spark Shuffle 結業篇
