hbase 单机 修改ZK绑定的ip地址

HBase 概述

HBase是Apache的Hadoop项目的子项目，是Hadoop Database的简称。

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。

HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。

HBase是Hadoop的生态系统，是建立在Hadoop文件系统（HDFS）之上的分布式、面向列的数据库，通过利用Hadoop的文件系统提供容错能力。如果你需要进行实时读写或者随机访问大规模的数据集的时候，请考虑使用HBase！

HBase作为Google Bigtable的开源实现，Google Bigtable利用GFS作为其文件存储系统类似，则HBase利用Hadoop HDFS作为其文件存储系统；Google通过运行MapReduce来处理Bigtable中的海量数据，同样，HBase利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。

HBase处理数据

虽然Hadoop是一个高容错、高延时的分布式文件系统和高并发的批处理系统，但是它不适用于提供实时计算；HBase是可以提供实时计算的分布式数据库，数据被保存在HDFS分布式文件系统上，由HDFS保证期高容错性，但是再生产环境中，HBase是如何基于hadoop提供实时性呢？ HBase上的数据是以StoreFile(HFile)二进制流的形式存储在HDFS上block块儿中；但是HDFS并不知道的HBase用于存储什么，它只把存储文件认为是二进制文件，也就是说，HBase的存储数据对于HDFS文件系统是透明的。

HBase与HDFS

在下面的表格中，我们对HDFS与HBase进行比较：

HDFS	HBase
HDFS适于存储大容量文件的分布式文件系统。	HBase是建立在HDFS之上的数据库。
HDFS不支持快速单独记录查找。	HBase提供在较大的表快速查找
HDFS提供了高延迟批量处理;没有批处理概念。	HBase提供了数十亿条记录低延迟访问单个行记录（随机存取）。
HDFS提供的数据只能顺序访问。	HBase内部使用哈希表和提供随机接入，并且其存储索引，可将在HDFS文件中的数据进行快速查找。

HBase 数据模型

HBase通过表格的模式存储数据，每个表格由列和行组成，其中，每个列又被划分为若干个列族（row family），请参考下面的图：

现在我们来看看HBase的逻辑数据模型与物理数据模型（实际存储的数据模型）：

逻辑数据模型：

物理数据模型：

HBase 架构

下图显示了HBase的组成结构：

通过上图我们可以得出Hbase中的每张表都按照一定的范围被分割成多个子表（HRegion），默认一个HRegion超过 256M 就要被分割成两个，由 HRegionServer管理，管理哪些HRegion由HMaster分配。

现在我们来介绍一下HBase中的一些组成部件以及它们起到的作用：

• Client：包含访问HBase的接口，并维护cache来加快对HBase的访问。
• Zookeeper：HBase依赖Zookeeper，默认情况下HBase管理Zookeeper实例（启动或关闭Zookeeper），Master与RegionServers启动时会向Zookeeper注册。Zookeeper的作用如下：

• 保证任何时候，集群中只有一个master
• 存储所有Region的寻址入口
• 实时监控Region server的上线和下线信息。并实时通知给master
• 存储HBase的schema和table元数据

• HRegionServer：用来维护master分配给他的region，处理对这些region的io请求；负责切分正在运行过程中变的过大的region。
• HRegion：HBase表在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。Region按大小分隔，每个表一般是只有一个region，当region的某个列族达到一个阈值（默认256M）时就会分成两个新的region。
• Store：每一个Region由一个或多个Store组成，至少是一个Store，HBase会把一起访问的数据放在一个Store里面，即为每个ColumnFamily建一个Store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个memStore和0或者多个StoreFile组成。Store的大小被HBase用来判断是否需要切分Region。
• StoreFile：memStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。
• HLog：HLog记录数据的所有变更，可以用来恢复文件，一旦region server 宕机，就可以从log中进行恢复。
• LogFlusher：一个LogFlusher的类是用来调用HLog.optionalSync()的。

HBase 的应用

• HBase是用来当有需要写重的应用程序。
• HBase可以帮助快速随机访问数据。
• HBase被许多公司所采纳，例如，Facebook、Twitter、Yahoo!、Adobe、OpenPlaces、WorldLingo等等。 

快速启动HBase

HBase 入门——独立式HBase

在本节中，你将首先学习单节点、独立的HBase的设置，并且学会运行单节点、独立的HBase实例！

在一个独立的HBase实例中，它具有所有的HBase系统服务程序：Master、RegionServers 和 ZooKeeper（在一个持续到本地文件系统的单一 JVM 中运行）。这是我们最基本的部署配置文件。我们将向您展示如何使用 HBase shell CLI 在 HBase 中创建表，在表中插入行，对表执行放置和扫描操作，启用或禁用表，以及启动和停止 HBase。除了下载 HBase，只要10分钟就可以完成以下的操作。

JDK版本要求

HBase要求安装JDK。

HBase下载与启动

选择一个Apache 下载镜像，下载 HBase Releases。点击stable目录，然后下载后缀为.tar.gz的二进制文件到你的到本地文件系统；例如 hbase-0.95-SNAPSHOT.tar.gz。

解压下载的文件，然后进入到那个要解压的目录。

$ tar xfz hbase-0.95-SNAPSHOT.tar.gz
$ cd hbase-0.95-SNAPSHOT

在你启动HBase之前，需要先设置 JAVA_HOME 环境变量。您可以通过操作系统的常规机制来设置变量，但HBase提供了一个中心机制 conf/hbase-env.sh，编辑此文件，取消注释以下行JAVA_HOME，并将其设置为您的操作系统的适当位置，JAVA_HOME 变量应设置为包含可执行文件 bin/JAVA 的目录。大多数现代 Linux 操作系统都提供了一种机制，例如在 RHEL 或 CentOS 上的替代方法，用于在 Java 等可执行版本之间进行透明切换。在这种情况下，您可以将 JAVA_HOME 设置为包含指向 bin/JAVA 的符号链接的目录，这通常是：/usr。

JAVA_HOME = / USR

编辑conf/hbase-site.xml，这是HBase的主要配置文件。此时，您只需要在HBase和ZooKeeper写入数据的本地文件系统上指定目录即可。默认情况下，在/tmp下创建一个新目录。许多服务器被配置为在重启时删除/tmp的内容，所以你应该在其他地方存储数据。以下配置将把HBase的数据存储在hbase目录下的testuser用户主目录中。将<property>标签粘贴到标签下<configuration>，在新的HBase安装中应该是空的。

独立HBase的hbase-site.xml：

<configuration>
  <property>
    <name>hbase.rootdir</name>
    <value>file:///home/testuser/hbase</value>
  </property>
  <property>
    <name>hbase.zookeeper.property.dataDir</name>
    <value>/home/testuser/zookeeper</value>
  </property>
</configuration>

您不需要创建HBase数据目录，HBase会为你做这个。

注意：上述示例中的hbase.rootdir指向本地文件系统中的一个目录。'file：/'前缀是我们如何表示本地文件系统。要在现有的HDFS实例上安装HBase，请将hbase.rootdir设置为指向您实例上的目录：例如，hdfs：//namenode.example.org：8020/hbase。有关更多信息，请参见下面关于独立 HBase HDFS 的部分。

提供了bin/start-hbase.sh脚本来方便的启动HBase。发出命令，如果一切正常，则会将消息记录到标准输出，显示HBase已成功启动。您可以使用该jps命令来验证您是否有一个名为 HMaster 的正在运行的进程。在独立模式下，HBase在单个JVM中运行所有守护进程，即HMaster，单个HRegionServer和ZooKeeper守护进程。

为此，打开HBase主文件夹，然后运行HBase启动脚本，如下所示：

$cd /usr/local/HBase/bin
$./start-hbase.sh

如果一切顺利，当运行HBase启动脚本，它会提示一条消息：HBase已经启动

starting master, logging to /usr/local/HBase/bin/../logs/hbase-tpmaster-localhost.localdomain.out

提示：Java需要安装并可用。如果您得到一个错误，指示Java未安装，但它位于您的系统上（可能位于非标准位置），请编辑conf / hbase-env.sh文件，并将该JAVA_HOME设置修改为指向包含在你的系统上的bin/Java。

停止HBase

1. 与提供bin / start-hbase.sh脚本以便方便地启动所有HBase守护进程相同，你可以使用bin/stop-hbase.sh脚本停止它们。

$ ./bin/stop-hbase.sh
stopping hbase....................
$

1. 发出命令后，进程关闭可能需要几分钟的时间。使用jps要确保HMASTER和HRegionServer进程被关闭。

以上向您展示了如何启动和停止一个独立的HBase实例。在接下来的部分中，我们将简要介绍一下HBase部署的其他模式。

MAC安装HBase

/Users/myname/Downloads/hbase-2.3.6-bin.tar.gz 

mv ./hbase-2.3.6-bin.tar.gz /usr/local/etc/hbase.tar.gz

cd /usr/local/etc

tar -xvf hbase.tar.gz

mv hbase.tar.gz

cd hbase-2.3.6

which java

返回一串文本

/usr/local/opt/openjdk/bin/jav这个就是命令行里输入java最终执行的文件了，也就是说JAVA_HOME就是bin所在的目录，即：

/usr/local/opt/openjdk

编辑HBase的环境配置文件，找到JAVA_HOME，如下：

现在就可以尝试来启动它了，启动和关闭的脚本都在 bin 里面，分别是 start-hbase.sh 和 start-hbase.sh（Windows下的话应该是.cmd结尾的那两个，双击对应的文件即可），现在我们来启动它：

sh ./bin/start-hbase.sh

如果没有其它问题的话会返回类似以下的文本：

running master, logging to /usr/local/etc/hbase/hbase-2.3.6/bin/../logs/hbase-liuweitian-master-f01898644177.out

可以使用以下命令来停用：

sh ./bin/stop-hbase.sh

HBase安装

---

HBase有单机, 伪分布式, 全分布式运行模式

依赖:

• 匹配HBase的Hadoop版本
• Java JDK 1.6+
• SSH

安装

$ brew install hbase
# 安装在/usr/local/Cellar/hbase/1.0.0

配置HBase

在conf/hbase-env.sh设置JAVA_HOME

$ cd /usr/local/Cellar/hbase/1.0.0/libexec/conf
$ vim hbase-env.sh

export JAVA_HOME="/usr/bin/java"

在conf/hbase-site.xml设置HBase的核心配置

$ vim hbase-site.xml

<configuration>
  <property>
    <name>hbase.rootdir</name>
    //这里设置让HBase存储文件的地方
    <value>file:///Users/andrew_liu/Downloads/hbase</value>
  </property>
  <property>
    <name>hbase.zookeeper.property.dataDir</name>
    //这里设置让HBase存储内建zookeeper文件的地方
    <value>/Users/andrew_liu/Downloads/zookeeper</value>
  </property>
</configuration>

/usr/local/Cellar/hbase/1.0.0/bin/start-hbase.sh提供HBase的启动

$ ./start-hbase.sh                                          
starting master, logging to /usr/local/Cellar/hbase/1.0.0/libexec/bin/../logs/hbase-andrew_liu-master-Andrew-liudeMacBook-Pro.local.out

验证是否安装成功

$ jps

3440 Jps
3362 HMaster # 有HMaster则说明安装成功
1885

启动HBase Shell

$ ./bin/hbase shell

HBase Shell; enter 'help<RETURN>' for list of supported commands.
Type "exit<RETURN>" to leave the HBase Shell
Version 1.0.0, r6c98bff7b719efdb16f71606f3b7d8229445eb81, Sat Feb 14 19:49:22 PST 2015

1.8.7-p357 :001 >
1.8.7-p357 :001 > exit  #退出shell

停止HBase运行

$ ./bin/stop-hbase.sh
stopping hbase....................

3. 伪分布式模式

必须关闭HBase

修改hbase-env.sh

HBASE_MANAGE_XK = true

修改hbase-site.xml, 设置HBase使用分布式模式运行

<configuration>
  <property>
    <name>hbase.rootdir</name>
    //Here you have to set the path where you want HBase to store its files.
    <value>hdfs://localhost:8020/hbase</value>
  </property>
  <property>
    <name>hbase.cluster.distributed</name>
  <value>true</value>
</property>
</configuration>

hbase.rootdir路径一定要跟hadoop中core-site.xml中fs.default.name相同

change the hbase.rootdir from the local filesystem to the address of your HDFS instance ---offical quick start

如何两处设置不同会引起ERROR: Can't get master address from ZooKeeper; znode data == null错误错误

在启动HBase之前, 请先启动Hadoop, 使之运行

启动HBase

$ ./start-hbase.sh
$ jps  #验证是否启动成功, 包含HMaster和HRegionServer说明启动成功

6400 DataNode
7872 Jps
7702 HMaster  
7624 HQuorumPeer
6315 NameNode
6508 SecondaryNameNode
6716 NodeManager
7804 HRegionServerHBase 
6623 ResourceManager

如果在启动HBase后, 提示如下

regionserver running as process 4667. Stop it first.
#请执行以下操作
$ kill -9 4667  #这里4667是要杀掉的进程号

启动成功HBase会在HDFS下创建/hbase目录

$ hdfs dfs -ls /hbase

4. HBase Shell

---

$ hbase shell  #启动HBase Shell

#创建表
> create 'student', 'description', 'course'  #创建表名为student的表, 指明两个列名, 分别为description和course

#信息明细
> list 'student'  #列出list表信息

