Apache HBase™参考指南

Preface

这是其随附的HBase版本的官方参考指南。

在这里,您可以找到有关 HBase 主题的 Authority 性文档(指当引用的 HBase 版本发布时的状态),也可以指向JavadocJIRA中可以找到相关信息的位置。

关于本指南

本参考指南正在进行中。可以在 HBase 源代码的_src/main/asciidoc 目录中找到本指南的源代码。该参考指南使用AsciiDoc进行了标记,最终的指南是根据这些AsciiDoc作为“站点”构建目标的一部分而生成的。运行

mvn site

生成此文档。欢迎对文档进行修改和改进。单击this link以针对 Apache HBase 提交新的文档错误,并预先选择了一些值。

撰写文档

有关 AsciiDoc 的概述以及开始为文档做出贡献的建议,请参见本文档后面的相关部分

如果这是您首次涉足分布式计算领域,请多加注意...

如果这是您首次进入分布式计算的美好世界,那么您将处于一段有趣的时期。首先,分布式系统很难。使分布式系统嗡嗡声需要跨越系统(硬件和软件)和网络的不同技能。

群集操作可能会由于各种原因而打 ic,这是由于 HBase 本身中的错误,配置错误(HBase 的配置不正确,还有 os 配置错误)any 直至硬件问题(无论是网卡驱动程序中的错误还是 RAM 总线不足)导致的(要提到两个最近的硬件问题示例,这些问题表现为“ HBase 缓慢”)。如果您已将计算结果绑定到单个框,则还需要重新校准。这是一个很好的起点:分布式计算的谬误

也就是说,不客气。
这是一个有趣的地方。
您好,HBase 社区。

Reporting Bugs

请使用JIRA报告与安全无关的错误。

为了保护现有的 HBase 安装不受新漏洞的影响,请 不要 使用 JIRA 报告与安全相关的错误。而是将您的报告发送到邮件列表[email protected],该列表允许任何人发送消息,但限制了可以阅读的人。该列表中的某人将与您联系以跟进您的报告。

支持和测试期望

在本指南中,短语/ supported /,/ notsupported /,/ tested /和/ not testing /出现在几个地方。为了清楚起见,这里简要说明了在 HBase 上下文中这些短语的一般含义。

Note

许多 Hadoop 供应商为 Apache HBase 提供了商业技术支持。这不是在 Apache HBase 项目的上下文中使用术语/ support /的意义。 Apache HBase 团队对您的 HBase 集群,您的配置或数据不承担任何责任。

  • Supported

    • 在 Apache HBase 的上下文中,/ supported /表示 HBase 旨在按所述方式工作,并且与已定义行为或功能的偏差应报告为错误。
  • Not Supported

    • 在 Apache HBase 的上下文中,/ notsupported /表示用例或使用模式不起作用,应将其视为反模式。如果您认为应该为给定的功能或使用模式重新考虑此指定,请提交 JIRA 或在其中一个邮件列表上进行讨论。
  • Tested

    • 在 Apache HBase 的上下文中,/ tested /表示某个功能已包含在单元测试或集成测试中,并且已被证明可以按预期工作。
  • Not Tested

    • 在 Apache HBase 的上下文中,/ nottested /表示功能或使用模式可能以给定方式工作,也可能无法工作,并且可能会或可能不会破坏您的数据或导致操作问题。这是一个未知数,并且无法保证。如果您可以提供证明/未测试的功能确实可以通过给定的方式工作的证据,请提交测试和/或 Metrics,以便其他用户可以确定此类功能或使用方式。

Getting Started

1. Introduction

Quickstart将使您在 HBase 的单节点独立实例上运行。

2.快速入门-独立 HBase

本节描述了单节点独立 HBase 的设置。一个独立实例具有所有 HBase 守护程序-主服务器,RegionServers 和 ZooKeeper-在单个 JVM 中运行并持久化到本地文件系统。这是我们最基本的部署配置文件。我们将向您展示如何使用hbase shell CLI 在 HBase 中创建表,如何在表中插入行,对表执行放置和扫描操作,启用或禁用表以及启动和停止 HBase。

除了下载 HBase 之外,此过程还需要不到 10 分钟的时间。

2.1. JDK 版本要求

HBase 要求安装 JDK。有关支持的 JDK 版本的信息,请参见Java

2.2. HBase 入门

过程:以独立模式下载,配置和启动 HBase

  • Apache 下载镜像列表中选择一个下载站点。单击建议的顶部链接。这将带您到* HBase Releases 的镜像。单击名为 stable 的文件夹,然后将以 .tar.gz 结尾的二进制文件下载到本地文件系统。现在不要下载以 src.tar.gz *结尾的文件。

  • 解压缩下载的文件,然后转到新创建的目录。

$ tar xzvf hbase-2.1.9-bin.tar.gz
$ cd hbase-2.1.9/
  • 在启动 HBase 之前,需要设置JAVA_HOME环境变量。您可以通过 os 的常用机制来设置变量,但是 HBase 提供了一个中心机制* conf/hbase-env.sh 。编辑此文件,取消 Comments 以JAVA_HOME开头的行,并将其设置为适合您的 os 的位置。 JAVA_HOME变量应设置为包含可执行文件 bin/java 的目录。大多数现代 Linuxos 都提供了一种机制,例如 RHEL 或 CentOS 上的/ usr/bin/alternatives,用于在诸如 Java 之类的可执行文件版本之间透明地进行切换。在这种情况下,可以将JAVA_HOME设置到包含指向 bin/java 的符号链接的目录,通常为/usr *。
JAVA_HOME=/usr
  • 编辑* conf/hbase-site.xml ,它是主要的 HBase 配置文件。这时,您需要在本地文件系统上指定 HBase 和 ZooKeeper 写入数据的目录并确认一些风险。默认情况下,在/ tmp 下创建一个新目录。许多服务器配置为在重新引导时删除/tmp 的内容,因此您应该将数据存储在其他位置。以下配置会将 HBase 的数据存储在名为testuser的用户的主目录的 hbase *目录中。将<property>标记粘贴在<configuration>标记下,该标记在新的 HBase 安装中应该为空。

示例 1.独立 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>
  <property>
    <name>hbase.unsafe.stream.capability.enforce</name>
    <value>false</value>
    <description>
      Controls whether HBase will check for stream capabilities (hflush/hsync).

      Disable this if you intend to run on LocalFileSystem, denoted by a rootdir
      with the 'file://' scheme, but be mindful of the NOTE below.

      WARNING: Setting this to false blinds you to potential data loss and
      inconsistent system state in the event of process and/or node failures. If
      HBase is complaining of an inability to use hsync or hflush it's most
      likely not a false positive.
    </description>
  </property>
</configuration>

您不需要创建 HBase 数据目录。 HBase 将为您完成此任务。如果创建目录,HBase 将尝试进行迁移,这不是您想要的。

Note

上例中的* hbase.rootdir 指向 local 文件系统*中的目录。 “ file://”前缀是我们表示本地文件系统的方式。您应该牢记配置示例中的“警告”。在独立模式下,HBase 使用 Apache Hadoop 项目中的本地文件系统抽象。这种抽象不能提供 HBase 安全运行所需的持久性保证。这对于可以很好地控制群集故障成本的本地开发和测试用例来说是不错的选择。它不适用于生产部署;最终您将丢失数据。

要将 HBase 放置在现有 HDFS 实例上,请设置* hbase.rootdir 指向您实例上的目录:例如 hdfs://namenode.example.org:8020/hbase *。有关此变体的更多信息,请参见下面有关基于 HDFS 的独立 HBase 的部分。

  • 提供* bin/start-hbase.sh 脚本是启动 HBase 的便捷方法。发出命令,如果一切顺利,则会在标准输出中记录一条消息,表明 HBase 已成功启动。您可以使用jps命令来验证您有一个名为HMaster的正在运行的进程。在独立模式下,HBase 在此单个 JVM 中运行所有守护程序,即 HMaster,单个 HRegionServer 和 ZooKeeper 守护程序。转到 http://localhost:16010 *以查看 HBase Web UI。

Note

Java 需要安装并可用。如果收到指示未安装 Java 的错误,但该错误已在系统上(可能位于非标准位置),请编辑* conf/hbase-env.sh 文件并修改JAVA_HOME设置以指向该目录在系统上包含 bin/java *。

过程:首次使用 HBase

  • 连接到 HBase。

使用位于 HBase 安装目录* bin/*中的hbase shell命令连接到正在运行的 HBase 实例。在此示例中,省略了启动 HBase Shell 时打印的一些用法和版本信息。 HBase Shell 提示符以>字符结尾。

$ ./bin/hbase shell
hbase(main):001:0>
  • 显示 HBase Shell 帮助文本。

键入help并按 Enter,以显示 HBase Shell 的一些基本用法信息以及一些示例命令。请注意,表名,行,列都必须用引号引起来。

  • 创建一个表。

使用create命令创建一个新表。您必须指定表名称和 ColumnFamily 名称。

hbase(main):001:0> create 'test', 'cf'
0 row(s) in 0.4170 seconds

=> Hbase::Table - test
  • 列出有关表的信息

使用list命令确认您的表存在

hbase(main):002:0> list 'test'
TABLE
test
1 row(s) in 0.0180 seconds

=> ["test"]

现在,使用describe命令查看详细信息,包括配置默认值

hbase(main):003:0> describe 'test'
Table test is ENABLED
test
COLUMN FAMILIES DESCRIPTION
{NAME => 'cf', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE =>
'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'f
alse', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE
 => '65536'}
1 row(s)
Took 0.9998 seconds
  • 将数据放入表中。

要将数据放入表中,请使用put命令。

hbase(main):003:0> put 'test', 'row1', 'cf:a', 'value1'
0 row(s) in 0.0850 seconds

hbase(main):004:0> put 'test', 'row2', 'cf:b', 'value2'
0 row(s) in 0.0110 seconds

hbase(main):005:0> put 'test', 'row3', 'cf:c', 'value3'
0 row(s) in 0.0100 seconds

在这里,我们插入三个值,一次插入一个。第一次插入位于row1的列cf:a处,值为value1。 HBase 中的列由列族前缀cf(在此示例中),冒号和列限定符后缀a(在本例中)组成。

  • 一次扫描表中的所有数据。

从 HBase 获取数据的一种方法是扫描。使用scan命令扫描表中的数据。您可以限制扫描,但是目前,所有数据都已获取。

hbase(main):006:0> scan 'test'
ROW                                      COLUMN+CELL
 row1                                    column=cf:a, timestamp=1421762485768, value=value1
 row2                                    column=cf:b, timestamp=1421762491785, value=value2
 row3                                    column=cf:c, timestamp=1421762496210, value=value3
3 row(s) in 0.0230 seconds
  • 获取单行数据。

要一次获取一行数据,请使用get命令。

hbase(main):007:0> get 'test', 'row1'
COLUMN                                   CELL
 cf:a                                    timestamp=1421762485768, value=value1
1 row(s) in 0.0350 seconds
  • 禁用表格。

如果要删除表或更改其设置,以及在其他情况下,则需要先使用disable命令禁用该表。您可以使用enable命令重新启用它。

hbase(main):008:0> disable 'test'
0 row(s) in 1.1820 seconds

hbase(main):009:0> enable 'test'
0 row(s) in 0.1770 seconds

如果您测试了上面的enable命令,请再次禁用该表:

hbase(main):010:0> disable 'test'
0 row(s) in 1.1820 seconds
  • 放下桌子。

要删除(删除)表,请使用drop命令。

hbase(main):011:0> drop 'test'
0 row(s) in 0.1370 seconds
  • 退出 HBase Shell。

要退出 HBase Shell 并从群集断开连接,请使用quit命令。 HBase 仍在后台运行。

过程:停止 HBase

  • 与提供* bin/start-hbase.sh 脚本以方便地启动所有 HBase 守护程序相同, bin/stop-hbase.sh *脚本将停止它们。
$ ./bin/stop-hbase.sh
stopping hbase....................
$
  • 发出命令后,关闭进程可能需要几分钟。使用jps确保已关闭 HMaster 和 HRegionServer 进程。

上面显示了如何启动和停止 HBase 的独立实例。在接下来的部分中,我们将简要概述 hbase 部署的其他模式。

2.3. 伪分布式本地安装

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

Hadoop Configuration

此过程假定您已在本地系统和/或远程系统上配置了 Hadoop 和 HDFS,并且它们正在运行并且可用。它还假定您正在使用 Hadoop2.Hadoop 文档中有关设置单节点群集的指南是一个很好的起点。

  • 如果 HBase 正在运行,请停止它。

如果您刚刚完成quickstart并且 HBase 仍在运行,请停止它。此过程将创建一个全新的目录,HBase 将在该目录中存储其数据,因此之前创建的所有数据库都将丢失。

  • Configure HBase.

编辑* hbase-site.xml *配置。首先,添加以下属性,该属性指示 HBase 在分布式模式下运行,每个守护程序一个 JVM 实例。

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

接下来,使用hdfs://// URI 语法将hbase.rootdir从本地文件系统更改为您的 HDFS 实例的地址。在此示例中,HDFS 在 localhost 上的端口 8020 上运行。请确保删除hbase.unsafe.stream.capability.enforce的条目或将其设置为 true。

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

您无需在 HDFS 中创建目录。 HBase 将为您完成此任务。如果创建目录,HBase 将尝试进行迁移,这不是您想要的。

  • Start HBase.

使用* bin/start-hbase.sh *命令启动 HBase。如果系统配置正确,则jps命令应显示正在运行的 HMaster 和 HRegionServer 进程。

  • 检查 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
  • 创建一个表并用数据填充它。

您可以使用 HBase Shell 创建表,使用数据填充表,扫描表并从中获取值,方法与shell exercises相同。

  • 启动和停止备用 HBase 主服务器(HMaster)。

Note

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

HMaster 服务器控制 HBase 群集。您最多可以启动 9 台备份 HMaster 服务器,这使 10 台 HMaster 总数(包括主服务器)在内。要启动备份 HMaster,请使用local-master-backup.sh。对于要启动的每个备份主服务器,添加一个代表该主服务器的端口偏移量的参数。每个 HMaster 使用两个端口(默认情况下为 16000 和 16010)。端口偏移量已添加到这些端口,因此,使用偏移量 2 时,备份 HMaster 将使用端口 16002 和 16012.以下命令使用端口 16002/16012、16003/16013 和 16005/16015 启动 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
  • 启动和停止其他 RegionServer

HRegionServer 按照 HMaster 的指示 Management 其 StoreFiles 中的数据。通常,群集中的每个节点都运行一个 HRegionServer。在同一系统上运行多个 HRegionServer 对于在伪分布式模式下进行测试很有用。 local-regionservers.sh命令允许您运行多个 RegionServer。它的工作方式与local-master-backup.sh命令类似,因为您提供的每个参数都代表实例的端口偏移量。每个 RegionServer 需要两个端口,默认端口为 16020 和 16030.由于 HBase 版本 1.1.0,HMaster 不使用区域服务器端口,因此剩下 10 个端口(16020 到 16029 和 16030 到 16039)用于 RegionServer。为了支持其他 RegionServer,请在运行脚本local-regionservers.sh之前将环境变量 HBASE_RS_BASE_PORT 和 HBASE_RS_INFO_BASE_PORT 设置为适当的值。例如对于基本端口,值为 16200 和 16300,可以在服务器上支持 99 个其他 RegionServer。以下命令启动四个附加的 RegionServer,它们在从 16022/16032(基本端口 16020/16030 加 2)开始的 Sequences 端口上运行。

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

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

$ .bin/local-regionservers.sh stop 3
  • Stop HBase.

您可以使用* bin/stop-hbase.sh *命令以与quickstart过程相同的方式停止 HBase。

2.4. 高级-完全分布式

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

此高级快速入门为集群添加了两个以上的节点。架构如下:

表 1.分布式集群演示架构

Node NameMasterZooKeeperRegionServer
node-a.example.comyesyesno
node-b.example.combackupyesyes
node-c.example.comnoyesyes

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

Note

确保所有节点都具有完全的通信访问权限,并且没有适当的防火墙规则可能阻止它们相互通信。如果看到诸如no route to host之类的错误,请检查防火墙。

过程:配置无密码的 SSH 访问

node-a必须能够登录node-bnode-c(并本身)才能启动守护程序。完成此操作的最简单方法是在所有主机上使用相同的用户名,并配置从node-a到其他每个主机的无密码 SSH 登录。

  • node-a上,生成一个密钥对。

以将要运行 HBase 的用户身份登录后,使用以下命令生成 SSH 密钥对:

$ ssh-keygen -t rsa

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

  • 创建将在其他节点上保存共享密钥的目录。

node-bnode-c上,以 HBase 用户身份登录,并在用户的主目录中创建* .ssh/*目录(如果尚不存在)。如果已经存在,请注意它可能已经包含其他密钥。

  • 将公钥复制到其他节点。

通过使用scp或其他某种安全方式,将公钥从node-a安全复制到每个节点。在其他每个节点上,创建一个名为* .ssh/authorized_keys 的新文件(如果尚不存在),并将 id_rsa.pub *文件的内容附加到文件末尾。请注意,您还需要针对node-a本身执行此操作。

$ cat id_rsa.pub >> ~/.ssh/authorized_keys
  • 测试无密码登录。

如果正确执行了该过程,则当您使用相同的用户名从node-a SSH 到其他任何一个节点时,不应该提示您 Importing 密码。

  • 由于node-b将运行备份主服务器,因此重复上述过程,在您看到node-a的任何地方都替换node-b。确保不要覆盖现有的* .ssh/authorized_keys *文件,而是使用>>运算符而不是>运算符将新密钥连接到现有文件上。

程序:准备node-a

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

  • 编辑* conf/regionservers *并删除包含localhost的行。添加带有node-bnode-c的主机名或 IP 地址的行。

即使您确实想在node-a上运行 RegionServer,也应使用其他服务器用来与其通信的主机名来引用它。在这种情况下,该值为node-a.example.com。这使您可以将任何主机名冲突将配置分发到群集的每个节点。保存文件。

  • 将 HBase 配置为使用node-b作为备份主机。

在* conf/中创建一个名为 backup-masters *的新文件,并在其中添加新行,其主机名为node-b。在此演示中,主机名是node-b.example.com

  • Configure ZooKeeper

实际上,您应该仔细考虑您的 ZooKeeper 配置。您可以在zookeeper部分中找到有关配置 ZooKeeper 的更多信息。此配置将指导 HBase 在群集的每个节点上启动和 ManagementZooKeeper 实例。

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>
  • 在配置中您将node-a称为localhost的任何地方,请将引用更改为指向其他节点将用来引用node-a的主机名。在这些示例中,主机名是node-a.example.com

程序:准备node-bnode-c

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

  • 下载并解压缩 HBase。

将 HBase 下载并解压缩到node-b,就像对独立和伪分布式快速入门所做的那样。

  • 将配置文件从node-a复制到node-bnode-c

群集的每个节点都需要具有相同的配置信息。将* conf/目录的内容复制到node-bnode-c上的 conf/*目录。

过程:启动和测试集群

  • 确保 HBase 不在任何节点上运行。

如果您忘记从先前的测试中停止 HBase,则将出现错误。使用jps命令检查 HBase 是否在您的任何节点上运行。查找进程HMasterHRegionServerHQuorumPeer。如果它们存在,杀死它们。

  • 启动集群。

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

ZooKeeper 首先启动,然后是主机,然后是 RegionServer,最后是备份主机。

  • 验证进程正在运行。

在群集的每个节点上,运行jps命令,并验证每个服务器上是否正在运行正确的进程。如果将其他 Java 进程用于其他目的,则可能还会看到它们在服务器上运行。

node-a jps输出

$ jps
20355 Jps
20071 HQuorumPeer
20137 HMaster

node-b jps输出

$ jps
15930 HRegionServer
16194 Jps
15838 HQuorumPeer
16010 HMaster

node-c jps输出

$ jps
13901 Jps
13639 HQuorumPeer
13737 HRegionServer

ZooKeeper Process Name

HQuorumPeer进程是一个由 HBase 控制和启动的 ZooKeeper 实例。如果以这种方式使用 ZooKeeper,则每个群集节点只能使用一个实例,并且仅适用于测试。如果 ZooKeeper 在 HBase 外部运行,则该过程称为QuorumPeer。有关 ZooKeeper 配置的更多信息,包括将外部 ZooKeeper 实例与 HBase 一起使用,请参阅zookeeper部分。

  • 浏览到 Web UI。

Web UI Port Changes

Web UI 端口更改

在低于 0.98.x 的 HBase 中,HBase Web UI 使用的 HTTP 端口从 Master 的 60010 和每个 RegionServer 的 60030 变为 Master 的 16010 和 RegionServer 的 16030.

如果一切设置正确,则应该可以使用网络浏览器连接到主服务器http://node-a.example.com:16010/或辅助主服务器http://node-b.example.com:16010/的 UI。如果可以通过localhost进行连接,但不能通过其他主机进行连接,请检查防火墙规则。您可以在其 IP 地址的端口 16030 上单击每个 RegionServer 的 Web UI,也可以单击主服务器的 Web UI 中的链接。

  • 测试当节点或服务消失时会发生什么。

使用已配置的三节点群集,情况将不会非常灵活。您仍然可以通过终止关联的进程并查看日志来测试主要 Master 或 RegionServer 的行为。

2.5. 接下来去哪里

下一章configuration提供了有关不同 HBase 运行模式,运行 HBase 的系统要求以及用于设置分布式 HBase 群集的关键配置区域的更多信息。

Apache HBase 配置

本章在Getting Started章的基础上进一步扩展,以进一步说明 Apache HBase 的配置。请仔细阅读本章,尤其是Basic Prerequisites,以确保您的 HBase 测试和部署顺利进行。还要熟悉支持和测试期望

3.配置文件

Apache HBase 使用与 Apache Hadoop 相同的配置系统。所有配置文件都位于* conf/*目录中,该目录需要与集群中的每个节点保持同步。

HBase 配置文件说明

  • backup-masters

    • 默认情况下不存在。一个纯文本文件,其中列出了主机应在其上启动备份主机进程的主机,每行一台主机。
  • hadoop-metrics2-hbase.properties

    • 用于连接 HBase Hadoop 的 Metrics2 框架。有关 Metrics2 的更多信息,请参见Hadoop Wiki 条目。默认情况下仅包含 Comments 掉的示例。
    • hbase-env.cmd hbase-env.sh *
    • 用于 Windows 和 Linux/Unix 环境的脚本,用于设置 HBase 的工作环境,包括 Java 的位置,Java 选项和其他环境变量。该文件包含许多 Comments 掉的示例以提供指导。
  • hbase-policy.xml

    • RPC 服务器用来对 Client 端请求做出授权决策的默认策略配置文件。仅在启用 HBase security时使用。
  • hbase-site.xml

    • HBase 的主要配置文件。该文件指定了覆盖 HBase 默认配置的配置选项。您可以在* docs/hbase-default.xml *上查看(但不能编辑)默认配置文件。您还可以在 HBase Web UI 的“ HBase 配置”选项卡中查看群集的整个有效配置(默认值和替代值)。
  • log4j.properties

    • 通过log4j进行 HBase 日志记录的配置文件。
  • regionservers

    • 一个纯文本文件,其中包含应在 HBase 群集中运行 RegionServer 的主机列表。默认情况下,此文件包含单个条目localhost。它应包含一列主机名或 IP 地址,每行一个,并且仅应包含localhost(如果群集中的每个节点都将在其localhost接口上运行 RegionServer)。

Checking XML Validity

在编辑 XML 时,最好使用支持 XML 的编辑器,以确保语法正确且 XML 格式正确。您还可以使用xmllintUtil 来检查 XML 格式是否正确。默认情况下,xmllint重排并将 XML 打印到标准输出。要检查格式是否正确并仅在存在错误的情况下打印输出,请使用命令xmllint -noout filename.xml

Keep Configuration In Sync Across the Cluster

在分布式模式下运行时,对 HBase 配置进行编辑后,请确保将* conf/*目录的内容复制到群集的所有节点。 HBase 不会为您这样做。使用rsyncscp或其他安全机制将配置文件复制到您的节点。对于大多数配置,服务器需要重新启动才能获取更改。动态配置是一个 exception,下面将对此进行描述。

4.基本先决条件

本节列出了必需的服务和一些必需的系统配置。

Java

下表总结了在各种 Java 版本上部署的 HBase 社区的建议。Importing“是”是指测试的基本水平和愿意帮助诊断和解决您可能遇到的问题的意愿。同样,Importing“否”或“不支持”通常意味着,如果您遇到问题,社区可能会要求您在 continue 提供帮助之前更改 Java 环境。在某些情况下,还将注意有关限制的特定指南(例如,是否进行编译/单元测试工作,特定的操作问题等)。

Long Term Support JDKs are recommended

HBase 建议下游用户使用来自 OpenJDK 项目或供应商的标记为长期支持(LTS)的 JDK 版本。截至 2018 年 3 月,这意味着 Java 8 是唯一适用的版本,下一个可能进行测试的版本将是 2018 年第三季度附近的 Java 11.

表 2. Java 对发布线的支持

HBase VersionJDK 7JDK 8JDK 9JDK 10
2.0Not SupportedyesNot SupportedNot Supported
1.3yesyesNot SupportedNot Supported
1.2yesyesNot SupportedNot Supported

Note

HBase 既不会构建也不会与 Java 6 一起运行。

Note

您必须在群集的每个节点上设置JAVA_HOME。 * hbase-env.sh *提供了一种方便的机制来执行此操作。

osUtil

  • ssh

    • HBase 广泛使用 Secure Shell(ssh)命令和 Util 在群集节点之间进行通信。集群中的每个服务器都必须运行ssh,以便可以 ManagementHadoop 和 HBase 守护程序。您必须能够使用共享密钥而不是密码通过 SSH 通过 SSH 从 Master 以及任何备份 Master 连接到所有节点,包括本地节点。您可以在“ 过程:配置无密码的 SSH 访问”中看到在 Linux 或 Unix 系统中进行此类设置的基本方法。如果您的群集节点使用 OS X,请参阅 Hadoop Wiki 上的SSH:设置远程桌面并启用自我登录部分。
  • DNS

    • HBase 使用 localhost 名自报告其 IP 地址。
  • NTP

    • 群集节点上的时钟应同步。少量的变化是可以接受的,但是较大的偏斜会导致不稳定和意外的行为。时间同步是检查集群中是否出现无法解释的问题的首要检查之一。建议您在群集上运行网络时间协议(NTP)服务或其他时间同步机制,并且所有节点都希望使用同一服务进行时间同步。请参阅* Linux 文档项目(TLDP)*的基本 NTP 配置来设置 NTP。
  • 文件和进程数限制(ulimit)

    • Apache HBase 是一个数据库。它要求能够一次打开大量文件。许多 Linux 发行版将允许单个用户打开的文件数限制为1024(在旧版本的 OS X 中为256)。您可以通过以运行 HBase 的用户身份登录时运行命令ulimit -n来检查服务器上的此限制。如果限制太低,您可能会遇到的一些问题请参见故障排除部分。您可能还会注意到以下错误:
2010-04-06 03:04:37,542 INFO org.apache.hadoop.hdfs.DFSClient: Exception increateBlockOutputStream java.io.EOFException
2010-04-06 03:04:37,542 INFO org.apache.hadoop.hdfs.DFSClient: Abandoning block blk_-6935524980745310745_1391901

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

计算打开文件的潜在数量

(StoreFiles per ColumnFamily) x (regions per RegionServer)

例如,假设一个模式每个区域有 3 个 ColumnFamily,每个 ColumnFamily 平均有 3 个 StoreFiles,并且每个 RegionServer 有 100 个区域,那么 JVM 将打开3 * 3 * 100 = 900文件 Descriptors,不计算打开的 JAR 文件,配置文件和其他文件。打开文件不会占用太多资源,并且允许用户打开太多文件的风险很小。

另一个相关的设置是允许用户一次运行的进程数。在 Linux 和 Unix 中,使用ulimit -u命令设置进程数。请勿将此与nproc命令混淆,该命令控制给定用户可用的 CPU 数量。在负载下,ulimit -u太低会导致 OutOfMemoryError 异常。

为运行 HBase 进程的用户配置文件 Descriptors 和进程的最大数量是一种 os 配置,而不是 HBase 配置。确保为实际运行 HBase 的用户更改设置也很重要。要查看哪个用户启动了 HBase,以及该用户的 ulimit 配置,请查看该实例的 HBase 日志的第一行。

示例 2. Ubuntu 上的ulimit设置

要在 Ubuntu 上配置 ulimit 设置,请编辑*/etc/security/limits.conf ,它是一个由空格分隔的四列文件。有关此文件格式的详细信息,请参考 limits.conf *的手册页。在以下示例中,第一行将具有用户名 hadoop 的 os 用户的打开文件(nofile)数量的软限制和硬限制都设置为 32768.第二行将同一用户的进程数设置为 32000.

