下面我們列出一些重要的配置。我們已經(jīng)將這部分分為必需的配置和值得推薦的配置。

HBase所需的配置

請你參考本教程中HBase基礎條件中的操作系統(tǒng)和Hadoop部分的內(nèi)容！

大型群集配置

如果您擁有一個包含大量區(qū)域的群集，那么在主服務器啟動后，Regionserver可能會暫時地進行檢查，而所有剩余的RegionServers落后。要簽入的第一臺服務器將被分配到所有不是最優(yōu)的區(qū)域。為防止出現(xiàn)上述情況，請將其hbase.master.wait.on.regionservers.mintostart屬性從其默認值1中調(diào)高。

HBase推薦的配置

ZooKeeper 配置：zookeeper.session.timeout

默認的超時時間是三分鐘（以毫秒為單位）。這意味著，如果服務器崩潰，則在主服務器在三分鐘前發(fā)現(xiàn)崩潰并開始恢復。您可能需要將超時調(diào)整到一分鐘甚至更短的時間，以便主服務器盡快通知故障。在更改此值之前，請確保您的JVM垃圾收集配置處于受控狀態(tài)，否則，長時間的垃圾回收會超出ZooKeeper會話超時時間，將取出您的RegionServer。（如果一個RegionServer長時間處于GC狀態(tài)，你可能需要在服務器上啟動恢復）。

要更改此配置，請編輯hbase-site.xml，將更改的文件復制到群集中并重新啟動。

我們將這個值設置得很高，以避免不必要的麻煩。如果出現(xiàn)類似“為什么我在執(zhí)行一個大規(guī)模數(shù)據(jù)導入的時候Region Server死掉啦”這樣的問題，可以解釋的原因是：他們的JVM未被解析，并且正在運行長時間的GC操作。

ZooKeeper 實例的數(shù)量

見ZooKeeper。

HDFS 配置

dfs.datanode.failed.volumes.tolerated

這是“DataNode 停止提供服務之前允許失敗的卷數(shù)。默認情況下，任何卷失敗都會導致 datanode 關閉”從HDFS-default.xml中的描述。您可能希望將其設置為可用磁盤數(shù)量的一半左右。

hbase.regionserver.handler.count

此設置定義了為應答傳入的用戶表請求而保持打開的線程數(shù)。經(jīng)驗法則是，當每個請求的有效載荷接近MB（大容量、掃描使用大緩存）時保持低數(shù)字，并且當有效負載?。ǐ@取，小投入，ICV，刪除）時保持此數(shù)字為高。正在進行的查詢的總大小受設置hbase.ipc.server.max.callqueue.size的限制。

如果這個數(shù)字的有效載荷很小，那么將這個數(shù)字設置為最大傳入客戶端數(shù)量是安全的，典型的例子是一個服務于網(wǎng)站的集群，因為put通常不被緩沖，大部分操作都是獲取的。

保持此設置的高風險的原因是，當前在區(qū)域服務器中發(fā)生的所有投入的總大小可能對其內(nèi)存造成太大的壓力，甚至會觸發(fā)OutOfMemoryError。在低內(nèi)存上運行的RegionServer將觸發(fā)其JVM的垃圾收集器，以更頻繁的方式運行，直到GC暫停變得明顯（原因是用于保留所有請求的有效載荷的所有內(nèi)存不能被丟棄，即便垃圾收集器正在進行嘗試）。一段時間之后，整個群集吞吐量都會受到影響，因為每個碰到該RegionServer的請求都將花費更長的時間，這更加劇了問題的嚴重性。

您可以通過rpc.logging查看某個RegionServer上是否有太多或太多的處理程序，然后跟蹤其日志（排隊請求消耗內(nèi)存）。

大型內(nèi)存機器的配置

HBase提供了一個合理的，保守的配置，可以在幾乎所有人們可能想要測試的機器類型上運行。如果你有更大的機器 - HBase有8G或更大的堆 - 你可能會發(fā)現(xiàn)下面的配置選項很有幫助。

壓縮（Compression）