#插入数据
> put 'student', 'row1', 'description:age', '18'  #意思为在student表row1处插入description:age的数据为18
> put 'student', 'row1', 'description:name', 'liu'
put 'student', 'row1', 'course:chinese', '100'

#一次扫描所有数据
> scan 'student

#使表失效 / 有效
> disable 'student'
> enable 'student'

#删除表(要先disable)
>  drop 'student'

#退出shell
> quit

在伪分布式模式安装HBase

在通过快速启动HBase的独立模式工作之后，您可以重新配置HBase以伪分布式模式运行。伪分布模式意味着HBase仍然在单个主机上完全运行，但是每个HBase守护进程（HMaster，HRegionServer和ZooKeeper）作为一个单独的进程运行：在独立模式下，所有守护进程都运行在一个jvm进程/实例中。默认情况下，除非按照快速启动HBase的独立模式中所述配置hbase.rootdir属性，否则您的数据仍存储在/tmp/中。在本演练中，我们将数据存储在HDFS中，假设您有HDFS可用。您可以跳过HDFS配置，继续将数据存储在本地文件系统中。

Hadoop配置

此过程假定您已在本地系统或远程系统上配置Hadoop和HDFS，并且它们正在运行且可用。它还假定您正在使用Hadoop 2。

1. 请停止HBase，如果它正在运行。如果刚刚完成快速启动HBase的独立模式并且HBase仍在运行，请停止它。这个过程将创建一个全新的目录，HBase将存储它的数据，所以你之前创建的任何数据库都将丢失。
2. 配置HBase。编辑hbase-site.xml配置。首先，添加以下指示HBase以分布式模式运行的属性，每个守护进程有一个JVM实例。

<property>
  <name>hbase.cluster.distributed</name>
  <value>true</value> 
</property>

1. 接下来，将 hbase rootdir 从本地文件系统更改为您的 HDFS 实例的地址，使用 HDFS:////或 URI 语法。在这个例子中，HDFS在端口8020的本地主机上运行。

<property>
  <name>hbase.rootdir</name>
  <value>hdfs://localhost:8020/hbase</value> 
</property>

1. 启动 HBase。使用bin/start-hbase.sh命令启动HBase。如果您的系统配置正确，该jps命令应显示HMaster和HRegionServer进程正在运行。
2. 检查HDFS中的HBase目录。如果一切正常，HBase在HDFS中创建它的目录。在上面的配置中，它存储在HDFS上的/hbase/中。您可以使用 hadoop 的 bin/目录中的 hadoop fs 命令来列出此目录。

$ ./bin/hadoop fs -ls /hbase
Found 7 items
drwxr-xr-x   - hbase users          0 2014-06-25 18:58 /hbase/.tmp
drwxr-xr-x   - hbase users          0 2014-06-25 21:49 /hbase/WALs
drwxr-xr-x   - hbase users          0 2014-06-25 18:48 /hbase/corrupt
drwxr-xr-x   - hbase users          0 2014-06-25 18:58 /hbase/data
-rw-r--r--   3 hbase users         42 2014-06-25 18:41 /hbase/hbase.id
-rw-r--r--   3 hbase users          7 2014-06-25 18:41 /hbase/hbase.version
drwxr-xr-x   - hbase users          0 2014-06-25 21:49 /hbase/oldWALs

1. 创建一个表并使用数据填充它。您可以使用HBase Shell创建一个表，使用数据填充它，使用与shell练习中相同的步骤扫描并从中获取值。
2. 启动和停止备份HBase主（HMaster）服务器。

注意：在同一个硬件上运行多个HMaster实例在生产环境中是没有意义的，就像运行伪分布式集群对于生产没有意义一样。此步骤仅供测试和学习之用。

HMaster服务器控制HBase集群。你可以启动最多9个备份HMaster服务器，这个服务器总共有10个HMaster计算主服务器。要启动备份HMaster，请使用local-master-backup.sh。对于要启动的每个备份主节点，请添加一个表示该主节点的端口偏移量的参数。每个HMaster使用三个端口（默认情况下为16010,16020和16030）。端口偏移量被添加到这些端口，因此使用偏移量2，备份HMaster将使用端口16012,16022和16032。以下命令使用端口：16012/16022/16032，16013/16023/16033和16015/16025/16035启动3个备份服务器。

$ ./bin/local-master-backup.sh start 2 3 5

要在不杀死整个群集的情况下杀死备份主机，则需要查找其进程ID（PID）。PID存储在一个名为/tmp/hbase-USER-X-master.pid的文件中。该文件的唯一内容是PID。您可以使用该kill -9命令来杀死该PID。以下命令将终止具有端口偏移1的主服务器，但保持群集正在运行：

$ cat /tmp/hbase-testuser-1-master.pid |xargs kill -9

1. 启动和停止其他RegionServers。HRegionServer按照HMaster的指示管理StoreFiles中的数据。通常，一个HRegionServer在集群中的每个节点上运行。在同一个系统上运行多个HRegionServers对于伪分布式模式下的测试非常有用。该local-regionservers.sh命令允许您运行多个RegionServer。它以类似的local-master-backup.sh命令的方式工作，因为您提供的每个参数都代表实例的端口偏移量。每个RegionServer需要两个端口，默认端口是16020和16030。但是，由于HMaster使用默认端口，所以其他RegionServers的基本端口不是默认端口，而HMaster自从HBase版本1.0.0以来也是RegionServer。基本端口是16200和16300。您可以在服务器上运行另外99个不是HMaster或备份HMaster的RegionServer。以下命令将启动另外四个RegionServers，它们在从16202/16302（基本端口16200/16300加2）开始的顺序端口上运行。

$ .bin/local-regionservers.sh start 2 3 4 5

要手动停止RegionServer，请使用带有stop参数和服务器偏移量的local-regionservers.sh命令停止。

$ .bin/local-regionservers.sh stop 3

1. 停止HBase。您可以使用bin/stop-hbase.sh命令以与快速启动独立式HBase过程相同的方式停止HBase 。

在完全分布式模式测试HBase

实际上，您需要一个完全分布式的配置来全面测试HBase，并将其用于实际场景中。在分布式配置中，集群包含多个节点，每个节点运行一个或多个HBase守护进程。这些包括主要和备份主实例，多个ZooKeeper节点和多个RegionServer节点。

此高级快速入门将两个以上的节点添加到您的群集。架构如下：

节点名称	Master	ZooKeeper	RegionServer
node-a.example.com	是	是	没有
node-b.example.com	备用	是	是
node-c.example.com	没有	是	是

这个快速入门假定每个节点都是虚拟机，并且它们都在同一个网络上。它基于之前的快速入门、伪分布式本地安装，假设您在该过程中配置的系统是现在node-a。继续之前，在node-a停止HBase 。

提示：请确保所有节点都具有完全的通信访问权限，并且没有任何防火墙规则可以阻止它们相互交谈。如果您看到任何错误，如no route to host，请检查您的防火墙。

配置无密码SSH访问

node-a需要能够登录node-b和node-c（和自己）才能启动守护进程。实现这一点的最简单的方法是在所有主机上使用相同的用户名，并配置无密码的SSH登录，从node-a到其他的。

1. 在node-a，生成一个密钥对。以运行HBase的用户身份登录时，使用以下命令生成SSH密钥对：

$ ssh-keygen -t rsa

如果命令成功，密钥对的位置将打印到标准输出。公钥的默认名称是id_rsa.pub。

1. 创建将在其他节点上保存的共享密钥的目录。在node-b和上node-c，以HBase用户身份登录，并在用户主目录中创建一个.ssh/目录（如果尚不存在）。如果它已经存在，请注意它可能已经包含其他键。
2. 将公钥复制到其他节点。通过使用scp或其他一些安全的手段，安全地将公钥从node-a复制到每个节点。在其他每个节点上，创建一个名为.ssh/authorized_keys的新文件（如果该文件尚不存在），并将id_rsa.pub文件的内容附加到该文件的末尾。请注意，你也需要为node-a本身执行此项。

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

1. 测试无密码登录。如果您正确执行了此过程，则node-a在使用相同用户名从其他任一节点进行SSH连接时，不应提示您输入密码。
2. 由于node-b将运行备份主机，请重复上述过程，在你看到node-a的任何地方替换node-b。请确保不要覆盖现有的.ssh / authorized_keys文件，而是使用>>运算符，而不是>运算符将新密钥连接到现有文件。

准备 node-a

node-a将运行您的主要主服务器和ZooKeeper进程，但不运行RegionServers。从node-a停止启动RegionServer。

1. 编辑conf/regionservers并删除包含localhost的行。为node-b和node-c加入具有主机名或IP地址线。即使你想在node-a运行一个RegionServer，你也应该用其他服务器用来与之通信的主机名来引用它。在这种情况下，那将是node-a.example.com。这使您可以将配置分发给群集中的每个节点，而不会造成任何主机名冲突。保存文件。
2. 配置HBase以将node-b作为备份主机。在conf/调用backup-masters中创建一个新文件，并添加一个新的行，其中的主机名为node-b。在这个演示中，主机名是node-b.example.com。
3. 配置ZooKeeper。实际上，你应该仔细考虑你的ZooKeeper配置。您可以在zookeeper部分找到更多关于配置ZooKeeper的信息。这个配置将指示HBase在集群的每个节点上启动和管理一个ZooKeeper实例。在node-a上，编辑conf/hbase-site.xml并添加下列属性。

<property>
  <name>hbase.zookeeper.quorum</name>
  <value>node-a.example.com,node-b.example.com,node-c.example.com</value>
</property>
<property>
  <name>hbase.zookeeper.property.dataDir</name>
  <value>/usr/local/zookeeper</value>
</property>

1. 在您的配置中，您已经将node-a作为localhost引用，将引用改为指向其他节点用来引用node-a的主机名。在这些例子中，主机名是node-a.example.com。

准备 node-b 和 node-c

node-b 将运行一个备份主服务器和一个ZooKeeper实例。

1. 下载并解压HBase。将HBase下载并解压到node-b，就像您为独立和伪分布式快速入门所操作的一样。
2. 将配置文件从node-a复制到node-b和node-c。您的群集的每个节点都需要具有相同的配置信息。将conf /目录下的内容复制到node-b和node-c上的conf /目录中。

启动并测试群集

1. 确保HBase没有在任何节点上运行。如果您在之前的测试中忘记停止HBase，您将会遇到错误。通过使用该jps命令检查HBase是否在任何节点上运行。寻找HMaster，HRegionServer和HQuorumPeer的进程。如果他们存在，删除他们。
2. 启动群集。在node-a，发出start-hbase.sh命令。您的输出将类似于下面的输出。

$ bin/start-hbase.sh
node-c.example.com: starting zookeeper, logging to /home/hbuser/hbase-0.98.3-hadoop2/bin/../logs/hbase-hbuser-zookeeper-node-c.example.com.out
node-a.example.com: starting zookeeper, logging to /home/hbuser/hbase-0.98.3-hadoop2/bin/../logs/hbase-hbuser-zookeeper-node-a.example.com.out
node-b.example.com: starting zookeeper, logging to /home/hbuser/hbase-0.98.3-hadoop2/bin/../logs/hbase-hbuser-zookeeper-node-b.example.com.out
starting master, logging to /home/hbuser/hbase-0.98.3-hadoop2/bin/../logs/hbase-hbuser-master-node-a.example.com.out
node-c.example.com: starting regionserver, logging to /home/hbuser/hbase-0.98.3-hadoop2/bin/../logs/hbase-hbuser-regionserver-node-c.example.com.out
node-b.example.com: starting regionserver, logging to /home/hbuser/hbase-0.98.3-hadoop2/bin/../logs/hbase-hbuser-regionserver-node-b.example.com.out 
node-b.example.com: starting master, logging to /home/hbuser/hbase-0.98.3-hadoop2/bin/../logs/hbase-hbuser-master-nodeb.example.com.out

1. 验证进程是否正在运行。在群集的每个节点上，运行该jps命令并验证每台服务器上是否运行了正确的进程。如果用于其他用途，您可能会看到在您的服务器上运行的其他Java进程。 例子：node-a jps输出：

$ jps
20355 Jps
20071 HQuorumPeer 
20137 HMaster

1. 示例：node-b jps输出：

$ jps
15930 HRegionServer
16194 Jps
15838 HQuorumPeer 
16010 HMaster

1. 例子：node-c jps输出：

$ jps
13901 Jps
13639 HQuorumPeer 
13737 HRegionServer

1. 浏览到Web UI。Web UI端口更改Web UI端口更改在 HBase 更新的0.98.x 中，HBase Web UI使用的HTTP端口从主服务器的60010和每个RegionServer的60030变为主服务器的16010和RegionServer的16030。如果一切设置正确，您应该能够使用Web浏览器连接到Master（http://node-a.example.com:16010/）或Secondary Master的UI（http://node-b.example.com:16010/）。如果您可以通过localhost而不是从另一台主机连接，请检查您的防火墙规则。您可以在端口16030的IP地址中查看每个RegionServers的Web UI，也可以通过单击Master的Web UI中的链接来查看。
2. 测试节点或服务消失时会发生什么。在配置了三节点群集后，事情不会很有弹性。您仍然可以通过关闭进程并查看日志来测试主Master或RegionServer的行为。

Apache HBase配置

Apache HBase配置文件

本节是本章内容的开篇，我们首先来认识Apache 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的编辑器，以确保您的语法正确且XML格式良好。您还可以使用该xmllint实用程序检查您的XML格式是否正确。默认情况下，xmllint重新流动并将XML打印到标准输出。要检查格式是否正确，并且只在存在错误时才打印输出，请使用命令xmllint -noout filename.xml。