hadoop  -       nofile  32768
hadoop  -       nproc   32000

仅当直接使用可插拔身份验证模块(PAM)环境时才应用设置。要将 PAM 配置为使用这些限制,请确保*/etc/pam.d/common-session *文件包含以下行:

session required  pam_limits.so
  • Linux Shell

    • HBase 附带的所有 shell 脚本都依赖GNU Bash shell。
  • Windows

    • 不建议在 Windows 计算机上运行生产系统。

4.1. Hadoop

下表总结了每个 HBase 版本支持的 Hadoop 版本。此表中未出现的较旧版本被认为不支持,并且可能缺少必要的功能,而较新版本未经测试,但可能合适。

基于 HBase 的版本,您应该选择最合适的 Hadoop 版本。您可以使用 Apache Hadoop 或供应商的 Hadoop 发行版。这里没有区别。有关 Hadoop 供应商的信息,请参见Hadoop Wiki

Hadoop 2.x is recommended.

Hadoop 2.x 速度更快,并且具有短路读取(请参见利用本地数据)等功能,这些功能将有助于改善 HBase 随机读取配置文件。 Hadoop 2.x 还包含重要的错误修复,这些错误修复将改善您的整体 HBase 体验。 HBase 不支持与 Hadoop 的早期版本一起运行。有关特定于不同 HBase 版本的要求,请参见下表。

Hadoop 3.x 仍处于早期访问版本中,尚未通过 HBase 社区针对生产用例的充分测试。

使用以下图例解释此表:

Hadoop 版本支持表

  • “ S” =支持

  • “ X” =不支持

  • “ NT” =未测试

HBase-1.2.xHBase-1.3.xHBase-1.5.xHBase-2.0.xHBase-2.1.x
Hadoop-2.4.xSSXXX
Hadoop-2.5.xSSXXX
Hadoop-2.6.0XXXXX
Hadoop-2.6.1+SSXSX
Hadoop-2.7.0XXXXX
Hadoop-2.7.1+SSSSS
Hadoop-2.8.[0-1]XXXXX
Hadoop-2.8.2NTNTNTNTNT
Hadoop-2.8.3+NTNTNTSS
Hadoop-2.9.0XXXXX
Hadoop-2.9.1+NTNTNTNTNT
Hadoop-3.0.xXXXXX
Hadoop-3.1.0XXXXX

Hadoop Pre-2.6.1 and JDK 1.8 Kerberos

在 Kerberos 环境中使用 2.6.1 之前的 Hadoop 版本和 JDK 1.8 时,由于 Kerberos keytab 重新登录错误,HBase 服务器可能会失败并中止。 JDK 1.7 的较新版本(1.7.0_80)也存在此问题。有关更多详细信息,请参考HADOOP-10786。在这种情况下,请考虑升级到 Hadoop 2.6.1.

Hadoop 2.6.x

如果计划在 HDFS 加密区域上运行 HBase,则基于 2.6.x 行**的 Hadoop 发行版必须应用HADOOP-11710。否则将导致群集故障和数据丢失。 Apache Hadoop 版本 2.6.1 中提供了此补丁。

Hadoop 2.y.0 Releases

从 Hadoop 2.7.0 版本开始,Hadoop PMC 习惯于在其主要版本 2 发行行中召集新的次要版本,因为它们尚未稳定/尚未准备就绪。因此,HBase 明确建议下游用户避免在这些版本之上运行。请注意,Hadoop PMC 还为 2.8.1 版本提供了相同的警告。作为参考,请参阅Apache Hadoop 2.7.0Apache Hadoop 2.8.0 版Apache Hadoop 2.8.1 版Apache Hadoop 2.9.0 版的发行公告。

Hadoop 3.0.x Releases

包含应用程序时间轴服务功能的 Hadoop 发行版可能会导致应用程序 Classpath 中出现意外版本的 HBase 类。计划使用 HBase 运行 MapReduce 应用程序的用户应确保其 YARN 服务中存在YARN-7190(当前已在 2.9.1 和 3.1.0 中修复)。

Hadoop 3.1.0 Release

Hadoop PMC 称 3.1.0 版本不稳定/无法投入生产。因此,HBase 明确建议下游用户避免在此版本之上运行。供参考,请参阅Hadoop 3.1.0 发布公告

Replace the Hadoop Bundled With HBase!

由于 HBase 依赖 Hadoop,因此将 Hadoop jarBinding 在其* lib *目录下。Binding 的罐子只能在独立模式下使用。在分布式模式下,群集上的 Hadoop 版本与 HBase 下的 Hadoop 版本相匹配是“关键”的。将 HBase lib 目录中找到的 hadoop jar 替换为您在集群上运行的版本中的等效 hadoop jar,以避免版本不匹配的问题。确保在整个群集中替换 HBase 下的 jar。 Hadoop 版本不匹配问题有多种表现形式。如果 HBase 似乎挂起,请检查是否不匹配。

4.1.1. dfs.datanode.max.transfer.threads

HDFS DataNode 可以随时提供服务的文件数量上限。在执行任何加载之前,请确保已配置 Hadoop 的* conf/hdfs-site.xml *,并将dfs.datanode.max.transfer.threads值至少设置为以下值:

<property>
  <name>dfs.datanode.max.transfer.threads</name>
  <value>4096</value>
</property>

完成上述配置后,请务必重新启动 HDFS。

如果没有适当的配置,将导致外观异常。一种表现是对缺少块的抱怨。例如:

10/12/08 20:10:31 INFO hdfs.DFSClient: Could not obtain block
          blk_XXXXXXXXXXXXXXXXXXXXXX_YYYYYYYY from any node: java.io.IOException: No live nodes
          contain current block. Will get new block locations from namenode and retry...

另请参见casestudies.max.transfer.threads,请注意,此属性以前称为dfs.datanode.max.xcievers(例如Hadoop HDFS:被 Xciever 欺骗)。

4.2. ZooKeeper 要求

ZooKeeper 3.4.x 是必需的。

5. HBase 运行模式:独立和分布式

HBase 具有两种运行模式:standalonedistributed。开箱即用,HBase 以独立模式运行。无论使用哪种模式,都需要通过编辑 HBase * conf *目录中的文件来配置 HBase。至少,您必须编辑 conf/hbase-env.sh 来告诉 HBase 使用哪个 Java。在此文件中,您设置了 HBase 环境变量,例如JVM的 heapsize 和其他选项,日志文件的首选位置等。将 JAVA_HOME 设置为指向 Java 安装的根目录。

5.1. 独立的 HBase

这是默认模式。 quickstart部分介绍了独立模式。在独立模式下,HBase 不使用 HDFS(而是使用本地文件系统),而是在同一 JVM 中运行所有 HBase 守护程序和本地 ZooKeeper。 ZooKeeper 绑定到一个知名端口,因此 Client 端可以与 HBase 进行通信。

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

5.2. Distributed

可以将分布式模式细分为分布式模式,但是所有守护程序都在单个节点上运行,也称为“ pseudo-distributed *”和“完全分布式”,其中,守护程序分布在群集中的所有节点上。 “伪分布式”与“完全分布式”的术语来自 Hadoop。

伪分布式模式可以针对本地文件系统运行,也可以针对* Hadoop 分布式文件系统*(HDFS)实例运行。全分布式模式只能在 HDFS 上运行。有关如何设置 HDFS 的信息,请参阅 Hadoop documentation。可以在http://www.alexjf.net/blog/distributed-systems/hadoop-yarn-installation-definitive-guide找到一个很好的在 Hadoop 2 上设置 HDFS 的演练。

5.2.1. Pseudo-distributed

Pseudo-Distributed Quickstart

快速入门已添加到“ quickstart”一章。参见quickstart-pseudo。本节中最初的某些信息已移至此处。

伪分布式模式只是在单个主机上运行的完全分布式模式。将此 HBase 配置仅用于测试和原型制作。不要将此配置用于生产或性能评估。

5.3. Fully-distributed

默认情况下,HBase 在独立模式下运行。提供独立模式和伪分布式模式都是为了进行小型测试。对于生产环境,建议使用分布式模式。在分布式模式下,HBase 守护程序的多个实例在群集中的多个服务器上运行。

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

此外,还配置了群集,以便多个群集节点可以注册为 RegionServers,ZooKeeper QuorumPeers 和备份 HMaster 服务器。这些配置基础都在quickstart-fully-distributed中进行了演示。

Distributed RegionServers

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

ZooKeeper 和 HBase

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

例子 3.例子分布式 HBase 集群

这是分布式 HBase 集群的基础知识* conf/hbase-site.xml 。用于实际工作的群集将包含更多自定义配置参数。大多数 HBase 配置指令具有默认值,除非在 hbase-site.xml *中覆盖了该值,否则将使用默认值。有关更多信息,请参见“ Configuration Files”。

<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 *文件,其中包含应运行备份 Master 实例的每个节点的列表。除非主控主机不可用,否则备份主控实例将处于空闲状态。

node-b.example.com
node-c.example.com

分布式 HBase 快速入门

有关具有多个 ZooKeeper,备份 HMaster 和 RegionServer 实例的简单三节点群集配置的演练,请参阅quickstart-fully-distributed

过程:HDFSClient 端配置

  • 值得注意的是,如果您在 Hadoop 集群上进行了 HDFSClient 端配置更改(例如 HDFSClient 端的配置指令),而不是服务器端配置,则必须使用以下方法之一来使 HBase 能够查看和使用这些配置更改:

  • 在* hbase-env.sh *中将指向HADOOP_CONF_DIR的指针添加到HBASE_CLASSPATH环境变量。

    • 在* ${HBASE_HOME}/conf 下添加 hdfs-site.xml (或 hadoop-site.xml *)或更佳的符号链接的副本,或

    • 如果只有少量的 HDFSClient 端配置,请将其添加到* hbase-site.xml *中。

此类 HDFSClient 端配置的示例为dfs.replication。例如,如果要以 5 的复制因子运行,除非您执行上述操作以使配置可用于 HBase,否则 HBase 将创建默认值为 3 的文件。

6.运行并确认安装

确保首先运行 HDFS。通过在HADOOP_HOME目录中运行* bin/start-hdfs.sh *来启动和停止 Hadoop HDFS 守护程序。您可以通过将putget文件测试到 Hadoop 文件系统中来确保启动正确。 HBase 通常不使用 MapReduce 或 YARN 守护程序。这些不需要启动。

如果您正在 Management 自己的 ZooKeeper,请启动并确认其正在运行,否则 HBase 将在启动过程中为您启动 ZooKeeper。

使用以下命令启动 HBase:

bin/start-hbase.sh

HBASE_HOME目录运行以上命令。