您應該考慮啟用ColumnFamily壓縮。有幾個選項可以在大多數(shù)情況下都是通過減小StoreFiles的大小來提高性能，從而減少I / O。

請參閱“HBase壓縮”了解更多信息。

配置WAL文件的大小和數(shù)量

在發(fā)生RS故障的情況下，HBase使用wal恢復尚未刷新到磁盤的memstore數(shù)據(jù)。這些WAL文件應該配置為略小于HDFS塊（默認情況下，HDFS塊為64Mb，WAL文件為?60Mb）。

HBase也對WAL文件的數(shù)量有限制，旨在確保在恢復過程中不會有太多的數(shù)據(jù)需要重放。這個限制需要根據(jù)memstore配置進行設置，以便所有必要的數(shù)據(jù)都可以適用。建議分配足夠多的WAL文件來存儲至少那么多的數(shù)據(jù)（當所有的存儲都接近完整時）。例如，對于16Gb RS堆，默認的memstore設置（0.4）和默認的WAL文件大?。?60Mb），16Gb * 0.4 / 60，WAL文件數(shù)的起點為?109。但是，由于所有的memstores不會一直占滿，所以可以分配更少的WAL文件。

管理分割（Splitting）

HBase通常會根據(jù)您的hbase-default.xml和hbase-site.xml 配置文件中的設置來處理您所在區(qū)域的分割。重要的設置包括：hbase.regionserver.region.split.policy，hbase.hregion.max.filesize，hbase.regionserver.regionSplitLimit。分割的一個簡單的觀點是，當一個區(qū)域發(fā)展到hbase.hregion.max.filesize時，它被分割。對于大多數(shù)使用模式，您應該使用自動分割。有關手動區(qū)域分割的更多信息，請參閱手動區(qū)域分割決策。

不要讓HBase自動分割你的區(qū)域，你可以選擇自己管理分割。HBase 0.90.0增加了這個功能。如果你知道你的密鑰空間，手動管理分割就行，否則讓HBase為你分割。手動分割可以減輕在負載下的區(qū)域創(chuàng)建和移動。這也使得區(qū)域邊界是已知的和不變的（如果你禁用區(qū)域分割）。如果使用手動分割，則可以更輕松地進行交錯式的基于時間的主要壓縮來分散網(wǎng)絡IO負載。

禁用自動分割：要禁用自動拆分，可以在集群配置或表配置中設置區(qū)域拆分策略：org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy

自動分割建議：如果禁用自動分割來診斷問題或在數(shù)據(jù)快速增長期間，建議在您的情況變得更加穩(wěn)定時重新啟用它們。

確定預分割區(qū)域的最佳數(shù)目：

預分割區(qū)域的最佳數(shù)量取決于您的應用程序和環(huán)境。一個好的經(jīng)驗法則是從每個服務器的10個預分割區(qū)域開始，隨著時間的推移數(shù)據(jù)不斷增長。盡量在區(qū)域太少的地方犯錯，稍后進行滾動分割更好。區(qū)域的最佳數(shù)量取決于您所在區(qū)域中最大的StoreFile。如果數(shù)據(jù)量增加，最大的StoreFile的大小將隨著時間增加。目標是使最大的區(qū)域足夠大，壓實選擇算法僅在定時的主要壓實期間將其壓縮。否則，該集群可能會同時出現(xiàn)大量壓實區(qū)域的壓實風暴。數(shù)據(jù)增長導致壓縮風暴，而不是人工分割決策，這一點很重要。

如果區(qū)域被分割成太多的區(qū)域，可以通過配置HConstants.MAJOR_COMPACTION_PERIOD來增加主要的壓縮間隔。HBase 0.90引入了org.apache.hadoop.hbase.util.RegionSplitter，它提供所有區(qū)域的網(wǎng)絡IO安全滾動分割。

管理壓縮（Compactions）

默認情況下，主要的壓縮計劃在7天內(nèi)運行一次。在HBase 0.96.x之前，默認情況下主要的壓縮計劃是每天發(fā)生一次。

如果您需要精確控制主要壓縮的運行時間和頻率，可以禁用托管的主要壓縮。請參閱“compaction.parameters表中的hbase.hregion.majorcompaction條目”的詳細信息。