在群集之间保持同步配置

当在分布式模式下运行时, 在对HBase配置进行编辑后，请确保将conf/目录的内容复制到群集的所有节点。HBase不会为你这么做的。请使用 rsync、scp 或其他安全机制将配置文件复制到你的节点。对于大多数配置, 服务器需要重新启动才能成功更改。动态配置是这方面的一个例外，在之后的内容将对此进行说明。

HBase基础条件

2021-02-25 15:08 更新

在本节中，我们列出了使用HBase时所需要的服务和一些必需的系统配置。

安装Java

Java是Hadoop和HBase主要先决条件。首先应该使用"java -verion"检查java是否存在在您的系统上。 java -version 命令的语法如下。

$ java -version

如果一切正常，它会得到下面的输出。

java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b13)
Java HotSpot(TM) Client VM (build 25.0-b02, mixed mode)

如果Java还没有安装在系统中，请你安装Java！

HBase版本与JDK

在下表中你可以看到HBase版本与其对应支持的JDK版本：

HBase版本	JDK 7	JDK 8
2.0	不支持	支持
1.3	支持	支持
1.2	支持	支持
1.1	支持	使用JDK 8运行将会正常工作，但是没有得到很好的测试。

注意：HBase不会使用Java 6构建或编译，并且，您必须在群集的每个节点上设置JAVA_HOME，hbase-env.sh 提供了一个方便的机制来做到这一点。

操作系统

SSH

（必须的）HBase广泛使用安全Shell（ssh）命令和实用程序在集群节点之间进行通信。集群中的每台服务器都必须运行ssh，以便可以管理Hadoop和HBase后台进程。您必须能够使用共享密钥而不是密码，通过SSH（包括本地节点）从主服务器和任何备份主服务器连接到所有节点。您可以在Linux或Unix系统中的“Procedure：Configure Passwordless SSH Access ”（配置无密码SSH访问）中看到这种设置的基本方法。如果群集节点使用OS X，请参阅Hadoop wiki上的，SSH：设置远程桌面和启用自登录。

DNS

HBase使用本地主机名来自行报告其IP地址。正向和反向DNS解析必须在0.92.0之前的HBase版本中工作。hadoop-dns-checker 工具，可以用来验证DNS在集群上是否正常工作。项目README文件提供了有关使用的详细说明。

  Loopback IP

在hbase-0.96.0之前，HBase只使用IP地址127.0.0.1来引用localhost，而这是不可配置的。有关更多详细信息，请参阅Loopback IP。

NTP

群集节点上的时钟应该同步。少量的变化是可以接受的，但是大量的不同会导致不稳定和意外的行为。如果在群集中看到无法解释的问题，则时间同步是首先要检查的事项之一。建议您在群集上运行网络时间协议（NTP）服务或其他时间同步机制，并且所有节点都查找相同的服务以进行时间同步。请参阅Linux文档项目（TLDP）中的基本NTP配置以设置NTP。

文件和进程数限制（ulimit）

Apache HBase是一个数据库。它需要能够一次打开大量的文件。许多Linux发行版限制了允许单个用户打开的文件数量1024（或者256，在旧版本的OS X上）。当以运行 HBase 的用户身份登录时，您可以通过在服务器上运行ulimit -n命令来检查服务器上的限制。您也可能会注意到以下错误：

2010-04-06 03：04：37,542信息org.apache.hadoop.hdfs.DFSClient：异常increateBlockOutputStream java.io.EOFException
2010-04-06 03：04：37,542 INFO org.apache.hadoop.hdfs.DFSClient：放弃块blk_-6935524980745310745_1391901

建议将ulimit提高到至少10,000，但更可能是10,240，因为该值通常以1024的倍数表示。每个ColumnFamily至少有一个StoreFile，如果该区域处于加载状态，则可能有多于六个的StoreFile。所需的打开文件的数量取决于ColumnFamilies的数量和区域的数量。以下是计算RegionServer上打开的文件的潜在数量的粗略公式。

计算打开文件的潜在数量：

（每个ColumnFamily的StoreFiles）x（每个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日志的第一行。

示例：ulimit在Ubuntu上的设置

要在Ubuntu上配置ulimit设置，请编辑：/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 shell。

Windows

在HBase 0.96之前，在Microsoft Windows上运行HBase仅限于测试目的。不建议在Windows计算机上运行生产系统。

Hadoop

下表总结了每个HBase版本支持的Hadoop版本。基于HBase的版本，您应该选择最合适的Hadoop版本。参考更多关于Hadoop环境配置的内容！

建议使用 Hadoop 2.x：Hadoop 2.x 速度更快，包括短路读取功能，这将有助于提高您的 HBase 随机读取配置文件；Hadoop 2.x 还包括重要的 bug 修复，可以改善您的整体 HBase 体验；HBase 不支持使用早期版本的 Hadoop 运行；有关特定于不同 HBase 版本的要求，请参见下表；Hadoop 3.x 仍处于早期访问版本中，尚未被 HBase 社区对生产用例进行充分测试。

使用以下的注解来解释下面的这个表格：

Hadoop版本支持矩阵：

• “S”=支持
• “X”=不支持
• “NT”=未测试

更换与 HBase 捆绑的 Hadoop

因为 HBase 依赖于Hadoop，它将Hadoop jar的一个实例捆绑在其 lib 目录下。捆绑的 jar 仅用于在独立模式下使用。在分布式模式下，群集上的 Hadoop 版本与 HBase 下的内容相匹配是至关重要的。将在 HBase lib 目录中找到的 hadoop jar 替换为您在群集上运行的 hadoop jar，以避免版本不匹配问题。确保在整个集群中替换 HBase 中的 jar。

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...

ZooKeeper要求

动物园管理员3.4.x 是必需的。HBase 使用的多功能, 只可从动物园管理员3.4.0。hbase.zookeeper.useMulti 配置属性默认为 true。参考 HBASE-12241 (在采用deadserver的复制队列时会中断复制的regionServer的崩溃) 和 HBASE-6775 (在可用于HBASE-6710 0.92 / 0.94兼容性修补程序时使用ZK.multi)。该属性被弃用，并且在 HBase 2.0 中始终启用 useMulti。

HBase 运行模式：独立式和分布式

HBase 有两种运行模式：独立式和分布式。HBase 以独立模式运行。无论您的模式如何，您都需要通过编辑HBase conf 目录中的文件来配置 HBase 。至少，您必须编辑 conf/hbase-env.sh 来告诉 HBase 要使用哪个 java。在这个文件中，你设置了 HBase 环境变量，比如 JVM 的 heapsize 和其他选项，日志文件的首选位置等等。设置 JAVA_HOME 以指向你的 java 安装的根目录。

独立式 HBase

默认情况下使用的是独立式的 HBase。在“快速启动 HBase”一节中，我们已经介绍过独立模式。在独立模式下，HBase 不使用 HDFS，而是使用本地文件系统，是在同一个 JVM 中运行所有 HBase 守护进程和本地 ZooKeeper。ZooKeeper 绑定到一个众所周知的端口，通过该端口，客户端可以和 HBase 进行通信。

独立于 HDFS的HBase

有时在独立的 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>

分布式 HBase

分布式模式可以细分为分布式、伪分布式（所有守护进程都在单个节点上运行）、完全分布式（守护进程分布在集群中的所有节点上）。其中，伪分布式模式与完全分布式的命名来自于 Hadoop。

伪分布式模式可以针对本地文件系统运行，也可以针对 Hadoop 分布式文件系统（HDFS）的实例运行。完全分布式模式只能在 HDFS上 运行。有关如何设置 HDFS，请参阅Hadoop HDFS。

伪分布式 HBase

伪分布式模式的 HBase 就是在单个主机上运行的完全分布式模式。使用此HBase配置仅进行测试和原型设计。请勿将此配置用于生产或性能评估。

完全分布式

默认情况下，HBase 以独立模式运行，独立模式和伪分布模式用于小规模测试。对于生产环境，建议使用分布式模式。在分布式模式下，HBase 守护进程的多个实例在集群中的多个服务器上运行。

就像在伪分布式模式中一样，完全分布式的配置要求您将 hbase.cluster.distributed 属性设置为 true。通常情况下， hbase.rootdir 被配置为指向高可用性的 HDFS 文件系统。

此外，还配置了群集，以便多个群集节点成为 RegionServer、ZooKeeper QuorumPeers 和备份 HMaster 服务器。

分布式区域服务器（RegionServers）

通常，你的群集将包含多个运行在不同服务器上的 RegionServer，以及主要和备份 Master 和 ZooKeeper 守护程序。主服务器上的 conf/regionservers 文件中包含一个主机列表，其 RegionServers 与该集群相关。每个主机都在一个单独的行上。当主服务器启动或停止时，此文件中列出的所有主机将启动和停止其 RegionServer 进程。

ZooKeeper和HBase

有关 HBase 的 ZooKeeper 设置说明，请参见 ZooKeeper 部分。

示例 - 分布式 HBase 集群示例

这是一个分布式 HBase 集群的简单的 conf/hbase-site.xml。用于实际工作的群集将包含更多自定义配置参数。大多数 HBase 配置指令都具有默认值，除非在 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 快速入门

请参阅快速入门 - 完全分布，了解包含多个 ZooKeeper、备份 HMaster 和 RegionServer 实例的简单三节点群集配置。

HDFS 客户端配置

1. 值得注意的是，如果您在 Hadoop 集群上进行了 HDFS 客户端配置更改（例如，HDFS 客户端的配置指令），而不是服务器端配置，则必须使用以下方法之一来启用HBase以查看和使用这些配置更改：

• 在 hbase-env.sh 中添加一个指向你 HADOOP_CONF_DIR 的 HBASE_CLASSPATH 环境变量的指针；
• 在$ {HBASE_HOME}/conf 下添加一个 hdfs-site.xml（或hadoop-site.xml）或更好的符号链接；
• 如果只有一小部分 HDFS 客户端配置，请将它们添加到 hbase-site.xml。

这种 HDFS 客户端配置的一个例子是 dfs.replication。例如，如果希望以5的复制因子运行，则 HBase 将创建缺省值为 3 的文件，除非您执行上述操作以使配置可用于 HBase。

运行HBase

保证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日志可以在日志子目录中找到。检查出来，特别是如果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完全关闭。

HBase Shell

使用Shell可以与HBase进行通信。HBase使用Hadoop文件系统来存储数据。它拥有一个主服务器和区域服务器。数据存储将在区域(表)的形式。这些区域被分割并存储在区域服务器。

主服务器管理这些区域服务器，所有这些任务发生在HDFS。下面给出的是一些由HBase Shell支持的命令。

Shell 通用命令

• status: 提供HBase的状态，例如，服务器的数量。
• version: 提供正在使用HBase版本。
• table_help: 表引用命令提供帮助。
• whoami: 提供有关用户的信息。

Shell 数据定义语言

下面列举了HBase Shell支持的可以在表中操作的命令。

• create: 用于创建一个表。
• list: 用于列出HBase的所有表。
• disable: 用于禁用表。
• is_disabled: 用于验证表是否被禁用。
• enable: 用于启用一个表。
• is_enabled: 用于验证表是否已启用。
• describe: 用于提供了一个表的描述。
• alter: 用于改变一个表。
• exists: 用于验证表是否存在。
• drop: 用于从HBase中删除表。
• drop_all: 用于丢弃在命令中给出匹配“regex”的表。
• Java Admin API: 在此之前所有的上述命令，Java提供了一个通过API编程来管理实现DDL功能。在这个org.apache.hadoop.hbase.client包中有HBaseAdmin和HTableDescriptor 这两个重要的类提供DDL功能。

Shell 数据操作语言

• put: 用于把指定列在指定的行中单元格的值在一个特定的表。
• get: 用于取行或单元格的内容。
• delete:用于删除表中的单元格值。
• deleteall: 用于删除给定行的所有单元格。
• scan: 用于扫描并返回表数据。
• count: 用于计数并返回表中的行的数目。
• truncate: 用于禁用、删除和重新创建一个指定的表。
• Java client API: 在此之前所有上述命令，Java提供了一个客户端API来实现DML功能，CRUD（创建检索更新删除）操作更多的是通过编程，在org.apache.hadoop.hbase.client包下。 在此包HTable 的 Put和Get是重要的类。

启动 HBase Shell

要访问HBase shell，你需要进入到HBase的主文件夹中：

cd /usr/localhost/
cd Hbase

然后通过使用“hbase shell”命令启动HBase shell：

./bin/hbase shell

如果已成功在系统中安装HBase，那么它会给出 HBase shell 提示符，如下图所示。

HBase Shell; enter 'help<RETURN>' for list of supported commands.
Type "exit<RETURN>" to leave the HBase Shell
Version 0.94.23, rf42302b28aceaab773b15f234aa8718fff7eea3c, Wed Aug 27
00:54:09 UTC 2014

hbase(main):001:0>

退出 HBase Shell

要退出shell命令，你可以通过键入 exit 或使用<Ctrl + C>实现。

HBase默认配置

2018-01-31 11:46 更新

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重启集群来注意到这个变化。

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属性（如果存在）。

没有默认值。

hbase.regionserver.global.memstore.size.lower.limit

强制刷新之前，区域服务器中所有存储区的最大大小。默认为hbase.regionserver.global.memstore.size（0.95）的95％。当由于内存限制而导致更新被阻塞时，此值的100％会导致最小可能的刷新。此配置中的默认值已被故意留空，以便兑现旧的hbase.regionserver.global.memstore.lowerLimit属性（如果存在）。

