下面我們列出一些重要的配置。我們已經將這部分分為必需的配置和值得推薦的配置。
HBase所需的配置
請你參考本教程中HBase基礎條件中的操作系統和Hadoop部分的內容！
大型群集配置
如果您擁有一個包含大量區域的群集，那麼在主服務器啟動後，Regionserver可能會暫時地進行檢查，而所有剩餘的RegionServers落後。要簽入的第一臺服務器將被分配到所有不是最優的區域。為防止出現上述情況，請將其hbase.master.wait.on.regionservers.mintostart屬性從其默認值1中調高。
HBase推薦的配置
ZooKeeper 配置：zookeeper.session.timeout
默認的超時時間是三分鐘（以毫秒為單位）。這意味著，如果服務器崩潰，則在主服務器在三分鐘前發現崩潰並開始恢復。您可能需要將超時調整到一分鐘甚至更短的時間，以便主服務器儘快通知故障。在更改此值之前，請確保您的JVM垃圾收集配置處於受控狀態，否則，長時間的垃圾回收會超出ZooKeeper會話超時時間，將取出您的RegionServer。（如果一個RegionServer長時間處於GC狀態，你可能需要在服務器上啟動恢復）。
要更改此配置，請編輯hbase-site.xml，將更改的文件複製到群集中並重新啟動。
我們將這個值設置得很高，以避免不必要的麻煩。如果出現類似“為什麼我在執行一個大規模數據導入的時候Region Server死掉啦”這樣的問題，可以解釋的原因是：他們的JVM未被解析，並且正在運行長時間的GC操作。
ZooKeeper 實例的數量
HDFS 配置
dfs.datanode.failed.volumes.tolerated
這是“DataNode 停止提供服務之前允許失敗的卷數。默認情況下，任何卷失敗都會導致 datanode 關閉”從HDFS-default.xml中的描述。您可能希望將其設置為可用磁盤數量的一半左右。
hbase.regionserver.handler.count
此設置定義了為應答傳入的用戶表請求而保持打開的線程數。經驗法則是，當每個請求的有效載荷接近MB（大容量、掃描使用大緩存）時保持低數字，並且當有效負載小（獲取，小投入，ICV，刪除）時保持此數字為高。正在進行的查詢的總大小受設置hbase.ipc.server.max.callqueue.size的限制。
如果這個數字的有效載荷很小，那麼將這個數字設置為最大傳入客戶端數量是安全的，典型的例子是一個服務於網站的集群，因為put通常不被緩衝，大部分操作都是獲取的。
保持此設置的高風險的原因是，當前在區域服務器中發生的所有投入的總大小可能對其內存造成太大的壓力，甚至會觸發OutOfMemoryError。在低內存上運行的RegionServer將觸發其JVM的垃圾收集器，以更頻繁的方式運行，直到GC暫停變得明顯（原因是用於保留所有請求的有效載荷的所有內存不能被丟棄，即便垃圾收集器正在進行嘗試）。一段時間之後，整個群集吞吐量都會受到影響，因為每個碰到該RegionServer的請求都將花費更長的時間，這更加劇了問題的嚴重性。
您可以通過rpc.logging查看某個RegionServer上是否有太多或太多的處理程序，然後跟蹤其日誌（排隊請求消耗內存）。
大型內存機器的配置
HBase提供了一個合理的，保守的配置，可以在幾乎所有人們可能想要測試的機器類型上運行。如果你有更大的機器 - HBase有8G或更大的堆 - 你可能會發現下面的配置選項很有幫助。
壓縮（Compression）
您應該考慮啟用ColumnFamily壓縮。有幾個選項可以在大多數情況下都是通過減小StoreFiles的大小來提高性能，從而減少I / O。
請參閱“HBase壓縮”瞭解更多信息。
配置WAL文件的大小和數量
在發生RS故障的情況下，HBase使用wal恢復尚未刷新到磁盤的memstore數據。這些WAL文件應該配置為略小於HDFS塊（默認情況下，HDFS塊為64Mb，WAL文件為〜60Mb）。
HBase也對WAL文件的數量有限制，旨在確保在恢復過程中不會有太多的數據需要重放。這個限制需要根據memstore配置進行設置，以便所有必要的數據都可以適用。建議分配足夠多的WAL文件來存儲至少那麼多的數據（當所有的存儲都接近完整時）。例如，對於16Gb RS堆，默認的memstore設置（0.4）和默認的WAL文件大小（〜60Mb），16Gb * 0.4 / 60，WAL文件數的起點為〜109。但是，由於所有的memstores不會一直佔滿，所以可以分配更少的WAL文件。
管理分割（Splitting）
HBase通常會根據您的hbase-default.xml和hbase-site.xml 配置文件中的設置來處理您所在區域的分割。重要的設置包括：hbase.regionserver.region.split.policy，hbase.hregion.max.filesize，hbase.regionserver.regionSplitLimit。分割的一個簡單的觀點是，當一個區域發展到hbase.hregion.max.filesize時，它被分割。對於大多數使用模式，您應該使用自動分割。有關手動區域分割的更多信息，請參閱手動區域分割決策。
不要讓HBase自動分割你的區域，你可以選擇自己管理分割。HBase 0.90.0增加了這個功能。如果你知道你的密鑰空間，手動管理分割就行，否則讓HBase為你分割。手動分割可以減輕在負載下的區域創建和移動。這也使得區域邊界是已知的和不變的（如果你禁用區域分割）。如果使用手動分割，則可以更輕鬆地進行交錯式的基於時間的主要壓縮來分散網絡IO負載。
禁用自動分割：要禁用自動拆分，可以在集群配置或表配置中設置區域拆分策略：org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy
自動分割建議：如果禁用自動分割來診斷問題或在數據快速增長期間，建議在您的情況變得更加穩定時重新啟用它們。
確定預分割區域的最佳數目：
預分割區域的最佳數量取決於您的應用程序和環境。一個好的經驗法則是從每個服務器的10個預分割區域開始，隨著時間的推移數據不斷增長。儘量在區域太少的地方犯錯，稍後進行滾動分割更好。區域的最佳數量取決於您所在區域中最大的StoreFile。如果數據量增加，最大的StoreFile的大小將隨著時間增加。目標是使最大的區域足夠大，壓實選擇算法僅在定時的主要壓實期間將其壓縮。否則，該集群可能會同時出現大量壓實區域的壓實風暴。數據增長導致壓縮風暴，而不是人工分割決策，這一點很重要。
如果區域被分割成太多的區域，可以通過配置HConstants.MAJOR_COMPACTION_PERIOD來增加主要的壓縮間隔。HBase 0.90引入了org.apache.hadoop.hbase.util.RegionSplitter，它提供所有區域的網絡IO安全滾動分割。
管理壓縮（Compactions）
默認情況下，主要的壓縮計劃在7天內運行一次。在HBase 0.96.x之前，默認情況下主要的壓縮計劃是每天發生一次。
如果您需要精確控制主要壓縮的運行時間和頻率，可以禁用託管的主要壓縮。請參閱“compaction.parameters表中的hbase.hregion.majorcompaction條目”的詳細信息。
不禁用主要壓縮：對於StoreFile清理來說，重要的壓縮是絕對必要的。不要完全禁用它們。您可以通過HBase shell或Admin API手動運行主要壓縮。
預測執行（Speculative Execution）
預測執行MapReduce任務是默認開啟的，對於HBase集群，通常建議關閉系統級的推測執行，除非您需要在特定情況下可以配置每個作業。將屬性 mapreduce.map.speculative 和 mapreduce.reduce.speculative 設置為 false。
其他配置
平衡器（Balancer）
平衡器（Balancer）是在主服務器上運行的一個週期性操作，用於重新分配集群上的區域。它通過hbase.balancer.period配置，默認為300000（5分鐘）。
有關LoadBalancer的更多信息，請參閱master.processes.loadbalancer。
禁用Blockcache
不要關閉塊緩存（你可以通過設置hfile.block.cache.size為零來實現）。這樣做沒有好處，因為RegionServer將花費所有的時間一次又一次地加載HFile索引。如果你的工作集是這樣配置塊緩存，那麼沒有益處，最少應保證hfile指數保存在塊緩存內的大小（你可以通過調查RegionServer UI粗略地瞭解你需要的大小；請參閱佔網頁頂部附近的索引塊大小）。
Nagle’s或小包裝的問題
如果在對HBase的操作中出現大約40ms左右的延遲，請嘗試Nagles的設置。例如，請參閱用戶郵件列表線程，將緩存設置為1的不一致掃描性能以及其中所引用的設置tcpNoDelay來提高掃描速度的問題。您也可以查看該文檔的尾部圖表：HBASE-7008 Set掃描緩存到一個更好的默認位置，我們的Lars Hofhansl會嘗試使用Nagle打開和關閉測量效果的各種數據大小。
更好的平均恢復時間（MTTR）
這部分是關於在服務器出現故障後會使服務器恢復更快的配置。請參閱Deveraj Das和Nicolas Liochon博客文章：簡介HBase平均恢復時間（MTTR）。
HBASE-8354強制Namenode使用lease恢復請求循環的問題是混亂的，但在低超時以及如何引起更快的恢復，包括引用添加到HDFS的修復程序方面，有很多好的討論。下面建議的配置是Varun的建議的提煉和測試，確保你在HDFS版本上運行，所以你有他所提到的修補程序，並且他自己添加到HDFS，幫助HBase MTTR（例如HDFS-3703，HDFS-3712和HDFS-4791 -Hadoop 2確保有他們並且後期Hadoop 1有一些）。在RegionServer中設置以下內容：
在NameNode/DataNode端，設置以下內容來啟用HDFS-3703，HDFS-3912中引入的“staleness”：
JMX
JMX（Java Management Extensions，Java管理擴展）提供了內置的工具，使您能夠監視和管理Java VM。要啟用遠程系統的監視和管理，在啟動 Java VM 時，您需要設置系統屬性com.sun.management.jmxremote.port（要啟用JMX RMI連接的端口號）。從歷史上看，除了上面提到的端口之外，JMX還會打開兩個附加的隨機TCP偵聽端口，這可能會導致端口衝突問題。
作為一種替代方法，您可以使用HBase提供的基於協處理器的JMX實現。要在0.99或更高版本中啟用它，請在hbase-site.xml中添加以下屬性：
不要同時為Java VM 設置com.sun.management.jmxremote.port
目前它支持Master和RegionServer Java VM。默認情況下，JMX偵聽TCP端口10102，您可以使用以下屬性進一步配置端口：
在大多數情況下，註冊表端口可以與連接器端口共享，所以只需要配置regionserver.rmi.registry.port。但是，如果要使用SSL通信，則必須將2個端口配置為不同的值。
默認情況下，密碼認證和SSL通信被禁用。要啟用密碼驗證，您需要像下面那樣更新hbase-env.sh：
請參閱$ JRE_HOME/lib/management下面的示例password/access文件。
要使用密碼驗證啟用SSL通信，請按照以下步驟操作：
然後像下面這樣更新hbase-env.sh：
最後，使用密鑰存儲在客戶端上啟動 jconsole：
要在主服務器上啟用HBase JMX實現，還需要在hbase-site.xml中添加以下屬性：
端口配置的相應屬性為：master.rmi.registry.port（默認為10101）和master.rmi.connector.port（默認情況下與registry.port相同）。
閱讀更多 會飛的魚go 的文章