不禁用主要壓縮：對于StoreFile清理來說，重要的壓縮是絕對必要的。不要完全禁用它們。您可以通過HBase shell或Admin API手動運行主要壓縮。

預測執(zhí)行（Speculative Execution）

預測執(zhí)行MapReduce任務是默認開啟的，對于HBase集群，通常建議關閉系統(tǒng)級的推測執(zhí)行，除非您需要在特定情況下可以配置每個作業(yè)。將屬性 mapreduce.map.speculative 和 mapreduce.reduce.speculative 設置為 false。

其他配置

平衡器（Balancer）

平衡器（Balancer）是在主服務器上運行的一個周期性操作，用于重新分配集群上的區(qū)域。它通過hbase.balancer.period配置，默認為300000（5分鐘）。

有關LoadBalancer的更多信息，請參閱master.processes.loadbalancer。

禁用Blockcache

不要關閉塊緩存（你可以通過設置hfile.block.cache.size為零來實現(xiàn)）。這樣做沒有好處，因為RegionServer將花費所有的時間一次又一次地加載HFile索引。如果你的工作集是這樣配置塊緩存，那么沒有益處，最少應保證hfile指數(shù)保存在塊緩存內(nèi)的大?。憧梢酝ㄟ^調(diào)查RegionServer UI粗略地了解你需要的大??；請參閱占網(wǎng)頁頂部附近的索引塊大?。?。

Nagle’s或小包裝的問題

如果在對HBase的操作中出現(xiàn)大約40ms左右的延遲，請嘗試Nagles的設置。例如，請參閱用戶郵件列表線程，將緩存設置為1的不一致掃描性能以及其中所引用的設置tcpNoDelay來提高掃描速度的問題。您也可以查看該文檔的尾部圖表：HBASE-7008 Set掃描緩存到一個更好的默認位置，我們的Lars Hofhansl會嘗試使用Nagle打開和關閉測量效果的各種數(shù)據(jù)大小。

更好的平均恢復時間（MTTR）

這部分是關于在服務器出現(xiàn)故障后會使服務器恢復更快的配置。請參閱Deveraj Das和Nicolas Liochon博客文章：簡介HBase平均恢復時間（MTTR）。

HBASE-8354強制Namenode使用lease恢復請求循環(huán)的問題是混亂的，但在低超時以及如何引起更快的恢復，包括引用添加到HDFS的修復程序方面，有很多好的討論。下面建議的配置是Varun的建議的提煉和測試，確保你在HDFS版本上運行，所以你有他所提到的修補程序，并且他自己添加到HDFS，幫助HBase MTTR（例如HDFS-3703，HDFS-3712和HDFS-4791 -Hadoop 2確保有他們并且后期Hadoop 1有一些）。在RegionServer中設置以下內(nèi)容：

<property>
  <name>hbase.lease.recovery.dfs.timeout</name>
  <value>23000</value>
  <description>How much time we allow elapse between calls to recover lease.
  Should be larger than the dfs timeout.</description>
</property>
<property>
  <name>dfs.client.socket-timeout</name>
  <value>10000</value>
  <description>Down the DFS timeout from 60 to 10 seconds.</description>
</property>

在NameNode/DataNode端，設置以下內(nèi)容來啟用HDFS-3703，HDFS-3912中引入的“staleness”：

<property>
  <name>dfs.client.socket-timeout</name>
  <value>10000</value>
  <description>Down the DFS timeout from 60 to 10 seconds.</description>
</property>
<property>
  <name>dfs.datanode.socket.write.timeout</name>
  <value>10000</value>
  <description>Down the DFS timeout from 8 * 60 to 10 seconds.</description>
</property>
<property>
  <name>ipc.client.connect.timeout</name>
  <value>3000</value>
  <description>Down from 60 seconds to 3.</description>
</property>
<property>
  <name>ipc.client.connect.max.retries.on.timeouts</name>
  <value>2</value>
  <description>Down from 45 seconds to 3 (2 == 3 retries).</description>