没有默认值。

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。例如，如果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。

默认为：2888

hbase.zookeeper.leaderport

ZooKeeper用于leader选举的端口。有关更多信息，请参阅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等的重试之前，主要用作等待的值。

默认为：100

hbase.client.pause.cqtbe

是否为CallQueueTooBigException（cqtbe）使用特殊的客户端pause。如果您观察到来自同一个RegionServer的频繁的CQTBE，并且其中的调用队列保持充满，则将此属性设置为比hbase.client.pause更高的值

没有默认值。

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，请将此值设置为与线程数量相关的适当值，这些值将对您有所帮助。

默认为：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.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.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。

没有默认值。

hbase.bucketcache.size

EITHER表示缓存的总堆内存大小的百分比（如果小于1.0），则表示BucketCache的总容量（兆字节）。默认值：0.0

hbase.bucketcache.bucket.sizes

用于bucketcache的存储区大小的逗号分隔列表。可以是多种尺寸。列出从最小到最大的块大小。您使用的大小取决于您的数据访问模式。必须是256的倍数，否则当你从缓存中读取时，你会遇到“java.io.IOException：Invalid HFile block magic”。如果您在此处未指定任何值，那么您可以选取代码中设置的默认bucketsizes。

没有默认值。

hfile.format.version

用于新文件的HFile格式版本。版本3添加了对hfiles中标签的支持（请参阅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套接字连接上设置没有延迟。

默认为：true

hbase.regionserver.hostname

这个配置适用于对HBase很熟悉的人：除非你真的知道你在做什么，否则不要设定它的价值。当设置为非空值时，这表示底层服务器的（面向外部）主机名。

没有默认值。

hbase.regionserver.hostname.disable.master.reversedns

这个配置适用于对HBase很熟练的人：除非你真的知道你在做什么，否则不要设定它的价值。当设置为true时，regionserver将使用当前节点主机名作为服务器名称，HMaster将跳过反向DNS查找并使用regionserver发送的主机名。请注意，此配置和hbase.regionserver.hostname是互斥的。

默认为：false

hbase.master.keytab.file

用于登录配置的HMaster服务器主体的kerberos密钥表文件的完整路径。

没有默认值。

hbase.master.kerberos.principal

“hbase/[e-mail]”，应该用来运行HMaster进程的Kerberos主体名称。主体名称的格式应为：user/hostname @ DOMAIN。如果使用“_HOST”作为主机名部分，它将被替换为正在运行的实例的实际主机名。

没有默认值。

hbase.regionserver.keytab.file

用于登录配置的HRegionServer服务器主体的kerberos密钥表文件的完整路径。

没有默认值。

hbase.regionserver.kerberos.principal

“hbase/[e-mail]”。应该用来运行HRegionServer进程的kerberos主体名称。主体名称的格式应为：user/hostname @ DOMAIN。如果使用“_HOST”作为主机名部分，它将被替换为正在运行的实例的实际主机名。此主体的条目必须存在于hbase.regionserver.keytab.file中指定的文件中

没有默认值。

hadoop.policy.file

RPC服务器使用策略配置文件对客户端请求进行授权决策。仅在启用HBase安全性时使用。

默认为：hbase-policy.xml

hbase.superuser

用户或组列表（以逗号分隔），允许在整个集群中拥有完全权限（不管存储的ACL）。仅在启用HBase安全性时使用。

没有默认值。

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来按需加载。

没有默认值。

hbase.coprocessor.master.classes

在活动的HMaster进程中默认加载的org.apache.hadoop.hbase.coprocessor.MasterObserver协处理器的逗号分隔列表。对于任何实施的协处理器方法，列出的类将按顺序调用。在实现你自己的MasterObserver之后，把它放在HBase的类路径中，并在这里添加完全限定的类名称。

没有默认值。

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.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。

默认为：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.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 ）。

默认为：org.apache.hadoop.hbase.master.balancer.StochasticLoadBalancer

hbase.master.loadbalance.bytable

平衡器运行时的因子表名称。默认：false。

默认为：false

hbase.master.normalizer.class

用于执行期间发生时的区域标准化的类。

默认为：org.apache.hadoop.hbase.master.normalizer.SimpleRegionNormalizer

hbase.rest.csrf.enabled

设置为true以启用对跨站点请求forgery（CSRF）的保护。

默认为：false

hbase.rest-csrf.browser-useragents-regex

通过将hbase.rest.csrf.enabled设置为true来启用为REST服务器，针对跨站点请求伪造（CSRF）的防护时，用于匹配HTTP请求的User-Agent标头的正则表达式的逗号分隔列表。如果传入的用户代理与这些正则表达式中的任何一个相匹配，则认为该请求被浏览器发送，因此CSRF预防被强制执行。如果请求的用户代理与这些正则表达式中的任何一个都不匹配，则该请求被认为是由除浏览器以外的其他东西发送的，例如脚本自动化。在这种情况下，CSRF不是一个潜在的攻击向量，所以预防没有被执行。这有助于实现与尚未更新以发送CSRF预防报头的现有自动化的向后兼容性。

默认为：^Mozilla.,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的类路径中，并在这里添加完全限定的类名称。

hbase.procedure.master.classes

在活动HMaster进程中默认加载的org.apache.hadoop.hbase.procedure.MasterProcedureManager过程管理器的逗号分隔列表。程序通过其签名进行标识，用户可以使用签名和即时名称来触发全局程序的执行。在实现你自己的MasterProcedureManager之后，把它放在HBase的类路径中，并在这里添加完全限定的类名称。

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.serial.replication.waitingMs

默认情况下，在复制中，我们不能确定slave集群中的操作顺序与master集群中的顺序相同。如果将REPLICATION_SCOPE设置为2，我们将按照写入顺序进行编辑。这个配置是设置在下一次检查之前，我们将等待多长时间（以毫秒为单位），如果日志不能被推送，因为有一些日志写在它之前还没有被推入。较大的等待将减少hbase：meta上的查询数量，但会增加复制的延迟。此功能依赖于zk-less分配，因此用户必须将hbase.assignment.usezk设置为false来支持它。

默认为：10000

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

hbase-env.sh

hbase-env.sh文件用来设置HBase环境变量。比如包括在启动HBase守护程序（如堆大小和垃圾回收器配置）时传递JVM的选项。您还可以设置HBase配置、日志目录、niceness、ssh选项，定位进程pid文件的位置等的配置。打开conf/hbase-env.sh文件并仔细阅读其内容。每个选项都有相当好的记录。如果希望在启动时由HBase守护进程读取，请在此处添加您自己的环境变量。

此处的更改将需要重启HBase才能注意到更改。

log4j.properties

编辑此文件以更改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文件通过测试）。

最小的情况是，当连接到集群时，HBase客户机需要依赖关系中的hbase-client模块：

<dependency>
  <groupId>org.apache.hbase</groupId>
  <artifactId>hbase-client</artifactId>
  <version>1.2.4</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>

Java客户端配置

Java客户端使用的配置保存在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实例然后可以传递给一个表，依此类推。

HBase配置示例

2018-01-31 13:58 更新

基本分布式HBase安装

在下文内容中是一个分布式10节点的群集的基本配置示例：其中，节点被命名为example0，example1...一直到example9，在这个例子中；HBase Master和HDFS NameNode正在节点example0上运行；RegionServers在节点example1- example9上运行；一个3节点ZooKeeper集合运行在example1、example2，以及example3的默认端口上；ZooKeeper的数据被保存到：directory/export/zookeeper。

下面我们显示在HBase conf目录中找到的主要配置文件  -hbase-site.xml，regionservers和hbase-env.sh。

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>

regionservers

在此文件中列出将运行RegionServers的节点。在我们的例子中，这些节点是example1- example9。

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

使用rsync将conf目录的内容复制到群集的所有节点。

HBase重要配置

2018-02-01 11:39 更新

下面我们列出一些重要的配置。我们已经将这部分分为必需的配置和值得推荐的配置。

HBase所需的配置

请你参考本教程中HBase基础条件中的操作系统和Hadoop部分的内容！

大型群集配置

如果您拥有一个包含大量区域的群集，那么在主服务器启动后，Regionserver可能会暂时地进行检查，而所有剩余的RegionServers落后。要签入的第一台服务器将被分配到所有不是最优的区域。为防止出现上述情况，请将其hbase.master.wait.on.regionservers.mintostart属性从其默认值1中调高。

HBase推荐的配置

ZooKeeper 配置：zookeeper.session.timeout

默认的超时时间是三分钟（以毫秒为单位）。这意味着，如果服务器崩溃，则在主服务器在三分钟前发现崩溃并开始恢复。您可能需要将超时调整到一分钟甚至更短的时间，以便主服务器尽快通知故障。在更改此值之前，请确保您的JVM垃圾收集配置处于受控状态，否则，长时间的垃圾回收会超出ZooKeeper会话超时时间，将取出您的RegionServer。（如果一个RegionServer长时间处于GC状态，你可能需要在服务器上启动恢复）。

要更改此配置，请编辑hbase-site.xml，将更改的文件复制到群集中并重新启动。

我们将这个值设置得很高，以避免不必要的麻烦。如果出现类似“为什么我在执行一个大规模数据导入的时候Region Server死掉啦”这样的问题，可以解释的原因是：他们的JVM未被解析，并且正在运行长时间的GC操作。

ZooKeeper 实例的数量

见ZooKeeper。

HDFS 配置

dfs.datanode.failed.volumes.tolerated

这是“DataNode 停止提供服务之前允许失败的卷数。默认情况下，任何卷失败都会导致 datanode 关闭”从HDFS-default.xml中的描述。您可能希望将其设置为可用磁盘数量的一半左右。

hbase.regionserver.handler.count

此设置定义了为应答传入的用户表请求而保持打开的线程数。经验法则是，当每个请求的有效载荷接近MB（大容量、扫描使用大缓存）时保持低数字，并且当有效负载小（获取，小投入，ICV，删除）时保持此数字为高。正在进行的查询的总大小受设置hbase.ipc.server.max.callqueue.size的限制。

如果这个数字的有效载荷很小，那么将这个数字设置为最大传入客户端数量是安全的，典型的例子是一个服务于网站的集群，因为put通常不被缓冲，大部分操作都是获取的。

保持此设置的高风险的原因是，当前在区域服务器中发生的所有投入的总大小可能对其内存造成太大的压力，甚至会触发OutOfMemoryError。在低内存上运行的RegionServer将触发其JVM的垃圾收集器，以更频繁的方式运行，直到GC暂停变得明显（原因是用于保留所有请求的有效载荷的所有内存不能被丢弃，即便垃圾收集器正在进行尝试）。一段时间之后，整个群集吞吐量都会受到影响，因为每个碰到该RegionServer的请求都将花费更长的时间，这更加剧了问题的严重性。

您可以通过rpc.logging查看某个RegionServer上是否有太多或太多的处理程序，然后跟踪其日志（排队请求消耗内存）。

大型内存机器的配置

HBase提供了一个合理的，保守的配置，可以在几乎所有人们可能想要测试的机器类型上运行。如果你有更大的机器 - HBase有8G或更大的堆 - 你可能会发现下面的配置选项很有帮助。

压缩（Compression）

您应该考虑启用ColumnFamily压缩。有几个选项可以在大多数情况下都是通过减小StoreFiles的大小来提高性能，从而减少I / O。

请参阅“HBase压缩”了解更多信息。

配置WAL文件的大小和数量

在发生RS故障的情况下，HBase使用wal恢复尚未刷新到磁盘的memstore数据。这些WAL文件应该配置为略小于HDFS块（默认情况下，HDFS块为64Mb，WAL文件为〜60Mb）。

HBase也对WAL文件的数量有限制，旨在确保在恢复过程中不会有太多的数据需要重放。这个限制需要根据memstore配置进行设置，以便所有必要的数据都可以适用。建议分配足够多的WAL文件来存储至少那么多的数据（当所有的存储都接近完整时）。例如，对于16Gb RS堆，默认的memstore设置（0.4）和默认的WAL文件大小（〜60Mb），16Gb * 0.4 / 60，WAL文件数的起点为〜109。但是，由于所有的memstores不会一直占满，所以可以分配更少的WAL文件。

管理分割（Splitting）

HBase通常会根据您的hbase-default.xml和hbase-site.xml 配置文件中的设置来处理您所在区域的分割。重要的设置包括：hbase.regionserver.region.split.policy，hbase.hregion.max.filesize，hbase.regionserver.regionSplitLimit。分割的一个简单的观点是，当一个区域发展到hbase.hregion.max.filesize时，它被分割。对于大多数使用模式，您应该使用自动分割。有关手动区域分割的更多信息，请参阅手动区域分割决策。

不要让HBase自动分割你的区域，你可以选择自己管理分割。HBase 0.90.0增加了这个功能。如果你知道你的密钥空间，手动管理分割就行，否则让HBase为你分割。手动分割可以减轻在负载下的区域创建和移动。这也使得区域边界是已知的和不变的（如果你禁用区域分割）。如果使用手动分割，则可以更轻松地进行交错式的基于时间的主要压缩来分散网络IO负载。

禁用自动分割：要禁用自动拆分，可以在集群配置或表配置中设置区域拆分策略：org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy

自动分割建议：如果禁用自动分割来诊断问题或在数据快速增长期间，建议在您的情况变得更加稳定时重新启用它们。