现在,您应该有一个正在运行的 HBase 实例。 HBase 日志可在* logs *子目录中找到。检查它们,特别是如果 HBase 无法启动。

HBase 还构建了一个列出重要属性的 UI。默认情况下,它部署在主主机上的端口 16010 上(HBase RegionServers 默认在端口 16020 上侦听,并在端口 16030 上构建一个信息性 HTTP 服务器)。如果主服务器在默认端口名为master.example.org的主机上运行,请将浏览器指向 http://master.example.org:16010 以查看 Web 界面。

HBase 启动后,请参见shell exercises部分,以了解如何创建表,添加数据,扫描插入以及最后禁用和删除表。

要在退出 HBase Shell 之后停止 HBase,请 Importing

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

关机可能需要一些时间才能完成。如果群集由许多计算机组成,则可能需要更长的时间。如果您正在运行分布式操作,请确保等到 HBase 完全关闭后再停止 Hadoop 守护程序。

7.默认配置

7.1. hbase-site.xml 和 hbase-default.xml

就像在 Hadoop 中将特定于站点的 HDFS 配置添加到* hdfs-site.xml 文件中一样,针对 HBase,特定于站点的自定义项也放入文件 conf/hbase-site.xml 中。有关可配置属性的列表,请参见下面的hbase 默认配置或在 src/main/resources 的 HBase 源代码中查看原始的 hbase-default.xml *源文件。

并非所有配置选项都将其显示在* hbase-default.xml *中。有些配置只会出现在源代码中。识别这些更改的唯一方法是通过代码审查。

当前,此处的更改将要求 HBase 重新启动群集以注意到更改。

7.2. HBase 默认配置

以下文档是使用默认的 hbase 配置文件* hbase-default.xml *作为源生成的。

  • hbase.tmp.dir

    • Description

本地文件系统上的临时目录。更改此设置以指向比'/ tmp'更永久的位置(java.io.tmpdir 的通常解析方法),因为在重新启动计算机时会清除'/ tmp'目录。

Default

${java.io.tmpdir}/hbase-${user.name}

  • hbase.rootdir

    • Description

区域服务器共享的目录,HBase 保留在该目录中。该 URL 应该是“完全限定”的,以包括文件系统方案。例如,要指定 HDFS 实例的 namenode 在端口 9000 上的 namenode.example.org 上运行的 HDFS 目录“/hbase”,请将此值设置为:hdfs://namenode.example.org:9000/hbase。默认情况下,我们会写入也设置了${hbase.tmp.dir}的内容(通常是/ tmp),因此请更改此配置,否则所有数据都会在计算机重新启动时丢失。

Default

${hbase.tmp.dir}/hbase

  • hbase.cluster.distributed

    • Description

群集将处于的模式。对于独立模式,可能的值为 false;对于分布式模式,可能的值为 true。如果为 false,则启动将在一个 JVM 中同时运行所有 HBase 和 ZooKeeper 守护程序。

Default

false

  • hbase.zookeeper.quorum

    • Description

ZooKeeper 集合中服务器的逗号分隔列表(此配置应已命名为 hbase.zookeeper.ensemble)。例如,“ host1.mydomain.com,host2.mydomain.com,host3.mydomain.com”。默认情况下,对于本地和伪分布式操作模式,此选项设置为 localhost。对于完全分布式的设置,应将其设置为 ZooKeeper 集成服务器的完整列表。如果在 hbase-env.sh 中设置了 HBASE_MANAGES_ZK,则这是 hbase 在群集启动/停止过程中将启动/停止 ZooKeeper 的服务器列表。在 Client 端,我们将获取此集成成员列表,并将其与 hbase.zookeeper.property.clientPort 配置放在一起。并将其作为 connectString 参数传递到 zookeeper 构造函数中。

Default

localhost

  • zookeeper.recovery.retry.maxsleeptime

    • Description

重试 Zookeeper 操作之前的最大睡眠时间(以毫秒为单位),此处需要一个最大时间,以使睡眠时间不会无限制地增长

Default

60000

  • hbase.local.dir

    • Description

本地文件系统上用作本地存储的目录。

Default

${hbase.tmp.dir}/local/

  • hbase.master.port

    • Description

HBase 主站应绑定的端口。

Default

16000

  • hbase.master.info.port

    • Description

HBase Master Web UI 的端口。如果您不希望运行 UI 实例,请设置为-1.

Default

16010

  • hbase.master.info.bindAddress

    • Description

HBase Master Web UI 的绑定地址

Default

0.0.0.0

  • hbase.master.logcleaner.plugins

    • Description

LogsCleaner 服务调用的以逗号分隔的 BaseLogCleanerDelegate 列表。这些 WAL 清理程序是按 Sequences 调用的,因此将修剪最多文件的清理程序放在前面。要实现自己的 BaseLogCleanerDelegate,只需将其放在 HBase 的 Classpath 中,然后在此处添加完全限定的类名。始终在列表中添加以上默认日志清除器。

Default

org.apache.hadoop.hbase.master.cleaner.TimeToLiveLogCleaner,org.apache.hadoop.hbase.master.cleaner.TimeToLiveProcedureWALCleaner

  • hbase.master.logcleaner.ttl

    • Description

WAL 在存档( {}/oldWALs)目录中保留多长时间,之后它将由主线程清除。该值以毫秒为单位。

Default

600000

  • hbase.master.procedurewalcleaner.ttl

    • Description

过程 WAL 将在存档目录中保留多长时间,之后将由主线程将其清除。该值以毫秒为单位。

Default

604800000

  • hbase.master.hfilecleaner.plugins

    • Description

由 HFileCleaner 服务调用的 BaseHFileCleanerDelegate 的逗号分隔列表。这些 HFiles 清理程序是按 Sequences 调用的,因此将修剪大多数文件的清理程序放在前面。要实现自己的 BaseHFileCleanerDelegate,只需将其放在 HBase 的 Classpath 中,然后在此处添加完全限定的类名。请始终在列表中添加上述默认日志清除器,因为它们将在 hbase-site.xml 中被覆盖。

Default

org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner

  • hbase.master.infoserver.redirect

    • Description

Master 是否侦听 Master Web UI 端口(hbase.master.info.port)并将请求重定向到 Master 和 RegionServer 共享的 Web UI 服务器。配置当 Master 服务于区域(不是默认值)时,这很有意义。

Default

true

  • hbase.master.fileSplitTimeout

    • Description

