# Apache HBase 配置
> 贡献者：[xixici](https://github.com/xixici)
在上一章[快速开始](#getting_started)的内容中，你学习了如何启动独立式、伪分布式以及完全分布式 HBase，在本章中，我们将介绍更多关于 Apache HBase 的配置，以进一步了解 Apache HBase。请仔细阅读本章，特别是[基本配置条件](#basic.prerequisites)部分，该部分能够确保您的 HBase 测试和部署顺利进行，并防止数据丢失。现在，一起进入学习吧！
## 3\. 配置文件
Apache HBase 使用与 Apache Hadoop 相同的配置系统。所有配置文件都位于 _conf/_ 目录中，需要保持群集中每个节点的同步。
### HBase 配置文件说明
_backup-masters_
默认情况下不存在。这是一个纯文本文件，其中列出了主服务器应在其上启动备份主进程的主机，每行一台主机。
_hadoop-metrics2-hbase.properties_
用于连接 HBase Hadoop 的 Metrics2 框架。有关 Metrics2 的更多信息，请参阅[Hadoop Wiki](https://wiki.apache.org/hadoop/HADOOP-6728-MetricsV2) 。默认情况下只包含注释出的示例。
_hbase-env.cmd_ and _hbase-env.sh_
用于 Windows 和 Linux/Unix 环境的脚本，以设置 HBase 的工作环境，包括 Java、Java 选项和其他环境变量的位置。该文件包含许多注释示例来提供指导。
_hbase-policy.xml_
RPC 服务器使用默认策略配置文件对客户端请求进行授权决策。仅在启用 HBase[安全](#security)模式下使用。
_hbase-site.xml_
主要的 HBase 配置文件。该文件指定覆盖 HBase 的默认配置的配置选项。您可以在 _docs/hbase-default.xml_ 中查看（但不要编辑）默认配置文件。您还可以在 HBase Web UI 的 HBase 配置选项卡中查看群集的整个有效配置（默认和覆盖）。
_log4j.properties_
通过`log4j`进行 HBase 日志记录的配置文件。
_regionservers_
包含应该在 HBase 集群中运行 RegionServer 的主机列表的纯文本文件。默认情况下，这个文件包含单个条目`localhost`t。它应该包含主机名或 IP 地址列表，每行一个，如果集群中的每个节点将在其`localhost`接口上运行 RegionServer 的话，则只应包含`localhost`
> 检查 XML 有效性
>
> 在编辑 XML 时，最好使用支持 XML 的编辑器，以确保您的语法正确且 XML 格式良好。您还可以使用该`xmllint` 程序检查您的 XML 格式是否正确。默认情况下，`xmllint` 重新流动并将 XML 打印到标准输出。要检查格式是否正确，并且只在存在错误时才打印输出，请使用命令`xmllint -noout filename.xml`。
> 在集群之间保持同步配置
>
> 当在分布式模式下运行时, 在对 HBase 配置进行编辑后，请确保将 conf/目录的内容复制到群集的所有节点。HBase 不会为你这么做的。请使用 `rsync`, `scp`或其他安全机制将配置文件复制到你的节点。对于大多数配置, 服务器需要重新启动才能成功更改。动态配置是这方面的一个例外，在之后的内容将对此进行说明。
## 4\. HBase 基础条件
在本节中，我们列出了使用 HBase 时所需要的服务和一些必需的系统配置。
Java
在下表中你可以看到 HBase 版本与其对应支持的 JDK 版本： 社区很乐意帮助你诊断和解决可能遇到的问题.你需要进去社区查找类似问题,可能需要你更改 java 环境.某些情况下,例如编译/测试单元有效性,具体操作问题)也要注意.
> 建议使用长期支持 JDKs
>
> HBase 建议用户依赖长期支持 (LTS)版本的 JDK,无论是 OpenJDK 项目或其他.截至 2018 年 3 月，这意味着 Java 8 是唯一适用的版本，而下一个可能的测试版本将是 2018 Q3 的 Java 11。
| HBase Version | JDK 7 | JDK 8 | JDK 9 (Non-LTS) | JDK 10 (Non-LTS) | JDK 11 |
| ------------- | ----- | ----- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 2.0+ | | | [HBASE-20264](https://issues.apache.org/jira/browse/HBASE-20264) | [HBASE-20264](https://issues.apache.org/jira/browse/HBASE-20264) | [HBASE-21110](https://issues.apache.org/jira/browse/HBASE-21110) |
| 1.2+ | | | [HBASE-20264](https://issues.apache.org/jira/browse/HBASE-20264) | [HBASE-20264](https://issues.apache.org/jira/browse/HBASE-20264) | [HBASE-21110](https://issues.apache.org/jira/browse/HBASE-21110) |
> HBase 不支持 Java 6 的构建或编译
> 你必须在集群的每个节点上设置`JAVA_HOME` 。_hbase-env.sh_ 提供了一种方便的机制。
操作系统
ssh
（必须的）HBase 广泛使用安全 Shell（ssh）命令和实用程序在集群节点之间进行通信。集群中的每台服务器都必须运行`ssh`，以便可以管理 Hadoop 和 HBase 后台进程。您必须能够使用共享密钥而不是密码，通过 SSH（包括本地节点）从主服务器和任何备份主服务器连接到所有节点。您可以在 Linux 或 Unix 系统中的"[Procedure: Configure Passwordless SSH Access](#passwordless.ssh.quickstart)"（配置无密码 SSH 访问）中看到这种设置的基本方法。如果群集节点使用 OS X，请参阅[SSH: Setting up Remote Desktop and Enabling Self-Login](https://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_%28Single-Node_Cluster%29)
DNS
HBase 使用本地主机名来自行报告其 IP 地址
NTP
群集节点上的时钟应该同步。少量的变化是可以接受的，但是大量的不同会导致不稳定和意外的行为。如果在群集中看到无法解释的问题，则时间同步是首先要检查的事项之一。建议您在群集上运行网络时间协议（NTP）服务或其他时间同步机制，并且所有节点都查找相同的服务以进行时间同步。请参阅 _The Linux Documentation Project (TLDP)_ 中的[Basic NTP Configuration](http://www.tldp.org/LDP/sag/html/basic-ntp-config.html)以设置 NTP。
文件和进程数限制
Apache HBase 是一个数据库。它需要能够一次打开大量的文件。许多 Linux 发行版限制了允许单个用户打开的文件数量`1024`（或者`256`，在旧版本的 OS X 上）。当以运行 HBase 的用户身份登录时，您可以通过在服务器上运行`ulimit -n` 命令来检查服务器上的限制。限制太低会产生一些 [故障](#trouble.rs.runtime.filehandles) 您也可能会注意到以下错误：
```
2010-04-06 03:04:37,542 INFO org.apache.hadoop.hdfs.DFSClient: Exception increateBlockOutputStream java.io.EOFException
2010-04-06 03:04:37,542 INFO org.apache.hadoop.hdfs.DFSClient: Abandoning block blk_-6935524980745310745_1391901
```
建议将 ulimit 提高到至少 10,000，但更可能是 10,240，因为该值通常以 1024 的倍数表示。每个 ColumnFamily 至少有一个 StoreFile，如果该区域处于加载状态，则可能有多于六个的 StoreFile。所需的打开文件的数量取决于 ColumnFamilies 的数量和区域的数量。以下是计算 RegionServer 上打开的文件的潜在数量的粗略公式。
计算打开文件的潜在数量：
```
(StoreFiles per ColumnFamily) x (regions per RegionServer)
```
假设一个模式的每个区域有 3 个 ColumnFamilies，每个 ColumnFamily 平均有 3 个 StoreFiles，每个 RegionServer 有 100 个区域，则 JVM 将打开`3 * 3 * 100 = 900`文件描述符，不包括打开的 JAR 文件、配置文件等等。打开一个文件不需要很多资源，而且允许用户打开太多文件的风险很小。
另一个相关设置是允许用户同时运行的进程数量。在 Linux 和 Unix 中，使用该`ulimit -u` 命令设置进程的数量。这不应与`nproc`命令混淆，该命令控制给定用户可用的 CPU 数量。在负载下，`ulimit -u`太低会导致 OutOfMemoryError 异常。
为运行 HBase 进程的用户配置文件描述符和进程的最大数量是操作系统配置，而不是 HBase 配置。确保为实际运行 HBase 的用户更改设置也很重要。要查看哪个用户启动了 HBase，以及该用户的 ulimit 配置，请查看该实例的 HBase 日志的第一行。
示例 2\. `ulimit` 在 Ubuntu 上的设置
要在 Ubuntu 上配置 _limits.conf_ 设置，请编辑：_/etc/security/limits.conf_，它是一个由四列组成的空格分隔的文件。在以下示例中，第一行将用户名为 hadoop 的操作系统用户的打开文件数（nofile）的软限制和硬限制设置为 32768。第二行将同一用户的进程数设置为 32000。
```
hadoop - nofile 32768
hadoop - nproc 32000
```
这些设置仅适用于可插入身份验证模块（PAM）环境指示使用它们的情况。要配置 PAM 以使用这些限制，请确保 _/etc/pam.d/common-session_ 文件包含以下行：
```
session required pam_limits.so
```
Linux Shell
所有 HBase 附带的 shell 脚本都依赖于[GNU Bash](http://www.gnu.org/software/bash) shell.
Windows
不建议在 Windows 计算机上运行生产系统。
### 4.1\. [Hadoop](https://hadoop.apache.org)
下表总结了每个 HBase 版本支持的 Hadoop 版本。下表总结了每个版本的 HBase 支持的 Hadoop 版本。未出现在此表中的旧版本被视为不受支持，可能缺少必要的功能，而新版本未经测试，但可能适用。
基于 HBase 的版本，您应该选择最合适的 Hadoop 版本。参考更多关于 Hadoop 环境配置的内容！ 版本无区别. 请查看 [the Hadoop wiki](https://wiki.apache.org/hadoop/Distributions%20and%20Commercial%20Support) .
> 建议使用 Hadoop 2.x
>
> Hadoop 2.x 速度更快，包括短路读取功能( [Leveraging local data](#perf.hdfs.configs.localread))，这将有助于提高您的 HBase 随机读取配置文件；Hadoop 2.x 还包括重要的 bug 修复，可以改善您的整体 HBase 体验；HBase 不支持使用早期版本的 Hadoop 运行；有关特定于不同 HBase 版本的要求，请参见下表
>
> Hadoop 3.x 仍处于早期访问版本中，尚未被 HBase 社区对生产用例进行充分测试。
使用以下的注解来解释下面的这个表格：
Hadoop 版本支持
* T = 支持
* F = 不支持
* N = 未测试
| | HBase-1.2.x, HBase-1.3.x | HBase-1.4.x | HBase-2.0.x | HBase-2.1.x |
| ------------- | ------------------------ | ----------- | ----------- | ----------- |
| Hadoop-2.4.x | T | F | F | F |
| Hadoop-2.5.x | T | F | F | F |
| Hadoop-2.6.0 | F | F | F | F |
| Hadoop-2.6.1+ | T | F | T | F |
| Hadoop-2.7.0 | F | F | F | F |
| Hadoop-2.7.1+ | T | T| T |T
| Hadoop-2.8.[0-1] |F |F | F | F |
| Hadoop-2.8.2 | N | N| N | N|
| Hadoop-2.8.3+ | N | N | T | T |
| Hadoop-2.9.0 | F | F | F | F |
| Hadoop-2.9.1+ | N |N | N |N |
| Hadoop-3.0.[0-2] |F | F | F | F |
| Hadoop-3.0.3+ | F | F | T | T |
| Hadoop-3.1.0 | F | F | F | F |
| Hadoop-3.1.1+ | F | F | T | T |
> Hadoop Pre-2.6.1 和 JDK 1.8 Kerbero
>
> 在 Kerberos 环境中使用 pre-2.6.1 Hadoop 版本和 JDK 1.8 时，HBase 服务器可能因 Kerberos keytab relogin 错误而失败并中止。JDK 1.7 (1.7. 0_80) 的后期版本也有问题[HADOOP-10786](https://issues.apache.org/jira/browse/HADOOP-10786)。在这种情况下考虑升级到 Hadoop 2.6.1+。
> Hadoop 2.6.
>
> 如果您计划在 HDFS 加密区域的顶部运行 HBase，则基于 2.6.x 行的 Hadoop 发行版**必须**具有 [HADOOP-11710](https://issues.apache.org/jira/browse/HADOOP-11710) 应用。如果不这样做，将导致群集故障和数据丢失。此修补程序存在于 Apache Hadoop 2.6.1+版本中。
> Hadoop 2.y.0
>
> Hadoop 2.7.0 开始两个版本未经测试或不受支持，因为 Hadoop PMC 明确将该版本标记为不稳定.因此，HBase 明确建议用户避免在这些版本之上运行。另外，Hadoop PMC 也给出了同样的警告。有关参考，请参见 [Apache Hadoop 2.7.0](https://s.apache.org/hadoop-2.7.0-announcement), [Apache Hadoop 2.8.0](https://s.apache.org/hadoop-2.8.0-announcement), [Apache Hadoop 2.8.1](https://s.apache.org/hadoop-2.8.1-announcement), and [Apache Hadoop 2.9.0](https://s.apache.org/hadoop-2.9.0-announcement).
> Hadoop 3.0.x
>
> 包含应用程序时间服务特性的 Hadoop 集群可能会导致出现意外的 HBase 类版本.用户要确保[YARN-7190](https://issues.apache.org/jira/browse/YARN-7190) 存在于 yarn 服务中 (目前已修复 2.9.1+ , 3.1.0+).
> Hadoop 3.1.0
>
> Hadoop PMC 声称 3.1.0 不稳定且不能用于生产.因此,HBase 建议用户避免使用本版本.详情: [release announcement for Hadoop 3.1.0](https://s.apache.org/hadoop-3.1.0-announcement).
> 更换 Hadoop
>
> 因为 hbase 依赖于 hadoop，并且 hadoop jar 存在 _lib_ 目录下。这些的 jar 仅在独立模式下使用。在分布式模式下，集群上的 Hadoop 版本与 HBase 下的版本匹配是 _ 至关重要 _ 的。将 hbase lib 目录中的 hadoop jar 替换为集群上运行的版本中的 hadoop jar，以避免版本不匹配问题。确保在整个集群中替换 hbase 下的 jar。Hadoop 版本不匹配问题有多种表现形式。如果 HBase 出现挂起，请检查是否不匹配。
#### 4.1.1\. `dfs.datanode.max.transfer.threads`
HDFS DataNode 在任何时候都会有一个文件数上限。在进行任何加载之前，请确保您已经配置了 Hadoop 的 _conf/hdfs-site.xml_，并将该`dfs.datanode.max.transfer.threads`值设置为至少如下的值：
```
<property>
<name>dfs.datanode.max.transfer.threads</name>
<value>4096</value>
</property>
```
进行上述配置后，务必重新启动 HDFS。
没有这个配置就会造成奇怪的故障。其中一种表现是缺失区块。例如：
```
10/12/08 20:10:31 INFO hdfs.DFSClient: Could not obtain block
blk_XXXXXXXXXXXXXXXXXXXXXX_YYYYYYYY from any node: java.io.IOException: No live nodes
contain current block. Will get new block locations from namenode and retry...
```
查看 [casestudies.max.transfer.threads](#casestudies.max.transfer.threads) 并注意 `dfs.datanode.max.xcievers` (e.g. [Hadoop HDFS: Deceived by Xciever](http://ccgtech.blogspot.com/2010/02/hadoop-hdfs-deceived-by-xciever.html)).
### 4.2\. ZooKeeper 要求
ZooKeeper 3.4.x 必需.
## 5\. HBase 运行模式：独立式和分布式
HBase 有两种运行模式：独立式和分布式。HBase 以独立模式运行。无论您的模式如何，您都需要通过编辑 HBase _conf_ 目录中的文件来配置 HBase 。至少，您必须编辑 conf/hbase-env.sh 来告诉 HBase 要使用哪个 java。在这个文件中，你设置了 HBase 环境变量，比如`JVM`的 heapsize 和其他选项，日志文件的首选位置等等。设置 JAVA_HOME 以指向你的 java 安装的根目录。
### 5.1\. Standalone HBase
默认情况下使用的是独立式的 HBase。在[快速开始](#quickstart)一节中，我们已经介绍过独立模式。在独立模式下，HBase 不使用 HDFS，而是使用本地文件系统，是在同一个 JVM 中运行所有 HBase 守护进程和本地 ZooKeeper。ZooKeeper 绑定到一个众所周知的端口，通过该端口，客户端可以和 HBase 进行通信。
#### 5.1.1\. Standalone HBase over HDFS
有时在独立的 hbase 上有一个有用的变体，它的所有的守护进程都在一个 JVM 中运行，而不是坚持到本地文件系统，而是坚持到一个 HDFS 实例。
当您打算使用简单的部署配置文件时，您可能会考虑使用此配置文件，加载很轻松，但是数据必须在节点的出入之间持续存在。向 HDFS 写入数据的地方可以确保后者。
要配置此独立变体，请编 _hbase-site.xml_，设置 _hbase.rootdir_ 以指向 HDFS 实例中的某个目录，然后将 _hbase.cluster.distributed_ 设置为 _false_。例如：
```
<configuration>
<property>
<name>hbase.rootdir</name>
<value>hdfs://namenode.example.org:8020/hbase</value>
</property>
<property>
<name>hbase.cluster.distributed</name>
<value>false</value>
</property>
</configuration>
```
### 5.2\. 分布式
分布式模式可以细分为 _ 分布式 _、_ 伪分布式 _（所有守护进程都在单个节点上运行）、_ 完全分布式 _（守护进程分布在集群中的所有节点上）。其中，伪分布式模式与完全分布式的命名来自于 Hadoop。
伪分布式模式可以针对本地文件系统运行，也可以针对 _Hadoop 分布式文件系统（HDFS）_ 的实例运行。完全分布式模式只能在 HDFS 上运行。有关如何设置 HDFS，请参阅 [http://www.alexjf.net/blog/distributed-systems/hadoop-yarn-installation-definitive-guide](http://www.alexjf.net/blog/distributed-systems/hadoop-yarn-installation-definitive-guide).
#### 5.2.1\. 伪分布式
> 伪分布式快速开始
>
> [快速开始](#quickstart) 章节包含相关信息.
伪分布式模式的 HBase 就是在单个主机上运行的完全分布式模式。使用此 HBase 配置仅进行测试和原型设计。请勿将此配置用于生产或性能评估。
### 5.3\. 完全分布式
默认情况下，HBase 以独立模式运行，独立模式和伪分布模式用于小规模测试。对于生产环境，建议使用分布式模式。在分布式模式下，HBase 守护进程的多个实例在集群中的多个服务器上运行。
就像在伪分布式模式中一样，完全分布式的配置要求您将`hbase.cluster.distributed` 属性设置为 `true`。通常情况下，`hbase.rootdir`被配置为指向高可用性的 HDFS。
此外，集群还配置了以多个群集节点成为 RegionServer、ZooKeeper QuorumPeers 和备份 HMaster 服务器。详见: [quickstart-fully-distributed](#quickstart_fully_distributed).
分布式 RegionServers
通常，你的群集将包含多个运行在不同服务器上的 RegionServer，以及主要和备份 Master 和 ZooKeeper 守护程序。主服务器上的 c_conf/regionservers_ 中包含一个主机列表，其 RegionServers 与该集群相关。每个主机都在一个单独的行上。当主服务器启动或停止时，此文件中列出的所有主机将启动和停止其 RegionServer 进程。
ZooKeeper and HBase
有关 HBase 的 ZooKeeper 设置说明，请参见 [ZooKeeper](#zookeeper)部分。
示例 3\. 分布式 HBase 集群示例
是一个分布式 HBase 集群的简单的 _conf/hbase-site.xml_ 。用于实际工作的群集将包含更多自定义配置参数。大多数 HBase 配置指令都具有默认值，除非在 _conf/hbase-site.xml_ 中覆盖该值，否则将使用这些默认值。有关更多信息，请参阅“配置文件”
```
<configuration>
<property>
<name>hbase.rootdir</name>
<value>hdfs://namenode.example.org:8020/hbase</value>
</property>
<property>
<name>hbase.cluster.distributed</name>
<value>true</value>
</property>
<property>
<name>hbase.zookeeper.quorum</name>
<value>node-a.example.com,node-b.example.com,node-c.example.com</value>
</property>
</configuration>
```
这是 _conf/regionservers_ 文件的示例，其中包含应在集群中运行 RegionServer 的节点的列表。这些节点需要安装 HBase，他们需要使用与主服务器相同的 _conf/_ 目录内容：
```
node-a.example.com
node-b.example.com
node-c.example.com
```
这是 _conf/backup-masters_ 文件的示例，其中包含应运行备份主实例的每个节点的列表。除非主主站变为不可用，否则备份主站实例将处于空闲状态。
```
node-b.example.com
node-c.example.com
```
分布式 HBase 快速入门
请参阅[quickstart-fully-distributed](#quickstart_fully_distributed)，了解包含多个 ZooKeeper、备份 HMaster 和 RegionServer 实例的简单三节点群集配置。
过程: HDFS 客户端配置
1. 值得注意的是，如果您在 Hadoop 集群上进行了 HDFS 客户端配置更改（例如，HDFS 客户端的配置指令），而不是服务器端配置，则必须使用以下方法之一来启用 HBase 以查看和使用这些配置更改：
1. 在 _hbase-env.sh_ 中添加一个指向你`HADOOP_CONF_DIR`的`HBASE_CLASSPATH`环境变量
2. 在 _${HBASE_HOME}/conf_ 下添加一个 _hdfs-site.xml_（或 _hadoop-site.xml_）或更好的符号链接
3. 只有一小部分 HDFS 客户端配置，请将它们添加到 _hbase-site.xml_
这种 HDFS 客户端配置的一个例子是`dfs.replication`。例如，如果希望以 5 的复制因子运行，则 HBase 将创建缺省值为 3 的文件，除非您执行上述操作以使配置可用于 HBase。
## 6\. 开始运行
保证 HDFS 第一次运行，你需要通过在 HADOOP_HOME 目录中运行 _bin/start-hdfs.sh_ 来启动和停止 Hadoop HDFS 守护进程。你确保它正确启动的方法是通过在 Hadoop 文件系统中测试文件的 put 和 get。HBase 通常不使用 MapReduce 或 YARN 守护进程，因此它们不需要启动。
如果您正在管理您自己的 ZooKeeper，请启动它并确认它正在运行，否则 HBase 将启动 ZooKeeper 作为其启动过程的一部分。
你可以从`HBASE_HOME`目录使用以下命令来启动 HBase：
```
bin/start-hbase.sh
```
您现在应该有一个正在运行的 HBase 实例。HBase 日志可以在 _log_ 子目录中找到。检查出来，特别是如果 HBase 启动困难。
HBase 也提供了一个 UI 列出了重要的属性。默认情况下，它被部署在 16010 端口的主控主机上（默认情况下 HBase RegionServers 侦听端口 16020，并在端口 16030 建立一个信息 HTTP 服务器）。如果主服务器（Master ）在默认端口上指定`master.example.org` 主机上运行，请将浏览器指向 http://master.example.org:16010 以查看 Web 界面。
一旦 HBase 启动，请参阅下面的 shell 部分，了解创建表，添加数据，扫描插入内容以及最终禁用和删除表的一些操作命令。
退出 HBase shell 后停止 HBase 进入：
```
$ ./bin/stop-hbase.sh
stopping hbase...............
```
关机可能需要稍等一些时间才能完成。如果您的集群由多台计算机组成，则可能需要更长的时间。如果您正在运行分布式操作，那么在停止 Hadoop 守护进程之前，一定要等到 HBase 完全关闭。
## 7\. 默认配置
### 7.1\. _hbase-site.xml_ 和 _hbase-default.xml_
在 Hadoop 中将特定于站点的 HDFS 配置添加到 _hdfs-site.xml_ 文件，那么对于 HBase，特定于站点的配置文件为 _conf/hbase-site.xml_。有关可配置属性的列表，请参见下面的 HBase 默认配置或查看 _src/main/resources_ 的 HBase 源代码中的原始 _hbase-default.xml_ 源文件。
并不是所有的配置选项都会将其发送到 _hbase-default.xml_。一些配置只会出现在源代码中；因此识别这些更改的唯一方法是通过代码审查。
目前，这里的更改将需要为 HBase 重启集群生效。
### 7.2\. HBase 默认配置
以下文档是使用默认的 HBase 配置文件 _hbase-default.xml_ 作为源生成的
`hbase.tmp.dir`
这是本地文件系统上的临时目录。将此设置更改为指向比“/tmp”更持久的位置，这是 java.io.tmpdir 的常见解决方案，因为在重新启动计算机时清除了“/tmp”目录。
默认: `${java.io.tmpdir}/hbase-${user.name}`
`hbase.rootdir`
这个目录是 region servers 共享的目录，HBase 保持不变。该 URL 应该是“完全限定的”以包括文件系统的 scheme。例如，要指定 HDFS 实例的"/hbase"目录，namenode 运行在 namenode.example.org 的 9000 端口，请将此值设置为：hdfs：//namenode.example.org：9000 / hbase。默认情况下，我们会写$ {hbase.tmp.dir}，通常是/tmp - 所以改变这个配置，否则所有的数据在计算机重启时都会丢失。
默认: `${hbase.tmp.dir}/hbase`
`hbase.cluster.distributed`
群集所处的模式。对于独立模式，可能的值为 false，对于分布式模式，可能的值为 true。如果为 false，启动将在一个 JVM 中一起运行所有 HBase 和 ZooKeeper 守护程序。
默认: `false`
`hbase.zookeeper.quorum`
使用逗号分隔的 ZooKeeper 集合中的服务器列表（这个配置应该被命名为 hbase.zookeeper.ensemble）。例如，“host1.mydomain.com，host2.mydomain.com，host3.mydomain.com”。默认情况下，对于本地和伪分布式操作模式，将其设置为 localhost。对于完全分布式安装，应将其设置为 ZooKeeper 集成服务器的完整列表。如果在 hbase-env.sh 中设置 HBASE_MANAGES_ZK，这是 hbase 将作为群集启动/停止的一部分来启动/停止 ZooKeeper 的服务器列表。客户端，我们将把这个集合成员的列表，并把它与 hbase.zookeeper.property.clientPort 配置放在一起。并将其作为 connectString 参数传递给 zookeeper 构造函数。
默认: `localhost`
`zookeeper.recovery.retry.maxsleeptime`
在重试 zookeeper 操作之前的最大睡眠时间（以毫秒为单位），这里需要最大时间，以便睡眠时间不会无限增长。
默认: `60000`
`hbase.local.dir`
将本地文件系统上的目录用作本地存储。
默认:`${hbase.tmp.dir}/local/`
`hbase.master.port`
HBase Master 应该绑定的端口。
默认: `16000`
`hbase.master.info.port`
HBase Master Web UI 的端口。如果您不想运行 UI 实例，请将其设置为-1。
默认: `16010`
`hbase.master.info.bindAddress`
HBase Master Web UI 的绑定地址
默认: `0.0.0.0`
`hbase.master.logcleaner.plugins`
由 LogsCleaner 服务调用的 BaseLogCleanerDelegate 的逗号分隔列表。这些 WAL 清理是按顺序调用的。要实现您自己的 BaseLogCleanerDelegate，只需将其放入 HBase 的类路径中，并在此添加完全限定的类名。始终在列表中添加上面的默认日志清理工具。
默认: `org.apache.hadoop.hbase.master.cleaner.TimeToLiveLogCleaner,org.apache.hadoop.hbase.master.cleaner.TimeToLiveProcedureWALCleaner`
`hbase.master.logcleaner.ttl`
WAL 在归档（{hbase.rootdir} / oldWALs）目录中保留多久，之后将由主线程清除。该值以毫秒为单位。
默认: `600000`
`hbase.master.procedurewalcleaner.ttl`
过程 WAL 将在归档目录中保留多久，之后将由主线程清除。该值以毫秒为单位。
默认: `604800000`
`hbase.master.hfilecleaner.plugins`
由 HFileCleaner 服务调用的 BaseHFileCleanerDelegate 的逗号分隔列表。这些 HFile 清理器按顺序调用。要实现您自己的 BaseHFileCleanerDelegate，只需将其放入 HBase 的类路径中，并在此添加完全限定的类名。总是在列表中添加上面的默认日志清除程序，因为它们将被覆盖在 hbase-site.xml 中。
默认: `org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner`
`hbase.master.infoserver.redirect`
Master 是否监听 Master Web UI 端口（hbase.master.info.port）并将请求重定向到由 Master 和 RegionServer 共享的 Web UI 服务器。配置，当主服务区域（而不是默认）时是有意义的。
默认: `true`
`hbase.master.fileSplitTimeout`
分割一个区域，在放弃尝试之前等待文件分割步骤需要多长时间。默认值：600000。这个设置在 hbase-1.x 中被称为 hbase.regionserver.fileSplitTimeout。Split 现在运行主端，因此重命名（如果找到'hbase.master.fileSplitTimeout'设置，将使用它来填充当前'hbase.master.fileSplitTimeout'配置。
默认: `600000`
`hbase.regionserver.port`
HBase RegionServer 绑定的端口。
默认: `16020`
`hbase.regionserver.info.port`
HBase RegionServer Web UI 的端口如果您不希望 RegionServer UI 运行，请将其设置为-1。
默认: `16030`
`hbase.regionserver.info.bindAddress`
HBase RegionServer Web UI 的地址
默认: `0.0.0.0`
`hbase.regionserver.info.port.auto`
Master 或 RegionServer UI 是否应搜索要绑定的端口。如果 hbase.regionserver.info.port 已被使用，则启用自动端口搜索。用于测试，默认关闭。
默认: `false`
`hbase.regionserver.handler.count`
在 RegionServers 上启动 RPC Listener 实例的计数。Master 使用相同的属性来处理主处理程序的数量。太多的处理者可能会适得其反。使其成为 CPU 数量的倍数。如果主要是只读的，处理程序计数接近 CPU 计数做得很好。从 CPU 数量的两倍开始，并从那里调整。
默认: `30`
`hbase.ipc.server.callqueue.handler.factor`
确定呼叫队列数量的因素。值为 0 表示在所有处理程序之间共享单个队列。值为 1 意味着每个处理程序都有自己的队列。
默认: `0.1`
`hbase.ipc.server.callqueue.read.ratio`
将调用队列分成读写队列。指定的时间间隔（应该在 0.0 到 1.0 之间）将乘以调用队列的数量。值为 0 表示不分割调用队列，这意味着读取和写入请求将被推送到相同的一组队列中。低于 0.5 的值意味着将比写入队列更少的读取队列。值为 0.5 意味着将有相同数量的读写队列。大于 0.5 的值意味着将有更多的读队列而不是写入队列。值为 1.0 意味着除了一个之外的所有队列都用于发送读取请求。示例：假设调用队列的总数为 10，则 read.ratio 为 0 意味着：10 个队列将同时包含读/写请求。0.3 的读取比例意味着：3 个队列将只包含读取请求，7 个队列将只包含写入请求。0.5 的 read.ratio 表示：5 个队列将只包含读取请求，5 个队列将只包含写入请求。0.8 的 read.ratio 意味着：8 个队列将只包含读取请求，2 个队列将只包含写入请求。1 的 read.ratio 表示：9 个队列将只包含读取请求，1 个队列将只包含写入请求。
默认: `0`
`hbase.ipc.server.callqueue.scan.ratio`
考虑到读取的调用队列的数量（根据调用队列的总数乘以 callqueue.read.ratio 计算），scan.ratio 属性将把读取的调用队列拆分为小读取和长读取队列。低于 0.5 的值意味着长读队列比短读队列少。值为 0.5 意味着将有相同数量的短读取和长读取队列。大于 0.5 的值意味着将会有比长读取队列更多的长读取队列。值 0 或 1 表示使用同一组队列进行获取和扫描。示例：给定读取调用队列的总数为 8，scan.ratio 为 0 或 1 意味着：8 个队列将包含长读请求和短读请求。0.3 的 scan.ratio 表示：2 个队列只包含长读请求，6 个队列只包含短读请求。0.5 的 scan.ratio 表示：4 个队列只包含长读请求，4 个队列只包含短读请求。0.8 的 scan.ratio 意味着：6 个队列只包含长读请求，2 个队列只包含短读请求。
默认: `0`
`hbase.regionserver.msginterval`
从 RegionServer 到 Master 的消息间隔（以毫秒为单位）。
默认: `3000`
`hbase.regionserver.logroll.period`
无论有多少次编辑，我们将滚动提交日志的时间段。
默认: `3600000`
`hbase.regionserver.logroll.errors.tolerated`
在触发服务器中止之前，我们将允许连续的 WAL 关闭错误的数量。如果在日志滚动过程中关闭当前 WAL 书写器失败，则设置为 0 将导致区域服务器中止。即使是一个很小的值（2 或 3）也会让区域服务器承担瞬间的 HDFS 错误。
默认: `2`
`hbase.regionserver.hlog.reader.impl`
WAL 文件读取器的实现。
默认: `org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader`
`hbase.regionserver.hlog.writer.impl`
WAL 文件编写器的实现。
默认: `org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter`
`hbase.regionserver.global.memstore.size`
在新更新被阻止并刷新之前，区域服务器中所有存储区的最大大小。默认为堆的 40％（0.4）。更新被阻止，强制刷新直到区域服务器中的所有内存大小都达到 hbase.regionserver.global.memstore.size.lower.limit。此配置中的默认值已被故意留空，以便兑现旧的 hbase.regionserver.global.memstore.upperLimit 属性（如果存在）。
默认: none
`hbase.regionserver.global.memstore.size.lower.limit`
强制刷新之前，区域服务器中所有存储区的最大大小。默认为 hbase.regionserver.global.memstore.size（0.95）的 95％。当由于内存限制而导致更新被阻塞时，此值的 100％会导致最小可能的刷新。此配置中的默认值已被故意留空，以便兑现旧的 hbase.regionserver.global.memstore.lowerLimit 属性（如果存在）。
默认: none
`hbase.systemtables.compacting.memstore.type`
确定用于系统表（如 META，名称空间表等）的 memstore 的类型。默认情况下，NONE 是类型，因此我们对所有系统表使用默认的 memstore。如果我们需要为系统表使用压缩存储器，那么将这个属性设置为：BASIC / EAGER
默认: `NONE`
`hbase.regionserver.optionalcacheflushinterval`
在自动刷新之前，编辑在内存中的最长时间。默认为 1 小时。将其设置为 0 将禁用自动刷新。
默认: `3600000`
`hbase.regionserver.dns.interface`
区域服务器应从中报告其 IP 地址的网络接口的名称。
默认: `default`
`hbase.regionserver.dns.nameserver`
域名服务器应使用的名称服务器（DNS）的主机名或 IP 地址，以确定主机用于通信和显示的主机名。
默认: `default`
`hbase.regionserver.region.split.policy`
分割策略决定了一个区域应该何时拆分。当前可用的各种其他拆分策略是：BusyRegionSplitPolicy，ConstantSizeRegionSplitPolicy，DisabledRegionSplitPolicy，DelimitedKeyPrefixRegionSplitPolicy，KeyPrefixRegionSplitPolicy 和 SteppingSplitPolicy。DisabledRegionSplitPolicy 会阻止手动区域分割。
默认: `org.apache.hadoop.hbase.regionserver.SteppingSplitPolicy`
`hbase.regionserver.regionSplitLimit`
限制区域数量，之后不再发生区域分割。这并不是硬性限制区域数量，而是作为区域服务商在一定限度之后停止分裂的指导方针。默认设置为 1000。
默认: `1000`
`zookeeper.session.timeout`
ZooKeeper 会话超时（以毫秒为单位）。它使用两种不同的方式。首先，这个值用于 HBase 用来连接到集合的 ZK 客户端。当它启动一个 ZK 服务器时它也被 HBase 使用，并且它被作为'maxSessionTimeout'传递。请参[http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions](http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions)。例如，如果 HBase 区域服务器连接到也由 HBase 管理的 ZK 集合，那么会话超时将是由此配置指定的。但是，连接到以不同配置管理的集成的区域服务器将受到该集合的 maxSessionTimeout 的限制。所以，尽管 HBase 可能会建议使用 90 秒，但是整体的最大超时时间可能会低于此值，并且会优先考虑。ZK 目前的默认值是 40 秒，比 HBase 的低。
默认: `90000`
`zookeeper.znode.parent`
ZooKeeper 中用于 HBase 的 Root ZNode。所有配置了相对路径的 HBase 的 ZooKeeper 文件都会在这个节点下。默认情况下，所有的 HBase 的 ZooKeeper 文件路径都被配置为一个相对路径，所以它们将全部进入这个目录下，除非被改变。
默认: `/hbase`
`zookeeper.znode.acl.parent`
Root ZNode 用于访问控制列表。
默认: `acl`
`hbase.zookeeper.dns.interface`
ZooKeeper 服务器应从中报告其 IP 地址的网络接口的名称。
默认: `default`
`hbase.zookeeper.dns.nameserver`
名称服务器（DNS）的主机名或 IP 地址，ZooKeeper 服务器应使用该名称服务器来确定主机用于通信和显示的主机名。
默认: `default`
`hbase.zookeeper.peerport`
ZooKeeper 同伴使用的端口进行彼此会话。有关更多信息，请参阅 [http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper](http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper)
默认: `2888`
`hbase.zookeeper.leaderport`
ZooKeeper 用于 leader 选举的端口。有关更多信息，请参阅 [http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper](http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper)
默认: `3888`
`hbase.zookeeper.property.initLimit`
来自 ZooKeeper 的配置 zoo.cfg 的属性。初始同步阶段可以采用的时钟（ticks）周期数。
默认: `10`
`hbase.zookeeper.property.syncLimit`
来自 ZooKeeper 的配置 zoo.cfg 的属性。发送请求和获取确认之间可以传递的时钟（ticks）数量。
默认: `5`
`hbase.zookeeper.property.dataDir`
来自 ZooKeeper 的配置 zoo.cfg 的属性。快照存储的目录。
默认: `${hbase.tmp.dir}/zookeeper`
`hbase.zookeeper.property.clientPort`
来自 ZooKeeper 的配置 zoo.cfg 的属性。客户端将连接的端口。
默认: `2181`
`hbase.zookeeper.property.maxClientCnxns`
来自 ZooKeeper 的配置 zoo.cfg 的属性。限制由 IP 地址标识的单个客户端的并发连接数量（在套接字级别）可能会对 ZooKeeper 集合的单个成员产生影响。设置为高，以避免独立运行和伪分布式运行的 zk 连接问题。
默认: `300`
`hbase.client.write.buffer`
BufferedMutator 写入缓冲区的默认大小（以字节为单位）。一个更大的缓冲区需要更多的内存 - 在客户端和服务器端，因为服务器实例化传递的写入缓冲区来处理它 - 但更大的缓冲区大小减少了 RPC 的数量。对于估计使用的服务器端内存，计算：hbase.client.write.buffer * hbase.regionserver.handler.count
默认: `2097152`
`hbase.client.pause`
一般客户端 pause 值。在运行失败的 get，region lookup 等的重试之前，主要用作等待的值。
hbase.client.retries.number 有关如何取消此初始暂停量以及此重试数量说明。
默认: `100`
`hbase.client.pause.cqtbe`
是否为 CallQueueTooBigException（cqtbe）使用特殊的客户端 pause。如果您观察到来自同一个 RegionServer 的频繁的 CQTBE，并且其中的调用队列保持充满，则将此属性设置为比 hbase.client.pause 更高的值
默认: none
`hbase.client.retries.number`
最大重试次数。用作所有可重试操作（如获取单元格值，启动行更新等）的最大值。重试间隔是基于 hbase.client.pause 的粗略函数。首先，我们在这段时间重试，但后来退后，我们很快就达到每十秒钟重试一次。请参阅 HConstants＃RETRY_BACKOFF 了解备份如何提升。改变这个设置和 hbase.client.pause 来适应你的工作负载。
默认: `15`
`hbase.client.max.total.tasks`
单个 HTable 实例发送到集群的最大并发突变任务数。
默认: `100`
`hbase.client.max.perserver.tasks`
单个 HTable 实例将发送到单个区域服务器的并发突变任务的最大数量。
默认: `2`
`hbase.client.max.perregion.tasks`
客户端将维护到单个 Region 的最大并发突变任务数。也就是说，如果已经有 hbase.client.max.perregion.tasks 写入这个区域，那么新的放入将不会被发送到这个区域，直到一些写入完成。
默认: `1`
`hbase.client.perserver.requests.threshold`
所有客户端线程（进程级别）中一个服务器的并发未决请求的最大数量。超过请求将立即抛出 ServerTooBusyException，以防止用户的线程被占用和只被一个缓慢的区域服务器阻止。如果使用固定数量的线程以同步方式访问 HBase，请将此值设置为与线程数量相关的适当值，这些值将对您有所帮助。详见:[https://issues.apache.org/jira/browse/HBASE-16388](https://issues.apache.org/jira/browse/HBASE-16388)
默认: `2147483647`
`hbase.client.scanner.caching`
如果从本地，客户端内存中未提供，则在扫描程序上调用 next 时尝试获取的行数。此配置与 hbase.client.scanner.max.result.size 一起使用，可以有效地使用网络。缺省值默认为 Integer.MAX_VALUE，这样网络将填充由 hbase.client.scanner.max.result.size 定义的块大小，而不受特定行数的限制，因为行的大小随表格的不同而不同。如果您事先知道扫描中不需要超过一定数量的行，则应通过扫描＃setCaching 将此配置设置为该行限制。缓存值越高，扫描器的速度越快，但是会占用更多的内存，而当缓存空置时，下一次调用的时间可能会越来越长。请勿设置此值，以便调用之间的时间大于扫描器超时；即 hbase.client.scanner.timeout.period
默认: `2147483647`
`hbase.client.keyvalue.maxsize`
指定 KeyValue 实例的组合的最大允许大小。这是为保存在存储文件中的单个条目设置上限。由于它们不能被分割，所以有助于避免因为数据太大而导致地区不能被分割。将此设置为最大区域大小的一小部分似乎是明智的。将其设置为零或更少将禁用检查。
默认: `10485760`
`hbase.server.keyvalue.maxsize`
单个单元格的最大允许大小，包括值和所有关键组件。值为 0 或更小将禁用检查。默认值是 10MB。这是保护服务器免受 OOM 情况的安全设置。
默认: `10485760`
`hbase.client.scanner.timeout.period`
客户端扫描程序的租期以毫秒为单位。
默认: `60000`
`hbase.client.localityCheck.threadPoolSize`
默认: `2`
`hbase.bulkload.retries.number`
最大重试次数，这是在面对分裂操作时尝试原子批量加载的最大迭代次数，0 意味着永不放弃。
默认: `10`
`hbase.master.balancer.maxRitPercent`
平衡时转换区域的最大百分比。默认值是 1.0。所以没有平衡器节流。如果将此配置设置为 0.01，则意味着在平衡时转换中最多有 1％的区域。那么当平衡时，集群的可用性至少为 99％。
默认: `1.0`
`hbase.balancer.period`
区域平衡器在主站运行的时间段。
默认: `300000`
`hbase.normalizer.period`
区域标准化程序在主程序中运行的时段。
默认: `300000`
`hbase.normalizer.min.region.count`
区域标准化程序最小数量
默认: `3`
`hbase.regions.slop`
如果任何区域服务器具有平均值+（平均*斜率）区域，则重新平衡。StochasticLoadBalancer（默认负载均衡器）中此参数的默认值为 0.001，其他负载均衡器（即 SimpleLoadBalancer）中的默认值为 0.2。
默认: `0.001`
`hbase.server.thread.wakefrequency`
在两次搜索之间休息的时间（以毫秒为单位）。用作日志滚筒等服务线程的睡眠间隔。
默认: `10000`
`hbase.server.versionfile.writeattempts`
在放弃之前重试尝试写入版本文件的次数。每个尝试都由 hbase.server.thread.wake 频率毫秒分隔。
默认: `3`
`hbase.hregion.memstore.flush.size`
如果 memstore 的大小超过此字节数，Memstore 将被刷新到磁盘。值由每个 hbase.server.thread.wakefrequency 运行的线程检查。
默认: `134217728`
`hbase.hregion.percolumnfamilyflush.size.lower.bound.min`
如果使用了 FlushLargeStoresPolicy，并且有多个列族，那么每当我们达到完全的 memstore 限制时，我们就会找出所有 memstore 超过“下限”的列族，只有在保留其他内存的同时刷新它们。默认情况下，“下限”将是“hbase.hregion.memstore.flush.size/column_family_number”，除非该属性的值大于该值。如果没有一个族的 memstore 大小超过下限，所有的 memstore 都将被刷新（就像往常一样）。
默认: `16777216`
`hbase.hregion.preclose.flush.size`
如果我们关闭时某个区域的存储空间大于或等于这个大小，则可以运行“预先刷新（pre-flush）”来清除存储区，然后再放置区域关闭标记并使区域脱机。关闭时，在关闭标志下运行刷新以清空内存。在此期间，该地区处于离线状态，我们没有进行任何写入。如果 memstore 内容很大，则此刷新可能需要很长时间才能完成。这个预刷新是为了清理大部分的 memstore，然后把关闭标志放到离线区域，这样在关闭标志下运行的刷新没有什么用处。
默认: `5242880`
`hbase.hregion.memstore.block.multiplier`
如果 memstore 具有 hbase.hregion.memstore.block.multiplier 乘以 hbase.hregion.memstore.flush.size 个字节，则阻止更新。在更新通信高峰期间有用的防止失控的 memstore。如果没有上限，memstore 就会填满，当刷新生成的 flush 文件需要很长时间才能压缩或拆分。
默认: `4`
`hbase.hregion.memstore.mslab.enabled`
启用 MemStore-Local 分配缓冲区，该功能可用于在繁重的写入负载下防止堆碎片。这可以减少在大堆停止全局 GC pause 的频率。
默认: `true`
`hbase.hregion.max.filesize`
最大 HFile 大小。如果一个地区的 HFiles 的总和已经超过了这个数值，这个地区就会被分成两部分。
默认: `10737418240`
`hbase.hregion.majorcompaction`
主要压缩之间的时间，以毫秒表示。设置为 0 可禁用基于时间的自动重要压缩。用户请求的和基于大小的主要压缩将仍然运行。这个值乘以 hbase.hregion.majorcompaction.jitter，使压缩在一个给定的时间窗口内稍微随机的时间开始。默认值是 7 天，以毫秒表示。如果主要压缩导致您的环境中断，则可以将它们配置为在部署的非高峰时间运行，或者通过将此参数设置为 0 来禁用基于时间的主要压缩，并在 cron 作业或另一个外部机制。
默认: `604800000`
`hbase.hregion.majorcompaction.jitter`
应用于 hbase.hregion.majorcompaction 的乘数会导致压缩发生在给定的时间量的任何一侧的 hbase.hregion.majorcompaction。数字越小，压缩将越接近 hbase.hregion.majorcompaction 时间间隔。
默认: `0.50`
`hbase.hstore.compactionThreshold`
如果任何一个 Store 中存在超过此数量的 StoreFiles（每个 MemStore 刷新一个 StoreFile），则会执行压缩以将所有 StoreFile 重写为单个 StoreFile。较大的值会延迟压实，但是当压缩发生时，需要较长时间才能完成。
默认: `3`
`hbase.regionserver.compaction.enabled`
开启/关闭 压缩 通过设置 true/false.也可以通过 compaction_switch shell 命令
默认: `true`
`hbase.hstore.flusher.count`
刷新线程的数量。用更少的线程，MemStore 刷新将排队。随着线程数量的增加，刷新将并行执行，增加了 HDFS 的负载，并可能导致更多的压缩。
默认: `2`
`hbase.hstore.blockingStoreFiles`
如果任何一个 Store 中存在超过此数量的 StoreFiles（每次刷新 MemStore 时将写入一个 StoreFile），则会阻止该区域的更新，直到压缩完成或超出 hbase.hstore.blockingWaitTime。
默认: `16`
`hbase.hstore.blockingWaitTime`
在达到 hbase.hstore.blockingStoreFiles 定义的 StoreFile 限制后，区域将阻止更新的时间。经过这段时间后，即使压缩尚未完成，该地区也将停止阻止更新。
默认: `90000`
`hbase.hstore.compaction.min`
压缩可以运行之前，必须有符合进行压缩条件的最小 StoreFiles 数量。调整 hbase.hstore.compaction.min 的目标是避免使用太多的小型 StoreFiles 来压缩。如果将此值设置为 2，则每次在 Store 中有两个 StoreFiles 时会导致轻微的压缩，这可能不合适。如果将此值设置得太高，则需要相应调整所有其他值。对于大多数情况下，默认值是适当的。在以前的 HBase 版本中，参数 hbase.hstore.compaction.min 被命名为 hbase.hstore.compactionThreshold。
默认: `3`
`hbase.hstore.compaction.max`
无论符合条件的 StoreFiles 的数量如何，将为单个次要压缩选择的 StoreFiles 的最大数量。有效地，hbase.hstore.compaction.max 的值控制单个压缩完成所需的时间长度。将其设置得更大意味着更多的 StoreFiles 包含在压缩中。对于大多数情况下，默认值是适当的。
默认: `10`
`hbase.hstore.compaction.min.size`
StoreFile（或使用 ExploringCompactionPolicy 时选择的 StoreFiles）小于此大小将始终有资格进行轻微压缩。这个大小或更大的 HFile 通过 hbase.hstore.compaction.ratio 进行计算，以确定它们是否合格。由于此限制表示所有 StoreFiles 的“自动包含”限制小于此值，因此在需要刷新多个 StoreFile（1-2 MB 范围内的许多 StoreFiles）的写入繁重环境中可能需要降低此值，因为每个 StoreFile 都将作为目标，对于压缩而言，所得到的 StoreFile 可能仍然在最小尺寸下，并且需要进一步的压缩。如果此参数降低，比率检查会更快地触发。这解决了在早期版本的 HBase 中看到的一些问题，但是在大多数情况下不再需要更改此参数。
默认: `134217728`
`hbase.hstore.compaction.max.size`
StoreFile（或使用 ExploringCompactionPolicy 时选择的 StoreFiles）大于此大小将被排除在压缩之外。提高 hbase.hstore.compaction.max.size 的效果较少，较大的 StoreFiles 不经常压缩。如果你觉得压缩过于频繁而没有太多好处，你可以尝试提高这个价值。默认值：LONG.MAX_VALUE 的值，以字节表示。
默认: `9223372036854775807`
`hbase.hstore.compaction.ratio`
对于轻微压缩，此比率用于确定大于 hbase.hstore.compaction.min.size 的给定 StoreFile 是否适合压缩。其作用是限制大型 StoreFiles 的压缩。hbase.hstore.compaction.ratio 的值以浮点小数表示。一个很大的比例，如 10，将产生一个大型的 StoreFile。相反，低值（如 0.25）会产生类似于 BigTable 压缩算法的行为，产生四个 StoreFiles。推荐使用 1.0 到 1.4 之间的中等数值。在调整此值时，您要平衡写入成本与读取成本。提高价值（如 1.4）会有更多的写入成本，因为你会压缩更大的 StoreFiles。然而，在读取期间，HBase 将需要通过更少的 StoreFiles 来完成读取。如果您不能利用 Bloom 过滤器，请考虑使用这种方法。否则，可以将此值降低到 1.0 以降低写入的背景成本，并使用 Bloom 过滤器来控制读取期间触摸的 StoreFiles 的数量。对于大多数情况下，默认值是适当的。
默认: `1.2F`
`hbase.hstore.compaction.ratio.offpeak`
允许您设置不同（默认情况下，更积极）的比率，以确定在非高峰时段是否包含较大的 StoreFiles。以与 hbase.hstore.compaction.ratio 相同的方式工作。仅当 hbase.offpeak.start.hour 和 hbase.offpeak.end.hour 也被启用时才适用。
默认: `5.0F`
`hbase.hstore.time.to.purge.deletes`
使用未来的时间戳延迟清除标记的时间。如果未设置，或设置为 0，则将在下一个主要压缩过程中清除所有删除标记（包括具有未来时间戳的标记）。否则，将保留一个删除标记，直到在标记的时间戳之后发生的主要压缩加上此设置的值（以毫秒为单位）。
默认: `0`
`hbase.offpeak.start.hour`
非高峰时段开始，以 0 到 23 之间的整数表示，包括 0 和 23 之间的整数。设置为-1 以禁用非高峰。
默认: `-1`
`hbase.offpeak.end.hour`
非高峰时段结束，以 0 到 23 之间的整数表示，包括 0 和 23 之间的整数。设置为-1 以禁用非高峰。
默认: `-1`
`hbase.regionserver.thread.compaction.throttle`
有两个不同的线程池用于压缩，一个用于大型压缩，另一个用于小型压缩。这有助于保持精简表（如 hbase：meta）的快速压缩。如果压缩度大于此阈值，则会进入大型压缩池。在大多数情况下，默认值是适当的。默认值：2 x hbase.hstore.compaction.max x hbase.hregion.memstore.flush.size（默认为 128MB）。值字段假定 hbase.hregion.memstore.flush.size 的值与默认值相同。
默认: `2684354560`
`hbase.regionserver.majorcompaction.pagecache.drop`
指定是否通过主要压缩删除读取/写入系统页面缓存的页面。将其设置为 true 有助于防止重大压缩污染页面缓存，这几乎总是要求的，特别是对于具有低/中等内存与存储率的群集。
默认: `true`
`hbase.regionserver.minorcompaction.pagecache.drop`
指定是否通过较小的压缩删除读取/写入系统页面缓存的页面。将其设置为 true 有助于防止轻微压缩污染页面缓存，这对于内存与存储比率较低的群集或写入较重的群集是最有利的。当大部分读取位于最近写入的数据上时，您可能希望在中等到低写入工作负载下将其设置为 false。
默认: `true`
`hbase.hstore.compaction.kv.max`
刷新或压缩时要读取并批量写入的 KeyValues 的最大数量。如果你有较大的 KeyValues，并且 Out Of Memory Exceptions 有问题，请将它设置得更低。
默认: `10`
`hbase.storescanner.parallel.seek.enable`
在 StoreScanner 中启用 StoreFileScanner 并行搜索功能，该功能可以在特殊情况下减少响应延迟。
默认: `false`
`hbase.storescanner.parallel.seek.threads`
如果启用了并行查找功能，则默认线程池大小。
默认: `10`
`hfile.block.cache.size`
StoreFile 使用的最大堆（-Xmx 设置）分配给块缓存的百分比。默认值为 0.4 意味着分配 40％。设置为 0 禁用，但不建议；您至少需要足够的缓存来保存存储文件索引。
默认: `0.4`
`hfile.block.index.cacheonwrite`
这允许在索引被写入时将非根多级索引块放入块高速缓存中。
默认: `false`
`hfile.index.block.max.size`
当多级块索引中叶级，中级或根级索引块的大小增长到这个大小时，块将被写出并启动一个新块。
默认: `131072`
`hbase.bucketcache.ioengine`
在哪里存储 bucketcache 的内容。其中之一：offheap、文件或 mmap。如果有文件，则将其设置为 file(s)：PATH_TO_FILE。mmap 意味着内容将在一个 mmaped 文件中。使用 mmap：PATH_TO_FILE。详见: [http://hbase.apache.org/book.html#offheap.blockcache](http://hbase.apache.org/book.html#offheap.blockcache)
默认: none
`hbase.bucketcache.size`
EITHER 表示缓存的总堆内存大小的百分比（如果小于 1.0），则表示 BucketCache 的总容量（兆字节）。默认值：0.0
默认: none
`hbase.bucketcache.bucket.sizes`
用于 bucketcache 的存储区大小的逗号分隔列表。可以是多种尺寸。列出从最小到最大的块大小。您使用的大小取决于您的数据访问模式。必须是 256 的倍数，否则当你从缓存中读取时，你会遇到“java.io.IOException：Invalid HFile block magic”。如果您在此处未指定任何值，那么您可以选取代码中设置的默认 bucketsizes。
默认: none
`hfile.format.version`
用于新文件的 HFile 格式版本。版本 3 添加了对 hfiles 中标签的支持（请参阅 [http://hbase.apache.org/book.html#hbase.tags](http://hbase.apache.org/book.html#hbase.tags)）。另请参阅配置“hbase.replication.rpc.codec”。
默认: `3`
`hfile.block.bloom.cacheonwrite`
为复合 Bloom 过滤器的内联块启用写入缓存。
默认: `false`
`io.storefile.bloom.block.size`
复合 Bloom 过滤器的单个块（“chunk”）的字节大小。这个大小是近似的，因为 Bloom 块只能被插入到数据块的边界处，而每个数据块的 key 的个数也不相同。
默认: `131072`
`hbase.rs.cacheblocksonwrite`
块完成后，是否应将 HFile 块添加到块缓存中。
默认: `false`
`hbase.rpc.timeout`
这是为了让 RPC 层定义一个远程调用超时（毫秒）HBase 客户端应用程序超时。它使用 ping 来检查连接，但最终会抛出 TimeoutException。
默认: `60000`
`hbase.client.operation.timeout`
操作超时是一个顶级的限制（毫秒），确保表格中的阻止操作不会被阻止超过这个限制。在每个操作中，如果 rpc 请求由于超时或其他原因而失败，则将重试直到成功或抛出 RetriesExhaustedException。但是，如果总的阻塞时间在重试耗尽之前达到操作超时，则会提前中断并抛出 SocketTimeoutException。
默认: `1200000`
`hbase.cells.scanned.per.heartbeat.check`
在 heartbeat 检查之间扫描的单元格的数量。在扫描处理过程中会发生 heartbeat 检查，以确定服务器是否应该停止扫描，以便将 heartbeat 消息发送回客户端。heartbeat 消息用于在长时间运行扫描期间保持客户端 - 服务器连接的活动。较小的值意味着 heartbeat 检查将更频繁地发生，因此将对扫描的执行时间提供更严格的界限。数值越大意味着 heartbeat 检查发生的频率越低。
默认: `10000`
`hbase.rpc.shortoperation.timeout`
这是“hbase.rpc.timeout”的另一个版本。对于集群内的 RPC 操作，我们依靠此配置为短操作设置短超时限制。例如，区域服务器试图向活动主服务器报告的短 rpc 超时可以更快地进行主站故障转移过程。
默认: `10000`
`hbase.ipc.client.tcpnodelay`
在 rpc 套接字连接上设置没有延迟。详见: [http://docs.oracle.com/javase/1.5.0/docs/api/java/net/Socket.html#getTcpNoDelay(](http://docs.oracle.com/javase/1.5.0/docs/api/java/net/Socket.html#getTcpNoDelay())
默认: `true`
`hbase.regionserver.hostname`
这个配置适用于对 HBase 很熟悉的人：除非你真的知道你在做什么，否则不要设定它的价值。当设置为非空值时，这表示底层服务器的（面向外部）主机名。
详见: [https://issues.apache.org/jira/browse/HBASE-12954](https://issues.apache.org/jira/browse/HBASE-12954)
默认: none
`hbase.regionserver.hostname.disable.master.reversedns`
这个配置适用于对 HBase 很熟练的人：除非你真的知道你在做什么，否则不要设定它的价值。当设置为 true 时，regionserver 将使用当前节点主机名作为服务器名称，HMaster 将跳过反向 DNS 查找并使用 regionserver 发送的主机名。请注意，此配置和 hbase.regionserver.hostname 是互斥的。详见: [https://issues.apache.org/jira/browse/HBASE-18226](https://issues.apache.org/jira/browse/HBASE-18226)
默认: `false`
`hbase.master.keytab.file`
用于登录配置的 HMaster 服务器主体的 kerberos 密钥表文件的完整路径。
默认: none
`hbase.master.kerberos.principal`
Ex. "hbase/_HOST@EXAMPLE.COM"应该用来运行 HMaster 进程的 Kerberos 主体名称。主体名称的格式应为：user/hostname @ DOMAIN。如果使用“_HOST”作为主机名部分，它将被替换为正在运行的实例的实际主机名。
默认: none
`hbase.regionserver.keytab.file`
用于登录配置的 HRegionServer 服务器主体的 kerberos 密钥表文件的完整路径。
默认: none
`hbase.regionserver.kerberos.principal`
Ex. "hbase/_HOST@EXAMPLE.COM"应该用来运行 HRegionServer 进程的 kerberos 主体名称。主体名称的格式应为：user/hostname @ DOMAIN。如果使用“_HOST”作为主机名部分，它将被替换为正在运行的实例的实际主机名。此主体的条目必须存在于 hbase.regionserver.keytab.file 中指定的文件中
默认: none
`hadoop.policy.file`
RPC 服务器使用策略配置文件对客户端请求进行授权决策。仅在启用 HBase 安全性时使用。
默认: `hbase-policy.xml`
`hbase.superuser`
用户或组列表（以逗号分隔），允许在整个集群中拥有完全权限（不管存储的 ACL）。仅在启用 HBase 安全性时使用。
默认: none
`hbase.auth.key.update.interval`
服务器中认证令牌的主密钥的更新间隔（以毫秒为单位）。仅在启用 HBase 安全性时使用。
默认: `86400000`
`hbase.auth.token.max.lifetime`
验证令牌过期的最长生存时间（以毫秒为单位）。仅在启用 HBase 安全性时使用。
默认: `604800000`
`hbase.ipc.client.fallback-to-simple-auth-allowed`
当客户端配置为尝试安全连接，但尝试连接到不安全的服务器时，该服务器可能会指示客户端切换到 SASL SIMPLE（不安全）身份验证。此设置控制客户端是否接受来自服务器的此指令。如果为 false（默认值），则客户端将不允许回退到 SIMPLE 身份验证，并会中止连接。
默认: `false`
`hbase.ipc.server.fallback-to-simple-auth-allowed`
当服务器配置为需要安全连接时，它将拒绝来自使用 SASL SIMPLE（不安全）身份验证的客户端的连接尝试。此设置允许安全服务器在客户端请求时接受来自客户端的 SASL SIMPLE 连接。如果为 false（默认值），服务器将不允许回退到 SIMPLE 身份验证，并将拒绝连接。警告：只有在将客户端转换为安全身份验证时，才应将此设置用作临时措施。必须禁止它才能进行安全操作。
默认: `false`
`hbase.display.keys`
当它被设置为 true 时，webUI 等将显示所有开始/结束键作为表格细节，区域名称等的一部分。当这被设置为假时，键被隐藏。
默认: `true`
`hbase.coprocessor.enabled`
启用或禁用协处理器加载。如果'false'（禁用），任何其他协处理器相关的配置将被忽略。
默认: `true`
`hbase.coprocessor.user.enabled`
启用或禁用用户（又名表）协处理器加载。如果'false'（禁用），则表格描述符中的任何表协处理器属性将被忽略。如果“hbase.coprocessor.enabled”为“false”，则此设置无效。
默认: `true`
`hbase.coprocessor.region.classes`
在所有表上默认加载的区域观察者或端点协处理器的逗号分隔列表。对于任何覆盖协处理器方法，这些类将按顺序调用。在实现自己的协处理器之后，将其添加到 HBase 的类路径中，并在此处添加完全限定的类名称。协处理器也可以通过设置 HTableDescriptor 或者 HBase shell 来按需加载。
默认: none
`hbase.coprocessor.master.classes`
在活动的 HMaster 进程中默认加载的 org.apache.hadoop.hbase.coprocessor.MasterObserver 协处理器的逗号分隔列表。对于任何实施的协处理器方法，列出的类将按顺序调用。在实现你自己的 MasterObserver 之后，把它放在 HBase 的类路径中，并在这里添加完全限定的类名称。
默认: none
`hbase.coprocessor.abortonerror`
如果协处理器加载失败，初始化失败或引发意外的 Throwable 对象，则设置为 true 将导致托管服务器（主服务器或区域服务器）中止。将其设置为 false 将允许服务器继续执行，但所涉及的协处理器的系统范围状态将变得不一致，因为它只能在一部分服务器中正确执行，所以这对于仅调试是非常有用的。
默认: `true`
`hbase.rest.port`
HBase REST 服务器的端口。
默认: `8080`
`hbase.rest.readonly`
定义 REST 服务器将启动的模式。可能的值有：false：此时，所有的 HTTP 方法都是允许的 - GET / PUT / POST / DELETE。true：此时只允许 GET 方法。
默认: `false`
`hbase.rest.threads.max`
REST 服务器线程池的最大线程数。池中的线程被重用来处理 REST 请求。这将控制同时处理的最大请求数。这可能有助于控制 REST 服务器使用的内存以避免 OOM 问题。如果线程池已满，则传入的请求将排队并等待一些空闲的线程。
默认: `100`
`hbase.rest.threads.min`
REST 服务器线程池的最小线程数。线程池总是至少有这么多的线程，所以 REST 服务器已经准备好为传入的请求提供服务。
默认: `2`
`hbase.rest.support.proxyuser`
启用运行 REST 服务器以支持代理用户模式。
默认: `false`
`hbase.defaults.for.version.skip`
设置为 true 可以跳过“hbase.defaults.for.version”检查。将其设置为 true 可以在除 maven 生成的另一侧之外的上下文中有用；即运行在 IDE 中。你需要设置这个布尔值为 true 以避免看到 RuntimeException：“hbase-default.xml 文件似乎是 HBase（\ $ {hbase.version}）的旧版本，这个版本是 XXX-SNAPSHOT”
默认: `false`
`hbase.table.lock.enable`
设置为 true 以启用锁定 zookeeper 中的表以进行模式更改操作。从主服务器锁定表可以防止并发的模式修改损坏表状态。
默认: `true`
`hbase.table.max.rowsize`
单行字节的最大大小（默认值为 1 Gb），用于 Get-ing 或 Scan'ning，不设置行内扫描标志。如果行大小超过此限制 RowTooBigException 被抛出到客户端。
默认: `1073741824`
`hbase.thrift.minWorkerThreads`
线程池的“核心大小”。在每个连接上创建新线程，直到创建了许多线程。
默认: `16`
`hbase.thrift.maxWorkerThreads`
线程池的最大大小。待处理的请求队列溢出时，将创建新线程，直到其号码达到此数字。之后，服务器开始丢弃连接。
默认: `1000`
`hbase.thrift.maxQueuedRequests`
在队列中等待的最大等待节点连接数。如果池中没有空闲线程，则服务器将请求排队。只有当队列溢出时，才会添加新的线程，直到 hbase.thrift.maxQueuedRequests 线程。
默认: `1000`
`hbase.regionserver.thrift.framed`
在服务器端使用 Thrift TFramedTransport。对于 thrift 服务器，这是推荐的传输方式，需要在客户端进行类似的设置。将其更改为 false 将选择默认传输，当由于 THRIFT-601 发出格式错误的请求时，容易受到 DoS 的影响。
默认: `false`
`hbase.regionserver.thrift.framed.max_frame_size_in_mb`
使用成帧传输时的默认帧大小，以 MB 为单位。
默认: `2`
`hbase.regionserver.thrift.compact`
使用 Thrift TCompactProtocol 二进制序列化协议。
默认: `false`
`hbase.rootdir.perms`
安全（kerberos）安装程序中根数据子目录的 FS Permissions。主服务器启动时，会使用此权限创建 rootdir，如果不匹配则设置权限。
默认: `700`
`hbase.wal.dir.perms`
安全（kerberos）安装程序中的根 WAL 目录的 FS Permissions。当主服务器启动时，它将使用此权限创建 WAL 目录，如果不匹配则设置权限。
默认: `700`
`hbase.data.umask.enable`
如果启用，则启用该文件权限应分配给区域服务器写入的文件
默认: `false`
`hbase.data.umask`
当 hbase.data.umask.enable 为 true 时，应该用来写入数据文件的文件权限
默认: `000`
`hbase.snapshot.enabled`
设置为 true 以允许 taken/restored/cloned。
默认: `true`
`hbase.snapshot.restore.take.failsafe.snapshot`
设置为 true 以在还原操作之前得到快照。所得到的快照将在失败的情况下使用，以恢复以前的状态。在还原操作结束时，此快照将被删除
默认: `true`
`hbase.snapshot.restore.failsafe.name`
restore 操作所采用的故障安全快照的名称。您可以使用{snapshot.name}，{table.name}和{restore.timestamp}变量根据要恢复的内容创建一个名称。
默认: `hbase-failsafe-{snapshot.name}-{restore.timestamp}`
`hbase.snapshot.working.dir`
快照过程将发生的位置。已完成快照的位置不会更改，但快照进程发生的临时目录将设置为此位置。为了提高性能，它可以是一个独立的文件系统，而不是根目录。有关详细信息，请参阅 HBase-21098
默认: none
`hbase.server.compactchecker.interval.multiplier`
这个数字决定了我们扫描的频率，看是否需要压缩。通常情况下，压缩是在某些事件（如 memstore flush）之后完成的，但是如果区域在一段时间内没有收到大量的写入，或者由于不同的压缩策略，则可能需要定期检查。检查之间的时间间隔是 hbase.server.compactchecker.interval.multiplier 乘以 hbase.server.thread.wakefrequency。
默认: `1000`
`hbase.lease.recovery.timeout`
在放弃之前，我们等待 dfs lease 的总恢复时间。
默认: `900000`
`hbase.lease.recovery.dfs.timeout`
dfs 恢复 lease 调用之间的时间间隔。应该大于 namenode 为 datanode 的一部分发出块恢复命令所需的时间总和；dfs.heartbeat.interval 和主数据节点所花费的时间，在死数据节点上执行数据块恢复到超时；通常是 dfs.client.socket-timeout。详见:HBASE-8389
默认: `64000`
`hbase.column.max.version`
新的列族描述符将使用此值作为要保留的默认版本数。
默认: `1`
`dfs.client.read.shortcircuit`
如果设置为 true，则此配置参数启用 short-circuit 本地读取。
默认: `false`
`dfs.domain.socket.path`
如果将 dfs.client.read.shortcircuit 设置为 true，则这是一个 UNIX 域套接字的路径，该套接字将用于 DataNode 与本地 HDFS 客户端之间的通信。如果该路径中存在字符串“_PORT”，则会被 DataNode 的 TCP 端口替换。请注意托管共享域套接字的目录的权限。
默认: `none`
`hbase.dfs.client.read.shortcircuit.buffer.size`
如果未设置 DFSClient 配置 dfs.client.read.shortcircuit.buffer.size，我们将使用此处配置的内容作为 short-circuit 读取默认直接字节缓冲区大小。DFSClient 本机默认值是 1MB；HBase 保持 HDFS 文件的打开状态，所以文件块*1MB 的数量很快就开始累积起来，并由于直接内存不足而威胁 OOME。所以，我们从默认设置下来。使它大于在 HColumnDescriptor 中设置的默认 hbase 块大小，通常是 64k。
默认: `131072`
`hbase.regionserver.checksum.verify`
如果设置为 true（默认），HBase 将验证 hfile 块的校验和。当 HBase 写出 hfiles 时，HBase 将校验和写入数据。HDFS（在此写入时）将校验和写入单独的文件，而不是需要额外查找的数据文件。设置这个标志可以节省一些 I/O。设置此标志时，HDFS 的校验和验证将在 hfile 流内部禁用。如果 hbase-checksum 验证失败，我们将切换回使用 HDFS 校验和（所以不要禁用 HDFS 校验！除此功能外，还适用于 hfiles，而不适用于 WAL）。如果这个参数设置为 false，那么 hbase 将不会验证任何校验和，而是取决于 HDFS 客户端中的校验和验证。
默认: `true`
`hbase.hstore.bytes.per.checksum`
新创建的校验和块中的字节数，用于 hfile 块中的 HBase 级校验和。
默认: `16384`
`hbase.hstore.checksum.algorithm`
用于计算校验和的算法的名称。可能的值是 NULL，CRC32，CRC32C。
默认: `CRC32C`
`hbase.client.scanner.max.result.size`
调用扫描器的下一个方法时返回的最大字节数。请注意，当单个行大于此限制时，行仍然完全返回。默认值是 2MB，这对于 1ge 网络是有好处的。有了更快和/或更高的延迟网络，这个值应该增加。
默认: `2097152`
`hbase.server.scanner.max.result.size`
调用扫描器的下一个方法时返回的最大字节数。请注意，当单个行大于此限制时，行仍然完全返回。默认值是 100MB。这是保护服务器免受 OOM 情况的安全设置。
默认: `104857600`
`hbase.status.published`
该设置激活了主控发布区域服务器的状态。当一台区域服务器死亡并开始恢复时，主服务器会将这些信息推送到客户端应用程序，让他们立即切断连接，而不是等待超时。
默认: `false`
`hbase.status.publisher.class`
用 multicast 消息实现状态发布。
默认: `org.apache.hadoop.hbase.master.ClusterStatusPublisher$MulticastPublisher`
`hbase.status.listener.class`
使用 multicast 消息实现状态监听器。
默认: `org.apache.hadoop.hbase.client.ClusterStatusListener$MulticastListener`
`hbase.status.multicast.address.ip`
用于 multicase 状态发布的 multicase 地址。
默认: `226.1.1.3`
`hbase.status.multicast.address.port`
用于 multicase 状态发布的 multicase 端口。
默认: `16100`
`hbase.dynamic.jars.dir`
自定义过滤器 JAR 的目录可以由区域服务器动态加载，而无需重新启动。但是，已加载的过滤器/协处理器类将不会被卸载。不适用于协处理器。详见:HBASE-1936
默认: `${hbase.rootdir}/lib`
`hbase.security.authentication`
控制是否为 HBase 启用安全身份验证。可能的值是“simple”（不认证）和“Kerberos”。
默认: `simple`
`hbase.rest.filter.classes`
用于 REST 服务的 Servlet 过滤器。
默认: `org.apache.hadoop.hbase.rest.filter.GzipFilter`
`hbase.master.loadbalancer.class`
用于在期间发生时执行区域平衡的类。它将 DefaultLoadBalancer 替换为默认值（因为它被重命名为 SimpleLoadBalancer ）。详见:
[http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.html](http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.html)
默认: `org.apache.hadoop.hbase.master.balancer.StochasticLoadBalancer`
`hbase.master.loadbalance.bytable`
平衡器运行时的因子表名称。默认：false。
默认: `false`
`hbase.master.normalizer.class`
用于执行期间发生时的区域标准化的类。详见: [http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/SimpleRegionNormalizer.html](http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/SimpleRegionNormalizer.html)
默认: `org.apache.hadoop.hbase.master.normalizer.SimpleRegionNormalizer`
`hbase.rest.csrf.enabled`
设置为 true 以启用跨站请求伪造的保护。
默认: `false`
`hbase.rest-csrf.browser-useragents-regex`
通过将 hbase.rest.csrf.enabled 设置为 true 来启用为 REST 服务器，针对跨站点请求伪造（CSRF）的防护时，用于匹配 HTTP 请求的 User-Agent 标头的正则表达式的逗号分隔列表。如果传入的用户代理与这些正则表达式中的任何一个相匹配，则认为该请求被浏览器发送，因此 CSRF 预防被强制执行。如果请求的用户代理与这些正则表达式中的任何一个都不匹配，则该请求被认为是由除浏览器以外的其他东西发送的，例如脚本自动化。在这种情况下，CSRF 不是一个潜在的攻击向量，所以预防没有被执行。这有助于实现与尚未更新以发送 CSRF 预防报头的现有自动化的向后兼容性。
默认: `<sup>Mozilla.**,**</sup>**Opera.**`
`hbase.security.exec.permission.checks`
如果启用此设置，并且基于 ACL 的访问控制处于活动状态（AccessController 协处理器作为系统协处理器安装，或作为表协处理器安装在表上），则必须授予所有相关用户 EXEC 权限（如果需要执行协处理器端点调用。像任何其他权限一样，EXEC 权限可以在全局范围内授予用户，也可以授予每个表或命名空间的用户。有关协处理器端点的更多信息，请参阅 HBase 联机手册的协处理器部分。有关使用 AccessController 授予或撤消权限的更多信息，请参阅 HBase 联机手册的安全性部分。
默认: `false`
`hbase.procedure.regionserver.classes`
在活动 HRegionServer 进程中默认加载的 org.apache.hadoop.hbase.procedure.RegionServerProcedureManager 过程管理器的逗号分隔列表。生命周期方法（init / start / stop）将由活动的 HRegionServer 进程调用，以执行特定的全局 barriered 过程。在实现你自己的 RegionServerProcedureManager 之后，把它放在 HBase 的类路径中，并在这里添加完全限定的类名称。
默认: none
`hbase.procedure.master.classes`
在活动 HMaster 进程中默认加载的 org.apache.hadoop.hbase.procedure.MasterProcedureManager 过程管理器的逗号分隔列表。程序通过其签名进行标识，用户可以使用签名和即时名称来触发全局程序的执行。在实现你自己的 MasterProcedureManager 之后，把它放在 HBase 的类路径中，并在这里添加完全限定的类名称。
默认: none
`hbase.coordinated.state.manager.class`
协调状态管理员的完全合格的名字。
默认: `org.apache.hadoop.hbase.coordination.ZkCoordinatedStateManager`
`hbase.regionserver.storefile.refresh.period`
用于刷新辅助区域的存储文件的时间段（以毫秒为单位）。0 意味着此功能被禁用。辅助区域在次要区域刷新区域中的文件列表时会看到来自主要文件的新文件（来自刷新和压缩）（没有通知机制）。但是频繁刷新可能会导致额外的 Namenode 压力。如果文件的刷新时间不能超过 HFile TTL（hbase.master.hfilecleaner.ttl），请求将被拒绝。此设置还建议将 HFile TTL 配置为较大的值。
默认: `0`
`hbase.region.replica.replication.enabled`
是否启用对辅助区域副本的异步 WAL 复制。如果启用了此功能，则会创建一个名为“region_replica_replication”的复制对等项，它将对日志进行尾随处理，并将突变复制到区域复制大于 1 的区域复制的区域复制。如果启用一次，禁用此复制也需要禁用复制对等使用 shell 或 Admin java 类。复制到辅助区域副本可以在标准群集间复制上工作。
默认: `false`
`hbase.http.filter.initializers`
一个以逗号分隔的类名列表。列表中的每个类都必须扩展 org.apache.hadoop.hbase.http.FilterInitializer。相应的过滤器将被初始化。然后，过滤器将应用于所有面向 jsp 和 servlet 网页的用户。列表的排序定义了过滤器的排序。默认的 StaticUserWebFilter 添加 hbase.http.staticuser.user 属性定义的用户主体。
默认: `org.apache.hadoop.hbase.http.lib.StaticUserWebFilter`
`hbase.security.visibility.mutations.checkauths`
如果启用此属性，将检查可见性表达式中的标签是否与发出突变的用户相关联
默认: `false`
`hbase.http.max.threads`
HTTP 服务器将在其 ThreadPool 中创建的最大线程数。
默认: `16`
`hbase.replication.rpc.codec`
启用复制时要使用的编解码器，以便标签也被复制。这与支持标签的 HFileV3 一起使用。如果标签未被使用或者所使用的 hfile 版本是 HFileV2，则可以使用 KeyValueCodec 作为复制编解码器。请注意，在没有标签时使用 KeyValueCodecWithTags 进行复制不会造成任何伤害。
默认: `org.apache.hadoop.hbase.codec.KeyValueCodecWithTags`
`hbase.replication.source.maxthreads`
任何复制源将用于并行传送编辑到接收器的最大线程数。这也限制了每个复制批次被分解成的块的数量。较大的值可以提高主群集和从群集之间的复制吞吐量。默认值为 10，很少需要改变。
默认: `10`
`hbase.http.staticuser.user`
要在呈现内容时在静态网页过滤器上过滤的用户名称。一个示例使用是 HDFS Web UI（用于浏览文件的用户）。
默认: `dr.stack`
`hbase.regionserver.handler.abort.on.error.percent`
区域服务器 RPC 线程的百分比无法中止 RS。-1 表示禁用中止；0 表示即使单个处理程序已经死亡也会中止；0.x 表示只有当这个百分比的处理程序死亡时才中止；1 表示只中止所有的处理程序已经死亡。
默认: `0.5`
`hbase.mob.file.cache.size`
要缓存的已打开文件处理程序的数量。更大的值将通过为每个移动文件缓存提供更多的文件处理程序来减少频繁的文件打开和关闭，从而有利于读取。但是，如果设置得太高，则可能导致“打开的文件处理程序太多”。默认值为 1000。
默认: `1000`
`hbase.mob.cache.evict.period`
mob 高速缓存驱逐高速缓存的 mob 文件之前的时间（秒）。默认值是 3600 秒。
默认: `3600`
`hbase.mob.cache.evict.remain.ratio`
当缓存的移动文件数量超过 hbase.mob.file.cache.size 时，触发驱逐后保留的文件的比率（介于 0.0 和 1.0 之间）会被触发。默认值是 0.5f。
默认: `0.5f`
`hbase.master.mob.ttl.cleaner.period`
ExpiredMobFileCleanerChore 运行的时间段。该单位是秒。默认值是一天。MOB 文件名仅使用文件创建时间的日期部分。我们使用这个时间来决定文件的 TTL 到期时间。所以删除 TTL 过期的文件可能会被延迟。最大延迟可能是 24 小时。
默认: `86400`
`hbase.mob.compaction.mergeable.threshold`
如果一个 mob 文件的大小小于这个值，那么它被认为是一个小文件，需要在 mob compaction 中合并。默认值是 1280MB。
默认: `1342177280`
`hbase.mob.delfile.max.count`
mob 压缩中允许的最大 del 文件数。在 mob 压缩中，当现有的 del 文件的数量大于这个值时，它们被合并，直到 del 文件的数量不大于该值。默认值是 3。
默认: `3`
`hbase.mob.compaction.batch.size`
在一批 mob 压缩中所允许的 mob 文件的最大数量。mob 压缩合并小的 mob 文件到更大的。如果小文件的数量非常大，则可能导致合并中的“打开的文件处理程序太多”。合并必须分成批次。此值限制在一批 mob 压缩中选择的 mob 文件的数量。默认值是 100。
默认: `100`
`hbase.mob.compaction.chore.period`
MobCompactionChore 运行的时间。该单位是秒。默认值是一个星期。
默认: `604800`
`hbase.mob.compactor.class`
执行 mob compactor，默认一个是 PartitionedMobCompactor。
默认: `org.apache.hadoop.hbase.mob.compactions.PartitionedMobCompactor`
`hbase.mob.compaction.threads.max`
MobCompactor 中使用的最大线程数。
默认: `1`
`hbase.snapshot.master.timeout.millis`
主快照程序执行的超时。
默认: `300000`
`hbase.snapshot.region.timeout`
区域服务器将线程保持在快照请求池中等待超时。
默认: `300000`
`hbase.rpc.rows.warning.threshold`
批处理操作中的行数，超过该值将记录警告。
默认: `5000`
`hbase.master.wait.on.service.seconds`
默认是 5 分钟。做 30 秒的测试。有关上下文，请参见 HBASE-19794。
默认: `30`
### 7.3\. _hbase-env.sh_
hbase-env.sh 文件用来设置 HBase 环境变量。比如包括在启动 HBase 守护程序（如堆大小和垃圾回收器配置）时传递 JVM 的选项。您还可以设置 HBase 配置、日志目录、niceness、ssh 选项，定位进程 pid 文件的位置等的配置。打开 _conf/hbase-env.sh_ 文件并仔细阅读其内容。每个选项都有相当好的记录。如果希望在启动时由 HBase 守护进程读取，请在此处添加您自己的环境变量。
此处的更改将需要重启 HBase 才能注意到更改。
### 7.4\. _log4j.properties_
编辑此文件以更改 HBase 文件的滚动速度，并更改 HBase 记录消息的级别。
此处的更改将需要重新启动集群以注意到更改，尽管可以通过 HBase UI 为特定的守护程序更改日志级别。
### 7.5\. 客户端配置和依赖关系连接到 HBase 集群
如果您在独立模式下运行 HBase，则不必为您的客户端配置任何内容，只要保证它们在同一台计算机上即可。
由于 HBase Master 可以移动，客户可以通过向 ZooKeeper 寻找当前的关键位置来进行引导。ZooKeeper 是保存所有这些值的地方。因此客户需要 ZooKeeper 集合的位置才能做其他事情。通常这个集合位置被保存在 _hbase-site.xml_ 中，并由客户端从`CLASSPATH`中提取。
如果你正在配置一个 IDE 来运行一个 HBase 客户端，你应该在你的类路径中包含 _conf/_ 目录，这样可以找到 _hbase-site.xml_ 设置（或者添加 _src/test/resources_ 来获取使用的 hbase-site.xml 文件通过测试）。
最小的情况是，当连接到集群时，HBase 客户机需要依赖关系中的 hbase-client 模块：
```
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-shaded-client</artifactId>
<version>2.0.0</version>
</dependency>
```
一个基本的客户端的 _hbase-site.xml_ 的使用示例可能如下所示：
```
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<property>
<name>hbase.zookeeper.quorum</name>
<value>example1,example2,example3</value>
<description>The directory shared by region servers.
</description>
</property>
</configuration>
```
#### 7.5.1\. Java 客户端配置
ava 客户端使用的配置保存在[HBaseConfiguration](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/HBaseConfiguration)实例中。
HBaseConfiguration 的工厂方法，`HBaseConfiguration.create();`;，在调用时会读取客户端上的第一个 _hbase-site.xml_ 的内容（`CLASSPATH`如果存在的话）（调用也将包含在任何发现的 _hbase-default.xml_ 中；_hbase-default.xml_ 在 _hbase.X.X.X.jar_ 里面）。也可以直接指定配置，而无需从 _hbase-site.xml_ 中读取数据。例如，要以编程方式设置集群的 ZooKeeper 集成，请执行以下操作：
```
Configuration config = HBaseConfiguration.create();
config.set("hbase.zookeeper.quorum", "localhost"); // Here we are running zookeeper locally
```
如果多个 ZooKeeper 实例组成 ZooKeeper 集合，则可以在逗号分隔列表中指定它们（就像在 _hbase-site.xml_ 文件中一样）。这个填充的`Configuration`实例然后可以传递给一个[表](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Table.html)，依此类推。
### 7.6\. 超时配置
HBase 提供了各种各样的超时设置来限制各种远程操作的执行时间。
* hbase.rpc.timeout
* hbase.rpc.read.timeout
* hbase.rpc.write.timeout
* hbase.client.operation.timeout
* hbase.client.meta.operation.timeout
* hbase.client.scanner.timeout.period
`hbase.rpc.timeout`属性限制单个 rpc 调用在超时之前可以运行的时间。要微调读或写相关的 RPC 超时，请设置`hbase.rpc.read.timeout`和`hbase.rpc.write.timeout`配置属性。如果没有这些属性，将使用`hbase.rpc.timeout`。
更高级别的超时为`hbase.client.operation.timeout`，对每个客户端调用都有效。例如，当由于`hbase.rpc.timeout`而导致 rpc 调用失败时，将重试该调用，直到达到`hbase.client.operation.timeout`。可以通过设置`hbase.client.meta.operation.timeout`配置值来微调系统表的客户端操作超时。如果不设置，则其值将使用`hbase.client.operation.timeout`。
扫描操作的超时控制方式不同。使用`hbase.client.scanner.timeout.period`属性设置此超时。
## 8\. HBase 配置示例
### 8.1\. 基本分布式 HBase 安装
在下文内容中是一个分布式 10 节点的群集的基本配置示例：其中，节点被命名为 example0，example1...一直到 example9，在这个例子中；HBase Master 和 HDFS NameNode 正在节点 example0 上运行；RegionServers 在节点 example1- example9 上运行；一个 3 节点 ZooKeeper 集合运行在 example1、example2，以及 example3 的默认端口上；ZooKeeper 的数据被保存到：_/export/zookeeper_r。
下面我们显示在 HBase conf 目录中找到的主要配置文件 _hbase-site.xml_, _regionservers_, and _hbase-env.sh_。
#### 8.1.1\. _hbase-site.xml_
```
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<property>
<name>hbase.zookeeper.quorum</name>
<value>example1,example2,example3</value>
<description>The directory shared by RegionServers.
</description>
</property>
<property>
<name>hbase.zookeeper.property.dataDir</name>
<value>/export/zookeeper</value>
<description>Property from ZooKeeper config zoo.cfg.
The directory where the snapshot is stored.
</description>
</property>
<property>
<name>hbase.rootdir</name>
<value>hdfs://example0:8020/hbase</value>
<description>The directory shared by RegionServers.
</description>
</property>
<property>
<name>hbase.cluster.distributed</name>
<value>true</value>
<description>The mode the cluster will be in. Possible values are
false: standalone and pseudo-distributed setups with managed ZooKeeper
true: fully-distributed with unmanaged ZooKeeper Quorum (see hbase-env.sh)
</description>
</property>
</configuration>
```
#### 8.1.2\. _regionservers_
在此文件中列出将运行 RegionServers 的节点。在我们的例子中，这些节点是 example1- example9。
```
example1
example2
example3
example4
example5
example6
example7
example8
example9
```
#### 8.1.3\. _hbase-env.sh_
_hbase-env.sh_ 文件中的以下行显示了如何设置`JAVA_HOME`环境变量（HBase 需要的）并将堆设置为 4 GB（而不是默认值 1 GB）。如果您复制并粘贴此示例，请务必调整`JAVA_HOME`以适合您的环境。
```
# The java implementation to use.
export JAVA_HOME=/usr/java/jdk1.8.0/
# The maximum amount of heap to use. Default is left to JVM default.
export HBASE_HEAPSIZE=4G
```
使用 rsync 将 _conf_ 目录的内容复制到群集的所有节点。
## 9\. HBase 重要配置
下面我们列出一些 _ 重要 _ 的配置。我们已经将这部分分为必需的配置和值得推荐的配置。
### 9.1\. 所需的配置
请你参考本教程中 HBase 基础条件中的操作系统和 Hadoop 部分的内容！
#### 9.1.1\. 大型群集配置
如果您拥有一个包含大量区域的群集，那么在主服务器启动后，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](https://issues.apache.org/jira/browse/HBASE-6389)
### 9.2\. 推荐的配置
#### 9.2.1\. ZooKeeper 配置
##### `zookeeper.session.timeout`
默认的超时时间是三分钟（以毫秒为单位）。这意味着，如果服务器崩溃，则在主服务器在三分钟前发现崩溃并开始恢复。您可能需要将超时调整到一分钟甚至更短的时间，以便主服务器尽快通知故障。在更改此值之前，请确保您的 JVM 垃圾收集配置处于受控状态，否则，长时间的垃圾回收会超出 ZooKeeper 会话超时时间，将取出您的 RegionServer。（如果一个 RegionServer 长时间处于 GC 状态，你可能需要在服务器上启动恢复）。
要更改此配置，请编辑 _hbase-site.xml_，将更改的文件复制到群集中并重新启动。
我们将这个值设置得很高，以避免不必要的麻烦。如果出现类似“为什么我在执行一个大规模数据导入的时候 Region Server 死掉啦”这样的问题，可以解释的原因是：他们的 JVM 未被解析，并且正在运行长时间的 GC 操作。
##### ZooKeeper 数量
详见 [zookeeper](#zookeeper).
#### 9.2.2\. 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](#rpc.logging)查看某个 RegionServer 上是否有太多或太多的处理程序，然后跟踪其日志（排队请求消耗内存）。
#### 9.2.3\. 大型内存机器的配置
HBase 提供了一个合理的，保守的配置，可以在几乎所有人们可能想要测试的机器类型上运行。如果你有更大的机器 - HBase 有 8G 或更大的堆 - 你可能会发现下面的配置选项很有帮助。
#### 9.2.4\. 压缩
您应该考虑启用 ColumnFamily 压缩。有几个选项可以在大多数情况下都是通过减小 StoreFiles 的大小来提高性能，从而减少 I / O。
详见 [compression](#compression)
#### 9.2.5\. 配置 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 文件。
#### 9.2.6\. 管理分割
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](#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 安全滚动分割。
#### 9.2.7\. 管理压缩
默认情况下，主要的压缩计划在 7 天内运行一次。
如果您需要精确控制主要压缩的运行时间和频率，可以禁用托管的主要压缩。请参阅 `hbase.hregion.majorcompaction` [compaction.parameters](#compaction.parameters)
> 不禁用主要压缩
>
> 对于 StoreFile 清理来说，重要的压缩是绝对必要的。不要完全禁用它们。您可以通过 HBase shell 或[Admin API](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Admin.html#majorCompact-org.apache.hadoop.hbase.TableName-)手动运行主要压缩。
详见: [compaction](#compaction)
#### 9.2.8\. 预测执行
预测执行 MapReduce 任务是默认开启的，对于 HBase 集群，通常建议关闭系统级的推测执行，除非您需要在特定情况下可以配置每个作业。将属性 `mapreduce.map.speculative` 和 `mapreduce.reduce.speculative` 设置为 false。
### 9.3\. 其他配置
#### 9.3.1\. 平衡器
平衡器（Balancer）是在主服务器上运行的一个周期性操作，用于重新分配集群上的区域。它通过`hbase.balancer.period`配置，默认为 300000（5 分钟）。
详见: [master.processes.loadbalancer](#master.processes.loadbalancer)
#### 9.3.2\. 禁用 Blockcache
不要关闭块缓存（你可以通过设置`hfile.block.cache.size`为零来实现）。这样做没有好处，因为 RegionServer 将花费所有的时间一次又一次地加载 HFile 索引。如果你的工作集是这样配置块缓存，那么没有益处，最少应保证 hfile 指数保存在块缓存内的大小（你可以通过调查 RegionServer UI 粗略地了解你需要的大小；请参阅占网页顶部附近的索引块大小）
#### 9.3.3\. [Nagle’s](http://en.wikipedia.org/wiki/Nagle’s_algorithm) 或小 package 问题
如果在对 HBase 的操作中出现大约 40ms 左右的延迟，请尝试 Nagles 的设置。 例如，请参阅用户邮件列表线程[Inconsistent scan performance with caching set to 1](http://search-hadoop.com/m/pduLg2fydtE/Inconsistent+scan+performance+with+caching+set+&subj=Re+Inconsistent+scan+performance+with+caching+set+to+1) 将缓存设置为 1 的不一致扫描性能以及其中所引用的设置`notcpdelay`来提高扫描速度的问题。详见文档底部图表[HBASE-7008 Set scanner caching to a better default](https://issues.apache.org/jira/browse/HBASE-7008) 设置了扫描缓存到一个更好的默认位置，我们的 Lars Hofhansl 会尝试使用 Nagle 打开和关闭测量效果的各种数据大小。
#### 9.3.4\. 更好的平均恢复时间
这部分是关于在服务器出现故障后会使服务器恢复更快的配置。详见:[Introduction to HBase Mean Time to Recover (MTTR)](http://hortonworks.com/blog/introduction-to-hbase-mean-time-to-recover-mttr/)
[HBASE-8354 forces Namenode into loop with lease recovery requests](https://issues.apache.org/jira/browse/HBASE-8389) 使用 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>
```
#### 9.3.5\. JMX
JMX（Java Management Extensions，Java 管理扩展）提供了内置的工具，使您能够监视和管理 Java VM。要启用远程系统的监视和管理，在启动 Java VM 时，您需要设置系统属性`com.sun.management.jmxremote.port`（要启用 JMX RMI 连接的端口号）。详见:[official documentation](http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html). 从历史上看，除了上面提到的端口之外，JMX 还会打开两个附加的随机 TCP 侦听端口，这可能会导致端口冲突问题。详见: [HBASE-10289](https://issues.apache.org/jira/browse/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 相同）。
## 10\. 动态配置
你可以在不重新启动服务器的情况下更改配置的子集。在 HBase shell 中，有新的操作符，`update_config` 以及 `update_all_config`，它们会提示服务器或所有服务器重新加载配置。
当前正在运行的服务器中，只能更改所有配置的子集。以下是这些支持动态更改的配置：
| Key |
| ------------------------------------------------------------ |
| hbase.ipc.server.fallback-to-simple-auth-allowed |
| hbase.cleaner.scan.dir.concurrent.size |
| hbase.regionserver.thread.compaction.large |
| hbase.regionserver.thread.compaction.small |
| hbase.regionserver.thread.split |
| hbase.regionserver.throughput.controller |
| hbase.regionserver.thread.hfilecleaner.throttle |
| hbase.regionserver.hfilecleaner.large.queue.size |
| hbase.regionserver.hfilecleaner.small.queue.size |
| hbase.regionserver.hfilecleaner.large.thread.count |
| hbase.regionserver.hfilecleaner.small.thread.count |
| hbase.regionserver.hfilecleaner.thread.timeout.msec |
| hbase.regionserver.hfilecleaner.thread.check.interval.msec |
| hbase.regionserver.flush.throughput.controller |
| hbase.hstore.compaction.max.size |
| hbase.hstore.compaction.max.size.offpeak |
| hbase.hstore.compaction.min.size |
| hbase.hstore.compaction.min |
| hbase.hstore.compaction.max |
| hbase.hstore.compaction.ratio |
| hbase.hstore.compaction.ratio.offpeak |
| hbase.regionserver.thread.compaction.throttle |
| hbase.hregion.majorcompaction |
| hbase.hregion.majorcompaction.jitter |
| hbase.hstore.min.locality.to.skip.major.compact |
| hbase.hstore.compaction.date.tiered.max.storefile.age.millis |
| hbase.hstore.compaction.date.tiered.incoming.window.min |
| hbase.hstore.compaction.date.tiered.window.policy.class |
| hbase.hstore.compaction.date.tiered.single.output.for.minor.compaction |
| hbase.hstore.compaction.date.tiered.window.factory.class |
| hbase.offpeak.start.hour |
| hbase.offpeak.end.hour |
| hbase.oldwals.cleaner.thread.size |
| hbase.oldwals.cleaner.thread.timeout.msec |
| hbase.oldwals.cleaner.thread.check.interval.msec |
| hbase.procedure.worker.keep.alive.time.msec |
| hbase.procedure.worker.add.stuck.percentage |
| hbase.procedure.worker.monitor.interval.msec |
| hbase.procedure.worker.stuck.threshold.msec |
| hbase.regions.slop |
| hbase.regions.overallSlop |
| hbase.balancer.tablesOnMaster |
| hbase.balancer.tablesOnMaster.systemTablesOnly |
| hbase.util.ip.to.rack.determiner |
| hbase.ipc.server.max.callqueue.length |
| hbase.ipc.server.priority.max.callqueue.length |
| hbase.ipc.server.callqueue.type |
| hbase.ipc.server.callqueue.codel.target.delay |
| hbase.ipc.server.callqueue.codel.interval |
| hbase.ipc.server.callqueue.codel.lifo.threshold |
| hbase.master.balancer.stochastic.maxSteps |
| hbase.master.balancer.stochastic.stepsPerRegion |
| hbase.master.balancer.stochastic.maxRunningTime |
| hbase.master.balancer.stochastic.runMaxSteps |
| hbase.master.balancer.stochastic.numRegionLoadsToRemember |
| hbase.master.loadbalance.bytable |
| hbase.master.balancer.stochastic.minCostNeedBalance |
| hbase.master.balancer.stochastic.localityCost |
| hbase.master.balancer.stochastic.rackLocalityCost |
| hbase.master.balancer.stochastic.readRequestCost |
| hbase.master.balancer.stochastic.writeRequestCost |
| hbase.master.balancer.stochastic.memstoreSizeCost |
| hbase.master.balancer.stochastic.storefileSizeCost |
| hbase.master.balancer.stochastic.regionReplicaHostCostKey |
| hbase.master.balancer.stochastic.regionReplicaRackCostKey |
| hbase.master.balancer.stochastic.regionCountCost |
| hbase.master.balancer.stochastic.primaryRegionCountCost |
| hbase.master.balancer.stochastic.moveCost |
| hbase.master.balancer.stochastic.maxMovePercent |
| hbase.master.balancer.stochastic.tableSkewCost |
- HBase™ 中文参考指南 3.0
- Preface
- Getting Started
- Apache HBase Configuration
- Upgrading
- The Apache HBase Shell
- Data Model
- HBase and Schema Design
- RegionServer Sizing Rules of Thumb
- HBase and MapReduce
- Securing Apache HBase
- Architecture
- In-memory Compaction
- Backup and Restore
- Synchronous Replication
- Apache HBase APIs
- Apache HBase External APIs
- Thrift API and Filter Language
- HBase and Spark
- Apache HBase Coprocessors
- Apache HBase Performance Tuning
- Troubleshooting and Debugging Apache HBase
- Apache HBase Case Studies
- Apache HBase Operational Management
- Building and Developing Apache HBase
- Unit Testing HBase Applications
- Protobuf in HBase
- Procedure Framework (Pv2): HBASE-12439
- AMv2 Description for Devs
- ZooKeeper
- Community
- Appendix