确定预分割区域的最佳数目：

预分割区域的最佳数量取决于您的应用程序和环境。一个好的经验法则是从每个服务器的10个预分割区域开始，随着时间的推移数据不断增长。尽量在区域太少的地方犯错，稍后进行滚动分割更好。区域的最佳数量取决于您所在区域中最大的StoreFile。如果数据量增加，最大的StoreFile的大小将随着时间增加。目标是使最大的区域足够大，压实选择算法仅在定时的主要压实期间将其压缩。否则，该集群可能会同时出现大量压实区域的压实风暴。数据增长导致压缩风暴，而不是人工分割决策，这一点很重要。

如果区域被分割成太多的区域，可以通过配置HConstants.MAJOR_COMPACTION_PERIOD来增加主要的压缩间隔。HBase 0.90引入了org.apache.hadoop.hbase.util.RegionSplitter，它提供所有区域的网络IO安全滚动分割。

管理压缩（Compactions）

默认情况下，主要的压缩计划在7天内运行一次。在HBase 0.96.x之前，默认情况下主要的压缩计划是每天发生一次。

如果您需要精确控制主要压缩的运行时间和频率，可以禁用托管的主要压缩。请参阅“compaction.parameters表中的hbase.hregion.majorcompaction条目”的详细信息。

不禁用主要压缩：对于StoreFile清理来说，重要的压缩是绝对必要的。不要完全禁用它们。您可以通过HBase shell或Admin API手动运行主要压缩。

预测执行（Speculative Execution）

预测执行MapReduce任务是默认开启的，对于HBase集群，通常建议关闭系统级的推测执行，除非您需要在特定情况下可以配置每个作业。将属性 mapreduce.map.speculative 和 mapreduce.reduce.speculative 设置为 false。

其他配置

平衡器（Balancer）

平衡器（Balancer）是在主服务器上运行的一个周期性操作，用于重新分配集群上的区域。它通过hbase.balancer.period配置，默认为300000（5分钟）。

有关LoadBalancer的更多信息，请参阅master.processes.loadbalancer。

禁用Blockcache

不要关闭块缓存（你可以通过设置hfile.block.cache.size为零来实现）。这样做没有好处，因为RegionServer将花费所有的时间一次又一次地加载HFile索引。如果你的工作集是这样配置块缓存，那么没有益处，最少应保证hfile指数保存在块缓存内的大小（你可以通过调查RegionServer UI粗略地了解你需要的大小；请参阅占网页顶部附近的索引块大小）。

Nagle’s或小包装的问题

如果在对HBase的操作中出现大约40ms左右的延迟，请尝试Nagles的设置。例如，请参阅用户邮件列表线程，将缓存设置为1的不一致扫描性能以及其中所引用的设置tcpNoDelay来提高扫描速度的问题。您也可以查看该文档的尾部图表：HBASE-7008 Set扫描缓存到一个更好的默认位置，我们的Lars Hofhansl会尝试使用Nagle打开和关闭测量效果的各种数据大小。

更好的平均恢复时间（MTTR）

这部分是关于在服务器出现故障后会使服务器恢复更快的配置。请参阅Deveraj Das和Nicolas Liochon博客文章：简介HBase平均恢复时间（MTTR）。

HBASE-8354强制Namenode使用lease恢复请求循环的问题是混乱的，但在低超时以及如何引起更快的恢复，包括引用添加到HDFS的修复程序方面，有很多好的讨论。下面建议的配置是Varun的建议的提炼和测试，确保你在HDFS版本上运行，所以你有他所提到的修补程序，并且他自己添加到HDFS，帮助HBase MTTR（例如HDFS-3703，HDFS-3712和HDFS-4791 -Hadoop 2确保有他们并且后期Hadoop 1有一些）。在RegionServer中设置以下内容：

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

在NameNode/DataNode端，设置以下内容来启用HDFS-3703，HDFS-3912中引入的“staleness”：

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

JMX

JMX（Java Management Extensions，Java管理扩展）提供了内置的工具，使您能够监视和管理Java VM。要启用远程系统的监视和管理，在启动 Java VM 时，您需要设置系统属性com.sun.management.jmxremote.port（要启用JMX RMI连接的端口号）。从历史上看，除了上面提到的端口之外，JMX还会打开两个附加的随机TCP侦听端口，这可能会导致端口冲突问题。

作为一种替代方法，您可以使用HBase提供的基于协处理器的JMX实现。要在0.99或更高版本中启用它，请在hbase-site.xml中添加以下属性：

<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

要在主服务器上启用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相同）。

HBase 动态配置

从 HBase 1.0.0 版本开始，你可以在不重新启动服务器的情况下更改配置的子集。在 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.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.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版本号和兼容性

HBase 有两种版本控制方案，分别是：pre-1.0 和 post-1.0。在本节内容中将作出详细的说明。

HBase post-1.0

从 1.0.0 版本开始，HBase 正在致力于 Semantic Versioning 的发布版本。综上所述：

对于给定的版本号 MAJOR.MINOR.PATCH，增加如下内容：

• MAJOR 版本，当你进行不兼容的 API 更改时
• MINOR 版本，当您以向后兼容的方式添加功能时
• PATCH 版本，当您进行向后兼容的错误修复时
• 预发布和构建元数据的其他标签可作为MAJOR.MINOR.PATCH格式的扩展。

兼容性维度：

除了通常的 API 版本考虑之外，HBase 还有其他需要考虑的兼容性维度。

Client-Server 线协议兼容性：

• 允许不同步更新客户端和服务器。
• 我们只能允许先升级服务器。也就是说，服务器将向后兼容旧客户端，这样新的 API 就可以使用。
• 示例：用户应该能够使用旧客户端连接到升级的群集。

Server-Server 协议兼容性：

• 不同版本的服务器可以共存于同一个群集中。
• 服务器之间的有线协议是兼容的。
• 分布式任务的工作人员（如复制和日志拆分）可以共存于同一个群集中。
• 相关协议（如使用ZK进行协调）也不会改变。
• 示例：用户可以执行滚动升级。

文件格式兼容性：

• 支持文件格式向前和向后兼容
• 示例：文件、ZK 编码、目录布局自动升级为 HBase 升级的一部分。用户可以降级到旧版本，并且一切都将继续工作。

客户端 API 兼容性：

• 允许更改或删除现有的客户端 API。
• 在我们更改/删除主要版本之前，API 需要被弃用。
• 修补程序（patch）版本中提供的 API 将在所有后续修补程序版本中提供。但是，可能会添加新的 API，这些 API 在以前的修补程序版本中将不可用。
• 修补程序版本中引入的新 API 只能以源代码兼容的方式添加：即实现公共 API 的代码将继续编译。示例：使用新废用的 API 的用户不需要使用 HBase API 调用修改应用程序代码，直到下一个主要版本。*

客户端二进制兼容性：

• 写入给定修补程序版本中提供的 API 的客户端代码可以运行不变（不需要重新编译），以抵补新的 jar 后续补丁版本。
• 写入给定修补程序版本中提供的 API 的客户端代码可能无法针对早期修补程序版本中的旧 jar 运行。示例：旧编译的客户端代码将在 jar 中保持不变。
• 如果客户端实现 HBase 接口，则可能需要重新编译升级到较新的次要（minor）版本。

服务器端有限的 API 兼容性（取自 Hadoop）：

• 内部API被标记为“稳定（Stable）”，“正在发展（Evolving）”或“不稳定（Unstable）”。
• 这意味着协处理器和插件（可插入类，包括复制）的二进制兼容性，只要这些只使用标记的接口/类。
• 例如：旧编译的协处理器，过滤器或插件代码将在新 jar 中保持不变。

相关性兼容性：

• HBase 的升级不需要依赖项目的兼容升级，包括运行 Java 时。
• 示例：Hadoop 的升级不会使我们所做的任何兼容性保证失效。

操作兼容性：

• 度量标准的更改
• 服务的行为变化
• 通过 /jmx/ 端点公开的 JMX API

概要

• 修补程序（patch）升级是一种直接替代方案。任何不是 Java 二进制和源代码兼容的更改都将不被允许。在修补程序版本中降级版本可能不兼容。
• 次要（minor）升级不需要修改应用程序/客户端代码。理想情况下，这将是一个直接替换，但如果使用新的 jar，则客户端代码，协处理器，过滤器等可能必须重新编译。
• 主要（major）升级允许 HBase 做出重大改变。

以下是兼容性矩阵列表：

	Major	Minor	Patch
客户端 - 服务器线路兼容性	不兼容	兼容	兼容
服务器 - 服务器兼容性	不兼容	兼容	兼容
文件格式兼容性	不兼容	兼容	兼容
客户端API兼容性	不兼容	兼容	兼容
客户端二进制兼容性	不兼容	不兼容	兼容
服务器端有限的API兼容性
稳定性（Stable）	不兼容	兼容	兼容
发展性（Evolving）	不兼容	不兼容	兼容
不稳定性（Unstable）	不兼容	不兼容	不兼容
相关性兼容性	不兼容	兼容	兼容
操作兼容性	不兼容	不兼容	兼容

HBase 有很多 API 要点，但对于上面的兼容性矩阵，我们区分了Client API（客户端 API），Limited Private API（有限的私有 API）和 Private API（私有 API）。

• InterfaceAudience（javadocs）：捕捉预期的受众，可能的值包括：

• Public：对于最终用户和外部项目是安全的；
• LimitedPrivate：用于我们期望可插入的内部组件，如协处理器；
• Private：严格用于 HBase 自身内部定义为 IA 的类中，Private 可以用作声明 IA.LimitedPrivate 接口的参数或返回值。将IA.Private对象视为不透明；不要尝试直接访问其方法或字段。

• InterfaceStability（javadocs）：描述允许接口更改的类型。可能的值包括：

• Stable：接口是固定的，预计不会改变；
• Evolving：界面可能会在未来的minor 版本中改变；
• Unstable：界面可能随时更改

请记住 HBase 项目中 InterfaceAudience 注释和 InterfaceStability 注释之间的以下相互作用：

• IA.Public 类本质上是稳定的，并坚持我们有关升级类型（主要，次要或修补程序）的稳定性保证。
• IA.LimitedPrivate 类应始终使用给定的 InterfaceStability 值的其中一个进行注释。如果他们不是，你应该假定他们是 IS.Unstable。
• IA.Private 类应该被认为是隐含不稳定的，不能保证发布之间的稳定性。

HBase 客户端 API

HBase 客户端 API 由所有标记有 InterfaceAudience.Public 接口的类或方法组成。hbase-client 和依赖模块中的所有主类都有InterfaceAudience.Public，InterfaceAudience.LimitedPrivate或InterfaceAudience.Private标记。并非所有其他模块（hbase-server等）中的类都有标记。如果一个类没有使用上述中的一个注释，则它被认为是一个InterfaceAudience.Private类。

HBase Limited Private API

LimitedPrivate 注释为接口附带了一组目标使用者。这些使用者是协处理器，phoenix，复制端点实现等。此时，HBase 只能保证修补程序版本之间的这些接口的源和二进制兼容性。

HBase Private API

所有使用InterfaceAudience.Private注释的类或没有注释的所有类仅在HBase内部使用。接口和方法签名可以随时改变。如果您依赖于标记为Private的特定界面，则应打开jira以建议将界面更改为Public或LimitedPrivate，或者为此目的公开的接口。

HBase Pre 1.0

HBase Pre-1.0 版本都是 EOM：对于新的安装，请勿部署：0.94.y、0.96.y 或 0.98.y，应该部署稳定的版本。

在语义版本化方案 pre-1.0 之前，HBase 追随 Hadoop 的 0.2x 或 0.9x 版本。

二进制兼容性：

当我们说两个 HBase 版本是兼容的时，我们的意思是这些版本是线（wire）和二进制兼容的。兼容的HBase版本意味着客户可以与兼容但不同版本的服务器通话。这也意味着你可以换出一个版本的 jar，并用另一个兼容版本的 jar 替换它们，所有的 jar 都可以工作。除非另有说明，否则 HBase 主要的版本都是二进制兼容的。您可以安全地在二进制兼容版本之间进行滚动升级。

滚动升级

滚动升级是您一次更新服务器群集中的服务器的过程。如果它们是二进制或线路兼容的，则可以跨 HBase 版本进行滚动升级。粗略地说，滚动升级是正常地停止每台服务器，更新软件，然后重新启动。您可以为集群中的每个服务器执行此操作。通常先升级 Master，然后再升级 RegionServers。

例如，下面的 HBase 是 symlinked 实际的 HBase 安装。在升级之前，在群集上运行滚动重启之前，我们将 symlink 更改为指向新的 HBase 软件版本，然后运行：

$ HADOOP_HOME=~/hadoop-2.6.0-CRC-SNAPSHOT ~/hbase/bin/rolling-restart.sh --config ~/conf_hbase

滚动重新启动脚本将首先正常停止并重新启动主服务器，然后依次重新启动每个 RegionServer。由于 symlink 被更改，所以重新启动时，服务器将使用新的HBase 版本。随着滚动升级的进行，检查日志中是否有错误。

在兼容二进制/Wire的版本之间进行滚动升级：

除非另有说明，否则 HBase 指向的版本是二进制兼容的。您可以在 HBase 主要版本之间进行滚动升级。例如，您可以通过在集群中进行滚动升级，使用0.94.6二进制文件替换0.94.5二进制文件，从而从 0.94.5 转到 0.94.6。