</property>
<property>
  <name>dfs.namenode.avoid.read.stale.datanode</name>
  <value>true</value>
  <description>Enable stale state in hdfs</description>
</property>
<property>
  <name>dfs.namenode.stale.datanode.interval</name>
  <value>20000</value>
  <description>Down from default 30 seconds</description>
</property>
<property>
  <name>dfs.namenode.avoid.write.stale.datanode</name>
  <value>true</value>
  <description>Enable stale state in hdfs</description>
</property>

JMX

JMX（Java Management Extensions，Java管理擴展）提供了內(nèi)置的工具，使您能夠監(jiān)視和管理Java VM。要啟用遠程系統(tǒng)的監(jiān)視和管理，在啟動 Java VM 時，您需要設置系統(tǒng)屬性com.sun.management.jmxremote.port（要啟用JMX RMI連接的端口號）。從歷史上看，除了上面提到的端口之外，JMX還會打開兩個附加的隨機TCP偵聽端口，這可能會導致端口沖突問題。

作為一種替代方法，您可以使用HBase提供的基于協(xié)處理器的JMX實現(xiàn)。要在0.99或更高版本中啟用它，請在hbase-site.xml中添加以下屬性：

<property>
  <name>hbase.coprocessor.regionserver.classes</name>
  <value>org.apache.hadoop.hbase.JMXListener</value>
</property>

不要同時為Java VM 設置com.sun.management.jmxremote.port

目前它支持Master和RegionServer Java VM。默認情況下，JMX偵聽TCP端口10102，您可以使用以下屬性進一步配置端口：

<property>
  <name>regionserver.rmi.registry.port</name>
  <value>61130</value>
</property>
<property>
  <name>regionserver.rmi.connector.port</name>
  <value>61140</value>
</property>

在大多數(shù)情況下，注冊表端口可以與連接器端口共享，所以只需要配置regionserver.rmi.registry.port。但是，如果要使用SSL通信，則必須將2個端口配置為不同的值。

默認情況下，密碼認證和SSL通信被禁用。要啟用密碼驗證，您需要像下面那樣更新hbase-env.sh：

export HBASE_JMX_BASE="-Dcom.sun.management.jmxremote.authenticate=true                  \
                       -Dcom.sun.management.jmxremote.password.file=your_password_file   \
                       -Dcom.sun.management.jmxremote.access.file=your_access_file"

export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE "
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE "

請參閱$ JRE_HOME/lib/management下面的示例password/access文件。

要使用密碼驗證啟用SSL通信，請按照以下步驟操作：

#1. generate a key pair, stored in myKeyStore
keytool -genkey -alias jconsole -keystore myKeyStore

#2. export it to file jconsole.cert
keytool -export -alias jconsole -keystore myKeyStore -file jconsole.cert

#3. copy jconsole.cert to jconsole client machine, import it to jconsoleKeyStore
keytool -import -alias jconsole -keystore jconsoleKeyStore -file jconsole.cert

然后像下面這樣更新hbase-env.sh：

export HBASE_JMX_BASE="-Dcom.sun.management.jmxremote.ssl=true                         \
                       -Djavax.net.ssl.keyStore=/home/tianq/myKeyStore                 \
                       -Djavax.net.ssl.keyStorePassword=your_password_in_step_1       \
                       -Dcom.sun.management.jmxremote.authenticate=true                \
                       -Dcom.sun.management.jmxremote.password.file=your_password file \
                       -Dcom.sun.management.jmxremote.access.file=your_access_file"

export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE "
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE "

最后，使用密鑰存儲在客戶端上啟動 jconsole：

jconsole -J-Djavax.net.ssl.trustStore=/home/tianq/jconsoleKeyStore

要在主服務器上啟用HBase JMX實現(xiàn)，還需要在hbase-site.xml中添加以下屬性：

<property>
  <name>hbase.coprocessor.master.classes</name>
  <value>org.apache.hadoop.hbase.JMXListener</value>
</property>

端口配置的相應屬性為：master.rmi.registry.port（默認為10101）和master.rmi.connector.port（默認情況下與registry.port相同）。