第二章：Hbase配置--Apache HBase TM Reference Guide
本章对“入门”一章进行了扩展，以进一步说明Apache HBase的配置。 请仔细阅读本章，特别是基本先决条件，以确保您的HBase测试和部署顺利进行。 熟悉支持和测试期望。
配置文件
Apache HBase使用与Apache Hadoop相同的配置系统。所有配置文件都位于conf /目录中，需要为群集中的每个节点保持同步。
HBase配置文件描述
-
backup-masters
默认情况下不存在。一个纯文本文件，列出主服务器应在其上启动备份主进程的主机，每行一个主机。 -
hadoop-metrics2-hbase.properties
用于连接HBase Hadoop的Metrics2框架。有关Metrics2的更多信息，请参阅Hadoop Wiki条目。默认情况下仅包含已注释掉的示例。 -
hbase-env.cmd和hbase-env.sh
用于Windows和Linux / Unix环境的脚本，用于设置HBase的工作环境，包括Java，Java选项和其他环境变量的位置。该文件包含许多注释掉的示例以提供指导。 -
HBase-policy.xml
RPC服务器用于对客户端请求进行授权决策的默认策略配置文件。仅在启用HBase安全性时使用。 -
HBase-site.xml
主要的HBase配置文件。此文件指定覆盖HBase默认配置的配置选项。您可以在docs / hbase-default.xml中查看（但不要编辑）默认配置文件。您还可以在HBase Web UI的HBase配置选项卡中查看群集的整个有效配置（默认值和覆盖）。 -
log4j.properties
通过log4j进行HBase日志记录的配置文件。 -
regionservers
一个纯文本文件，包含应在HBase集群中运行RegionServer的主机列表。默认情况下，此文件包含单个条目localhost。它应包含主机名或IP地址列表，每行一个，并且如果群集中的每个节点将在其localhost接口上运行RegionServer，则应仅包含localhost。
编辑XML时，最好使用支持XML的编辑器来确保语法正确并且XML格式正确。您还可以使用xmllint实用程序检查XML是否格式正确。默认情况下，xmllint重新流动并将XML打印到标准输出。要检查格式是否正确并且仅在出现错误时打印输出，请使用命令xmllint -noout filename.xml。
在分布式模式下运行时，在对HBase配置进行编辑后，请确保将conf /目录的内容复制到群集的所有节点。 HBase不会为你做这件事。 使用rsync，scp或其他安全机制将配置文件复制到节点。 对于大多数配置，服务器需要重新启动才能获取更改。 动态配置是一个例外，将在下面描述。
基本条件
本节列出了所需的服务和一些必需的系统配置。
Java
下表总结了在各种Java版本上部署的HBase社区的建议。符号表示测试的基本级别，以及帮助诊断和解决可能遇到的问题的意愿。 类似地，x或entry的条目通常意味着如果您遇到问题，社区可能会要求您在继续提供帮助之前更改Java环境。 在某些情况下，还将注意到有关限制的具体指导（例如，编制/单元测试工作，具体操作问题等）。
HBase建议下游用户依赖于OpenJDK项目或供应商标记为长期支持（LTS）的JDK版本。 截至2018年3月，这意味着Java 8是唯一适用的版本，下一个可能的测试版本将是2018年第三季度的Java 11。
HBase既不会构建也不会运行Java 6。
您必须在群集的每个节点上设置JAVA_HOME。 hbase-env.sh提供了一个方便的机制来执行此操作。
操作系统实用程序
-
SSH
HBase广泛使用Secure Shell（ssh）命令和实用程序在集群节点之间进行通信。 群集中的每个服务器都必须运行ssh，以便可以管理Hadoop和HBase守护程序。 您必须能够使用共享密钥而不是密码通过SSH（包括本地节点）从主服务器以及任何备份主服务器连接到所有节点。 您可以在“过程：配置无密码SSH访问”中查看Linux或Unix系统中此类设置的基本方法。 如果您的群集节点使用OS X，请参阅Hadoop wiki上的SSH：设置远程桌面和启用自我登录部分。 -
DNS
HBase使用本地主机名自我报告其IP地址。 -
NTP
群集节点上的时钟应该同步。少量的变化是可以接受的，但是更大量的偏斜会导致不稳定和意外的行为。如果您在群集中看到无法解释的问题，则首先要检查时间同步。建议您在群集上运行网络时间协议（NTP）服务或其他时间同步机制，并且所有节点都会查找同一服务以进行时间同步。请参阅Linux文档项目（TLDP）中的基本NTP配置以设置NTP。
- 文件和进程数限制（ulimit）
Apache HBase是一个数据库。它需要能够一次打开大量文件。许多Linux发行版将允许单个用户打开的文件数限制为1024（在旧版OS X上为256）。当以运行HBase的用户身份登录时，可以通过运行命令ulimit -n来检查服务器上的此限制。如果限制太低，请参阅“故障排除”部分，了解可能遇到的一些问题。您可能还会注意到以下错误：
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日志的第一行。
要在Ubuntu上配置ulimit设置，请编辑/etc/security/limits.conf，这是一个包含四列的空格分隔文件。 有关此文件格式的详细信息，请参阅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 shell。 -
Windows
建议不要在Windows机器上运行生产系统。
Hadoop
下表总结了每个HBase版本支持的Hadoop版本。 未出现在此表中的较旧版本被视为不受支持且可能缺少必要的功能，而较新版本未经测试但可能适用。
根据HBase的版本，您应该选择最合适的Hadoop版本。 您可以使用Apache Hadoop或供应商的Hadoop发行版。 这里没有区别。 有关Hadoop供应商的信息，请参阅Hadoop wiki。
Hadoop 2.x速度更快，并且包含一些功能，例如短路读取（请参阅利用本地数据），这将有助于改善HBase随机读取配置文件。 Hadoop 2.x还包含重要的错误修复程序，可以改善您的整体HBase体验。 HBase不支持与早期版本的Hadoop一起运行。 有关不同HBase版本的特定要求，请参阅下表。
Hadoop 3.x仍处于早期访问版本中，尚未经过HBase社区对生产用例的充分测试。
在Kerberos环境中使用2.6.1之前的Hadoop版本和JDK 1.8时，由于Kerberos keytab relogin错误，HBase服务器可能会失败并中止。 JDK 1.7（1.7.0_80）的后期版本也存在问题。 有关其他详细信息，请参阅HADOOP-10786。 在这种情况下，请考虑升级到Hadoop 2.6.1+。
如果您计划在HDFS加密区域之上运行HBase，则基于2.6.x行的Hadoop发行版必须应用HADOOP-11710。 如果不这样做，将导致群集故障和数据丢失。 该补丁存在于Apache Hadoop 2.6.1+版本中。
从Hadoop版本2.7.0开始，Hadoop PMC养成了在主要版本2发行版上调用新的次要版本的习惯，因为它们不稳定/生产就绪。因此，HBase明确建议下游用户避免在这些版本之上运行。请注意，Hadoop PMC另外发布了2.8.1版本。有关参考，请参阅Apache Hadoop 2.7.0，Apache Hadoop 2.8.0，Apache Hadoop 2.8.1和Apache Hadoop 2.9.0的发布公告。
包含应用程序时间线服务功能的Hadoop发行版可能会导致应用程序类路径中出现意外版本的HBase类。计划使用HBase运行MapReduce应用程序的用户应确保YARN-7190存在于其YARN服务中（目前已在2.9.1+和3.1.0+中修复）。
Hadoop PMC称3.1.0版本不稳定/生产就绪。因此，HBase明确建议下游用户避免在此版本之上运行。有关参考，请参阅 Hadoop 3.1.0的发布公告。
因为HBase依赖于Hadoop，所以它将Hadoop jar捆绑在其lib目录下。捆绑的罐子仅用于独立模式。在分布式模式下，群集上的Hadoop版本与HBase下的版本匹配至关重要。将HBase lib目录中的hadoop jar替换为您在群集上运行的版本中的等效hadoop jar，以避免版本不匹配问题。确保在整个群集中替换HBase下的jar。 Hadoop版本不匹配问题有各种表现形式。如果HBase出现挂起，请检查是否不匹配。
- dfs.datanode.max.transfer.threads
HDFS DataNode具有任何时候将服务的文件数量的上限。 在进行任何加载之前，请确保已配置Hadoop的conf / hdfs-site.xml，并将dfs.datanode.max.transfer.threads值设置为至少以下值：
<property>
<name>dfs.datanode.max.transfer.threadsname>
<value>4096value>
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并注意此属性以前称为dfs.datanode.max.xcievers（例如Hadoop HDFS: Deceived by Xciever）。
ZooKeeper Requirements
ZooKeeper 3.4.x is required.
HBase运行模式：独立和分布式
HBase有两种运行模式：独立模式和分布式模式。 开箱即用，HBase以独立模式运行。 无论您的模式是什么，您都需要通过编辑HBase conf目录中的文件来配置HBase。 至少，您必须编辑conf / hbase-env.sh以告知HBase使用哪个java。 在此文件中，您可以设置HBase环境变量，例如JVM的heapsize和其他选项，日志文件的首选位置等。将JAVA_HOME设置为指向java安装的根目录。
独立HBase
这是默认模式。 独立模式是快速入门部分中描述的内容。 在独立模式下，HBase不使用HDFS - 它使用本地文件系统 - 它在同一个JVM中运行所有HBase守护进程和本地ZooKeeper。 ZooKeeper与知名人士结合
- 独立HBase over HDFS
独立hbase的一个有时有用的变体是所有守护进程在一个JVM内部运行，而不是持久存储到本地文件系统，而是持久存储到HDFS实例。
当您想要一个简单的部署配置文件时，您可能会考虑此配置文件，加载很轻，但数据必须在节点的运行中保持不变。 写入复制数据的HDFS可确保后者。
要配置此独立变量，请编辑hbase-site.xml设置hbase.rootdir以指向HDFS实例中的目录，但随后将hbase.cluster.distributed设置为false。 例如：
<configuration>
<property>
<name>hbase.rootdirname>
<value>hdfs://namenode.example.org:8020/hbasevalue>
property>
<property>
<name>hbase.cluster.distributedname>
<value>falsevalue>
property>
configuration>
分布式
分布式模式可以细分为分布式，但所有守护进程都在单个节点上运行 - a.k.a.伪分布式 - 并且完全分布式，其中守护程序分布在集群中的所有节点上。 伪分布与完全分布的命名法来自Hadoop。
伪分布式模式可以针对本地文件系统运行，也可以针对Hadoop分布式文件系统（HDFS）的实例运行。 完全分布式模式只能在HDFS上运行。 有关如何设置HDFS的信息，请参阅Hadoop文档。 可以在http://www.alexjf.net/blog/distributed-systems/hadoop-yarn-installation- definitive-guide上找到在Hadoop 2上设置HDFS的良好演练。
- 伪分布式
伪分布式模式只是在单个主机上运行的完全分布式模式。使用此HBase配置仅用于测试和原型设计。请勿将此配置用于生产或性能评估。
完全分布式
默认情况下，HBase以独立模式运行。提供独立模式和伪分布模式都是为了进行小规模测试。对于生产环境，建议使用分布式模式。在分布式模式下，HBase守护程序的多个实例在群集中的多个服务器上运行。
与伪分布式模式一样，完全分布式配置要求您将hbase.cluster.distributed属性设置为true。通常，hbase.rootdir配置为指向高可用性HDFS文件系统。
此外，还配置了群集，以便多个群集节点登记为RegionServers，ZooKeeper QuorumPeers和备份HMaster服务器。这些配置基础知识都在快速入门 - 完全分布式中进行了演示。
- 分布式RegionServers
通常，您的群集将包含多个在不同服务器上运行的RegionServers，以及主要和备份Master和ZooKeeper守护程序。主服务器上的conf / regionservers文件包含RegionServers与此集群关联的主机列表。每个主机都在一个单独的行上。当主服务器启动或停止时，此文件中列出的所有主机都将启动和停止其RegionServer进程。
- ZooKeeper和HBase
有关HBase的ZooKeeper设置说明，请参阅ZooKeeper部分。
这是分布式HBase集群的简单conf / hbase-site.xml。 用于实际工作的集群将包含更多自定义配置参数。 大多数HBase配置指令都有默认值，除非在hbase-site.xml中覆盖该值，否则将使用这些默认值。 有关更多信息，请参阅“配置文件”。
<configuration>
<property>
<name>hbase.rootdirname>
<value>hdfs://namenode.example.org:8020/hbasevalue>
property>
<property>
<name>hbase.cluster.distributedname>
<value>truevalue>
property>
<property>
<name>hbase.zookeeper.quorumname>
<value>node-a.example.com,node-b.example.com,node-c.example.comvalue>
property>
configuration>
这是一个示例conf / regionservers文件，其中包含应在群集中运行RegionServer的节点列表。 这些节点需要安装HBase，并且需要使用与主服务器相同的conf /目录内容
``bash
node-a.example.com
node-b.example.com
node-c.example.com
这是一个示例conf / backup-masters文件，其中包含应运行备份主实例的每个节点的列表。 除非主Master变为不可用，否则备份Master实例将处于空闲状态。
```bash
node-b.example.com
node-c.example.com
- 分布式HBase快速入门
有关多个ZooKeeper，备份HMaster和RegionServer实例的简单三节点群集配置的详细信息，请参阅quickstart-full-distributed。
过程：HDFS客户端配置
- 值得注意的是，如果您在Hadoop集群上进行了HDFS客户端配置更改（例如HDFS客户端的配置指令），而不是服务器端配置，则必须使用以下方法之一来启用HBase以查看和使用这些配置配置更改：
将指向HADOOP_CONF_DIR的指针添加到hbase-env.sh中的HBASE_CLASSPATH环境变量中。
在$ {HBASE_HOME}/ conf下添加hdfs-site.xml（或hadoop-site.xml）或更好的符号链接的副本，或者
如果只有一小部分HDFS客户端配置，请将它们添加到hbase-site.xml。
这种HDFS客户端配置的一个示例是dfs.replication。例如，如果要以复制因子5运行，HBase将创建默认值为3的文件，除非您执行上述操作以使配置可用于HBase。
运行和确认你的安装
hdfs.sh在HADOOP_HOME目录中结束。 您可以通过测试文件的放入和获取到Hadoop文件系统来确保它正确启动。 HBase通常不使用MapReduce或YARN守护进程。 这些不需要启动。
如果您正在管理自己的ZooKeeper，请启动它并确认它正在运行，否则HBase将为您启动ZooKeeper作为其启动过程的一部分。
使用以下命令启动HBase：
bin/start-hbase.sh
从HBASE_HOME目录运行以上命令。
您现在应该有一个正在运行的HBase实例。 可以在logs子目录中找到HBase日志。特别是如果HBase启动有问题，请检查它们。
HBase还提供了一个列出重要属性的UI。 默认情况下，它部署在主机主机端口16010上（HBase RegionServers默认侦听端口16020，并在端口16030上建立信息HTTP服务器）。 如果主服务器在默认端口上名为master.example.org的主机上运行，请将浏览器指向http://master.example.org:16010以查看Web界面。
HBase启动后，请参阅shell练习部分，了解如何创建表，添加数据，扫描插入，最后禁用和删除表。
退出HBase shell后停止HBase进入
$ ./bin/stop-hbase.sh
stopping hbase...............
关机可能需要一些时间才能完成。 如果您的群集由许多计算机组成，则可能需要更长时间。 如果您正在运行分布式操作，请务必等到HBase完全关闭后再停止Hadoop守护程序。
默认配置
以下文档是使用默认的hbase配置文件hbase-default.xml作为源生成的。
-
hbase.tmp.dir
- 描述
- 本地文件系统上的临时目录。将此设置更改为指向比’/ tmp’更永久的位置，这是java.io.tmpdir的常用解决方案，因为’/ tmp’目录在机器重启时被清除。
- 默认
$ {java.io.tmpdir} / HBase的 - $ {user.name}
-
hbase.rootdir
- 描述
- 区域服务器共享的目录以及HBase持久存在的目录。 URL应该是“完全限定的”以包含文件系统方案。例如，要在端口9000上的namenode.example.org上指定HDFS实例的namenode运行的HDFS目录“/ hbase”，请将此值设置为：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.c
leaner.TimeToLiveProcedureWALCleaner
-
hbase.master.logcleaner.ttl
- 描述
- WAL保留在归档（{hbase.rootdir} / oldWALs）目录中多长时间，之后将由主线程清理。该值以毫秒为单位。
- 默认 600000
-
hbase.master.procedurewalcleaner.ttl
- 描述
- 过程WAL将保留在归档目录中多长时间，之后将由主线程清除。该值以毫秒为单位。
- 默认 604800000
-
hbase.master.hfilecleaner.plugins
- 描述
- 由HFileCleaner服务调用的以逗号分隔的BaseHFileCleanerDelegate列表。这些HFiles清洁剂按顺序调用，因此将清洁剂放在前面修剪最多的文件。要实现自己的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服务器。配置。当Master服务区域时（而不是默认值），这是有意义的。
- 默认true
-
hbase.master.fileSplitTimeout
描述
拆分区域，在中止尝试之前等待文件拆分步骤需要多长时间。默认值：600000。此设置曾在hbase-1.x中称为hbase.regionserver.fileSplitTimeout。 Split现在运行master-side因此重命名（如果找到’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侦听器实例的数量。 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个队列将包含两个读/写请求。 read.ratio为0.3意味着：3个队列仅包含读取请求，7个队列仅包含写入请求。 read.ratio为0.5意味着：5个队列仅包含读取请求，5个队列仅包含写入请求。 read.ratio为0.8意味着：8个队列仅包含读取请求，2个队列仅包含写入请求。 read.ratio为1表示：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个队列将包含长读取请求和短读取请求。 scan.ratio为0.3意味着：2个队列只包含长读请求，6个队列只包含短读请求。 scan.ratio为0.5意味着：4个队列只包含长读请求，4个队列只包含短读请求。 scan.ratio为0.8意味着：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％。当由于memstore限制而阻止更新时，此值的100％值会导致最小可能的刷新。此配置中的默认值有意留空，以便遵守旧的hbase.regionserver.global.memstore.lowerLimit属性（如果存在）。
- 默认 none
-
hbase.systemtables.compacting.memstore.type
- 描述
- 确定要用于系统表（如META，命名空间表等）的memstore类型。默认情况下，NONE是类型，因此我们对所有系统表使用默认memstore。如果我们需要对系统表使用压缩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客户端。 HBase在启动ZK服务器时也会使用它，并将其作为’maxSessionTimeout’传递。请参阅https://zookeeper.apache.org/ doc / 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
- 描述
- 用于访问控制列表的根ZNode。
- 默认ACL
-
hbase.zookeeper.dns.interface
- 描述
- ZooKeeper服务器应从中报告其IP地址的网络接口的名称。
- 默认 default
-
hbase.zookeeper.dns.nameserver
- 描述
- ZooKeeper服务器应使用的名称服务器（DNS）的主机名或IP地址，用于确定主服务器用于通信和显示目的的主机名。
- 默认 default
-
hbase.zookeeper.peerport
- 描述
- ZooKeeper对等体使用的端口相互通信。有关详细信息，请参阅https://zookeeper.apache.org/doc/r3.4.10/ zookeeperStarted.html＃sc_RunningReplicatedZooKeeper。
- 默认2888
-
hbase.zookeeper.leaderport
- 描述
- ZooKeeper用于领导者选举的端口。有关详细信息，请参阅https://zookeeper.apache.org/doc/r3.4.10/ zookeeperStarted.html＃sc_RunningReplicatedZooKeeper。
- 默认3888
hbase.zookeeper.property.initLimit
- 描述
- 来自ZooKeeper的配置zoo.cfg的属性。初始同步阶段可以采用的滴答数。
- 默认10
-
hbase.zookeeper.property.syncLimit
- 描述
- 来自ZooKeeper的配置zoo.cfg的属性。在发送请求和获取确认之间可以传递的滴答数。
- 默认 5
-
hbase.zookeeper.property.dataDir
- 描述
- 来自ZooKeeper的配置zoo.cfg的属性。存储快照的目录。
- 默认
$ {} hbase.tmp.dir /zookeeper
-
hbase.zookeeper.property.clientPort
- 描述
- 来自ZooKeeper的配置zoo.cfg的属性。客户端将连接的端口。
- 默认2181
等等…
hbase-env.sh
在此文件中设置HBase环境变量。 示例包括在HBase守护程序启动时传递JVM的选项，例如堆大小和垃圾收集器配置。 您还可以设置HBase配置，日志目录，niceness，ssh选项，查找进程pid文件的位置等的配置。在conf / hbase-env.sh中打开文件并仔细阅读其内容。 每个选项都有相当详细的记录。 如果您希望在启动时通过HBase守护程序读取它们，请在此处添加您自己的环境变量。
此处的更改将需要群集重新启动以使HBase注意到更改。
log4j.properties
编辑此文件以更改滚动HBase文件的速率并更改HBase的级别记录消息。
此处的更改将要求HBase重新启动群集以注意更改，但可以通过HBase UI更改特定守护程序的日志级别。
连接到HBase集群的客户端配置和依赖项
如果您在独立模式下运行HBase，则无需为客户端配置任何工作，只要它们都在同一台计算机上。
由于HBase Master可以移动，客户端通过向ZooKeeper查找当前关键位置来引导。 ZooKeeper是保存所有这些值的地方。 因此，客户端需要ZooKeeper集合的位置才能执行任何其他操作。 通常，此集合位置保留在hbase-site.xml中，并由客户端从CLASSPATH中获取。
如果要配置IDE以运行HBase客户端，则应在类路径中包含conf /目录，以便找到hbase-site.xml设置（或添加src / test / resources以获取所使用的hbase-site.xml） 通过测试）。
对于使用Maven的Java应用程序，在连接到集群时，建议使用hbase-shaded-client模块：
<dependency>
<groupId>org.apache.hbasegroupId>
<artifactId>hbase-shaded-clientartifactId>
<version>2.0.0version>
dependency>
仅客户端的基本示例hbase-site.xml可能如下所示：
<configuration>
<property>
<name>hbase.zookeeper.quorumname>
<value>example1,example2,example3value>
<description>The directory shared by region servers.
description>
property>
configuration>
- Java客户端配置
Java客户端使用的配置保存在HBaseConfiguration实例中。
HBaseConfiguration上的工厂方法，HBaseConfiguration.create（）;，在调用时，将读取客户端CLASSPATH上找到的第一个hbase-site.xml的内容（如果存在）（调用也将考虑任何hbase-default。 发现xml; hbase.XXXjar中有一个hbase-default.xml。 也可以直接指定配置，而无需从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实例传递给Table，依此类推。
超时设置
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安装
以下是分布式十节点集群的基本配置示例：*在此示例中，节点通过节点example9命名为example0，example1等。 * HBase Master和HDFS NameNode正在节点example0上运行。 * RegionServers在节点example1-example9上运行。 * 3节点ZooKeeper集合在默认端口上的example1，example2和example3上运行。 * ZooKeeper数据持久保存到目录/ export / zookeeper。
下面我们将展示在HBase conf目录中找到的主要配置文件 - hbase-site.xml，regionservers和hbase-env.sh。
hbase-site.xml
<configuration>
<property>
<name>hbase.zookeeper.quorumname>
<value>example1,example2,example3value>
<description>The directory shared by RegionServers.
description>
property>
<property>
<name>hbase.zookeeper.property.dataDirname>
<value>/export/zookeepervalue>
<description>Property from ZooKeeper config zoo.cfg.
The directory where the snapshot is stored.
description>
property>
<property>
<name>hbase.rootdirname>
<value>hdfs://example0:8020/hbasevalue>
<description>The directory shared by RegionServers.
description>
property>
<property>
<name>hbase.cluster.distributedname>
<value>truevalue>
<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>
regionservers
example1
example2
example3
example4
example5
example6
example7
example8
example9
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
重要配置
下面我们列出一些重要的配置。 我们已将此部分划分为所需的配置和值得推荐的配置。
必需的配置
查看os和hadoop部分。
大群集配置
如果您的群集包含许多区域，则在主服务器启动后，Regionserver可能会暂时检入，而所有剩余的RegionServers都会滞后。 将为所有要检入的服务器分配所有不是最佳的区域。 要防止出现上述情况，请将hbase.master.wait.on.regionservers.mintostart属性从其默认值1开始。请参阅HBASE- 6389修改条件以确保主服务器在启动区域之前等待足够数量的区域服务器 作业更详细。
推荐配置
ZooKeeper配置
zookeeper.session.timeout
默认超时为三分钟（以毫秒为单位）。这意味着如果服务器崩溃，将在Master发现崩溃并开始恢复之前三分钟。您可能需要将超时调整到一分钟甚至更短，以便Master更快地注意到故障。在更改此值之前，请确保您的JVM垃圾回收配置受到控制，否则，超过ZooKeeper会话超时的长垃圾回收将取消您的
RegionServer。 （你可能没问题 - 你可能希望恢复在服务器上启动，如果RegionServer已经在GC中存在很长一段时间）。
要更改此配置，请编辑hbase-site.xml，在集群中复制已更改的文件并重新启动。
我们将此值设置得很高，以避免我们不得不在邮件列表上提出问题，询问为什么RegionServer在大量导入过程中出现问题。通常的原因是他们的JVM未被调整，并且他们遇到了长时间的GC暂停。我们的想法是，当用户熟悉HBase时，我们会让他们不得不知道它的所有复杂性。后来当他们建立了一些信心时，他们就可以玩这样的配置了。
HDFS配置
dfs.datanode.failed.volumes.tolerated
这是“…在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.
有关更多信息，请参阅压缩
配置WAL文件的大小和数量
HBase使用wal来恢复在RS出现故障时尚未刷新到磁盘的memstore数据。这些WAL文件应配置为略小于HDFS块（默认情况下，HDFS块为64Mb，WAL文件为~60Mb）。
HBase还对WAL文件的数量有限制，旨在确保在恢复期间永远不会有太多需要重放的数据。需要根据memstore配置设置此限制，以便所有必需的数据都适合。建议分配足够的WAL文件来存储至少那么多数据（当所有存储库都接近满时）。例如，对于16Gb RS堆，默认memstore设置（0.4）和默认WAL文件大小（~60Mb），16Gb * 0.4 / 60，WAL文件计数的起点为~109。但是，由于预计所有的memstore都不会一直填满，因此可以分配更少的WAL文件。
管理分裂
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找到你要分割的位置。手动拆分可以减轻区域创建和负载下的移动。它还使得区域边界已知并且不变（如果禁用区域分割）。如果使用手动拆分，则更容易进行交错的，基于时间的主要压缩以分散网络IO负载。
禁用自动拆分
要禁用自动拆分，可以在集群配置或表配置中将区域拆分策略设置为org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy
如果禁用自动拆分以诊断问题或在数据快速增长期间，建议在情况变得更稳定时重新启用它们。管理区域自身分裂的潜在好处并非无可争议。
确定预分割区域的最佳数量
预分割区域的最佳数量取决于您的应用和环境。一个好的经验法则是从每个服务器的10个预分割区域开始，并观察数据随时间的增长。最好是在太少的区域一边犯错，然后再进行滚动拆分。最佳区域数取决于您所在地区最大的StoreFile。如果数据量增加，则最大StoreFile的大小将随时间增加。目标是使最大区域足够大，使得压缩选择算法仅在定时主要压缩期间压缩它。否则，群集可能容易压缩暴风雨，同时压缩大量区域。重要的是要了解数据增长导致压缩风暴而不是手动拆分决策。
如果将区域拆分为太多大区域，则可以通过配置HConstants.MAJOR_COMPACTION_PERIOD来增加主要压缩间隔。org.apache.hadoop.hbase.util.RegionSplitter实用程序还提供所有区域的网络IO安全滚动拆分。
管理的压缩
默认情况下，主要压缩计划在7天内运行一次。
如果您需要准确控制主要压缩的运行时间和频率，则可以禁用托管主要压缩。有关详细信息，请参阅compaction.parameters表中的hbase.hregion.majorcompaction条目。
StoreFile清理绝对需要主要的压缩。不要完全禁用它们。您可以通过HBase shell或Admin API手动运行主要压缩。
有关压缩和压缩文件选择过程的更多信息，请参见压缩
Speculative Execution
默认情况下，MapReduce任务的推测执行处于启用状态，对于HBase群集，通常建议在系统级别关闭“推测执行”，除非您针对特定情况需要它，可以按工作进行配置。将属性mapreduce.map.speculative和mapreduce.reduce.speculative设置为false。
其他配置
平衡器
平衡器是一个定期操作，在主服务器上运行以重新分配集群上的区域。它通过hbase.balancer.period配置，默认为300000（5分钟）。
有关LoadBalancer的更多信息，请参阅master.processes.loadbalancer。
禁用Blockcache
不要关闭块缓存（您可以通过将hfile.block.cache.size设置为零来实现）。目前我们做得不好，因为RegionServer将花费所有时间一遍又一遍地加载HFile指数。如果您的工作集使得块缓存没有用，那么至少调整块缓存大小以使HFile索引保持在缓存中（您可以通过调查RegionServer UI来大致了解所需的大小;您将会看到索引块大小占据网页顶部附近）。
Nagle或小包装问题
如果在针对HBase的操作中出现大约40ms左右的偶然延迟，请尝试Nagles的设置。例如，请参阅用户邮件列表线程，将缓存设置为1的不一致扫描性能以及其中引用的问题，其中设置notcpdelay可提高扫描速度。您可能还会看到HBASE-7008尾部的图形将扫描仪缓存设置为更好的默认值，我们的Lars Hofhansl尝试各种数据大小w / Nagle开启和关闭测量效果。
更好的平均恢复时间（MTTR）
本节介绍的配置将使服务器在发生故障后恢复得更快。 请参阅Deveraj Das和Nicolas Liochon博客文章HBase平均恢复时间简介（MTTR）的简要介绍。
问题HBASE-8354迫使Namenode进入具有租约恢复请求的循环是一个混乱的问题，但在低超时时有一堆很好的讨论，以及如何引起更快的恢复，包括引入添加到HDFS的修复程序。 阅读Varun Sharma的评论。 以下建议的配置是Varun的建议，经过提炼和测试。 确保你在最新版本的HDFS上运行，这样你就可以获得他所引用的修复程序，并自己添加到帮助HBase MTTR的HDFS（例如HDFS-3703，HDFS-3712和HDFS-4791 - Hadoop 2肯定有它们和 迟到的Hadoop 1有一些）。 在RegionServer中设置以下内容。
<property>
<name>hbase.lease.recovery.dfs.timeoutname>
<value>23000value>
<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-timeoutname>
<value>10000value>
<description>Down the DFS timeout from 60 to 10 seconds.description>
property>
<property>
<name>dfs.client.socket-timeoutname>
<value>10000value>
<description>Down the DFS timeout from 60 to 10 seconds.description>
property>
<property>
<name>dfs.datanode.socket.write.timeoutname>
<value>10000value>
<description>Down the DFS timeout from 8 * 60 to 10 seconds.description>
property>
<property>
<name>ipc.client.connect.timeoutname>
<value>3000value>
<description>Down from 60 seconds to 3.description>
property>
<property>
<name>ipc.client.connect.max.retries.on.timeoutsname>
<value>2value>
<description>Down from 45 seconds to 3 (2 == 3 retries).description>
property>
<property>
<name>dfs.namenode.avoid.read.stale.datanodename>
<value>truevalue>
<description>Enable stale state in hdfsdescription>
property>
<property>
<name>dfs.namenode.stale.datanode.intervalname>
<value>20000value>
<description>Down from default 30 secondsdescription>
property>
<property>
<name>dfs.namenode.avoid.write.stale.datanodename>
<value>truevalue>
<description>Enable stale state in hdfsdescription>
property>
JMX
JMX（Java Management Extensions）提供了内置的工具，使您可以监视和管理Java VM。 要从远程系统启用监视和管理，需要在启动Java VM时设置系统属性com.sun.management.jmxremote.port（要通过其启用JMX RMI连接的端口号）。 有关更多信息，请参阅官方文档。 从历史上看，除了上面提到的端口之外，JMX还会打开两个额外的随机TCP侦听端口，这可能会导致端口冲突问题。 （详见HBASE-10289）
作为替代方案，您可以使用HBase提供的基于协处理器的JMX实现。 要启用它，请在hbase-site.xml中添加以下属性：
<property>
<name>hbase.coprocessor.regionserver.classesname>
<value>org.apache.hadoop.hbase.JMXListenervalue>
property>
不要同时为Java VM设置com.sun.management.jmxremote.port。
动态配置
可以在不需要重新启动服务器的情况下更改配置的子集。 在HBase shell中，操作update_config和update_all_config将提示服务器或所有服务器重新加载配置。
当前只能在正在运行的服务器中更改所有配置的子集。 以下是这些配置：
表3.配置支持动态更改
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