在次要（minor）版本中，我们调用的版本是有线/协议兼容的，在这种情况下，也可以执行滚动升级。例如，在从 0.98.x 升级到 HBase 1.0.0 时，我们声明可以在 hbase-0.98.x 和 hbase-1.0.0 之间进行滚动升级。

HBase回滚

当你在试着升级 HBase 的时候，你可能会遇到升级失败的问题，并且想要将其恢复成之前的版本。本节就介绍如何执行回滚以将 HBase 恢复为到较早的版本。请注意，这应该只在主要版本和一些次要版本之间需要。您应该始终能够在相同次要版本的 HBase Patch 版本之间进行降级。这些说明可能要求您在开始升级过程之前注意相关的事项，因此请务必事先阅读本节。

HBase回滚注意事项

回滚与降级：

本节介绍如何对 HBase 次要版本和主要版本之间的升级执行回滚。在本文档中，回滚指的是采取升级后的集群并将其恢复到旧版本的过程，同时丢失升级后发生的所有更改。相比之下，群集降级会将升级后的群集恢复到旧版本，同时保留升级后写入的任何数据。我们目前仅提供回滚 HBase 集群的说明。此外，只有在执行升级之前遵循这些说明，回滚才有效。

当这些指令谈论回滚与降级的先决条件群集服务（即HDFS）时，您应该将服务版本与退化的降级案例视为相同。

复制：

除非您正在执行全部服务回滚，否则 HBase 群集将会丢失任何配置的对等 HBase 复制。如果您的集群配置为 HBase 复制，那么在按照这些说明进行操作之前，您应该记录所有复制节点。执行回滚之后，您应该将每个记录的对等点添加回群集。另外要注意，自升级后写入群集的数据可能已经或可能未被复制到任何对等方。

数据地点：

除非您正在执行全部服务回滚，否则通过回滚过程可能会破坏Region Server的所有局部位置。在群集有时间通过紧凑排列恢复数据位置之前，您应该期望性能的降级。或者，您可以强制压缩来加速此过程，但要以生成群集负载为代价。

可配置的位置：

以下说明假设 HBase 数据目录和 HBase znode 的默认位置。这两个位置都是可配置的，您应该在继续操作之前验证群集中使用的值。如果您有不同的值，只需将默认值替换为在配置中找到的 HBase 数据目录，它是通过密钥 "HBase" (rootdir) 配置的，并且具有默认的 "/HBase"。* HBase znode通过密钥'zookeeper.znode.parent'进行配置，默认值为'/ hbase'。

所有服务回滚

如果您要执行 HDFS 和 ZooKeeper 服务的回滚，那么 HBase 的数据将在此过程中回滚。

要求

• 能够回滚 HDFS 和 ZooKeeper

升级前

在升级前不需要额外的步骤。作为一项额外的预防措施，您可能希望使用 distcp 将 HBase 数据备份到要升级的群集之外。为此，请本节内容中的按照“HDFS降级后回滚”的“升级前”部分中的步骤操作，但它是复制到另一个 HDFS 实例，而不是在同一实例中。

执行回滚

1. 停止 HBase
2. 执行 HDFS 和 ZooKeeper 的回滚（HBase 应该保持停止状态）
3. 将安装的 HBase 版本更改为以前的版本
4. 启动 HBase
5. 验证 HBase 内容 - 使用 HBase shell 列出表格并扫描一些已知值。

HDFS 回滚和 ZooKeeper 降级后回滚

如果您将回滚 HDFS，但通过 ZooKeeper 降级，那么 HBase 将处于不一致的状态。在完成此过程之前，您必须确保集群未启动。

要求

• 能够回滚 HDFS
• 能够降级 ZooKeeper

升级前

在升级前不需要额外的步骤。作为一种额外的预防措施，您可能希望使用 distcp 将 HBase 数据备份到要升级的群集之外。为此，请本节内容中的按照“HDFS降级后回滚”的“升级前”部分中的步骤操作，但它将复制到另一个HDFS实例，而不是在同一实例中。

执行回滚

1. 停止 HBase
2. 执行 HDFS 回滚和 ZooKeeper 降级（HBase 应该保持停止状态）
3. 将安装的 HBase 版本更改为以前的版本
4. 清除与 HBase 相关的 ZooKeeper 信息。警告：此步骤将永久销毁所有复制对等点。
   清理 ZooKeeper 中的 HBase 信息：

[hpnewton@gateway_node.example.com ~]$ zookeeper-client -server zookeeper1.example.com:2181,zookeeper2.example.com:2181,zookeeper3.example.com:2181
Welcome to ZooKeeper!
JLine support is disabled
rmr /hbase
quit
Quitting...

1. 启动 HBase
2. 验证 HBase 内容 - 使用 HBase shell 列出表格并扫描一些已知值。

HDFS 降级后回滚

如果您要执行 HDFS 降级，则无论ZooKeeper是否通过回滚、降级或重新安装，您都需要遵循这些指示信息。

要求

• 可以降级 HDFS
• 升级前群集必须能够运行 MapReduce 作业
• HDFS 超级用户访问
• 在 HDFS 中至少有两个 HBase 数据目录的副本空间

升级前

在开始升级过程之前，您必须对 HBase 的支持数据进行完整备份。以下说明介绍了在当前HDFS实例中备份数据的过程。或者，您可以使用 distcp 命令将数据复制到另一个 HDFS 群集。

1. 停止 HBase 群集
2. 将 HBase 数据目录复制到备份位置, 方法是使用 distcp 命令作为 HDFS 超级用户 (下面显示在启用安全的群集上)；
   使用distcp备份HBase数据目录：

[hpnewton@gateway_node.example.com ~]$ kinit -k -t hdfs.keytab [e-mail]
[hpnewton@gateway_node.example.com ~]$ hadoop distcp /hbase /hbase-pre-upgrade-backup

1. Distcp 将启动一个 mapreduce 作业来处理以分布式方式复制文件。检查 distcp 命令的输出，以确保此作业成功完成。

执行回滚

1. 停止 HBase
2. 执行 HDFS 的降级和 ZooKeeper 的降级/回滚（HBase 应该保持停止状态）
3. 将安装的 HBase 版本更改为以前的版本
4. 将 HBase 数据目录从升级前恢复为 HDFS 超级用户 (如下所示在启用安全的群集上)。如果您将数据备份到另一个 HDFS 群集而不是本地，则需要使用distcp 命令将其复制回当前的 HDFS 群集。
   恢复 HBase 数据目录：

[hpnewton@gateway_node.example.com ~]$ kinit -k -t hdfs.keytab [e-mail]
[hpnewton@gateway_node.example.com ~]$ hdfs dfs -mv /hbase /hbase-upgrade-rollback
[hpnewton@gateway_node.example.com ~]$ hdfs dfs -mv /hbase-pre-upgrade-backup /hbase

1. 清除与 HBase 相关的 ZooKeeper 信息。警告：此步骤将永久销毁所有复制对等点。
   清理 ZooKeeper 中的 HBase 信息：

[hpnewton@gateway_node.example.com ~]$ zookeeper-client -server zookeeper1.example.com:2181,zookeeper2.example.com:2181,zookeeper3.example.com:2181
Welcome to ZooKeeper!
JLine support is disabled
rmr /hbase
quit
Quitting...

1. 启动 HBase
2. 验证 HBase 内容 - 使用 HBase shell 列出表格并扫描一些已知值。

HBase升级路径

HBase：从 0.98.x 升级到 1.x

在本节中，首先，你需要注意 1.0.0 版本以上的 HBase 做出了重大的更改，所以在继续升级过程前，你应该仔细阅读这些重要的更改部分，以免发生意外。

HBase 1.0.0+ 重要更改部分：

在这里，我们列出了自 0.98.x 版本之后的 1.0.0 以上版本的重要更改，您应该知道这些更改会在升级后生效。

• HBase 1.0.0+ 中 ZooKeeper 3.4 是必需的。
• HBase 默认端口已更改：
  HBase使用的端口已更改。他们曾经是在600XX范围内。在HBase 1.0.0中，它们已经从临时端口范围中移出，并且是160XX（主 Web UI 为 60010，现在为16010; RegionServer Web UI 为 60030，现在为16030等）。如果要保留旧的端口位置，请将hbase-default.xml中的端口设置配置复制到hbase-site.xml中，将它们更改回 HBase 0.98.x 版本的旧值，并确保在重新启动之前已分发了配置。
• HBase 主端口绑定更改：
  在 HBase 1.0.x 中，HBase Master绑定RegionServer端口以及主端口。此行为从1.0之前的 HBase 版本更改。在 HBase 1.1 和 2.0 分支中，此行为将恢复为 HBase 主服务器未绑定RegionServer端口的 1.0 行为。
• hbase.bucketcache.percentage.in.combinedcache 配置已被删除：
  如果您正在使用BucketCache，则可能已使用此配置。如果不使用 BucketCache，则此更改不会影响您。它的移除意味着您的 L1 LruBlockCache 现在使用 hfile.block.cache.size 来调整大小，即，如果您不在执行 BucketCache，您可以调整堆上 L1 LruBlockCache 的大小 - 并且 BucketCache 大小不适用于该 hbase.bucketcache.size 设置。您可能需要调整 configs 以将 LruBlockCache 和 BucketCache 大小设置为 0.98.x 和之前的大小。如果你没有设置这个配置，它的默认值是 0.9。如果你什么都不做，你的 BucketCache 将会增加10％。您的 L1 LruBlockCache 将成为 java 堆大小的 hfile.block.cache.size 倍（hfile.block.cache.size 是 0.0 到 1.0 之间的浮点数）。

HBase：从 0.96.x 升级到 0.98.x

HBase 从 0.96.x 到 0.98.x 的滚动升级工作。这两个版本不是二进制兼容的。

需要执行其他步骤才能利用 0.98.x 的一些新功能，包括单元可见性标签，单元 ACL 和透明服务器端加密。有关更多信息，请参阅保护 Apache HBase。显着的性能改进包括对提前写日志线程模型的更改，它在高负载、反向扫描仪、MapReduce 快照文件和带区压缩的情况下提供更高的事务吞吐量。

客户端和服务器可以运行 0.98.x 和 0.96.x 版本。但是，由于 Java API 中的更改，应用程序可能需要重新编译。

HBase：从 0.94.x 升级到 0.98.x

HBase 从 0.94.x 直接到 0.98.x 的滚动升级不起作用。升级路径遵循与从 0.94.x 升级到 0.96.x 相同的过程。需要额外的步骤才能使用 0.98.x 的一些新功能。

HBase：从 0.94.x 升级到 0.96.x

Singularity

您必须完全停止旧版本的 0.94.x 群集才能进行升级。如果您正在群集之间进行复制，则两个群集都必须进行升级。请确保它完全处于关机状态。WAL 文件越少，升级运行的速度就越快（升级将在文件系统中找到的所有日志文件都分解为升级过程的一部分）。所有客户端也必须升级到 0.96。

API 已经改变。您需要重新编译 0.96 的代码，您可能需要调整应用程序以适应新的 API（TODO：更改列表）。

执行 0.96 升级

在升级过程中，HDFS 和 ZooKeeper 必须启动并运行！

HBase 0.96.0 附带升级脚本，请运行：

$ bin/hbase upgrade

以查看其用法。该升级脚本有两种主要模式：check 和 execute。

check

检查（check）步骤针对正在运行的 0.94 群集运行。从下载的 0.96.x 二进制文件运行它。检查步骤正在寻找 HFile v1 文件的存在。这些在 HBase 0.96.0 中不受支持。要让它们重写为 HFile v2，您必须运行压缩。

检查步骤在其运行结束时打印统计数据（在日志中 grep 用于 “Result:”），打印其扫描的表的绝对路径、找到的任何 HFile v1 文件、包含所述文件的区域（这些区域将需要大的压缩）以及任何如果找到损坏的文件。一个损坏的文件是不可读的，所以未定义（HFile v1 和 HFile v2 都没有）。

要运行检查步骤，请运行：

$ bin/hbase upgrade -check

这里是示例输出：

Tables Processed:
hdfs://localhost:41020/myHBase/.META.
hdfs://localhost:41020/myHBase/usertable
hdfs://localhost:41020/myHBase/TestTable
hdfs://localhost:41020/myHBase/t

Count of HFileV1: 2
HFileV1:
hdfs://localhost:41020/myHBase/usertable    /fa02dac1f38d03577bd0f7e666f12812/family/249450144068442524
hdfs://localhost:41020/myHBase/usertable    /ecdd3eaee2d2fcf8184ac025555bb2af/family/249450144068442512

Count of corrupted files: 1
Corrupted Files:
hdfs://localhost:41020/myHBase/usertable/fa02dac1f38d03577bd0f7e666f12812/family/1
Count of Regions with HFileV1: 2
Regions to Major Compact:
hdfs://localhost:41020/myHBase/usertable/fa02dac1f38d03577bd0f7e666f12812
hdfs://localhost:41020/myHBase/usertable/ecdd3eaee2d2fcf8184ac025555bb2af

There are some HFileV1, or corrupt files (files with incorrect major version)

在上面的示例输出中，两个区域中有两个 HFile v1 文件和一个损坏的文件，应该删除损坏的文件。具有 HFile v1 的地区需要进行大规模压缩。为了紧凑，请启动hbase shell 并查看如何压缩单个区域。完成主要压缩后，重新运行检查步骤，并且 HFile v1 文件应该消失，替换为 HFile v2 实例。

