下面我们列出一些 _ 重要 _ 的配置。我们已经将这部分分为必需的配置和值得推荐的配置。
请你参考本教程中 HBase 基础条件中的操作系统和 Hadoop 部分的内容！
如果您拥有一个包含大量区域的群集，那么在主服务器启动后，Regionserver 可能会暂时地进行检查，而所有剩余的 RegionServers 落后。要签入的第一台服务器将被分配到所有不是最优的区域。为防止出现上述情况，请将其hbase.master.wait.on.regionservers.mintostart属性从其默认值 1 中调高。详见: HBASE-6389 Modify the conditions to ensure that Master waits for sufficient number of Region Servers before starting region assignments
zookeeper.session.timeout默认的超时时间是三分钟（以毫秒为单位）。这意味着，如果服务器崩溃，则在主服务器在三分钟前发现崩溃并开始恢复。您可能需要将超时调整到一分钟甚至更短的时间，以便主服务器尽快通知故障。在更改此值之前，请确保您的 JVM 垃圾收集配置处于受控状态，否则，长时间的垃圾回收会超出 ZooKeeper 会话超时时间，将取出您的 RegionServer。（如果一个 RegionServer 长时间处于 GC 状态，你可能需要在服务器上启动恢复）。
要更改此配置，请编辑 hbase-site.xml，将更改的文件复制到群集中并重新启动。
我们将这个值设置得很高，以避免不必要的麻烦。如果出现类似“为什么我在执行一个大规模数据导入的时候 Region Server 死掉啦”这样的问题，可以解释的原因是：他们的 JVM 未被解析，并且正在运行长时间的 GC 操作。
详见 zookeeper.
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 或更大的堆 - 你可能会发现下面的配置选项很有帮助。
您应该考虑启用 ColumnFamily 压缩。有几个选项可以在大多数情况下都是通过减小 StoreFiles 的大小来提高性能，从而减少 I / O。
详见 compression
在发生 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 文件。
HBase 通常会根据您的 hbase-default.xml 和 hbase-site.xml 配置文件中的设置来处理您所在区域的分割。重要的设置包括：hbase.regionserver.region.split.policy, hbase.hregion.max.filesize, hbase.regionserver.regionSplitLimit。分割的一个简单的观点是，当一个区域发展到 hbase.hregion.max.filesize 时，它被分割。对于大多数使用模式，您应该使用自动分割。详见: manual region splitting decisions for more information about manual region splitting.
不要让 HBase 自动分割你的区域，你可以选择自己管理分割。HBase 0.90.0 增加了这个功能。如果你知道你的密钥空间，手动管理分割就行，否则让 HBase 为你分割。手动分割可以减轻在负载下的区域创建和移动。这也使得区域边界是已知的和不变的（如果你禁用区域分割）。如果使用手动分割，则可以更轻松地进行交错式的基于时间的主要压缩来分散网络 IO 负载。
禁用自动分割
要禁用自动拆分，可以在集群配置或表配置中设置区域拆分策略： org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy
自动分割建议
如果禁用自动分割来诊断问题或在数据快速增长期间，建议在您的情况变得更加稳定时重新启用它们。
确定预分割区域的最佳数目
预分割区域的最佳数量取决于您的应用程序和环境。一个好的经验法则是从每个服务器的 10 个预分割区域开始，随着时间的推移数据不断增长。尽量在区域太少的地方犯错，稍后进行滚动分割更好。区域的最佳数量取决于您所在区域中最大的 StoreFile。如果数据量增加，最大的 StoreFile 的大小将随着时间增加。目标是使最大的区域足够大，压实选择算法仅在定时的主要压实期间将其压缩。否则，该集群可能会同时出现大量压实区域的压实风暴。数据增长导致压缩风暴，而不是人工分割决策，这一点很重要。
如果区域被分割成太多的区域，可以通过配置HConstants.MAJOR_COMPACTION_PERIOD 来增加主要的压缩间隔。org.apache.hadoop.hbase.util.RegionSplitter`提供所有区域的网络 IO 安全滚动分割。
默认情况下，主要的压缩计划在 7 天内运行一次。
如果您需要精确控制主要压缩的运行时间和频率，可以禁用托管的主要压缩。请参阅 hbase.hregion.majorcompaction compaction.parameters
不禁用主要压缩
对于 StoreFile 清理来说，重要的压缩是绝对必要的。不要完全禁用它们。您可以通过 HBase shell 或Admin API手动运行主要压缩。
详见: compaction
预测执行 MapReduce 任务是默认开启的，对于 HBase 集群，通常建议关闭系统级的推测执行，除非您需要在特定情况下可以配置每个作业。将属性 mapreduce.map.speculative 和 mapreduce.reduce.speculative 设置为 false。
平衡器（Balancer）是在主服务器上运行的一个周期性操作，用于重新分配集群上的区域。它通过hbase.balancer.period配置，默认为 300000（5 分钟）。
详见: master.processes.loadbalancer
不要关闭块缓存（你可以通过设置hfile.block.cache.size为零来实现）。这样做没有好处，因为 RegionServer 将花费所有的时间一次又一次地加载 HFile 索引。如果你的工作集是这样配置块缓存，那么没有益处，最少应保证 hfile 指数保存在块缓存内的大小（你可以通过调查 RegionServer UI 粗略地了解你需要的大小；请参阅占网页顶部附近的索引块大小）
如果在对 HBase 的操作中出现大约 40ms 左右的延迟，请尝试 Nagles 的设置。 例如，请参阅用户邮件列表线程Inconsistent scan performance with caching set to 1 将缓存设置为 1 的不一致扫描性能以及其中所引用的设置notcpdelay来提高扫描速度的问题。详见文档底部图表HBASE-7008 Set scanner caching to a better default 设置了扫描缓存到一个更好的默认位置，我们的 Lars Hofhansl 会尝试使用 Nagle 打开和关闭测量效果的各种数据大小。
这部分是关于在服务器出现故障后会使服务器恢复更快的配置。详见:Introduction to HBase Mean Time to Recover (MTTR)
HBASE-8354 forces Namenode into loop with lease recovery requests 使用 lease 恢复请求循环的问题是混乱的，但在低超时以及如何引起更快的恢复，包括引用添加到 HDFS 的修复程序方面，有很多好的讨论。下面建议的配置是 Varun 的建议的提炼和测试，确保你在 HDFS 版本上运行，所以你有他所提到的修补程序，并且他自己添加到 HDFS，帮助 HBase MTTR（例如 HDFS-3703，HDFS-3712 和 HDFS-4791 -Hadoop 2 确保有他们并且后期 Hadoop 1 有一些）。在 RegionServer 中设置以下内容：
<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 端，设置以下内容来启用 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（Java Management Extensions，Java 管理扩展）提供了内置的工具，使您能够监视和管理 Java VM。要启用远程系统的监视和管理，在启动 Java VM 时，您需要设置系统属性com.sun.management.jmxremote.port（要启用 JMX RMI 连接的端口号）。详见:official documentation. 从历史上看，除了上面提到的端口之外，JMX 还会打开两个附加的随机 TCP 侦听端口，这可能会导致端口冲突问题。详见: HBASE-10289
作为一种替代方法，您可以使用 HBase 提供的基于协处理器的 JMX 实现。启用它，请在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>
在大多数情况下，注册表端口可以与连接器端口共享，所以只需要配置 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
To 要在主服务器上启用 HBase JMX 实现，还需要在 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 相同）。