分割区域,在中止尝试之前要 await 文件分割步骤多长时间。默认值:600000.此设置以前在 hbase-1.x 中称为 hbase.regionserver.fileSplitTimeout。现在,Split 在主端运行,因此重命名(如果找到了“ hbase.master.fileSplitTimeout”设置,它将使用它来初始化当前的“ hbase.master.fileSplitTimeout”配置。

Default

600000

  • hbase.regionserver.port

    • Description

HBase RegionServer 绑定到的端口。

Default

16020

  • hbase.regionserver.info.port

    • Description

如果您不希望运行 RegionServer UI,请将 HBase RegionServer Web UI 的端口设置为-1.

Default

16030

  • hbase.regionserver.info.bindAddress

    • Description

HBase RegionServer Web UI 的地址

Default

0.0.0.0

  • hbase.regionserver.info.port.auto

    • Description

Master 或 RegionServer UI 是否应搜索要绑定的端口。如果 hbase.regionserver.info.port 已在使用中,则启用自动端口搜索。对于测试很有用,默认情况下处于关闭状态。

Default

false

  • hbase.regionserver.handler.count

    • Description

在 RegionServer 上旋转的 RPC 侦听器实例数。 Master 使用相同的属性来计算 master 处理程序的数量。过多的处理程序可能适得其反。将其设为 CPU 计数的倍数。如果大多数情况下是只读的,则处理程序计数接近 cpu 计数的效果很好。从两倍的 CPU 计数开始,然后从那里进行调整。

Default

30

  • hbase.ipc.server.callqueue.handler.factor

    • Description

确定呼叫队列数量的因素。值为 0 表示所有处理程序之间共享一个队列。值为 1 表示每个处理程序都有自己的队列。

Default

0.1

  • hbase.ipc.server.callqueue.read.ratio

    • Description

将呼叫队列划分为读写队列。指定的间隔(应在 0.0 到 1.0 之间)将乘以呼叫队列的数量。值为 0 表示不拆分呼叫队列,这意味着读取和写入请求都将被推送到同一组队列中。小于 0.5 的值表示读队列少于写队列。值为 0.5 表示将有相同数量的读取和写入队列。大于 0.5 的值表示将有比写队列更多的读队列。值 1.0 表示除一个队列外的所有队列均用于调度读取请求。示例:给定呼叫队列的总数为 10,读取比率为 0 表示:10 个队列将包含两个读取/写入请求。 read.ratio 为 0.3 表示:3 个队列仅包含读取请求,而 7 个队列仅包含写入请求。 read.ratio 为 0.5 意味着:5 个队列将仅包含读取请求,而 5 个队列将仅包含写入请求。 read.ratio 为 0.8 表示:8 个队列仅包含读取请求,而 2 个队列仅包含写入请求。 read.ratio 为 1 表示:9 个队列仅包含读取请求,而 1 个队列仅包含写入请求。

Default

0

  • hbase.ipc.server.callqueue.scan.ratio

    • Description

给定读取呼叫队列的数量(根据呼叫队列总数乘以 callqueue.read.ratio 计算得出),scan.ratio 属性会将读取呼叫队列分为小读取队列和长读取队列。小于 0.5 的值表示长读队列少于短读队列。值 0.5 表示将有相同数量的短读和长读队列。大于 0.5 的值表示长读取队列比短读取队列多。值为 0 或 1 表示对获取和扫描使用相同的队列集。示例:假设读取呼叫队列的总数为 8,则 scan.ratio 为 0 或 1 表示:8 个队列将同时包含长读取请求和短读取请求。 scan.ratio 为 0.3 表示:2 个队列将仅包含长读请求,而 6 个队列将仅包含短读请求。 scan.ratio 为 0.5 表示:4 个队列将仅包含长读请求,而 4 个队列将仅包含短读请求。 scan.ratio 为 0.8 表示:6 个队列将仅包含长读请求,而 2 个队列将仅包含短读请求。

Default

0

  • hbase.regionserver.msginterval

    • Description

从 RegionServer 到 Master 的消息之间的间隔(以毫秒为单位)。

Default

3000

  • hbase.regionserver.logroll.period

    • Description

无论提交多少编辑,我们都会滚动提交日志的时间段。

Default

3600000

  • hbase.regionserver.logroll.errors.tolerated

    • Description

在触发服务器异常终止之前,我们将允许的连续 WAL 关闭错误数。如果在日志滚动过程中关闭当前 WAL 写入器失败,则设置为 0 将导致区域服务器中止。即使是很小的值(2 或 3)也将使区域服务器克服瞬态 HDFS 错误。

Default

2

  • hbase.regionserver.hlog.reader.impl

    • Description

WAL 文件阅读器实现。

Default

org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader

  • hbase.regionserver.hlog.writer.impl

    • Description

WAL 文件编写器实现。

Default

org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter

  • hbase.regionserver.global.memstore.size

    • Description

在阻止新更新并强制进行刷新之前,区域服务器中所有内存存储区的最大大小。默认为堆的 40%(0.4)。阻止更新并强制进行刷新,直到区域服务器中所有内存存储的大小达到 hbase.regionserver.global.memstore.size.lower.limit。此配置中的默认值有意保留为空,以保留旧的 hbase.regionserver.global.memstore.upperLimit 属性(如果存在)。

Default

none

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

    • Description

强制刷新之前,区域服务器中所有内存存储区的最大大小。默认为 hbase.regionserver.global.memstore.size(0.95)的 95%。如果由于内存存储限制而阻止更新,则此值的 100%值将导致最小的刷新发生。此配置中的默认值有意保留为空,以保留旧的 hbase.regionserver.global.memstore.lowerLimit 属性(如果存在)。

Default

none

  • hbase.systemtables.compacting.memstore.type

    • Description

确定用于系统表(如 META,名称空间表等)的内存存储的类型。默认情况下,类型为 NONE,因此我们对所有系统表使用默认的内存存储。如果我们需要对系统表使用压缩存储区,则将此属性设置为 BASIC/EAGER

Default

NONE

  • hbase.regionserver.optionalcacheflushinterval

    • Description

编辑内容在自动刷新之前在内存中保留的最长时间。默认值 1 小时。将其设置为 0 以禁用自动刷新。

Default

3600000

  • hbase.regionserver.dns.interface

    • Description

区域服务器应从中报告其 IP 地址的网络接口的名称。

Default

default

  • hbase.regionserver.dns.nameserver

    • Description

区域服务器应使用该名称服务器(DNS)的主机名或 IP 地址来确定主机用于通讯和显示目的的主机名。

Default

default

  • hbase.regionserver.region.split.policy

    • Description

拆分策略确定何时应拆分区域。当前可用的其他各种拆分策略为 BusyRegionSplitPolicy,ConstantSizeRegionSplitPolicy,DisabledRegionSplitPolicy,DelimitedKeyPrefixRegionSplitPolicy,KeyPrefixRegionSplitPolicy 和 SteppingSplitPolicy。 DisabledRegionSplitPolicy 阻止手动区域分割。

Default

org.apache.hadoop.hbase.regionserver.SteppingSplitPolicy

  • hbase.regionserver.regionSplitLimit

    • Description

区域数量的限制,之后将不再进行区域划分。这不是对区域数量的硬限制,但可作为区域服务器在特定限制后停止拆分的准则。默认设置为 1000.

Default

1000

  • zookeeper.session.timeout

    • Description

ZooKeeper 会话超时(以毫秒为单位)。它以两种不同的方式使用。首先,在 HBase 用于连接到集成体的 ZKClient 端中使用此值。 HBase 在启动 ZK 服务器时也使用它,并将其作为“ maxSessionTimeout”传递。参见https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkSessions。例如,如果 HBase 区域服务器连接到也由 HBaseManagement 的 ZK 集成,则会话超时将是此配置指定的会话超时。但是,连接到使用不同配置 Management 的集成服务器的区域服务器将受到该集成服务器的 maxSessionTimeout 的影响。因此,即使 HBase 可能建议使用 90 秒,该集合的最大超时值也可以低于此值,并且它将具有优先权。 ZK 随附的当前默认 maxSessionTimeout 为 40 秒,比 HBase 的低。

Default

90000

  • zookeeper.znode.parent

    • Description

ZooKeeper 中用于 HBase 的根 ZNode。配置有相对路径的所有 HBase 的 ZooKeeper 文件都将位于此节点下。默认情况下,所有 HBase 的 ZooKeeper 文件路径都配置有相对路径,因此除非更改,否则它们都将位于此目录下。

Default

/hbase

  • zookeeper.znode.acl.parent

    • Description

根 ZNode 用于访问控制列表。

Default

acl

  • hbase.zookeeper.dns.interface

    • Description

ZooKeeper 服务器应从中报告其 IP 地址的网络接口的名称。

Default

default

  • hbase.zookeeper.dns.nameserver

    • Description

ZooKeeper 服务器应使用其名称服务器(DNS)的主机名或 IP 地址来确定主机用于通信和显示目的的主机名。

Default

default

  • hbase.zookeeper.peerport

    • Description

ZooKeeper 对等方用来互相通信的端口。有关更多信息,请参见https://zookeeper.apache.org/doc/r3.3.3/zookeeperStarted.html#sc_RunningReplicatedZooKeeper

Default

2888

  • hbase.zookeeper.leaderport

    • Description

ZooKeeper 用于领导者选举的端口。有关更多信息,请参见https://zookeeper.apache.org/doc/r3.3.3/zookeeperStarted.html#sc_RunningReplicatedZooKeeper

Default

3888

  • hbase.zookeeper.property.initLimit

    • Description

ZooKeeper 的配置 zoo.cfg 中的属性。初始同步阶段可以进行的滴答声数量。

Default

10

  • hbase.zookeeper.property.syncLimit

    • Description

ZooKeeper 的配置 zoo.cfg 中的属性。在发送请求和获得确认之间可以经过的滴答数。

Default

5

  • hbase.zookeeper.property.dataDir

    • Description

ZooKeeper 的配置 zoo.cfg 中的属性。快照存储的目录。

Default

${hbase.tmp.dir}/zookeeper

  • hbase.zookeeper.property.clientPort

    • Description

ZooKeeper 的配置 zoo.cfg 中的属性。Client 端将连接的端口。

Default

2181

  • hbase.zookeeper.property.maxClientCnxns

    • Description

ZooKeeper 的配置 zoo.cfg 中的属性。限制单个 Client 端通过 IP 地址标识到 ZooKeeper 集成的单个成员的并发连接数(在套接字级别)。设置为高值可避免独立运行和伪分布式运行的 zk 连接问题。

Default

300

  • hbase.client.write.buffer

    • Description

BufferedMutator 写缓冲区的默认大小(以字节为单位)。较大的缓冲区会占用更多的内存-在 Client 端和服务器端,因为服务器会实例化传递的写缓冲区来处理它-但较大的缓冲区会减少制作的 RPC 数量。要估计服务器端使用的内存,请评估 hbase.client.write.buffer * hbase.regionserver.handler.count

Default

2097152

  • hbase.client.pause

    • Description

常规 Client 端暂停值。在运行重试失败的获取,区域查找等之前,主要用作 await 值。请参见 hbase.client.retries.number,以获取有关我们如何从此初始暂停量回退以及此暂停如何进行重试的描述。

Default

100

  • hbase.client.pause.cqtbe

    • Description

是否对 CallQueueTooBigException(cqtbe)使用特殊的 Client 端暂停。如果您观察到来自同一 RegionServer 的频繁 CQTBE 并且那里的呼叫队列保持满状态,则将此属性设置为比 hbase.client.pause 高的值。

Default

none

  • hbase.client.retries.number

    • Description

最大重试次数。用作所有可重试操作的最大值,例如获取单元格的值,开始行更新等。重试间隔是基于 hbase.client.pause 的粗略函数。首先,我们以该时间间隔重试,然后通过退避,我们很快就达到了每十秒钟重试一次的目的。有关备份如何增加的信息,请参见 HConstants#RETRY_BACKOFF。更改此设置和 hbase.client.pause 以适合您的工作量。

Default

15

  • hbase.client.max.total.tasks

    • Description

一个 HTable 实例将发送到群集的最大并发变异任务数。

Default

100

  • hbase.client.max.perserver.tasks

    • Description

单个 HTable 实例将发送到单个区域服务器的最大并发变异任务数。

Default

2

  • hbase.client.max.perregion.tasks

    • Description

Client 将维护到一个区域的最大并发突变任务数。也就是说,如果已经对该区域进行了 hbase.client.max.perregion.tasks 写入,则在完成某些写入之前,不会将新的 puts 发送到该区域。

Default

1

  • hbase.client.perserver.requests.threshold

    • Description

所有 Client 端线程(进程级别)中一台服务器的并发暂挂请求的最大数量。超出的请求将立即引发 ServerTooBusyException,以防止仅一台慢速区域服务器占用和阻止用户的线程。如果您使用固定数量的线程以同步方式访问 HBase,请将其设置为与线程数量相关的合适值将对您有所帮助。有关详情,请参见https://issues.apache.org/jira/browse/HBASE-16388

Default

2147483647

  • hbase.client.scanner.caching

    • Description

如果未从(本地,Client 端)内存提供服务,则在扫描器上调用 next 时我们尝试获取的行数。此配置与 hbase.client.scanner.max.result.size 一起使用,以尝试有效地使用网络。默认情况下,默认值为 Integer.MAX_VALUE,以便网络将填充 hbase.client.scanner.max.result.size 定义的块大小,而不是受特定的行数限制,因为行的大小因表而异。如果您提前知道一次扫描不需要多于一定数量的行,则应通过 Scan#setCaching 将此配置设置为该行限制。较高的缓存值将启用更快的扫描程序,但会消耗更多的内存,并且当缓存为空时,对 next 的某些调用可能会花费越来越长的时间。请勿将此值设置为两次调用之间的时间大于扫描程序的超时时间;即 hbase.client.scanner.timeout.period

Default

2147483647

  • hbase.client.keyvalue.maxsize

    • Description

指定 KeyValue 实例的组合最大允许大小。这是为存储文件中保存的单个条目设置上限。由于无法拆分它们,因此有助于避免由于数据太大而无法进一步拆分区域。将其设置为最大区域大小的一小部分似乎是明智的。将其设置为零或更少将禁用检查。

Default

10485760

  • hbase.server.keyvalue.maxsize

    • Description

单个单元格的最大允许大小,包括值和所有关键组件。小于或等于 0 的值将禁用该检查。默认值为 10MB。这是一项安全设置,可以保护服务器免受 OOM 情况的影响。

Default

10485760

  • hbase.client.scanner.timeout.period

    • Description

Client 端扫描程序的租用期限(以毫秒为单位)。

Default

60000

  • hbase.client.localityCheck.threadPoolSize

    • Default

2

  • hbase.bulkload.retries.number

    • Description

最大重试次数。这是面对分裂操作时尝试进行的原子批量加载的最大迭代次数 0 表示永不放弃。

Default

10

  • hbase.master.balancer.maxRitPercent

    • Description

平衡时过渡区域的最大百分比。默认值为 1.0. 因此,没有平衡器节流。如果将此配置设置为 0.01,则表示平衡时最多有 1%的过渡区域。然后,平衡时群集的可用性至少为 99%。

Default

1.0

  • hbase.balancer.period

    • Description

区域平衡器在主服务器中运行的时间段。

Default

300000

  • hbase.normalizer.period

    • Description

区域规范化器在主服务器中运行的时间段。

Default

300000

  • hbase.regions.slop

    • Description

如果任何区域服务器具有平均(平均*斜率)区域,则重新平衡。在 StochasticLoadBalancer(默认负载均衡器)中,此参数的默认值为 0.001,而在其他负载均衡器(即 SimpleLoadBalancer)中默认值为 0.2.

Default

0.001

  • hbase.server.thread.wakefrequency

    • Description

两次搜索工作之间的睡眠时间(以毫秒为单位)。用作日志线程等服务线程的睡眠间隔。

Default

10000

  • hbase.server.versionfile.writeattempts

    • Description

在终止之前尝试重试几次尝试写入版本文件。每次尝试都由 hbase.server.thread.wakefrequency 毫秒分隔。

Default

3

  • hbase.hregion.memstore.flush.size

    • Description

如果内存大小超过此字节数,则将内存存储刷新到磁盘。值由运行每个 hbase.server.thread.wakefrequency 的线程检查。

Default

134217728

  • hbase.hregion.percolumnfamilyflush.size.lower.bound.min

    • Description

如果使用了 FlushLargeStoresPolicy 并且有多个列族,那么每次我们达到内存存储区的总限制时,我们都会找出所有其内存存储区超出“下限”的列族,并仅刷新它们,同时将其他存储区保留在内存中。默认情况下,“下界”将为“ hbase.hregion.memstore.flush.size/column_family_number”,除非该属性的值大于该值。如果没有一个家族的内存大小超过下限,则将刷新所有内存(就像往常一样)。

Default

16777216

  • hbase.hregion.preclose.flush.size

    • Description

如果在关闭时某个区域中的存储器大小等于或大于此大小,则在设置区域已关闭标志并使该区域脱机之前,运行“预冲洗”以清除存储器。关闭时,在关闭标志下运行刷新以清空内存。在这段时间内,该地区处于离线状态,我们没有进行任何写操作。如果 memstore 内容很大,则刷新可能需要很长时间才能完成。预刷新的目的是在放置关闭标志并使区域脱机之前清理掉大部分的内存存储,因此在关闭标志下运行的刷新几乎没有作用。

Default

5242880

  • hbase.hregion.memstore.block.multiplier

    • Description

如果 memstore 具有 hbase.hregion.memstore.block.multiplier 乘以 hbase.hregion.memstore.flush.size 字节,则阻止更新。防止更新流量激增期间失控的存储器。如果没有上限,则内存存储将进行填充,以便在刷新结果刷新文件时需要花费很长时间来压缩或拆分,或更糟糕的是,我们 OOME。

Default

4

  • hbase.hregion.memstore.mslab.enabled

    • Description

启用 MemStore-Local Allocation Buffer,该功能可防止在重写入负载下发生堆碎片。这可以减少大堆上停止世界 GC 暂停的频率。

Default

true

  • hbase.hregion.max.filesize

    • Description

最大 HFile 大小。如果区域的 HFiles 大小的总和超过了该值,则该区域将一分为二。

Default

10737418240

  • hbase.hregion.majorcompaction

    • Description

两次大压实之间的时间,以毫秒为单位。设置为 0 以禁用基于时间的自动专业压缩。用户请求的基于大小的大型压缩仍将运行。将该值乘以 hbase.hregion.majorcompaction.jitter 可以使压缩在给定的时间范围内在某个随机时间开始。默认值为 7 天,以毫秒为单位。如果大型压缩在您的环境中造成破坏,则可以将其配置为在部署的非高峰时间运行,或者通过将此参数设置为 0 来禁用基于时间的大型压缩,并在 cron 作业或其他作业中运行大型压缩外部机制。

Default

604800000

  • hbase.hregion.majorcompaction.jitter

    • Description

应用于 hbase.hregion.majorcompaction 的乘数,使压缩在 hbase.hregion.majorcompaction 的任一侧发生给定的时间。数量越小,紧缩将发生在 hbase.hregion.majorcompaction 间隔上。

Default

0.50

  • hbase.hstore.compactionThreshold

    • Description

如果在任何一个 Store 中都存在超过此数目的 StoreFile(每次刷新 MemStore 都会写入一个 StoreFile),则会运行压缩以将所有 StoreFile 重写为一个 StoreFile。较大的值会延迟压缩,但是当压缩确实发生时,则需要更长的时间才能完成。

Default

3

  • hbase.hstore.flusher.count

    • Description

刷新线程数。如果线程较少,则将对 MemStore 刷新进行排队。如果线程更多,则将并行执行刷新,从而增加 HDFS 的负载,并可能导致更多的压缩。

Default

2

  • hbase.hstore.blockingStoreFiles

    • Description

如果在任何一个 Store 中都存在超过此数目的 StoreFile(每次刷新 MemStore 都写入一个 StoreFile),则将阻止对此区域进行更新,直到压缩完成或超过 hbase.hstore.blockingWaitTime。

Default

16

  • hbase.hstore.blockingWaitTime

    • Description

达到 hbase.hstore.blockingStoreFiles 定义的 StoreFile 限制后,区域将阻止更新的时间。经过此时间后,即使压缩尚未完成,该区域也将停止阻止更新。

Default

90000

  • hbase.hstore.compaction.min

    • Description

运行压缩之前必须符合压缩条件的最小 StoreFiles 数。调整 hbase.hstore.compaction.min 的目标是避免最终产生太多无法压缩的微小 StoreFiles。每次在存储中有两个 StoreFiles 时,将此值设置为 2 都会导致较小的压缩,这可能不合适。如果将此值设置得太高,则所有其他值都需要相应地进行调整。在大多数情况下,默认值为适当。在以前的 HBase 版本中,参数 hbase.hstore.compaction.min 命名为 hbase.hstore.compactionThreshold。

Default

3

  • hbase.hstore.compaction.max

    • Description

无论合格的 StoreFiles 数量如何,一次较小的压缩将选择的 StoreFiles 的最大数量。有效地,hbase.hstore.compaction.max 的值控制完成一次压缩的时间长度。将其设置为更大意味着压缩中将包含更多 StoreFiles。在大多数情况下,默认值为适当。

Default

10

  • hbase.hstore.compaction.min.size

    • Description

小于此大小的 StoreFile(或使用 ExploringCompactionPolicy 时选择的 StoreFiles)始终可以进行较小的压缩。大小更大的 HFile 由 hbase.hstore.compaction.ratio 评估以确定它们是否合格。因为此限制表示所有小于此值的 StoreFiles 的“自动包含”限制,所以在需要大量写入 1-2 MB 范围的 StoreFiles 的写繁重环境中,可能需要减小此值,因为每个 StoreFile 都将作为目标。进行压缩,生成的 StoreFiles 可能仍小于最小大小,需要进一步压缩。如果降低此参数,则比率检查将更快地触发。这解决了早期版本的 HBase 中遇到的一些问题,但是在大多数情况下不再需要更改此参数。默认值:128 MB,以字节为单位。

Default

134217728

  • hbase.hstore.compaction.max.size

    • Description

大于此大小的 StoreFile(或使用 ExploringCompactionPolicy 时选择的 StoreFiles)将被排除在压缩之外。增大 hbase.hstore.compaction.max.size 的效果较小,而较大的 StoreFiles 则不会经常压缩。如果您认为压缩过于频繁而没有太多好处,则可以尝试提高此值。默认值:LONG.MAX_VALUE 的值,以字节为单位。

Default

9223372036854775807

  • hbase.hstore.compaction.ratio

    • Description

对于较小的压缩,此比率用于确定大于 hbase.hstore.compaction.min.size 的给定 StoreFile 是否适合压缩。它的作用是限制大型 StoreFiles 的压缩。 hbase.hstore.compaction.ratio 的值表示为浮点十进制。很大的比例(例如 10)将产生一个巨大的 StoreFile。相反,较低的值(例如.25)将产生类似于 BigTable 压缩算法的行为,从而产生四个 StoreFiles。建议在 1.0 到 1.4 之间使用一个适中的值。调整此值时,您要平衡写入成本和读取成本。将值提高(到 1.4 之类)会增加写入成本,因为您将压缩更大的 StoreFiles。但是,在读取期间,HBase 将需要搜索较少的 StoreFiles 来完成读取。如果您无法利用布隆过滤器,请考虑使用这种方法。否则,您可以将此值降低到 1.0 之类,以减少写入的背景成本,并使用 Bloom 过滤器控制读取期间接触到的 StoreFiles 的数量。在大多数情况下,默认值为适当。

Default

1.2F

  • hbase.hstore.compaction.ratio.offpeak

    • Description

允许您设置不同的比率(默认情况下更具侵略性),以确定非高峰时段压缩中是否包含较大的 StoreFiles。以与 hbase.hstore.compaction.ratio 相同的方式工作。仅在同时启用了 hbase.offpeak.start.hour 和 hbase.offpeak.end.hour 的情况下适用。

Default

5.0F

  • hbase.hstore.time.to.purge.deletes

    • Description

延迟清除带有 Future 时间戳记的删除标记的时间。如果未设置或设置为 0,则所有删除标记(包括带有 Future 时间戳记的标记)将在下一次主要压缩期间清除。否则,将保留删除标记,直到在标记的时间戳加上此设置的值之后发生的主要压缩为止(以毫秒为单位)。

Default

0

  • hbase.offpeak.start.hour

    • Description

非高峰时间的开始,表示为 0 到 23 之间的一个整数(包括 0 和 23)。设置为-1 可禁用非峰值。

Default

-1

  • hbase.offpeak.end.hour

    • Description

非高峰时段的结束时间,以 0 到 23 之间的一个整数表示,包括 0 和 23.设置为-1 可禁用非峰值。

Default

-1

  • hbase.regionserver.thread.compaction.throttle

    • Description

有两种不同的线程池用于压缩,一种用于大压缩,另一种用于小压缩。这有助于保持精简表(例如 hbase:meta)的紧缩。如果压缩大于此阈值,它将进入大型压缩池。在大多数情况下,默认值为适当。默认值:2 x hbase.hstore.compaction.max x hbase.hregion.memstore.flush.size(默认为 128MB)。值字段假定 hbase.hregion.memstore.flush.size 的值与默认值保持不变。

Default

2684354560

  • hbase.regionserver.majorcompaction.pagecache.drop

    • Description

指定是否通过主要压缩将读取/写入的页面丢弃到系统页面缓存中。将其设置为 true 有助于防止大型压缩污染页面缓存,这几乎总是需要的,尤其是对于内存/存储比率低/中等的群集。

Default

true

  • hbase.regionserver.minorcompaction.pagecache.drop

    • Description

指定是否通过较小的压缩将读取/写入的页面丢弃到系统页面缓存中。将其设置为 true 有助于防止较小的压缩对页面缓存造成污染,这在内存与存储比率低或写入量很大的群集中最有用。当大量读取都在最近写入的数据上时,您可能希望在中等到低的写入工作量下将其设置为 false。

Default

true

  • hbase.hstore.compaction.kv.max

    • Description

刷新或压缩时要批量读取和写入的 KeyValue 的最大数量。如果您有较大的键值和内存不足异常问题,请将其设置为较低,如果行宽且较小的行,请将其设置为较高。

Default

10

  • hbase.storescanner.parallel.seek.enable

    • Description

在 StoreScanner 中启用 StoreFileScanner 并行查找功能,该功能可以减少特殊情况下的响应延迟。

Default

false

  • hbase.storescanner.parallel.seek.threads

    • Description

如果启用了并行查找功能,则为默认线程池大小。

Default

10

  • hfile.block.cache.size

    • Description

分配给 StoreFile 使用的块缓存的最大堆的百分比(-Xmx 设置)。默认值为 0.4 表示分配 40%。设置为 0 以禁用,但不建议这样做;您至少需要足够的缓存来保存存储文件索引。

Default

0.4

  • hfile.block.index.cacheonwrite

    • Description

这允许在写入索引时将非根多级索引块放入块高速缓存中。

Default

false

  • hfile.index.block.max.size

    • Description

当多级块索引中的叶级,中间级或根级索引块的大小增长到该大小时,将写出该块并开始一个新块。

Default

131072

  • hbase.bucketcache.ioengine

    • Description

存储桶式缓存内容的位置。其中之一:堆,文件,文件或 mmap。如果是一个或多个文件,请将其设置为 file:PATH_TO_FILE。 mmap 表示内容将在 mmaped 文件中。使用 mmap:PATH_TO_FILE。有关更多信息,请参见http://hbase.apache.org/book.html#offheap.blockcache

Default

none

  • hbase.bucketcache.size

    • Description

EITHER 代表要提供给缓存的总堆内存大小的百分比的浮点数(如果<1.0),或者,它是 BucketCache 的总容量(以兆字节为单位)。默认值:0.0

Default

none

  • hbase.bucketcache.bucket.sizes

    • Description

以逗号分隔的存储区存储区大小列表。可以是多种尺寸。按从小到大的 Sequences 列出块大小。您使用的大小将取决于您的数据访问模式。必须为 256 的倍数,否则当您从缓存中读取数据时,将遇到“ java.io.IOException:无效的 HFile 块魔术”。如果在此处未指定任何值,则将选择代码中设置的默认存储桶大小(请参见 BucketAllocator#DEFAULT_BUCKET_SIZES)。

Default

none

  • hfile.format.version

    • Description

用于新文件的 HFile 格式版本。第 3 版增加了对 hfiles 中标签的支持(请参阅http://hbase.apache.org/book.html#hbase.tags)。另请参阅配置“ hbase.replication.rpc.codec”。

Default

3

  • hfile.block.bloom.cacheonwrite

    • Description

为复合 Bloom 过滤器的内联块启用写时缓存。

Default

false

  • io.storefile.bloom.block.size

    • Description

复合布隆过滤器的单个块(“块”)的字节大小。此大小是近似值,因为 Bloom 块只能插入数据块边界,并且每个数据块的键数有所不同。

Default

131072

  • hbase.rs.cacheblocksonwrite

    • Description

块完成后是否应将 HFile 块添加到块缓存中。

Default

false

  • hbase.rpc.timeout

    • Description

这是为 RPC 层定义的,HBaseClient 端应用程序需要花费多长时间(毫秒)来进行远程调用以使超时。它使用 ping 来检查连接,但最终将抛出 TimeoutException。

Default

60000

  • hbase.client.operation.timeout

    • Description

操作超时是一个顶级限制(毫秒),可确保 Table 中的阻止操作不会超过此限制。在每个操作中,如果 rpc 请求由于超时或其他原因而失败,它将重试直到成功或抛出 RetriesExhaustedException。但是,如果阻塞的总时间在重试用尽之前达到了操作超时,它将提前中断并抛出 SocketTimeoutException。

Default

1200000

  • hbase.cells.scanned.per.heartbeat.check

    • Description

在两次心跳检查之间扫描的细胞数。心跳检查在扫描处理期间进行,以确定服务器是否应停止扫描以便将心跳消息发送回 Client 端。心跳消息用于在长时间运行的扫描期间保持 Client 端-服务器连接保持活动状态。较小的值表示心跳检查将更频繁地发生,因此将对扫描的执行时间提供更严格的限制。较大的值表示心跳检查发生的频率较低

Default

10000

  • hbase.rpc.shortoperation.timeout

    • Description

这是“ hbase.rpc.timeout”的另一个版本。对于群集内的那些 RPC 操作,我们依靠此配置为短操作设置短超时限制。例如,区域服务器尝试向活动主服务器报告的较短 rpc 超时时间可以使主服务器故障转移过程更快。

Default

10000

  • hbase.ipc.client.tcpnodelay

    • Description

设置 rpc 套接字连接没有延迟。参见http://docs.oracle.com/javase/1.5.0/docs/api/java/net/Socket.html#getTcpNoDelay(

Default

true

  • hbase.regionserver.hostname

    • Description

此配置适用于 maven:除非您真的知道自己在做什么,否则请不要设置其值。设置为非空值时,它表示基础服务器的(外部)主机名。有关详情,请参见https://issues.apache.org/jira/browse/HBASE-12954

Default

none

  • hbase.regionserver.hostname.disable.master.reversedns

    • Description

此配置适用于 maven:除非您真的知道自己在做什么,否则请不要设置其值。设置为 true 时,regionserver 将使用当前节点的主机名作为服务器名,而 HMaster 将跳过反向 DNS 查找,而是使用 regionserver 发送的主机名。请注意,此配置和 hbase.regionserver.hostname 是互斥的。有关更多详细信息,请参见https://issues.apache.org/jira/browse/HBASE-18226

Default

false

  • hbase.master.keytab.file

    • Description

kerberos keytab 文件的完整路径,用于登录已配置的 HMaster 服务器主体。

Default

none

  • hbase.master.kerberos.principal

    • Description

例如“ hbase/[email protected]”。用来运行 HMaster 进程的 Kerberos 主体名称。主体名称应采用以下格式:user/hostname @ DOMAIN。如果将“ _HOST”用作主机名部分,它将被正在运行的实例的实际主机名替换。

Default

none

  • hbase.regionserver.keytab.file

    • Description

kerberos keytab 文件的完整路径,用于登录已配置的 HRegionServer 服务器主体。

Default

none

  • hbase.regionserver.kerberos.principal

    • Description

例如“ hbase/[email protected]”。用来运行 HRegionServer 进程的 Kerberos 主体名称。主体名称应采用以下格式:user/hostname @ DOMAIN。如果将“ _HOST”用作主机名部分,它将被正在运行的实例的实际主机名替换。该主体的条目必须存在于 hbase.regionserver.keytab.file 中指定的文件中

Default

none

  • hadoop.policy.file

    • Description

RPC 服务器用来对 Client 端请求做出授权决策的策略配置文件。仅在启用 HBase 安全性时使用。

Default

hbase-policy.xml

  • hbase.superuser

    • Description

在整个集群中,无论存储的 ACL 如何,都被授予完全特权的用户或组(以逗号分隔)的列表。仅在启用 HBase 安全性时使用。

Default

none

  • hbase.auth.key.update.interval

    • Description

服务器中认证令牌的主密钥的更新间隔(以毫秒为单位)。仅在启用 HBase 安全性时使用。

Default

86400000

  • hbase.auth.token.max.lifetime

    • Description

认证令牌到期的最大生存时间(以毫秒为单位)。仅在启用 HBase 安全性时使用。

Default

604800000

  • hbase.ipc.client.fallback-to-simple-auth-allowed

    • Description

当 Client 端配置为尝试安全连接,但尝试连接到不安全的服务器时,该服务器可能会指示 Client 端切换到 SASL SIMPLE(不安全)身份验证。此设置控制 Client 端是否将接受来自服务器的此指令。如果为 false(默认值),则 Client 端将不允许回退到 SIMPLE 身份验证,并将中止连接。

Default

false

  • hbase.ipc.server.fallback-to-simple-auth-allowed

    • Description

当服务器配置为需要安全连接时,它将使用 SASL SIMPLE(不安全)身份验证拒绝来自 Client 端的连接尝试。此设置允许安全服务器在 Client 端请求时接受来自 Client 端的 SASL SIMPLE 连接。如果为 false(默认值),则服务器将不允许回退到 SIMPLE 身份验证,并且将拒绝连接。警告:在将 Client 端转换为安全身份验证时,仅应将此设置用作临时措施。为了安全操作,必须将其禁用。

Default

false

  • hbase.display.keys

    • Description

如果将其设置为 true,则 webUI 会显示所有开始/结束键,作为表详细信息,区域名称等的一部分。如果将其设置为 false,则将隐藏键。

Default

true

  • hbase.coprocessor.enabled

    • Description

启用或禁用协处理器加载。如果为“ false”(禁用),则将忽略任何其他与协处理器相关的配置。

Default

true

  • hbase.coprocessor.user.enabled

    • Description

启用或禁用用户(aka 表)协处理器加载。如果为“ false”(禁用),则将忽略表 Descriptors 中的任何表协处理器属性。如果“ hbase.coprocessor.enabled”为“ false”,则此设置无效。

Default

true

  • hbase.coprocessor.region.classes

    • Description

默认情况下,在所有表上加载的逗号分隔的协处理器列表。对于任何重写协处理器方法,将按 Sequences 调用这些类。在实现自己的协处理器之后,只需将其放在 HBase 的 Classpath 中,然后在此处添加完全限定的类名即可。也可以通过设置 HTableDescriptor 来按需加载协处理器。

Default

none

  • hbase.coprocessor.master.classes

    • Description

逗号分隔的 org.apache.hadoop.hbase.coprocessor.MasterObserver 协处理器列表,默认情况下在活动 HMaster 进程中加载。对于任何已实现的协处理器方法,将按 Sequences 调用列出的类。在实现自己的 MasterObserver 之后,只需将其放入 HBase 的 Classpath 中,并在此处添加完全限定的类名。

Default

none

  • hbase.coprocessor.abortonerror

    • Description

设置为 true 会导致在协处理器无法加载,初始化失败或引发意外的 Throwable 对象时导致托管服务器(主服务器或区域服务器)中止。将其设置为 false 将允许服务器 continue 执行,但是有问题的协处理器的系统范围状态将变得不一致,因为它将仅在一部分服务器中正确执行,因此这仅对调试有用。

Default

true

  • hbase.rest.port

    • Description

HBase REST 服务器的端口。

Default

8080

  • hbase.rest.readonly

    • Description

定义启动 REST 服务器的模式。可能的值是:false:允许所有 HTTP 方法-GET/PUT/POST/DELETE。 true:仅允许 GET 方法。

Default

false

  • hbase.rest.threads.max

    • Description

REST 服务器线程池的最大线程数。池中的线程被重用以处理 REST 请求。这控制了并发处理的最大请求数。这可能有助于控制 REST 服务器使用的内存,以避免 OOM 问题。如果线程池已满,则传入的请求将排队,并 await 一些空闲线程。

Default

100

  • hbase.rest.threads.min

    • Description

REST 服务器线程池的最小线程数。线程池始终至少具有这些线程数,因此 REST 服务器已准备就绪,可以处理传入的请求。

Default

2

  • hbase.rest.support.proxyuser

    • Description

允许运行 REST 服务器以支持代理用户模式。

Default

false

  • hbase.defaults.for.version.skip

    • Description

设置为 true 可以跳过“ hbase.defaults.for.version”检查。将其设置为 true 可以在 Maven 生成的另一端以外的环境中使用。即在 IDE 中运行。您需要将此布尔值设置为 true 以避免看到 RuntimeException 投诉:“ hbase-default.xml 文件似乎适用于旧版本的 HBase( ${}),此版本为 X.X.X-SNAPSHOT”

Default

false

  • hbase.table.lock.enable

    • Description

设置为 true 以启用将锁锁定在 zookeeper 中以进行模式更改操作。来自主服务器的表锁定可防止将并发模式修改为损坏的表状态。

Default

true

  • hbase.table.max.rowsize

    • Description

未设置行内扫描标志的“获取”或“扫描”单行的最大大小(以字节为单位)(默认为 1 Gb)。如果行大小超过此限制,则将 RowTooBigException 抛出给 Client 端。

Default

1073741824

  • hbase.thrift.minWorkerThreads

    • Description

线程池的“核心大小”。在每个连接上都会创建新线程,直到创建了这么多线程。

Default

16

  • hbase.thrift.maxWorkerThreads

    • Description

线程池的最大大小。当挂起的请求队列溢出时,将创建新线程,直到它们的数量达到该数量为止。此后,服务器开始断开连接。

Default

1000

  • hbase.thrift.maxQueuedRequests

    • Description

在队列中 await 的未决 Thrift 连接的最大数量。如果池中没有空闲线程,则服务器会将请求排队。仅当队列溢出时,才添加新线程,直到 hbase.thrift.maxQueuedRequests 线程。

Default

1000

  • hbase.regionserver.thrift.framed

    • Description

在服务器端使用 Thrift TFramedTransport。对于节俭服务器,这是建议的传输方式,并且在 Client 端需要类似的设置。将其更改为 false 将选择默认传输方式,当由于 THRIFT-601 发出格式错误的请求时,该传输方式容易受到 DoS 攻击。

Default

false

  • hbase.regionserver.thrift.framed.max_frame_size_in_mb

    • Description

使用成帧传输时的默认帧大小,以 MB 为单位

Default

2

  • hbase.regionserver.thrift.compact

    • Description

使用 Thrift TCompactProtocol 二进制序列化协议。

Default

false

  • hbase.rootdir.perms

    • Description

安全(kerberos)设置中根数据子目录的 FS 权限。当 master 启动时,它将创建具有此权限的 rootdir 或设置不匹配的权限。

Default

700

  • hbase.wal.dir.perms

    • Description

安全(kerberos)设置中的根 WAL 目录的 FS 权限。当 master 启动时,它将使用此权限创建 WAL 目录,或者在不匹配时设置权限。

Default

700

  • hbase.data.umask.enable

    • Description

启用(如果为 true),应将文件权限分配给由 regionserver 写入的文件

Default

false

  • hbase.data.umask

    • Description

hbase.data.umask.enable 为 true 时应用于写入数据文件的文件权限

Default

000

  • hbase.snapshot.enabled

    • Description

设置为 true 以允许拍摄/还原/克隆快照。

Default

true

  • hbase.snapshot.restore.take.failsafe.snapshot

    • Description

设置为 true 以在还原操作之前进行快照。如果发生故障,将使用拍摄的快照来还原以前的状态。在还原操作结束时,此快照将被删除

Default

true

  • hbase.snapshot.restore.failsafe.name

    • Description

还原操作获取的故障安全快照的名称。您可以使用\ {},\ {}和\ {}变量根据要还原的内容创建名称。

Default

hbase-failsafe-{snapshot.name}-{restore.timestamp}

  • hbase.server.compactchecker.interval.multiplier

    • Description

该数字确定我们进行扫描以查看是否有必要进行压缩的频率。通常,压缩是在某些事件(例如 memstore 刷新)之后完成的,但是,如果区域一段时间未收到大量写入,或者由于不同的压缩策略,则可能需要定期检查它。检查之间的间隔是 hbase.server.compactchecker.interval.multiplier 乘以 hbase.server.thread.wakefrequency。

Default

1000

  • hbase.lease.recovery.timeout

    • Description

在放弃之前,我们 awaitdfs 租赁恢复的总时间为多长时间。

Default

900000

  • hbase.lease.recovery.dfs.timeout

    • Description

dfs 之间恢复租约调用的时间。应该大于名称节点作为数据节点的一部分发出块恢复命令所花费的时间总和; dfs.heartbeat.interval 以及主数据节点所花费的时间,在死数据节点上执行块恢复到超时;通常是 dfs.client.socket-timeout。有关更多信息,请参见 HBASE-8389 的末尾。

Default

64000

  • hbase.column.max.version

    • Description

新的列族 Descriptors 将使用此值作为要保留的默认版本数。

Default

1

  • dfs.client.read.shortcircuit

    • Description

如果设置为 true,则此配置参数启用短路本地读取。

Default

false

  • dfs.domain.socket.path

    • Description

如果 dfs.client.read.shortcircuit 设置为 true,这是 UNIX 域套接字的路径,该套接字将用于 DataNode 与本地 HDFSClient 端之间的通信。如果此路径中存在字符串“ _PORT”,它将被 DataNode 的 TCP 端口替换。请注意托管共享域套接字的目录的权限; dfsclient 将向 HBase 用户以外的其他用户开放。

Default

none

  • hbase.dfs.client.read.shortcircuit.buffer.size

    • Description

如果未设置 DFSClient 配置 dfs.client.read.shortcircuit.buffer.size,我们将使用此处配置的短路读取默认直接字节缓冲区大小。 DFSClient 本机默认值为 1MB; HBase 保持其 HDFS 文件处于打开状态,因此文件块数* 1MB 很快就开始增加,并由于直接内存不足而威胁了 OOME。因此,我们将其设置为默认值。使其>在 HColumnDescriptor 中设置的默认 hbase 块大小,通常为 64k。

Default

131072

  • hbase.regionserver.checksum.verify

    • Description

如果设置为 true(默认值),则 HBase 会验证 hfile 块的校验和。 HBase 在写出 hfile 时,将校验和与数据内联。 HDFS(在撰写本文时)将校验和写入数据文件之外的单独文件,这需要额外的查找。设置该标志可节省一些 I/O。设置此标志时,将在 hfile 流上内部禁用 HDFS 的校验和验证。如果 hbase-checksum 验证失败,我们将切换回使用 HDFS 校验和(因此请不要禁用 HDFS 校验和!此外,此功能仅适用于 hfile,不适用于 WAL)。如果将此参数设置为 false,则 hbase 将不会验证任何校验和,而是取决于 HDFSClient 端中进行的校验和验证。

Default

true

  • hbase.hstore.bytes.per.checksum

    • Description

hfile 块中 HBase 级别校验和的新创建校验和块中的字节数。

Default

16384

  • hbase.hstore.checksum.algorithm

    • Description

用于计算校验和的算法的名称。可能的值为 NULL,CRC32,CRC32C。

Default

CRC32C

  • hbase.client.scanner.max.result.size

    • Description

调用扫描仪的下一个方法时返回的最大字节数。请注意,当单行大于此限制时,该行仍将完全返回。默认值为 2MB,适合 1ge 网络。对于更快和/或高延迟的网络,此值应增加。

Default

2097152

  • hbase.server.scanner.max.result.size

    • Description

调用扫描仪的下一个方法时返回的最大字节数。请注意,当单行大于此限制时,该行仍将完全返回。默认值为 100MB。这是一项安全设置,可以保护服务器免受 OOM 情况的影响。

Default

104857600

  • hbase.status.published

    • Description

此设置激活主服务器发布区域服务器状态。当区域服务器停止运行并开始恢复时,主服务器会将此信息推送到 Client 端应用程序,以使它们立即断开连接,而不必 await 超时。

Default

false

  • hbase.status.publisher.class

    • Description

使用多播消息实现状态发布。

Default

org.apache.hadoop.hbase.master.ClusterStatusPublisher$MulticastPublisher

  • hbase.status.listener.class

    • Description

使用多播消息实现状态侦听器。

Default

org.apache.hadoop.hbase.client.ClusterStatusListener$MulticastListener

  • hbase.status.multicast.address.ip

    • Description

用于通过多播发布状态的多播地址。

Default

226.1.1.3

  • hbase.status.multicast.address.port

    • Description

组播端口,用于通过组播发布状态。

Default

16100

  • hbase.dynamic.jars.dir

    • Description

区域服务器无需重新启动即可从其动态加载自定义过滤器 JAR 的目录。但是,已经加载的过滤器/协处理器类不会被卸载。有关更多详细信息,请参见 HBASE-1936.不适用于协处理器。

Default

${hbase.rootdir}/lib

  • hbase.security.authentication

    • Description

控制是否为 HBase 启用安全身份验证。可能的值为“简单”(不进行身份验证)和“ kerberos”。

Default

simple

  • hbase.rest.filter.classes

    • Description

REST 服务的 Servlet 过滤器。

Default

org.apache.hadoop.hbase.rest.filter.GzipFilter

  • hbase.master.loadbalancer.class

    • Description

当周期发生时用于执行区域平衡的类。有关其工作原理的更多信息,请参见类 Comments。http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.html它将 DefaultLoadBalancer 替换为默认值(因为重命名为 SimpleLoadBalancer)。

Default

org.apache.hadoop.hbase.master.balancer.StochasticLoadBalancer

  • hbase.master.loadbalance.bytable

    • Description

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

Default

false

  • hbase.master.normalizer.class

    • Description

发生周期时用于执行区域规范化的类。有关其工作原理的更多信息,请参见类 Commentshttp://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/SimpleRegionNormalizer.html

Default

org.apache.hadoop.hbase.master.normalizer.SimpleRegionNormalizer

  • hbase.rest.csrf.enabled

    • Description

设置为 true 以启用针对跨站点请求伪造(CSRF)的保护

Default

false

  • hbase.rest-csrf.browser-useragents-regex

    • Description

通过将 hbase.rest.csrf.enabled 设置为 true 为 REST 服务器启用跨站点请求伪造(CSRF)保护时,用逗号分隔的正则表达式列表,用于与 HTTP 请求的 User-AgentHeaders 匹配。如果传入的 User-Agent 与这些正则表达式中的任何一个匹配,则该请求被视为由浏览器发送,因此强制执行 CSRF 防护。如果请求的用户代理与这些正则表达式都不匹配,则认为该请求是由浏览器以外的其他设备(例如脚本化自动化)发送的。在这种情况下,CSRF 并不是潜在的攻击媒介,因此无法执行预防措施。这有助于实现与尚未更新为发送 CSRF 预防 Headers 的现有自动化的向后兼容性。

Default

Mozilla.,Opera.

  • hbase.security.exec.permission.checks

    • Description

如果启用此设置并且基于 ACL 的访问控制处于活动状态(AccessController 协处理器既可以作为系统协处理器安装,也可以作为表协处理器安装在表上),那么如果所有相关用户需要执行协处理器端点的能力,则必须授予他们 EXEC 特权电话。像任何其他权限一样,EXEC 特权可以全局授予用户,也可以基于每个表或每个命名空间授予用户。有关协处理器端点的更多信息,请参见 HBase 在线手册的协处理器部分。有关使用 AccessController 授予或撤消权限的更多信息,请参见 HBase 在线手册的安全性部分。

Default

false

  • hbase.procedure.regionserver.classes

    • Description

逗号分隔的 org.apache.hadoop.hbase.procedure.RegionServerProcedureManager 过程 Management 器列表,默认情况下在活动 HRegionServer 进程中加载。生命周期方法(init/start/stop)将由活动的 HRegionServer 进程调用,以执行特定的全局受阻过程。在实现自己的 RegionServerProcedureManager 之后,只需将其放在 HBase 的 Classpath 中,然后在此处添加完全限定的类名。

Default

none

  • hbase.procedure.master.classes

    • Description

逗号分隔的 org.apache.hadoop.hbase.procedure.MasterProcedureManager 过程 Management 器列表,默认情况下在活动 HMaster 进程上加载。过程由其签名标识,用户可以使用签名和即时名称来触发全局障碍过程的执行。在实现自己的 MasterProcedureManager 之后,只需将其放入 HBase 的 Classpath 中,然后在此处添加完全限定的类名即可。

Default

none

  • hbase.coordinated.state.manager.class

    • Description

实现协调状态 Management 器的类的全限定名称。

Default

org.apache.hadoop.hbase.coordination.ZkCoordinatedStateManager

  • hbase.regionserver.storefile.refresh.period

    • Description

刷新辅助区域的存储文件的时间段(以毫秒为单位)。 0 表示此功能被禁用。一旦辅助区域刷新了该区域中的文件列表(没有通知机制),辅助区域就会从主服务器看到新文件(通过刷新和压缩)。但是过于频繁的刷新可能会导致额外的 Namenode 压力。如果文件刷新的时间不能超过 HFile TTL(hbase.master.hfilecleaner.ttl),则拒绝请求。还建议通过此设置将 HFile TTL 配置为更大的值。

Default

0

  • hbase.region.replica.replication.enabled

    • Description

是否启用了到辅助区域副本的异步 WAL 复制。如果启用此功能,将创建一个名为“ region_replica_replication”的复制对等方,它将复制日志尾部并将突变复制到具有区域复制> 1 的表的区域副本中。如果启用一次,则禁用此复制还需要禁用复制使用 Shell 或 Admin java 类的对等体。到辅助区域副本的复制通过标准的群集间复制进行。

Default

false

  • hbase.http.filter.initializers

    • Description

用逗号分隔的类名称列表。列表中的每个类都必须扩展 org.apache.hadoop.hbase.http.FilterInitializer。相应的过滤器将被初始化。然后,该筛选器将应用于所有面向用户的 jsp 和 servlet 网页。列表的 Sequences 定义了过滤器的 Sequences。默认的 StaticUserWebFilter 添加由 hbase.http.staticuser.user 属性定义的用户主体。

Default

org.apache.hadoop.hbase.http.lib.StaticUserWebFilter

  • hbase.security.visibility.mutations.checkauths

    • Description

如果启用此属性,将检查可见性表达式中的标签是否与发出突变的用户相关联

Default

false

  • hbase.http.max.threads

    • Description

HTTP Server 将在其 ThreadPool 中创建的最大线程数。

Default

16

  • hbase.replication.rpc.codec

    • Description

启用复制时要使用的编解码器,以便也复制标签。与 HFileV3 一起使用,后者支持其中的标签。如果未使用标签,或者使用的 hfile 版本为 HFileV2,则可以将 KeyValueCodec 用作复制编解码器。请注意,在没有标签的情况下使用 KeyValueCodecWithTags 进行复制不会造成任何危害。

Default

org.apache.hadoop.hbase.codec.KeyValueCodecWithTags

  • hbase.replication.source.maxthreads

    • Description

任何复制源用于将编辑并行传送到接收器的最大线程数。这也限制了每个复制批处理分成的块数。较大的值可以提高主群集和从群集之间的复制吞吐量。默认值 10 几乎不需要更改。

Default

10

  • hbase.http.staticuser.user

    • Description

呈现内容时在静态 Web 筛选器上作为筛选条件的用户名。 HDFS Web UI(用于浏览文件的用户)是一个示例用法。

Default

dr.stack

  • hbase.regionserver.handler.abort.on.error.percent

    • Description

区域服务器 RPC 线程无法中止 RS 的百分比。 -1 禁用中止; 0 即使有一个处理程序死亡,也中止; 0.x 仅在此百分比的处理程序已死亡时才中止; 1 只有中止所有处理程序的人都死了。

Default

0.5

  • hbase.mob.file.cache.size

    • Description

要缓存的已打开文件处理程序的数量。较大的值将为每个 mob 文件缓存提供更多的文件处理程序,从而有利于读取,并减少频繁的文件打开和关闭操作。但是,如果设置得太高,则可能导致“打开的文件处理程序太多”。默认值为 1000.

Default

1000

  • hbase.mob.cache.evict.period

    • Description

暴民缓存逐出已缓存的暴徒文件之前的时间(以秒为单位)。默认值为 3600 秒。

Default

3600

  • hbase.mob.cache.evict.remain.ratio

    • Description

当缓存的 mob 文件的数量超过 hbase.mob.file.cache.size 时,将触发逐出后保留的缓存文件的比例(介于 0.0 和 1.0 之间)。默认值为 0.5f。

Default

0.5f

  • hbase.master.mob.ttl.cleaner.period

    • Description

ExpiredMobFileCleanerChore 运行的周期。单位是第二。默认值为一天。 MOB 文件名仅使用文件创建时间中的日期部分。我们用这段时间来确定文件的 TTL 到期时间。因此,TTL 过期文件的删除可能会延迟。最大延迟时间可能是 24 小时。

Default

86400

  • hbase.mob.compaction.mergeable.threshold

    • Description

如果 mob 文件的大小小于此值,则将其视为小文件,需要在 mob 压缩中合并。默认值为 1280MB。

Default

1342177280

  • hbase.mob.delfile.max.count

    • Description

mob 压缩中允许的最大 del 文件数。在 mob 压缩中,当现有 del 文件的数量大于此值时,将合并它们,直到 del 文件的数量不大于该值。预设值为 3.

Default

3

  • hbase.mob.compaction.batch.size

    • Description

一批 mob 压缩中允许的 mob 文件的最大数量。暴民压缩将小暴民文件合并为大暴民文件。如果小文件的数量很大,则合并中可能会导致“打开的文件处理程序太多”。合并必须分批进行。该值限制了一批 mob 压缩中选择的 mob 文件的数量。默认值为 100.

Default

100

  • hbase.mob.compaction.chore.period

    • Description

MobCompactionChore 运行的时间。单位是第二。默认值为一周。

Default

604800

  • hbase.mob.compactor.class

    • Description

实现 mob 压缩器,默认之一是 PartitionedMobCompactor。

Default

org.apache.hadoop.hbase.mob.compactions.PartitionedMobCompactor

  • hbase.mob.compaction.threads.max

    • Description

MobCompactor 中使用的最大线程数。

Default

1

  • hbase.snapshot.master.timeout.millis

    • Description

快照过程执行的主服务器超时。

Default

300000

  • hbase.snapshot.region.timeout

    • Description

区域服务器将线程保留在快照请求池中的 await 时间。

Default

300000

  • hbase.rpc.rows.warning.threshold

    • Description

批处理操作中的行数,如果超过该行,将记录警告。

Default

5000

  • hbase.master.wait.on.service.seconds

    • Description

默认值为 5 分钟。进行 30 秒的测试。有关某些上下文,请参见 HBASE-19794.

Default

30

7.3. hbase-env.sh

在此文件中设置 HBase 环境变量。示例包括在 HBase 守护程序启动时传递 JVM 的选项,例如堆大小和垃圾收集器配置。您还可以为 HBase 配置,日志目录,niceness,ssh 选项,在何处查找进程 pid 文件等设置配置。在* conf/hbase-env.sh *中打开文件并仔细阅读其内容。每个选项都有充分的文档记录。如果希望在启动时由 HBase 守护程序读取环境变量,请在此处添加您自己的环境变量。

此处的更改将要求群集重新启动,以便 HBase 注意到更改。

7.4. log4j.properties

编辑此文件以更改 HBase 文件的滚动速率并更改 HBase 记录消息的级别。

尽管可以通过 HBase UI 更改特定守护程序的日志级别,但此处的更改将要求 HBase 重新启动集群以注意到更改。

7.5. Client 端配置和依赖关系连接到 HBase 集群

如果您以独立模式运行 HBase,则无需配置任何配置即可让 Client 端正常工作,前提是它们都在同一台计算机上。

由于 HBase Master 可能会四处移动,因此 Client 端可以通过向 ZooKeeper 查找当前的关键位置来进行引导。 ZooKeeper 是保留所有这些值的位置。因此,Client 在执行其他任何操作之前,需要先确定 ZooKeeper 合奏的位置。通常,此合奏位置保留在* hbase-site.xml *中,并由 Client 端从CLASSPATH获取。

如果要配置 IDE 以运行 HBaseClient 端,则应在 Classpath 中包括* conf/目录,以便可以找到 hbase-site.xml 设置(或添加 src/test/resources *以选择测试使用的 hbase-site.xml)。

对于使用 Maven 的 Java 应用程序,建议在连接到集群时包括 hbase-shaded-client 模块依赖项:

<dependency>
  <groupId>org.apache.hbase</groupId>
  <artifactId>hbase-shaded-client</artifactId>
  <version>2.0.0</version>
</dependency>

仅用于 Client 端的基本示例* hbase-site.xml *可能如下所示:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>hbase.zookeeper.quorum</name>
    <value>example1,example2,example3</value>
    <description>The directory shared by region servers.
    </description>
  </property>
</configuration>

7.5.1. JavaClient 端配置

JavaClient 端使用的配置保存在HBaseConfiguration实例中。

HBaseConfiguration HBaseConfiguration.create();的工厂方法在调用时将读取在 Client 端CLASSPATH上找到的第一个* hbase-site.xml 的内容(如果存在)(调用还将包括任何 hbase-default.xml *找到了; * hbase-default.xml 放在 hbase.XXXjar 内。也可以直接指定配置,而不必从 hbase-site.xml *中读取。例如,以编程方式为集群设置 ZooKeeper 集成,请执行以下操作:

Configuration config = HBaseConfiguration.create();
config.set("hbase.zookeeper.quorum", "localhost");  // Here we are running zookeeper locally

如果多个 ZooKeeper 实例构成了 ZooKeeper 集合,则可以在逗号分隔的列表中指定它们(就像在* hbase-site.xml *文件中一样)。然后可以将此填充的Configuration实例传递给Table,依此类推。

7.6. 超时设定

HBase 提供了各种各样的超时设置,以限制各种远程操作的执行时间。

  • hbase.rpc.timeout

  • hbase.rpc.read.timeout

  • hbase.rpc.write.timeout

  • hbase.client.operation.timeout

  • hbase.client.meta.operation.timeout

  • hbase.client.scanner.timeout.period

hbase.rpc.timeout属性限制了单个 RPC 调用在超时之前可以运行多长时间。要微调与读取或写入相关的 RPC 超时,请设置hbase.rpc.read.timeouthbase.rpc.write.timeout配置属性。如果没有这些属性,将使用hbase.rpc.timeout

较高级别的超时是hbase.client.operation.timeout,它对于每个 Client 端调用均有效。例如,由于hbase.rpc.timeout而导致 RPC 调用超时失败时,它将重试,直到达到hbase.client.operation.timeout。可以通过设置hbase.client.meta.operation.timeout配置值来微调系统表的 Client 端操作超时。如果未设置,则其值将使用hbase.client.operation.timeout

扫描操作的超时控制不同。使用hbase.client.scanner.timeout.period属性设置此超时时间。

8.配置示例

8.1. 基本的分布式 HBase 安装

这是一个分布式十节点群集的基本配置示例:在此示例中,节点通过节点example9命名为example0example1等。 * HBase 主节点和 HDFS NameNode 在节点example0上运行。 * RegionServer 在节点example1-example9上运行。 * 3 节点的 ZooKeeper 集成在默认端口上的example1example2example3上运行。 * ZooKeeper 数据保存在目录/export/zookeeper *中。

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

8.1.1. hbase-site.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>hbase.zookeeper.quorum</name>
    <value>example1,example2,example3</value>
    <description>The directory shared by RegionServers.
    </description>
  </property>
  <property>
    <name>hbase.zookeeper.property.dataDir</name>
    <value>/export/zookeeper</value>
    <description>Property from ZooKeeper config zoo.cfg.
    The directory where the snapshot is stored.
    </description>
  </property>
  <property>
    <name>hbase.rootdir</name>
    <value>hdfs://example0:8020/hbase</value>
    <description>The directory shared by RegionServers.
    </description>
  </property>
  <property>
    <name>hbase.cluster.distributed</name>
    <value>true</value>
    <description>The mode the cluster will be in. Possible values are
      false: standalone and pseudo-distributed setups with managed ZooKeeper
      true: fully-distributed with unmanaged ZooKeeper Quorum (see hbase-env.sh)
    </description>
  </property>
</configuration>

8.1.2. regionservers

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

example1
example2
example3
example4
example5
example6
example7
example8
example9

8.1.3. hbase-env.sh

  • hbase-env.sh *文件中的以下各行显示了如何设置JAVA_HOME环境变量(HBase 必需)以及如何将堆设置为 4 GB(而不是默认值 1 GB)。如果您复制并粘贴此示例,请确保调整JAVA_HOME以适合您的环境。
# The java implementation to use.
export JAVA_HOME=/usr/java/jdk1.8.0/

# The maximum amount of heap to use. Default is left to JVM default.
export HBASE_HEAPSIZE=4G

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

9.重要配置

下面我们列出了一些重要的配置。我们将本节分为所需的配置和值得一看的推荐配置。

9.1. 所需配置

查看oshadoop部分。

9.1.1. 大集群配置

如果您的群集具有很多区域,则在主服务器启动后,Regionserver 可能会短暂签入,而所有其他 RegionServer 都将滞后。该第一台要签入的服务器将被分配所有非最佳区域。为防止发生上述情况,请将hbase.master.wait.on.regionservers.mintostart属性从其默认值 1 上调。有关更多详细信息,请参见HBASE-6389 修改条件以确保主服务器在开始区域分配之前 await 足够数量的区域服务器

9.2. 推荐配置

9.2.1. ZooKeeper 配置

zookeeper.session.timeout

默认超时为 90 秒(以毫秒为单位)。这意味着,如果服务器崩溃,则主服务器将在 90 秒后通知崩溃并开始恢复。您可能需要将超时调整为一分钟或更短,以便主服务器能够更快地注意到故障。更改此值之前,请确保已控制 JVM 垃圾收集配置,否则,持续超过 ZooKeeper 会话超时的长时间垃圾收集将占用 RegionServer。 (这样做可能会很好-如果 RegionServer 长时间处于 GC 中,您可能希望恢复在服务器上开始)。

要更改此配置,请编辑* hbase-site.xml *,在集群中复制更改的文件,然后重新启动。

我们将此值设置得很高,以免我们不得不在邮件列表中提出问题,以询问为什么在大规模导入期间 RegionServer 出现故障。通常的原因是他们的 JVM 未调整,并且正在运行很长的 GC 暂停。我们的想法是,当用户熟悉 HBase 时,我们不必为他们省却所有复杂性。稍后,当他们构建起一定的信心时,他们便可以使用这样的配置。

ZooKeeper 实例数

See zookeeper.

9.2.2. HDFS 配置

dfs.datanode.failed.volumes.tolerated

这是* hdfs-default.xml *说明中的“…在 DataNode 停止提供服务之前允许失败的卷数。默认情况下,任何卷故障都会导致数据节点关闭”。您可能希望将其设置为可用磁盘数量的一半。

hbase.regionserver.handler.count

此设置定义保持打开状态以响应对用户表的传入请求的线程数。经验法则是,当每个请求的有效负载接近 MB 时(大放置,使用大缓存进行扫描),此数字应保持较低;当有效负载较小(获取,小放置,ICV,删除)时,请保持较高的数字。正在进行的查询的总大小受设置hbase.ipc.server.max.callqueue.size的限制。

如果有效负载很小,可以安全地将该数目设置为最大数量的传入 Client 端,典型示例是为网站提供服务的群集,因为通常不对 put 进行缓冲,并且大多数操作都可以得到。

将该设置保持在较高状态是危险的,原因是区域服务器中当前正在发生的所有 put 的总大小可能会对其内存施加过多压力,甚至触发 OutOfMemoryError。在内存不足的情况下运行的 RegionServer 会触发其 JVM 的垃圾收集器更频繁地运行,直到 GC 暂停变得明显为止(原因是,用于保留所有请求有效负载的所有内存都不能被废弃,垃圾收集器尝试)。一段时间后,整个群集的吞吐量会受到影响,因为命中该 RegionServer 的每个请求都将花费更长的时间,从而使问题更加严重。

您可以通过在单个 RegionServer 上rpc.logging然后尾随其日志(排队的请求占用内存)来了解您是否拥有过多的处理程序。

9.2.3. 大内存机器的配置

HBase 带有合理,保守的配置,几乎可以在人们可能要测试的所有计算机类型上使用。如果您有较大的计算机(HBase 具有 8G 和较大的堆),则以下配置选项可能会有所帮助。去做。

9.2.4. Compression

您应该考虑启用 ColumnFamily 压缩。有几个选项几乎是无摩擦的,并且在大多数情况下,它们通过减小 StoreFiles 的大小从而减少 I/O 来提高性能。

有关更多信息,请参见compression

9.2.5. 配置 WAL 文件的大小和数量

如果 RS 发生故障,HBase 使用wal来恢复尚未刷新到磁盘的内存存储数据。这些 WAL 文件应配置为略小于 HDFS 块(默认情况下,HDFS 块为 64Mb,WAL 文件为~60Mb)。

HBase 对 WAL 文件的数量也有限制,旨在确保在恢复过程中不会有太多数据需要重播。需要根据 memstore 配置设置此限制,以便所有必需的数据都适合。建议分配足够的 WAL 文件以至少存储那么多的数据(当所有内存存储都快用完时)。例如,对于 16Gb RS 堆,默认内存存储设置(0.4)和默认 WAL 文件大小(~60Mb),16Gb * 0.4/60,WAL 文件计数的起点是~109.但是,由于并非所有存储器都始终都已满,因此可以分配较少的 WAL 文件。

9.2.6. 托管拆分

HBase 通常根据* hbase-default.xml hbase-site.xml *配置文件中的设置来处理区域划分。重要设置包括hbase.regionserver.region.split.policyhbase.hregion.max.filesizehbase.regionserver.regionSplitLimit。分割的一种简化视图是,当区域增长到hbase.hregion.max.filesize时,将对其进行分割。对于大多数使用模式,应使用自动拆分。有关手动区域分割的更多信息,请参见手动区域分割决策

您可以选择自己 Management 拆分,而不是让 HBase 自动拆分区域。如果您非常了解密钥空间,则可以手动 Management 拆分,否则让 HBase 为您确定拆分的位置。手动拆分可以减轻区域创建和负载下的移动。它还使区域边界是已知且不变的(如果禁用区域划分)。如果使用手动拆分,则更容易进行基于时间的交错压缩,以分散网络 IO 负载。

禁用自动拆分

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

Automatic Splitting Is Recommended

如果禁用自动拆分以诊断问题或在数据快速增长期间,建议在情况变得更稳定时重新启用它们。Management 区域分裂自己的潜在好处并非没有争议。

确定预分割区域的最佳数量

预分割区域的最佳数量取决于您的应用程序和环境。一个好的经验法则是从每个服务器 10 个预分割区域开始,并观察数据随时间增长的情况。最好在区域太少的一侧犯错误,然后再进行滚动拆分。最佳区域数取决于您所在区域中最大的 StoreFile。如果数据量增加,则最大的 StoreFile 的大小将随时间增加。目的是使最大区域足够大,以使压缩选择算法仅在定时大压缩期间对其进行压缩。否则,集群可能会同时受到大量区域的压缩风暴。重要的是要了解数据增长会导致压缩风暴,而不是手动拆分决定。

如果将区域分成太多大区域,则可以通过配置HConstants.MAJOR_COMPACTION_PERIOD来增加主要压缩间隔。 org.apache.hadoop.hbase.util.RegionSplitterUtil 还提供所有区域的网络 IO 安全滚动拆分。

9.2.7. 托管压缩

默认情况下,大型压缩计划为每 7 天运行一次。

如果需要精确控制大型压缩的时间和频率,则可以禁用托管大型压缩。有关详细信息,请参见compaction.parameters表中的hbase.hregion.majorcompaction条目。

Do Not Disable Major Compactions

对于 StoreFile 清理,绝对必需进行大压缩。请勿完全禁用它们。您可以通过 HBase shell 或Admin API手动运行主要压缩。

有关压缩和 zipfile 选择过程的更多信息,请参阅compaction

9.2.8. 投机执行

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

9.3. 其他配置

9.3.1. Balancer

平衡器是一种定期操作,在主服务器上运行,以重新分配群集上的区域。它是通过hbase.balancer.period配置的,默认值为 300000(5 分钟)。

有关 LoadBalancer 的更多信息,请参见master.processes.loadbalancer

9.3.2. 禁用块缓存

不要关闭块缓存(您可以通过将hfile.block.cache.size设置为零来关闭它)。目前,如果您这样做的话,我们做得并不好,因为 RegionServer 会花所有的时间一遍又一遍地加载 HFile 索引。如果您的工作组对块缓存不利,请至少调整块缓存的大小,以使 HFile 索引保留在缓存中(您可以通过调查 RegionServer UI 来大致了解所需的大小;您将请参阅网页顶部附近的索引块大小)。

9.3.3. Nagle 或小包装问题

如果在针对 HBase 的操作中偶尔会出现 40ms 左右的延迟,请尝试 Nagles 的设置。例如,请参见用户邮件列表线程缓存设置为 1 时扫描性能不一致以及其中引用的问题,其中设置notcpdelay可以提高扫描速度。您可能还会看到HBASE-7008 将扫描仪缓存设置为更好的默认值尾部的图形,其中我们的 Lars Hofhansl 尝试打开和关闭 Nagle 来测量效果的各种数据大小。

9.3.4. 更好的平均恢复时间(MTTR)

本节介绍的配置将使服务器在出现故障后更快地恢复。请参阅 Deveraj Das 和 Nicolas Liochon 博客文章HBase 平均恢复时间(MTTR)简介的简要介绍。

问题HBASE-8354 强制 Namenode 进入具有租约恢复请求的循环杂乱无章,但对于低超时问题以及如何导致更快的恢复(包括对添加到 HDFS 的修复程序的引用),最后有很多很好的讨论。阅读 Varun Sharma 的 Comment。以下建议的配置是 Varun 的建议经过提炼和测试的。确保您在最新版本的 HDFS 上运行,因此您具有他所引用的修复程序,并且自己添加了可帮助 HBase MTTR 的 HDFS(例如,HDFS-3703,HDFS-3712 和 HDFS-4791)。 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 中引入的“陈旧性”。

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

9.3.5. JMX

JMX(JavaManagement 扩展)提供了内置的工具,使您可以监视和 ManagementJava VM。要从远程系统启用监视和 Management,在启动 Java VM 时,需要设置系统属性com.sun.management.jmxremote.port(要用来启用 JMX RMI 连接的端口号)。有关更多信息,请参见official documentation。从历史上看,除了上面提到的端口之外,JMX 还打开了两个附加的随机 TCP 侦听端口,这可能会导致端口冲突问题。 (有关详情,请参见HBASE-10289)

或者,您可以使用 HBase 提供的基于协处理器的 JMX 实现。要启用它,请在* hbase-site.xml *中添加以下属性:

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

Note

请勿同时为 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 *下的示例密码/访问文件。

要通过密码验证启用 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 "

最后,使用密钥库在 Client 端上启动jconsole

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

Note

要在 Master 上启用 HBase JMX 实现,还需要在* hbase-site.xml *中添加以下属性:

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

端口配置的相应属性是master.rmi.registry.port(默认情况下为 10101)和master.rmi.connector.port(默认情况下与 Registry.port 相同)

10.动态配置

可以更改配置的子集,而无需重新启动服务器。在 HBase Shell 中,操作update_configupdate_all_config将提示服务器或所有服务器重新加载配置。

当前,正在运行的服务器中只能更改所有配置的一部分。这些是这些配置:

表 3.配置支持动态更改

Key
hbase.ipc.server.fallback-to-simple-auth-allowed
hbase.cleaner.scan.dir.concurrent.size
hbase.regionserver.thread.compaction.large
hbase.regionserver.thread.compaction.small
hbase.regionserver.thread.split
hbase.regionserver.throughput.controller
hbase.regionserver.thread.hfilecleaner.throttle
hbase.regionserver.hfilecleaner.large.queue.size
hbase.regionserver.hfilecleaner.small.queue.size
hbase.regionserver.hfilecleaner.large.thread.count
hbase.regionserver.hfilecleaner.small.thread.count
hbase.regionserver.hfilecleaner.thread.timeout.msec
hbase.regionserver.hfilecleaner.thread.check.interval.msec
hbase.regionserver.flush.throughput.controller
hbase.hstore.compaction.max.size
hbase.hstore.compaction.max.size.offpeak
hbase.hstore.compaction.min.size
hbase.hstore.compaction.min
hbase.hstore.compaction.max
hbase.hstore.compaction.ratio
hbase.hstore.compaction.ratio.offpeak
hbase.regionserver.thread.compaction.throttle
hbase.hregion.majorcompaction
hbase.hregion.majorcompaction.jitter
hbase.hstore.min.locality.to.skip.major.compact
hbase.hstore.compaction.date.tiered.max.storefile.age.millis
hbase.hstore.compaction.date.tiered.incoming.window.min
hbase.hstore.compaction.date.tiered.window.policy.class
hbase.hstore.compaction.date.tiered.single.output.for.minor.compaction
hbase.hstore.compaction.date.tiered.window.factory.class
hbase.offpeak.start.hour
hbase.offpeak.end.hour
hbase.oldwals.cleaner.thread.size
hbase.oldwals.cleaner.thread.timeout.msec
hbase.oldwals.cleaner.thread.check.interval.msec
hbase.procedure.worker.keep.alive.time.msec
hbase.procedure.worker.add.stuck.percentage
hbase.procedure.worker.monitor.interval.msec
hbase.procedure.worker.stuck.threshold.msec
hbase.regions.slop
hbase.regions.overallSlop
hbase.balancer.tablesOnMaster
hbase.balancer.tablesOnMaster.systemTablesOnly
hbase.util.ip.to.rack.determiner
hbase.ipc.server.max.callqueue.length
hbase.ipc.server.priority.max.callqueue.length
hbase.ipc.server.callqueue.type
hbase.ipc.server.callqueue.codel.target.delay
hbase.ipc.server.callqueue.codel.interval
hbase.ipc.server.callqueue.codel.lifo.threshold
hbase.master.balancer.stochastic.maxSteps
hbase.master.balancer.stochastic.stepsPerRegion
hbase.master.balancer.stochastic.maxRunningTime
hbase.master.balancer.stochastic.runMaxSteps
hbase.master.balancer.stochastic.numRegionLoadsToRemember
hbase.master.loadbalance.bytable
hbase.master.balancer.stochastic.minCostNeedBalance
hbase.master.balancer.stochastic.localityCost
hbase.master.balancer.stochastic.rackLocalityCost
hbase.master.balancer.stochastic.readRequestCost
hbase.master.balancer.stochastic.writeRequestCost
hbase.master.balancer.stochastic.memstoreSizeCost
hbase.master.balancer.stochastic.storefileSizeCost
hbase.master.balancer.stochastic.regionReplicaHostCostKey
hbase.master.balancer.stochastic.regionReplicaRackCostKey
hbase.master.balancer.stochastic.regionCountCost
hbase.master.balancer.stochastic.primaryRegionCountCost
hbase.master.balancer.stochastic.moveCost
hbase.master.balancer.stochastic.maxMovePercent
hbase.master.balancer.stochastic.tableSkewCost

Upgrading

升级时不能跳过主要版本。如果要从 0.98.x 版本升级到 2.x,则必须先从 0.98.x 升级到 1.2.x,然后再从 1.2.x 升级到 2.x。

查看Apache HBase 配置,尤其是Hadoop。熟悉支持和测试期望

11. HBase 版本号和兼容性

11.1. 理想的语义版本控制

从 1.0.0 版本开始,HBase 正在朝Semantic Versioning进行版本控制。综上所述:

给定版本号 MAJOR.MINOR.PATCH,增加:

  • 当您进行不兼容的 API 更改时的主要版本,

  • 以向后兼容的方式添加功能时的 MINOR 版本,并且

  • 进行向后兼容的错误修复时的 PATCH 版本。

  • 预发布和构建元数据的其他标签可作为 MAJOR.MINOR.PATCH 格式的 extensions 使用。

Compatibility Dimensions

除了通常的 API 版本控制注意事项之外,HBase 还具有我们需要考虑的其他兼容性维度。

Client 端-服务器有线协议兼容性

  • 允许更新 Client 端和服务器不同步。

  • 我们只能先升级服务器。即服务器将与旧 Client 端向后兼容,这样新的 API 就可以了。

  • 示例:用户应该能够使用旧 Client 端连接到升级的群集。

服务器-服务器协议兼容性

  • 不同版本的服务器可以共存于同一群集中。

  • 服务器之间的有线协议兼容。

  • 复制和日志拆分等分布式任务的工作程序可以共存于同一群集中。

  • 相关协议(例如使用 ZK 进行协调)也不会更改。

  • 示例:用户可以执行滚动升级。

文件格式兼容性

  • 支持文件格式向后和向前兼容

  • 示例:作为 HBase 升级的一部分,文件,ZK 编码,目录布局会自动升级。用户可以降级到较旧的版本,并且一切将 continue 工作。

Client 端 API 兼容性

  • 允许更改或删除现有的 Client 端 API。

  • 对于整个主要版本,都需要弃用 API,然后再进行更改/删除。

  • 例如:API 在 2.0.1 中已弃用,并在 4.0.0 中被标记为删除。另一方面,在 2.0.0 中弃用的 API 可以在 3.0.0 中删除。

  • 修补程序版本中提供的 API 将在所有更高的修补程序版本中提供。但是,可能会添加新的 API,而这些 API 在较早的修补程序版本中将不可用。

  • 补丁版本中引入的新 API 将仅以与源兼容的方式添加\ [1]:即,实现公共 API 的代码将 continue 编译。

  • 示例:使用新近弃用的 API 的用户无需使用 HBase API 调用即可修改应用程序代码,直到下一个主要版本。 *

Client 端二进制兼容性

  • 写入给定补丁程序版本中可用的 API 的 Client 端代码可以针对更高版本的补丁程序的新 jar 保持不变(无需重新编译)。

  • 写入给定补丁程序版本中可用的 API 的 Client 端代码可能无法与早期补丁程序版本中的旧 jar 一起运行。

  • 示例:旧的已编译 Client 端代码将与新的 jar 一起使用。

  • 如果 Client 端实现了 HBase 接口,则可能需要重新编译才能升级到较新的次要版本(有关不兼容更改的警告,请参阅发行说明)。将尽一切努力提供默认的实现,因此不会出现这种情况。

服务器端受限 API 兼容性(取自 Hadoop)

  • 内部 API 被标记为稳定,不断 Developing 或不稳定

  • 这意味着协处理器和插件(可插拔的类,包括复制)的二进制兼容性,只要它们仅使用标记的接口/类即可。

  • 示例:旧的编译的协处理器,过滤器或插件代码将与新的 jar 一起使用。

Dependency Compatibility

  • HBase 的升级将不需要对依赖项目进行不兼容的升级,除了 Apache Hadoop。

  • HBase 的升级将不需要 Java 运行时的不兼容升级。

  • 示例:将 HBase 升级到支持* Dependency Compatibility *的版本将不需要您升级 Apache ZooKeeper 服务。

  • 示例:如果当前的 HBase 版本支持在 JDK 8 上运行,则升级到支持* Dependency Compatibility *的版本也将在 JDK 8 上运行。

Hadoop Versions

以前,我们尝试维护底层 Hadoop 服务的依赖项兼容性,但在过去几年中,这已证明是站不住脚的。当 HBase 项目尝试维持对 Hadoop 较早版本的支持时,我们删除了“支持”的次要版本号,这些次要版本无法 continue 查看其发行版。此外,Hadoop 项目有一套自己的兼容性指南,这意味着在某些情况下,必须更新到较新的受支持的次要版本,可能会破坏我们的一些兼容性承诺。

Operational Compatibility

  • Metric changes

  • 服务的行为变化

  • 通过/jmx/端点公开的 JMX API

Summary

  • 修补程序升级是一种替代产品。与 Java 二进制文件和源代码不兼容的任何更改都将不允许。\ [2]在补丁程序发行版中降级版本可能不兼容。

  • 较小的升级不需要修改应用程序/Client 端代码。理想情况下,这将是直接替换,但如果使用新的 jar,则必须重新编译 Client 端代码,协处理器,过滤器等。

  • 重大升级使 HBase 社区可以进行重大更改。

*表 4.兼容性列表\ [3] *

MajorMinorPatch
Client 端-服务器线兼容性NYY
Server-Server CompatibilityNYY
文件格式兼容性N [4]YY
Client 端 API 兼容性NYY
Client 二进制兼容性NNY
服务器端受限 API 兼容性
StableNYY
EvolvingNNY
UnstableNNN
Dependency CompatibilityNYY
Operational CompatibilityNNY

11.1.1. HBase API 表面

HBase 有很多 API 要点,但是对于上面的兼容性矩阵,我们区分了 Client API,Limited Private API 和 Private API。 HBase 使用Apache Yetus 受众 Comments指导下游对稳定性的期望。

  • InterfaceAudience(javadocs):捕获目标受众,可能的值包括:

  • 公共:对最终用户和外部项目安全

    • LimitedPrivate:用于我们希望可插拔的内部组件,例如协处理器

    • 私有:严格用于 HBase 本身定义为IA.Private的类可用作声明为IA.LimitedPrivate的接口的参数或返回值。将IA.Private对象视为不透明;不要尝试直接访问其方法或字段。

  • InterfaceStability(javadocs):描述允许哪些类型的接口更改。可能的值包括:

  • 稳定:接口固定,预计不会改变

    • 不断 Developing:将来的次要版本界面可能会发生变化

    • 不稳定:界面可能随时更改

请记住 HBase 项目中InterfaceAudienceInterfaceStability注解之间的以下交互:

  • IA.Public类具有固有的稳定性,并遵守与升级类型(主要,次要或补丁)有关的稳定性保证。

  • IA.LimitedPrivate类应始终使用给定的InterfaceStability值之一进行 Comments。如果不是,则应假定它们为IS.Unstable

  • IA.Private类应视为隐式不稳定,不能保证发行版之间的稳定性。

  • HBaseClient 端 API

    • HBaseClient 端 API 包含所有标有 InterfaceAudience.Public 接口的类或方法。 hbase-client 和从属模块中的所有主要类都具有 InterfaceAudience.Public,InterfaceAudience.LimitedPrivate 或 InterfaceAudience.Private 标记。并非其他模块(hbase-server 等)中的所有类都具有标记。如果一个类未使用其中之一进行 Comments,则假定该类为 InterfaceAudience.Private 类。
  • HBase LimitedPrivate API

    • LimitedPrivate 注解随附了一组接口的目标使用者。这些使用者是协处理器,凤凰,复制终结点实现或类似者。此时,HBase 仅保证补丁程序版本之间的这些接口的源和二进制兼容性。
  • HBase 专用 API

    • 所有使用 InterfaceAudience 进行 Comments 的类。私有或不具有 Comments 的所有类仅供 HBase 内部使用。接口和方法签名可以随时更改。如果您依赖于标记为“专用”的特定接口,则应打开“ jira”以建议将接口更改为“公共”或“有限私有”,或为此目的公开的接口。

Binary Compatibility

当我们说两个 HBase 版本兼容时,是指这些版本是有线和二进制兼容的。兼容的 HBase 版本意味着 Client 端可以与兼容但版本不同的服务器通信。这也意味着您可以换掉一个版本的 jar,然后用另一个兼容版本的 jar 替换它们,所有这些都可以使用。除非另有说明,否则 HBase 点版本(主要)是二进制兼容的。您可以安全地在二进制兼容版本之间进行滚动升级。即跨维护版本:例如从 1.2.4 到 1.2.6. 请参阅 HBase 开发邮件列表上的链接:[版本之间的兼容性是否还意味着二进制兼容性?]。

11.2. 滚动升级

滚动升级是一次更新群集中的服务器的过程。如果 HBase 版本是二进制或有线兼容的,则可以跨 HBase 版本滚动升级。有关此含义的更多信息,请参见二进制/有线兼容版本之间的滚动升级。粗略地讲,滚动升级是每个服务器的正常停止,更新软件然后重新启动的操作。您为集群中的每个服务器执行此操作。通常,先升级主服务器,然后再升级 RegionServers。有关可以帮助使用滚动升级过程的工具,请参见Rolling Restart

例如,在下面的内容中,HBase 被符号链接到实际的 HBase 安装。升级时,在对群集进行滚动重启之前,我们将符号链接更改为指向新的 HBase 软件版本,然后运行

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

滚动重新启动脚本将首先正常停止并重新启动主服务器,然后依次停止每个 RegionServer。由于符号链接已更改,因此在重新启动时,服务器将使用新的 HBase 版本启动。随着滚动升级的进行,请检查日志中是否有错误。

二进制/有线兼容版本之间的滚动升级

除非另有说明,否则 HBase 次要版本是二进制兼容的。您可以在 HBase 点版本之间执行Rolling Upgrades。例如,可以通过在整个群集中进行滚动升级来从 1.2.6 升级到 1.2.4,将 1.2.4 二进制文件替换为 1.2.6 二进制文件。

在下面的特定于次要版本的部分中,我们指出了版本与 wire/protocol 兼容的地方,在这种情况下,还可以执行Rolling Upgrades

12. Rollback

有时,尝试升级时事情并没有按计划进行。本节说明如何对早期 HBase 版本执行“回滚”。请注意,仅在主要版本和某些次要版本之间才需要这样做。您应该始终能够在同一次要版本的 HBase 修补程序版本之间“降级”。这些说明可能要求您在开始升级过程之前采取步骤,因此请务必先通读本节。

12.1. Caveats

回滚与降级

本节介绍如何在 HBase 次要和主要版本之间的升级上执行回滚。在本文档中,回滚指的是获取升级后的集群并将其还原到旧版本的过程,同时会丢失自升级以来发生的所有更改。相比之下,群集“降级”会将升级后的群集还原到旧版本,同时保留自升级以来写入的所有数据。当前,我们仅提供回滚 HBase 群集的说明。此外,仅在执行升级之前遵循以下说明时,回滚才有效。

当这些说明讨论先决条件群集服务(即 HDFS)的回滚与降级时,应将服务版本与降级的退化情况相同。

Replication

除非您执行所有服务回滚,否则 HBase 群集将丢失用于 HBase 复制的所有已配置对等项。如果为集群配置了 HBase 复制,则在遵循这些说明之前,应记录所有复制对等体。执行回滚后,应将每个记录的对等方添加回群集中。有关启用 HBase 复制,列出对等方以及添加对等方的更多信息,请参见Management 和配置群集复制。还请注意,自升级以来写入集群的数据可能已经复制或可能尚未复制到任何对等点。确定哪些对等点(如果有)已看到复制数据并回滚这些对等点中的数据,超出了本指南的范围。

Data Locality

除非您执行所有服务回滚,否则执行回滚过程可能会破坏 Region Server 的所有位置。您应该期望性能下降,直到群集有时间进行压缩以恢复数据局部性为止。 (可选)您可以强制压缩以加快生成群集负载的速度,从而加快此过程。

Configurable Locations

以下说明假定 HBase 数据目录和 HBase znode 的默认位置。这两个位置都是可配置的,并且在 continue 之前,您应该验证集群中使用的值。如果您使用不同的值,则只需将默认值替换为在配置中找到的值即可.* HBase 数据目录是通过键“ hbase.rootdir”配置的,其默认值为“/hbase”。 * HBase znode 是通过键“ zookeeper.znode.parent”配置的,其默认值为“/hbase”。

12.2. 所有服务回滚

如果要同时执行 HDFS 和 ZooKeeper 服务的回滚,则 HBase 的数据将在此过程中回滚。

Requirements

  • 能够回滚 HDFS 和 ZooKeeper

Before upgrade

升级前不需要其他步骤。作为一种额外的预防措施,您可能希望使用 distcp 从要升级的群集中备份 HBase 数据。为此,请遵循“ HDFS 降级后回滚”的“升级前”部分中的步骤,但复制到另一个 HDFS 实例,而不是复制到同一实例中。

执行回滚

  • Stop HBase

  • 对 HDFS 和 ZooKeeper 执行回滚(HBase 应该保持停止状态)

  • 将已安装的 HBase 版本更改为以前的版本

  • Start HBase

  • 验证 HBase 内容-使用 HBase Shell 列出表并扫描一些已知值。

12.3. HDFS 回滚和 ZooKeeper 降级后的回滚

如果您要回滚 HDFS 但要通过 ZooKeeper 降级,则 HBase 将处于不一致状态。您必须确保集群没有启动,直到完成此过程。

Requirements

  • 能够回滚 HDFS

  • 降级 ZooKeeper 的能力

Before upgrade

升级前不需要其他步骤。作为一种额外的预防措施,您可能希望使用 distcp 从要升级的群集中备份 HBase 数据。为此,请遵循“ HDFS 降级后回滚”的“升级前”部分中的步骤,但复制到另一个 HDFS 实例,而不是复制到同一实例中。

执行回滚

  • Stop HBase

  • 对 HDFS 执行回滚,对 ZooKeeper 进行降级(HBase 应该保持停止状态)

  • 将已安装的 HBase 版本更改为以前的版本

  • 清除与 HBase 相关的 ZooKeeper 信息。警告:此步骤将永久破坏所有复制对等。有关更多信息,请参见“警告”下有关“ HBase 复制”的部分。

从 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...
  • Start HBase

  • 验证 HBase 内容-使用 HBase Shell 列出表并扫描一些已知值。

12.4. HDFS 降级后回滚

如果要执行 HDFS 降级,则无论 ZooKeeper 是经过回滚,降级还是重新安装,都需要遵循这些说明。

Requirements

  • 能够降级 HDFS

  • 升级前的集群必须能够运行 MapReduce 作业

  • HDFS 超级用户访问

  • HDFS 中至少有两个 HBase 数据目录副本的足够空间

Before upgrade

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

  • 停止 HBase 集群

  • 使用distcp command作为 HDFS 超级用户将 HBase 数据目录复制到备份位置(如下所示,在启用安全性的群集上)

使用 distcp 备份 HBase 数据目录

[hpnewton@gateway_node.example.com ~]$ kinit -k -t hdfs.keytab [email protected]
[hpnewton@gateway_node.example.com ~]$ hadoop distcp /hbase /hbase-pre-upgrade-backup
  • Distcp 将启动 mapreduce 作业以处理以分布式方式复制文件。检查 distcp 命令的输出,以确保此作业成功完成。

执行回滚

  • Stop HBase

  • 对 HDFS 执行降级,对 ZooKeeper 执行降级/回滚(HBase 应该保持停止状态)

  • 将已安装的 HBase 版本更改为以前的版本

  • 以 HDFS 超级用户的身份从升级之前还原 HBase 数据目录(如下所示,在启用安全性的群集上)。如果您将数据备份到另一个 HDFS 群集上而不是本地上,则需要使用 distcp 命令将其复制回当前 HDFS 群集上。

恢复 HBase 数据目录

[hpnewton@gateway_node.example.com ~]$ kinit -k -t hdfs.keytab [email protected]
[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
  • 清除与 HBase 相关的 ZooKeeper 信息。警告:此步骤将永久破坏所有复制对等。有关更多信息,请参见“警告”下有关“ HBase 复制”的部分。

从 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...
  • Start HBase

  • 验证 HBase 内容-使用 HBase Shell 列出表并扫描一些已知值。

13.升级路径

13.1. 从 1.x 升级到 2.x

在本节中,我们将首先指出与之前的稳定 HBase 版本相比的重大更改,然后介绍升级过程。请务必仔细阅读前者,以免出现意外。

13.1.1. 注意事项的变化!

首先,我们将介绍升级到 HBase 2.0 时可能会遇到的部署/操作更改。之后,我们将调出下游应用程序的更改。请注意,“操作”部分介绍了协处理器。另请注意,本节并不旨在传达您可能感兴趣的有关新功能的信息。有关更改的完整摘要,请参阅源版本工件中计划升级到的版本的 CHANGES.txt 文件。

更新到 HBase 2.0 中的基本必备条件最低要求

如第Basic Prerequisites节所述,HBase 2.0 至少需要 Java 8 和 Hadoop 2.6. HBase 社区建议确保在升级 HBase 版本之前,先决条件已完成所有必需的升级。

HBCK 必须与 HBase 服务器版本匹配

您“不得”对 HBase 2.0 集群使用 HBCK 的 HBase 1.x 版本。 HBCK 与 HBase 服务器版本紧密相关。对 HBase 2.0 群集使用较早版本的 HBCK 工具将以不可恢复的方式破坏性地更改该群集。

从 HBase 2.0 开始,HBCK(也称为 HBCK1 hbck1 *)是一种只读工具,可以报告某些非公共系统内部组件的状态。您不应该依赖这些内部组件的格式或内容来在 HBase 版本之间保持一致。

要了解有关 HBCK 更换的信息,请参阅Apache HBase 运营 Management中的HBase HBCK2

HBase 2.0 中不再有配置设置

以下配置设置不再适用或不可用。有关详细信息,请参见详细的发行说明。

  • hbase.config.read.zookeeper.config(有关迁移的详细信息,请参见ZooKeeper 配置不再从 zoo.cfg 中读取)

  • hbase.zookeeper.useMulti(HBase 现在始终使用 ZK 的多功能功能)

  • hbase.rpc.client.threads.max

  • hbase.rpc.client.nativetransport

  • hbase.fs.tmp.dir

  • hbase.bucketcache.combinedcache.enabled

  • hbase.bucketcache.ioengine 不再支持“堆”值。

  • hbase.bulkload.staging.dir

  • 严格来说,hbase.balancer.tablesOnMaster 并未删除,但其含义已发生根本变化,用户不应设置它。有关详细信息,请参见“主托管区域”功能已损坏且不受支持部分。

  • hbase.master.distributed.log.replay 有关详细信息,请参见删除了“分布式日志重播”功能部分

  • hbase.regionserver.disallow.writes.when.recovering 有关详细信息,请参见删除了“分布式日志重播”功能部分

  • hbase.regionserver.wal.logreplay.batch.size 有关详细信息,请参见删除了“分布式日志重播”功能部分

  • hbase.master.catalog.timeout

  • hbase.regionserver.catalog.timeout

  • hbase.metrics.exposeOperationTimes

  • hbase.metrics.showTableName

  • hbase.online.schema.update.enable(HBase 现在始终支持此功能)

  • hbase.thrift.htablepool.size.max

在 HBase 2.0 中重命名的配置属性

以下属性已重命名。尝试设置旧属性将在运行时被忽略。

表 5.重命名属性

Old nameNew name
hbase.rpc.server.nativetransporthbase.netty.nativetransport
hbase.netty.rpc.server.worker.counthbase.netty.worker.count
hbase.hfile.compactions.discharger.intervalhbase.hfile.compaction.discharger.interval
hbase.hregion.percolumnfamilyflush.size.lower.boundhbase.hregion.percolumnfamilyflush.size.lower.bound.min

HBase 2.0 中具有不同默认值的配置设置

以下配置设置更改了其默认值。在适用的情况下,给出了用于还原 HBase 1.2 行为的值。

  • hbase.security.authorization 现在默认为 false。设置为 true 可恢复与以前的默认行为相同的行为。

  • hbase.client.retries.number 现在设置为 10.以前是 35.建议下游用户使用 Client 端超时,如Timeout settings部分所述。

  • hbase.client.serverside.retries.multiplier 现在设置为 3.以前是 10.建议下游用户使用 Client 端超时,如Timeout settings部分所述。

  • hbase.master.fileSplitTimeout 现在设置为 10 分钟。以前是 30 秒。

  • hbase.regionserver.logroll.multiplier 现在设置为 0.5. 以前是 0.95. 此更改与以下块大小加倍相关。结合起来,这两个配置更改应该使 WAL 的大小与 hbase-1.x 中的 WAL 大小相同,但是小块的发生率应该降低,因为在达到块大小阈值之前我们无法滚动 WAL。参见HBASE-19148进行讨论。

  • hbase.regionserver.hlog.blocksize 的默认值是 WAL 目录的 HDFS 默认块大小的 2 倍。以前,它等于 WAL 目录的 HDFS 默认块大小。

  • hbase.client.start.log.errors.counter 更改为 5.以前是 9.

  • hbase.ipc.server.callqueue.type 更改为“ fifo”。在 HBase 版本 1.0-1.2 中,这是“最后期限”。在 1.x 之前和之后的版本中,它已经默认为'fifo'。

  • 默认情况下,hbase.hregion.memstore.chunkpool.maxsize 为 1.0. 以前是 0.0. 实际上,这意味着以前我们在内存存储处于堆状态时不会使用块池,而现在我们会使用。有关 MSLAB 块池的更多信息,请参见GC 长时间停顿部分。

  • hbase.master.cleaner.interval 现在设置为 10 分钟。以前是 1 分钟。

  • 现在,hbase.master.procedure.threads 将默认为可用 CPU 数量的 1/4,但不少于 16 个线程。以前,线程数等于 CPU 数。

  • hbase.hstore.blockingStoreFiles 现在是 16.以前是 10.

  • hbase.http.max.threads 现在是 16.以前是 10.

  • hbase.client.max.perserver.tasks 现在是 2.以前是 5.

  • hbase.normalizer.period 现在是 5 分钟。以前是 30 分钟。

  • hbase.regionserver.region.split.policy 现在是 SteppingSplitPolicy。以前,它是 IncreasingToUpperBoundRegionSplitPolicy。

  • Replication.source.ratio 现在为 0.5. 以前是 0.1.

“主托管区域”功能已损坏且不受支持

HBase 1.y 中可用的功能“ Master 充当区域服务器”和相关的后续工作在 HBase 2.y 中不起作用,由于 Master 初始化上的死锁,不应在生产设置中使用。建议下游用户将相关配置设置视为实验性功能,而该功能不适合生产设置。

相关更改的简要摘要:

  • 主人默认不再携带地区

  • hbase.balancer.tablesOnMaster 是一个布尔值,默认为 false(如果它持有表的 HBase 1.x 列表,则默认为 false)

  • hbase.balancer.tablesOnMaster.systemTablesOnly 是布尔值,可将用户表保持为主状态。默认为假

  • 那些希望复制旧服务器列表配置的用户应该部署一个独立的 RegionServer 进程,然后依赖 Region Server Groups

删除了“分布式日志重播”功能

分布式日志重播功能已损坏,已从 HBase 2.y 中删除。结果,所有相关的配置,Metrics,RPC 字段和日志记录也已删除。请注意,在运行 HBase 1.0 时发现该功能不可靠,默认情况下未使用此功能,当我们开始忽略将其打开的配置(HBASE-14465)时,该功能已在 HBase 1.2.0 中有效删除。如果当前正在使用该功能,请确保执行干净关机,确保所有 DLR 工作已完成,并在升级之前禁用该功能。

前缀树编码已删除

前缀树编码已从 HBase 2.0.0(HBASE-19179)中删除。在 hbase-1.2.7,hbase-1.4.0 和 hbase-1.3.2 中已弃用(最新!)。

由于未积极维护此功能,因此删除了该功能。如果有兴趣恢复这种以降低写入速度为代价来改善随机读取延迟的便利功能,请在* dev 的 hbase dot apache dot org *处编写 HBase 开发人员列表。

在升级到 HBase 2.0 之前,需要从所有表中删除前缀树编码。为此,首先需要将编码从 PREFIX_TREE 更改为 HBase 2.0 支持的其他格式。之后,您必须对以前使用 PREFIX_TREE 编码的表进行压缩。要检查哪些列族使用的数据块编码不兼容,可以使用Pre-Upgrade Validator

Changed metrics

以下 Metrics 已更改名称:

  • 以前以“ AssignmentManger” [sic]的名义发布的 Metrics 现在以“ AssignmentManager”的名义发布

以下 Metrics 已更改其含义:

  • 基于每个区域服务器发布的度量标准'blockCacheEvictionCount'不再包括由于其所在的 hfile 无效(例如,通过压缩)而从缓存中删除的块。

  • Metrics“ totalRequestCount”每个请求增加一次;之前,它增加了请求中携带的Actions的数量;例如如果一个请求是由四个 Get 和两个 Put 组成的multi,则我们将'totalRequestCount'增加 6;现在无论如何我们都增加一。期望在 hbase-2.0.0 中看到该 Metrics 的较低值。

  • 现在,“ readRequestCount”对返回非空行的读取进行计数,在较旧的 hbase 中,无论是否为 Result,我们都会增加“ readRequestCount”。如果对不存在的行的请求,则此更改将使读取请求图的配置文件平坦。 YCSB 读取繁重的工作负载可以执行此操作,具体取决于数据库的加载方式。

以下 Metrics 已删除:

  • 与分布式日志重播功能有关的 Metrics 不再存在。通常在区域服务器上下文中以“重播”名称找到它们。有关详细信息,请参见删除了“分布式日志重播”功能部分。

添加了以下 Metrics:

  • “ totalRowActionRequestCount”是区域行操作的总数,该操作汇总了读写操作。

Changed logging

HBase-2.0.0 现在使用slf4j作为其日志记录前端。以前,我们使用log4j (1.2)。对于大多数情况而言,过渡应该是无缝的。 slf4j 很好地解释了* log4j.properties *日志记录配置文件,因此您不会注意到日志系统发出的任何差异。

也就是说,您的* log4j.properties *可能需要刷新。例如,请参见HBASE-20351,其中陈旧的日志配置文件表现为 netty 配置,并在 DEBUG 级别上作为每个 shell 命令调用的前导转储。

ZooKeeper 配置不再从 zoo.cfg 中读取

HBase 不再选择读取与 ZooKeeper 相关的配置设置的'zoo.cfg'文件。如果以前使用“ hbase.config.read.zookeeper.config”配置来实现此功能,则应在添加前缀“ hbase.zookeeper.property”的同时将所有需要的设置迁移到 hbase-site.xml 文件。每个属性名称。

权限变更

以下与权限相关的更改是更改的语义或默认值:

  • 现在,授予用户的权限将与该用户的现有权限合并,而不是覆盖它们。 (有关详细信息,请参见HBASE-17472 的发行说明)

  • 区域服务器组命令(在 1.4.0 中添加)现在需要 Management 员权限。

大多数 Admin API 不适用于 HBase 2.0 之前的 Client 端的 HBase 2.0 群集

从 HBase 2.0 之前的 Client 端使用许多 Management 命令时,这些命令不起作用。这包括一个具有 HBase 2.0 之前版本的库 jar 的 HBase Shell。您将需要计划中断使用 ManagementAPI 和命令,直到您还可以更新到所需的 Client 端版本。

从 HBase 2.0 之前的 Client 端执行以下 Client 端操作不适用于 HBase 2.0 群集:

  • list_procedures

  • split

  • merge_region

  • list_quotas

  • enable_table_replication

  • disable_table_replication

  • 快照相关命令

在 1.0 中不推荐使用的 Management 命令已被删除。

在 1.0 中不推荐使用的以下命令已被删除。列出了替换命令(如果适用)。

  • 'hlog'命令已被删除。下游用户应改为使用“ wal”命令。

区域服务器内存消耗发生变化。

从 HBase 1.4 之前的版本升级的用户应阅读区域服务器内存消耗发生变化。部分中的说明。

此外,HBase 2.0 更改了跟踪内存存储器以进行刷新决策的方式。以前,数据大小和存储开销都用于计算冲刷阈值的利用率。现在,仅使用数据大小来做出这些按区域的决策。在 Global 范围内,存储开销的增加用于做出有关强制刷新的决策。

用于拆分和合并的 Web UI 对行前缀进行操作

以前,Web UI 在表状态页上包含功能,可以根据编码的区域名称合并或拆分。在 HBase 2.0 中,该功能通过使用行前缀来起作用。

从 HBase 1.4 之前的复制用户的特殊升级

用户在运行 1.4.0 发行版之前使用复制的 HBase 版本时,请务必阅读复制对等方的 TableCFs 配置部分中的说明。

HBase Shell 更改

HBase shell 命令依赖于 Binding 的 JRuby 实例。Binding 的 JRuby 已从 1.6.8 版本更新到 9.1.10.0 版本。表示从 Ruby 1.8 到 Ruby 2.3.3 的更改,后者为用户脚本引入了不兼容的语言更改。

现在,HBase Shell 命令将忽略早期 HBase 1.4 发行版中的“ --return-values”标志。相反,shell 始终表现出好像已传递该标志的行为。如果您希望避免在控制台中打印表达式结果,则应按照irbrc部分中的说明更改 IRB 配置。

HBase 2.0 中的协处理器 API 已更改

已对所有协处理器 API 进行重构,以提高对二进制 API 兼容性的支持能力,以支持将来的 HBase 版本。如果您或您依赖的应用程序具有自定义的 HBase 协处理器,则应阅读HBASE-18169 的发行说明以获得升级到 HBase 2.0 之前需要进行的更改的详细信息。

例如,如果您在 HBase 1.2 中具有 BaseRegionObserver,则至少需要对其进行更新以实现 RegionObserver 和 RegionCoprocessor 并添加方法

...
  @Override
  public Optional<RegionObserver> getRegionObserver() {
    return Optional.of(this);
  }
...

HBase 2.0 不能再写入 HFile v2 文件。

HBase 简化了我们内部的 HFile 处理。结果,我们不能再写比默认版本 3 更早的 HFile 版本。升级用户之前,应确保 hbase-site.xml 中的 hfile.format.version 未设置为 2.否则,将导致区域服务器故障。 HBase 仍可以读取以旧版本 2 格式编写的 HFile。

HBase 2.0 无法再读取基于序列文件的 WAL 文件。

HBase 无法再读取以 Apache Hadoop 序列文件格式编写的不赞成使用的 WAL 文件。应将 hbase.regionserver.hlog.reader.impl 和 hbase.regionserver.hlog.reader.impl 配置条目设置为使用基于 Protobuf 的 WAL 读取器/写入器类。自 HBase 0.96 起,此实现已成为默认设置,因此对于大多数下游用户而言,旧的 WAL 文件不应该成为问题。

干净关闭群集应确保没有 WAL 文件。如果不确定给定的 WAL 文件格式,则可以在 HBase 群集脱机时使用hbase wal命令解析文件。在 HBase 2.0 中,此命令将无法读取基于序列文件的 WAL。有关该工具的更多信息,请参见WALPrettyPrinter部分。

过滤器行为的变化

过滤器 ReturnCode NEXT_ROW 已重新定义为跳至当前族的下一行,而不是所有族的下一行。这更合理,因为 ReturnCode 是 Store 级别的概念,而不是区域级别的概念。

下游 HBase 2.0 用户应使用 shadeClient 端

强烈建议下游用户依赖 Maven 坐标 org.apache.hbase:hbase-shaded-client 进行运行时使用。该工件包含与 HBase 集群通信时所需的所有实现细节,同时最大程度地减少了公开的第三方依赖项的数量。

请注意,此工件在 org.apache.hadoop 包空间中公开了一些类(例如 o.a.h.configuration.Configuration),以便我们可以保持与公共 API 的源兼容性。包括了这些类,以便可以对其进行更改以使用与其余 HBaseClient 端代码相同的重新定位的第三方依赖关系。如果需要在代码中“还”使用 Hadoop,则应确保所有与 Hadoop 相关的 jar 在 Classpath 中的 HBaseClient 端 jar 之前。

MapReduce 的下游 HBase 2.0 用户必须切换到新工件

HBase 与 Apache Hadoop MapReduce 集成的下游用户必须切换到依赖 org.apache.hbase:hbase-shaded-mapreduce 模块进行运行时使用。从历史上看,下游用户依赖于这些类的 org.apache.hbase:hbase-server 或 org.apache.hbase:hbase-shaded-server 工件。不再支持这两种用法,并且在大多数情况下将在运行时失败。

请注意,此工件在 org.apache.hadoop 包空间中公开了一些类(例如 o.a.h.configuration.Configuration),以便我们可以保持与公共 API 的源兼容性。包括了这些类,以便可以对其进行更改以使用与其余 HBaseClient 端代码相同的重新定位的第三方依赖关系。如果需要在代码中“还”使用 Hadoop,则应确保所有与 Hadoop 相关的 jar 在 Classpath 中的 HBaseClient 端 jar 之前。

对运行时 Classpath 的重大更改

HBase 的许多内部依赖项已从运行时 Classpath 中更新或删除。不遵循下游 HBase 2.0 用户应使用 shadeClient 端中的指导的下游 Client 端用户将必须检查 Maven 引入的依赖关系集以产生影响。 LimitedPrivate 协处理器 API 的下游用户将需要检查运行时环境的影响。有关我们过去一直在协调兼容的运行时版本方面遇到的问题的第三方库的新处理方法的详细信息,请参见参考指南HBase-第三方依赖关系和 shade/重定位

Client 端 API 对源代码和二进制兼容性的多项重大更改

用于 HBase 的 JavaClient 端 API 进行了许多更改,这些更改破坏了源代码兼容性和二进制兼容性,有关详细信息,请参阅要升级到的版本的兼容性检查报告。

跟踪实施变更

HBase 跟踪功能的支持实现已从 Apache HTrace 3 更新为 HTrace 4,其中包括一些重大更改。尽管 HTrace 3 和 HTrace 4 可以在同一运行时中共存,但它们不会相互集成,从而导致跟踪信息脱节。

升级期间对 HBase 进行的内部更改足以进行编译,但是尚未确认跟踪功能没有任何退步。请考虑此功能在不久的将来过期。

如果您以前依赖于与 HBase 操作集成的 Client 端跟踪,则建议您也将用法升级到 HTrace 4.

HFile 失去向前兼容性

由 2.0.0、2.0.1、2.1.0 生成的 HFile 与 1.4.6-,1.3.2.1-,1.2.6.1-和其他非活动版本不向前兼容。为什么 HFile 失去兼容性是新版本(2.0.0、2.0.1、2.1.0)中的 hbase 使用 protobuf 序列化/反序列化 TimeRangeTracker(TRT),而旧版本使用 DataInput/DataOutput。为了解决这个问题,我们必须将HBASE-21012放入 2.x,并将HBASE-21013放入 1.x。有关更多信息,请检查HBASE-21008

Performance

考虑到读写路径已发生重大变化,升级到 hbase-2.0.0 时,性能概要文件可能会发生变化。在发布时,根据上下文的不同,写入可能会变慢,而读取结果可能会相同或好得多。准备花些时间进行调整(请参阅Apache HBase 性能调优)。性能也是一个需要积极审查的领域,因此希望在以后的发行版中有所改进(请参阅HBASE-20188 测试性能)。

默认压缩吞吐量

HBase 2.x 带有默认的压缩执行速度限制。此限制是按 RegionServer 定义的。在以前的 HBase 版本中,默认情况下压缩的运行速度没有限制。对压缩的吞吐量施加限制应确保来自 RegionServer 的操作更加稳定。

请注意,此限制是每个 RegionServer 而不是每个压缩