默认情况下，检查步骤将扫描 HBase 根目录（在配置中定义为 hbase.rootdir）。要仅扫描特定目录，请传递 dir 选项。

$ bin/hbase upgrade -check -dir /myHBase/testTable

上述命令将检测 /myHBase/testTable 目录中的 HFile v1 文件。

一旦检查步骤报告所有 HFile v1 文件已被重写，则继续进行升级是安全的。

execute

在检查步骤显示群集没有 HFile v1 后，继续升级是安全的。接下来是执行（execute）步骤。在执行 execute 步骤之前，您必须关闭您的 0.94.x CLUSTER。如果检测到正在运行的 HBase 主服务器或 RegionServer，则 execute 步骤将不会运行。

在升级过程中，HDFS 和 ZooKeeper 应该启动并运行。如果 zookeeper 由 HBase 管理，那么您可以启动 zookeeper，以便通过运行升级：

$ ./hbase/bin/hbase-daemon.sh start zookeeper

执行升级步骤由三个子步骤组成。

• 命名空间：HBase 0.96.0 支持命名空间。升级需要重新排序文件系统中的目录以使命名空间正常工作。
• ZNodes：清除所有 znode，以便可以使用新的 protobuf'ed 格式将新的 znode 写入其位置，并且可以将一些 znode 迁移到适当位置：例如复制和表状态znodes
• WAL 日志分割：如果 0.94.x 集群没有完全关闭，我们将在0.96.0 启动之前将 WAL 日志分割为迁移的一部分。这个 WAL 分割比本地分布式 WAL 分割运行速度慢，因为它全部在单个升级过程中。

要运行执行步骤，请确保首先在服务器和客户端的各处复制了 HBase 0.96.0 二进制文件。确保 0.94.0 群集已关闭。然后执行如下操作：

$ bin/hbase upgrade -execute

以下是一些示例输出：

Starting Namespace upgrade
Created version file at hdfs://localhost:41020/myHBase with version=7
Migrating table testTable to hdfs://localhost:41020/myHBase/.data/default/testTable
.....
Created version file at hdfs://localhost:41020/myHBase with version=8
Successfully completed NameSpace upgrade.
Starting Znode upgrade
.....
Successfully completed Znode upgrade

Starting Log splitting
...
Successfully completed Log splitting

如果执行步骤的输出看起来不错，请停止开始执行升级的zookeeper实例：

$ ./hbase/bin/hbase-daemon.sh stop zookeeper

然后就可以启动 hbase-0.96.0。

故障排除

旧客户端连接到0.96群集

出现如下的异常，升级过程将会失败：

17:22:15  Exception in thread "main" java.lang.IllegalArgumentException: Not a host:port pair: PBUF
17:22:15  *
17:22:15   api-compat-8.ent.cloudera.com ��  ���(
17:22:15    at org.apache.hadoop.hbase.util.Addressing.parseHostname(Addressing.java:60)
17:22:15    at org.apache.hadoop.hbase.ServerName.&init>(ServerName.java:101)
17:22:15    at org.apache.hadoop.hbase.ServerName.parseVersionedServerName(ServerName.java:283)
17:22:15    at org.apache.hadoop.hbase.MasterAddressTracker.bytesToServerName(MasterAddressTracker.java:77)
17:22:15    at org.apache.hadoop.hbase.MasterAddressTracker.getMasterAddress(MasterAddressTracker.java:61)
17:22:15    at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getMaster(HConnectionManager.java:703)
17:22:15    at org.apache.hadoop.hbase.client.HBaseAdmin.&init>(HBaseAdmin.java:126)
17:22:15    at Client_4_3_0.setup(Client_4_3_0.java:716)
17:22:15    at Client_4_3_0.main(Client_4_3_0.java:63)

升级 META 以使用 Protocol Buffers（Protobuf）

HBase 从 0.96 之前的版本升级时，META 需要转换为使用协议缓冲区（Protobuf）。这是由配置选项 hbase.MetaMigrationConvertingToPB 控制，它在默认情况下被设置为 true。因此，默认情况下，您不需要采取任何措施。

迁移是一次性事件。但是，每次启动群集时，META 都会进行扫描以确保不需要转换。如果您的区域数量非常多，则此扫描可能需要很长时间。在 0.98.5 开始，您可以在 HBase的-site.xml 中设置 hbase.MetaMigrationConvertingToPB 为 false ，以禁用此启动扫描。

HBase：从 0.92.x 升级到 0.94.x

我们曾经认为 HBase 的 0.92 版本和 0.94 版本是接口兼容的，您可以在这些版本之间进行滚动升级，但是后来我们发现 HColumnDescriptor 中的HBASE-5357 Use builder 模式更改了方法签名，不是返回 void，而是返回 HColumnDescriptor。这将抛出 java.lang.NoSuchMethodError: org.apache.hadoop.hbase.HColumnDescriptor.setMaxVersions(I)V，因此 0.92 和 0.94 不兼容，你不能在它们之间进行滚动升级。

HBase：从 0.90.x 升级到 0.92.x

升级指南

您会发现 0.92.0 与 0.90.x 版本稍有不同，这里有一些需要注意的事项。

这些是升级前需要了解的重要内容：

• 默认情况下 MSLAB 处于开启状态。如果您有很多区域，请观看该堆的使用情况。
• 默认情况下，分布式日志分割处于开启状态。它应该使 RegionServer 故障转移更快。
• 有一个单独的包安全。
• 如果 -XX: MaxDirectMemorySize 是设置在您的 hbase. sh，它将启用实验性的离堆缓存 (您可能不希望这样)。

不可回退：

要移动到 0.92.0，你只需关闭群集，将 HBase 0.90.x 替换为 HBase 0.92.0 二进制文件（确保清除所有 0.90.x 实例）并重新启动（不能从 0.90.x 到 0.92.x 重新启动，必须重新启动）。在启动时，.META. 表格内容被重写，从 info:regioninfo 列中移除表格模式。此外，首次启动后完成的任何刷新都将以新的0.92.0 文件格式（带有内嵌块（版本2）的 HBase 文件格式）写入数据。这意味着一旦您在 HBase 数据目录中启动了 HBase 0.92.0，您就无法回到 0.90.x。

MSLAB 默认为开启：

在 0.92.0 中，该 hbase.hregion.memstore.mslab.enabled 标志被设置为 true。在 0.90.x 中是 false。启用它时，即使内存存储为零或仅包含一些小元素，memstores 也会逐步为 MSLAB 2MB 块分配内存。这通常很好，但是如果您在 0.90.x 群集中每个 RegionServer 有很多区域（并且 MSLAB 已关闭），则可能会发现自己升级时出现 OOME，因为 thousands of regions * number of column families * 2MB MSLAB（至少）将堆放在顶部。设置hbase.hregion.memstore.mslab.enabled 为 false 或将 hbase.hregion.memstore.mslab.chunksize 设置为小于2MB 的 MSLAB 大小。

分布式日志分割处于默认状态：

此前，WAL 日志崩溃是由 Master 单独分割的。在 0.92.0 中，日志分割由群集完成。这应该大大减少分割日志和使区域重新联机所需的时间。

内存计算改变：

在 0.92.0 中，包含嵌入块（版本2）索引和 bloom 过滤器的 HBase 文件格式占用了来自文件系统的相同 LRU 使用的高速缓存块。在 0.90.x 版本中，HFile v1 指数位于 LRU 之外，因此即使索引位于没有被使用的文件中，也会占用空间。利用 LRU 中的索引，你可能会发现块缓存的空间较少。相应地调整块缓存。块大小的默认大小已经从0.22.0（堆的20％）改变为0.25。

可用的 Hadoop 版本：

在 Hadoop 1.0.x（或 CDH3u3）上运行 0.92.0。性能优势值得推动。否则，我们的 Hadoop 处方就像以前一样；您需要一个支持工作同步的 Hadoop。

如果在 Hadoop 1.0.x（或 CDH3u3）上运行，请启用本地读取。

HBase 0.92.0 附带 ZooKeeper 3.4.2：

如果可以的话，升级你的 ZooKeeper。如果你不能，3.4.2 客户端应该与 3.3.X 集成（HBase 使用 3.4.2 API）进行工作。

联机更改默认为关闭状态：

在 0.92.0 中，我们添加了一个实验性在线模式更改设施。它在默认情况下是关闭的。您自担风险启用它。联机修改和分割表格不能很好地协同工作，所以请确保您的群集静态使用此功能（现在）。

WebUI：

网络用户界面（web UI）在 0.92.0 中添加了一些附加功能。它显示当前正在转换的区域的列表，最近的压缩/刷新和正在运行的进程的进程列表（如果一切正常并且请求正在及时处理，通常是空的）。其他添加内容包括按区域请求、调试 servlet 转储等。

安全 tarball：

我们现在运送两个 tarballs：安全和不安全的 HBase。

HBase复制的变化：

0.92.0 增加了两个新功能：multi-slave 复制和 multi-master 复制。启用它的方式与添加新的对等方式相同，因此为了拥有 multi-master，您只需运行 add_peer，就可以为每个群集充当其他从属群集的主节点。冲突是在时间戳级别处理的，这可能是也可能不是您想要的，因此需要在每个用例基础上对其进行评估。复制在 0.92 仍然是实验性的，默认情况下是禁用的，运行需要您自担风险。

如果 OOME，RegionServer 现在会中止：

如果一个 OOME，我们现在有 JVM kill RegionServer 进程，所以它快速下降。之前，RegionServer 可能会在受伤的状态下徘徊一段时间后停滞。要禁用此功能，并建议您将其保留原位，则需要编辑 bin/hbase 文件。

HFile v2 和“更大，更少”的趋势：

0.92.0 以新格式存储数据，HBase 文件格式包含内嵌块（版本2）。随着 HBase 的运行，它会将您的所有数据从 HFile v1 移至 HFile v2 格式。此自动迁移将在刷新和紧凑排列运行时在后台运行。HFile v2 允许 HBase 运行更大的区域/文件。事实上，我们鼓励所有前进的 HBase 都倾向于 Facebook axiom #1，运行时区域更大，区域更少。如果你现在有很多区域 - 每个主机超过100个 - 你应该考虑在你移动到 0.92.0（在 0.92.0，默认大小现在是 1G，从 256M 开始）之后设置你的区域大小，然后运行在线合并工具。

HBase：从 0.20.x 或 0.89.x 升级到 HBase 0.90.x

此版本的 0.90.x HBase 可以在 HBase 0.20.x 或 HBase 0.89.x 写入的数据上启动。不需要迁移步骤。HBase 0.89.x 和 0.90.x 以不同的方式地写出了区域目录的名称，它们用区域名称的 md5 哈希来命名，而不是 jenkins 哈希，所以这意味着一旦启动，就不会返回到 HBase 0.20 。X。

确保在升级时从 conf 目录中删除 hbase-default.xml。此文件的 0.20.x 版本将具有用于 0.90.x HBase 的子优化配置。在 HBase 的 -default.xml 文件中现在被捆绑到 HBase jar 上进行读取。如果您想查看此文件的内容，请在：src/main/resources/hbase-default.xml 的 src 树中查看它，或者参阅 HBase 默认配置。

最后，如果从 0.20.x 升级，请检查您的 shell 中的 .META 模式。在过去，我们会建议用户使用 16kb 的 MEMSTORE_FLUSHSIZE，在 shell 中运行：

hbase> scan '-ROOT-'

这将输出当前 .META. 模式。检查 MEMSTORE_FLUSHSIZE 大小。它是 16kb（16384）吗？如果是的话，你需要修改它(默认的值是 64MB (67108864)) 运行脚本bin/set_meta_memstore_size.rb，这个脚本会修改.META.schema。如果不运行的话，集群会比较慢。

使用Apache HBase Shell

2018-03-02 13:46 更新

Apache HBase Shell

Apache HBase Shell 是在（J）Ruby 的 IRB 的基础上增加了一些 HBase 特定的命令。你可以在 IRB 中做的任何事情，都可以在 HBase Shell 中完成。

要运行 HBase shell，请执行如下操作：

$ ./bin/hbase shell

输入：help，然后按 <RETURN> 查看 shell 命令和选项的列表。至少浏览器帮助输出末尾的段落，了解如何将变量和命令参数输入到 HBase shell 中；尤其要注意表名、行和列等是如何引用的。

请参阅本教程中的快速启动HBase章节的“shell 练习”部分。

用Ruby编写脚本

有关脚本编写 Apache HBase 的示例，请查看 HBase bin 目录；查看以* .rb结尾的文件，要运行这些文件之一，请执行如下操作：

$ ./bin/hbase org.jruby.Main PATH_TO_SCRIPT

以非交互模式运行 Shell

HBase Shell（HBASE-11658）添加了一种新的非交互模式。非交互模式捕获 HBase Shell 命令的退出状态（成功或失败），并将该状态返回给命令解释器。如果您使用正常的交互模式，HBase Shell 将只会返回自己的退出状态，这几乎总是会0成功的。

要调用非交互模式，请将 -n 或 --non-interactive 选项传递给 HBase Shell。

OS脚本中的HBase Shell

您可以在操作系统脚本解释器中使用 HBase shell，例如 Bash shell，它是大多数 Linux 和 UNIX 发行版的默认命令解释程序。以下准则使用 Bash 语法，但可以调整为使用 C 样式的 shell（例如 csh 或 tcsh），并且可能会修改为使用 Microsoft Windows 脚本解释器一起使用。

注意：以这种方式生成 HBase Shell 命令的速度很慢，所以在决定何时将 HBase 操作与操作系统命令行相结合时，请记住这一点。

示例——将命令传递给 HBase Shell

您可以使用 echo 命令和 |（管道）操作，以非交互模式将命令传递到 HBase Shell。一定要转义 HBase 命令中的字符，否则 shell 将会解释这些字符。一些调试级别的输出已从下面的示例中截断。

$ echo "describe 'test1'" | ./hbase shell -n

Version 0.98.3-hadoop2, rd5e65a9144e315bb0a964e7730871af32f5018d5, Sat May 31 19:56:09 PDT 2014

describe 'test1'

DESCRIPTION                                          ENABLED
 'test1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'NON true
 E', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0',
  VERSIONS => '1', COMPRESSION => 'NONE', MIN_VERSIO
 NS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS =>
 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false'
 , BLOCKCACHE => 'true'}
1 row(s) in 3.2410 seconds

若要取消所有输出，请将其回显到 /dev/null：

$ echo "describe 'test'" | ./hbase shell -n > /dev/null 2>&1

示例8——检查脚本命令的结果

由于脚本不是设计为交互式运行的，因此您需要一种方法来检查命令是失败还是成功。HBase shell 使用为成功的命令返回值0的标准约定，并为失败的命令返回一些非零值。Bash 将命令的返回值存储在一个名为 $? 的特殊环境变量中。因为每次 shell 运行任何命令时都会覆盖该变量，所以应该将结果存储在另一个脚本定义的变量中。

下面的这个脚本展示了一种方法来存储返回值并根据它做出决定：

#!/bin/bash

echo "describe 'test'" | ./hbase shell -n > /dev/null 2>&1
status=$?
echo "The status was " $status
if ($status == 0); then
    echo "The command succeeded"
else
    echo "The command may have failed."
fi
return $status

在脚本中检查成功或失败

获取退出代码0意味着您脚本编写的命令确实成功了。但是，获取非零退出代码并不一定意味着命令失败。该命令可能已成功，但客户端失去连接，或者其他事件阻碍了其成功。这是因为 RPC 命令是无状态的。确保操作状态的唯一方法是检查。例如，如果你的脚本创建一个表，但返回一个非零的退出值，你应该检查表是否实际创建，然后再试图创建它。

从命令文件读取HBase Shell命令

您可以将 HBase Shell 命令输入到文本文件中，每行一个命令，并将该文件传递给HBase Shell。

示例9——命令文件示例

create 'test', 'cf'
list 'test'
put 'test', 'row1', 'cf:a', 'value1'
put 'test', 'row2', 'cf:b', 'value2'
put 'test', 'row3', 'cf:c', 'value3'
put 'test', 'row4', 'cf:d', 'value4'
scan 'test'
get 'test', 'row1'
disable 'test'
enable 'test'

示例10——指示HBase Shell执行命令

将命令文件的路径作为 hbase shell 命令的唯一参数传递。每个命令都会执行并显示其输出。如果您未在脚本中包含该 exit 命令，则会返回到 HBase shell 提示符。没有办法以编程方式检查每个单独的命令是否成功或失败。此外，尽管您看到每个命令的输出，但命令本身并未回显到屏幕，因此可能难以将命令与其输出对齐。

$ ./hbase shell ./sample_commands.txt
0 row(s) in 3.4170 seconds

TABLE
test
1 row(s) in 0.0590 seconds

0 row(s) in 0.1540 seconds

0 row(s) in 0.0080 seconds

0 row(s) in 0.0060 seconds

0 row(s) in 0.0060 seconds

ROW                   COLUMN+CELL
 row1                 column=cf:a, timestamp=1407130286968, value=value1
 row2                 column=cf:b, timestamp=1407130286997, value=value2
 row3                 column=cf:c, timestamp=1407130287007, value=value3
 row4                 column=cf:d, timestamp=1407130287015, value=value4
4 row(s) in 0.0420 seconds

COLUMN                CELL
 cf:a                 timestamp=1407130286968, value=value1
1 row(s) in 0.0110 seconds

0 row(s) in 1.5630 seconds

0 row(s) in 0.4360 seconds

将VM选项传递给Shell

您可以使用 HBASE_SHELL_OPTS 环境变量将 VM 选项传递到 HBase Shell 。您可以在您的环境中进行设置，例如通过编辑 〜/ .bashrc，或将其设置为启动HBase Shell 的命令的一部分。以下的示例设置了几个与垃圾回收相关的变量，仅用于运行 HBase Shell 的 VM 的生命周期。为了可读性，该命令应该在单行中全部运行，但是会被 \ 字符打断。

$ HBASE_SHELL_OPTS="-verbose:gc -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps \
  -XX:+PrintGCDetails -Xloggc:$HBASE_HOME/logs/gc-hbase.log" ./bin/hbase shell

 

HBase shell 技巧

2018-03-03 14:23 更新

shell 技巧

表变量

HBase 0.95 版本增加了为表提供 jruby 风格的面向对象引用的 shell 命令。以前，作用于表的所有 shell 命令都具有程序风格，该风格始终将表的名称作为参数。HBase 0.95 引入了将表分配给 jruby 变量的功能。表引用可以用来执行数据读写操作，比如放入、扫描、以及管理功能（如禁用，删除，描述表等）。

例如，以前你总是会指定一个表名：

hbase(main):000:0> create ‘t’, ‘f’
0 row(s) in 1.0970 seconds
hbase(main):001:0> put 't', 'rold', 'f', 'v'
0 row(s) in 0.0080 seconds

hbase(main):002:0> scan 't'
ROW                                COLUMN+CELL
 rold                              column=f:, timestamp=1378473207660, value=v
1 row(s) in 0.0130 seconds

hbase(main):003:0> describe 't'
DESCRIPTION                                                                           ENABLED
 't', {NAME => 'f', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_ true
 SCOPE => '0', VERSIONS => '1', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => '2
 147483647', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false
 ', BLOCKCACHE => 'true'}
1 row(s) in 1.4430 seconds

hbase(main):004:0> disable 't'
0 row(s) in 14.8700 seconds

hbase(main):005:0> drop 't'
0 row(s) in 23.1670 seconds

hbase(main):006:0>

现在，您可以将该表分配给一个变量，并在 jruby shell 代码中使用结果。

hbase(main):007 > t = create 't', 'f'
0 row(s) in 1.0970 seconds

=> Hbase::Table - t
hbase(main):008 > t.put 'r', 'f', 'v'
0 row(s) in 0.0640 seconds
hbase(main):009 > t.scan
ROW                           COLUMN+CELL
 r                            column=f:, timestamp=1331865816290, value=v
1 row(s) in 0.0110 seconds
hbase(main):010:0> t.describe
DESCRIPTION                                                                           ENABLED
 't', {NAME => 'f', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION_ true
 SCOPE => '0', VERSIONS => '1', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => '2
 147483647', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false
 ', BLOCKCACHE => 'true'}
1 row(s) in 0.0210 seconds
hbase(main):038:0> t.disable
0 row(s) in 6.2350 seconds
hbase(main):039:0> t.drop
0 row(s) in 0.2340 seconds

如果该表已被创建，则可以使用 get_table 方法将一个表分配给一个变量：

hbase(main):011 > create 't','f'
0 row(s) in 1.2500 seconds

=> Hbase::Table - t
hbase(main):012:0> tab = get_table 't'
0 row(s) in 0.0010 seconds

=> Hbase::Table - t
hbase(main):013:0> tab.put ‘r1’ ,’f’, ‘v’
0 row(s) in 0.0100 seconds
hbase(main):014:0> tab.scan
ROW                                COLUMN+CELL
 r1                                column=f:, timestamp=1378473876949, value=v
1 row(s) in 0.0240 seconds
hbase(main):015:0>

列表功能也已被扩展，以便它返回一个表名称作为字符串的列表。然后，您可以使用 jruby 根据这些名称对表操作进行脚本编写。list_snapshots 命令的作用也相似。

hbase(main):016 > tables = list(‘t.*’)
TABLE
t
1 row(s) in 0.1040 seconds

=> #<#<Class:0x7677ce29>:0x21d377a4>
hbase(main):017:0> tables.map { |t| disable t ; drop  t}
0 row(s) in 2.2510 seconds

=> [nil]
hbase(main):018:0>

irbrc

在您的主目录中为自己创建一个 .irbrc 文件，添加自定义项。一个有用的是历史记录命令，因此命令可以跨 Shell 调用进行保存：

$ more .irbrc
require 'irb/ext/save-history'
IRB.conf[:SAVE_HISTORY] = 100
IRB.conf[:HISTORY_FILE] = "#{ENV['HOME']}/.irb-save-history"

请参阅 .irbrc 的 ruby 文档以了解其他可能的配置。

将数据记录到时间戳

要将日期“08/08/16 20:56:29”从 hbase 日志转换为时间戳，请执行以下操作：

hbase(main):021:0> import java.text.SimpleDateFormat
hbase(main):022:0> import java.text.ParsePosition
hbase(main):023:0> SimpleDateFormat.new("yy/MM/dd HH:mm:ss").parse("08/08/16 20:56:29", ParsePosition.new(0)).getTime() => 1218920189000

从走另一个方向：

hbase(main):021:0> import java.util.Date
hbase(main):022:0> Date.new(1218920189000).toString() => "Sat Aug 16 20:56:29 UTC 2008"

以与 HBase 日志格式完全相同的格式输出将会对 SimpleDateFormat 产生一些影响。

查询 Shell 配置

hbase(main):001:0> @shell.hbase.configuration.get("hbase.rpc.timeout")
=> "60000"

在 shell 中设置一个配置：

hbase(main):005:0> @shell.hbase.configuration.setInt("hbase.rpc.timeout", 61010)
hbase(main):006:0> @shell.hbase.configuration.get("hbase.rpc.timeout")
=> "61010"

使用 HBase Shell 预分割表

在通过 HBase Shell 的 create 命令创建表时，您可以使用各种选项预先拆分表。

最简单的方法是在创建表格时指定一个分割点数组。请注意，当将字符串文字指定为分割点时，这些将根据字符串的基础字节表示创建分割点。所以当指定分割点“10”时，我们实际上是指定了字节分割点“\x31\30”。

分割点将定义 n+1 区域，其中 n 是分割点的数量。最低的区域将包含从最低可能的键直到但不包括第一分割点密钥的所有密钥。下一个区域将包含从第一个分割点开始的密钥，但不包括下一个分割点密钥键。这将持续到最后的所有分界点。最后一个区域将从最后一个拆分点定义为最大可能的密钥。

hbase>create 't1','f',SPLITS => ['10','20',30']

在上面的例子中，将使用列族 "f" 创建表 "t1"，预先拆分到四个区域。请注意，第一个区域将包含从“\x00”到“\x30”（因为“\x31”是“1”的 ASCII 码）的所有密钥。

您可以使用以下变化将分割点传递到文件中。在这个例子中，分割是从对应于本地文件系统上的本地路径的文件中读取的。文件中的每一行都指定一个分割点密钥。

hbase>create 't14','f',SPLITS_FILE=>'splits.txt'

其他选项是根据所需的区域数量和分割算法自动计算分割。HBase 提供基于统一拆分或基于十六进制密钥分割密钥范围的算法，但您可以提供自己的拆分算法来细分密钥范围。

# create table with four regions based on random bytes keys
hbase>create 't2','f1', { NUMREGIONS => 4 , SPLITALGO => 'UniformSplit' }

# create table with five regions based on hex keys
hbase>create 't3','f1', { NUMREGIONS => 5, SPLITALGO => 'HexStringSplit' }

由于 HBase Shell 实际上是一个 Ruby 环境，因此您可以使用简单的 Ruby 脚本以算法方式计算分割。

# generate splits for long (Ruby fixnum) key range from start to end key
hbase(main):070:0> def gen_splits(start_key,end_key,num_regions)
hbase(main):071:1>   results=[]
hbase(main):072:1>   range=end_key-start_key
hbase(main):073:1>   incr=(range/num_regions).floor
hbase(main):074:1>   for i in 1 .. num_regions-1
hbase(main):075:2>     results.push([i*incr+start_key].pack("N"))
hbase(main):076:2>   end
hbase(main):077:1>   return results
hbase(main):078:1> end
hbase(main):079:0>
hbase(main):080:0> splits=gen_splits(1,2000000,10)
=> ["\000\003\r@", "\000\006\032\177", "\000\t'\276", "\000\f4\375", "\000\017B<", "\000\022O{", "\000\025\\\272", "\000\030i\371", "\000\ew8"]
hbase(main):081:0> create 'test_splits','f',SPLITS=>splits
0 row(s) in 0.2670 seconds

=> Hbase::Table - test_splits

请注意，HBase Shell 命令 truncate 有效地删除并重新创建具有默认选项的表格，这将丢弃任何预分割。如果您需要截断预分割表，则必须显式删除并重新创建表以重新指定自定义分割选项。

调试

shell 调试开关

您可以在 shell 中设置一个调试开关，以查看更多输出 - 例如，运行命令时出现更多的异常堆栈跟踪：

hbase> debug <RETURN>

DEBUG 日志级别

要在 shell 中启用 DEBUG 级日志记录，请使用该 -d 选项启动它：

$ ./bin/hbase shell -d

Count 命令

Count 命令返回表中的行数。配置正确的 CACHE 时速度非常快：

hbase> count '<tablename>', CACHE => 1000

上述计数一次取 1000 行。如果行很大，请将 CACHE 设置得较低。默认是每次读取一行。