前言

在容器化时代，使用 Docker 部署像 HBase 这样复杂的分布式系统也比较方便。社区也提供了许多方便的 HBase Docker 镜像，没有找到官方的 apache的，但有包含许多大数据工具的 harisekhon/hbase 或用于学习目的的 bigdatauniversity/hbase 等，下载量多的一般都比较老了，也可以找最新的。选择一个合适的镜像可以快速启动 HBase 实例。小子是在老镜像上基础上创建的。

问题及结论

然而，即使使用了预构建的镜像，仍然可能遇到挑战。先总结一下小子在 Docker 环境中使用 HBase 2.5.11 时，遇到的问题及解决方案，后面是详细介绍：

1. HMaster 启动失败： 由于本地文件系统缺少 hflush 能力，通过设置 hbase.unsafe.stream.capability.enforce=false 绕过强制检查得以解决。
2. Zookeeper 启动失败： 因 /tmp 目录数据不一致，通过清理 Zookeeper 数据目录并强调持久化存储的重要性得以解决。
3. Snappy 压缩失败： 由于默认 Codec 依赖 Native 库在 Docker 环境中出现问题，通过在 hbase-site.xml 中配置使用纯 Java 的 Snappy Codec (hbase.io.compress.snappy.codec) 解决。

环境

• HBase 版本: 2.5.11
• 部署环境: Docker (未使用 HDFS，hbase.rootdir（/hbase-data) 指向本地文件系统路径)
• 1-master+1-regionserver+1-zookeeper

问题一：HMaster 启动失败 - “StreamLacksCapabilityException: hflush”

在尝试启动 HBase 集群时，遇到的第一个拦路虎是 HMaster 进程无法成功启动。检查 Master 日志 (logs/hbase--master-....log)，定位到以下关键错误信息：

2025-04-26T09:04:32,270 WARN  [main] wal.AbstractProtobufLogWriter: Init output failed, path=file:/hbase-data/MasterData/WALs/...
org.apache.hadoop.hbase.util.CommonFSUtils$StreamLacksCapabilityException: hflush# ... (堆栈跟踪)2025-04-26T09:04:32,277 ERROR [main] wal.AsyncFSWALProvider: The RegionServer async write ahead log provider relies on the ability to call hflush for proper operation... but the current FileSystem does not support doing so. Please check the config value of 'hbase.wal.dir' and ensure it points to a FileSystem mount that has suitable capabilities...2025-04-26T09:04:32,281 ERROR [main] master.HMaster: Failed to become active master
java.io.IOException: cannot get log writer# ... (Caused by: StreamLacksCapabilityException: hflush)2025-04-26T09:04:32,282 ERROR [main] master.HMaster: ***** ABORTING master ...: Unhandled exception. Starting shutdown. *****

原因分析:

日志非常清晰地指出了问题所在：

1. HBase 的 hbase.rootdir 被配置为 file:/hbase-data，使用的是本地文件系统。
2. HBase 默认（或当前配置）的 Write-Ahead Log (WAL) 提供者是 AsyncFSWALProvider。
3. AsyncFSWALProvider 设计上依赖底层文件系统提供 hflush 功能，这是 HDFS 文件系统的一个重要能力，用于确保数据被强制刷写到存储介质，保证数据持久性。
4. 然而，标准的本地文件系统 (file:/) 实现通常不保证或不报告支持 hflush 这个 HDFS 特有的能力。
5. 因此，在初始化 WAL 时，由于底层文件系统缺少所需的能力，导致 AsyncFSWALProvider 初始化失败，进而 HMaster 启动中止。

解决方案探索与最终方案:

小子查资料（包括从gemini和chatgpt上问）首先尝试修改 hbase-site.xml（在$HBASE_HOME/conf下），将 WAL 提供者更改为旧版的、理论上更适合本地文件系统的 filesystem：

<property><name>hbase.wal.provider</name><value>filesystem</value>
</property>

遗憾的是，仅仅这样修改并重启后，问题依旧存在。推测可能是 HBase 或 Hadoop 的底层库在实际使用 WAL 提供者之前，仍然会进行一个文件系统能力的预检查，这个检查仍然失败了。

最终找到并确认有效的解决方案是在 hbase-site.xml 中添加以下配置，显式地禁用强制的文件流能力检查（是联网的chatgpt给出的答案）：

<property><name>hbase.unsafe.stream.capability.enforce</name><value>false</value>
</property>

解释: 将此参数设置为 false，相当于告诉 HBase：“我知道我使用的文件系统可能没有报告支持 hflush 这些高级能力，但请不要因为这个检查就失败，继续尝试运行。” 这样就绕过了启动时的强制检查。

关于 “unsafe”: 这个名字提醒我们，禁用检查意味着 HBase 失去了对底层存储 hflush 能力的强保证。对于本地文件系统，操作系统通常有缓存机制，虽然 filesystem WAL 提供者会尽力（如使用 fsync）保证数据落盘，但在极端情况（如 OS 崩溃且 fsync 未完成）下，理论上存在丢失极少量已确认写入的数据的风险。不过，在 Docker 中使用可靠的本地卷进行开发或测试，这种风险通常是可接受的。生产环境中使用非 HDFS 存储时，务必谨慎评估此配置的安全性影响。

应用此配置并重启后，HMaster 终于成功启动了！

问题二：Zookeeper 启动失败 - “No snapshot found, but there are log entries”

在多次重启（尤其在容器内直接重启hbase时）的 Zookeeper 进程也可能启动失败。查看 Zookeeper 的日志 ($HBASE_HOME/logs/zookeeper.log)，发现了这个错误：

2025-04-26T08:46:06,621 INFO  [main] persistence.SnapStream: zookeeper.snapshot.compression.method = CHECKED
java.io.IOException: No snapshot found, but there are log entries. Something is broken!at org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:290)at org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:285)# ... (堆栈跟踪省略)

日志同时显示 Zookeeper 的数据和快照目录位于 /tmp/hbase-root/zookeeper/version-2。

原因分析:

这个错误表明 Zookeeper 的数据目录处于一个不一致的状态：存在事务日志文件，却没有对应的快照文件作为恢复的起点。在 Docker 环境下，尤其当数据目录指向 /tmp 时，常见原因有：

1. /tmp 的易失性: 容器重启可能导致 /tmp 目录下的内容被部分或全部清除。
2. 不正常关闭: 上次容器非正常退出，可能导致 Zookeeper 数据文件写入中断或损坏。
3. 缺少持久化: Zookeeper 的数据目录没有配置 Docker Volume 或绑定挂载到宿主机的持久化存储上。

小子的容器原因，是因为没有重启pod，老版本hbase启用成功过，zk有数据持久化到目录，升级到高版本不兼容，就启动不起来了。

解决方案:

最直接有效的办法是清理掉这个损坏的 Zookeeper 数据目录。

1. 停止 HBase 相关容器。
2. 进入 Master 容器（如果 ZK 在此容器内）或操作对应的 Docker Volume。
3. 删除 Zookeeper 数据目录：

   # 示例：在容器内执行
   rm -rf /tmp/hbase-root/zookeeper
   

或直接重新启动容器。

执行清理操作后，Zookeeper 成功启动。

配置优化：调整 JVM 堆内存

为了让 HBase 更稳定、性能更好，可以根据容器或服务器的资源情况，为 HBase 的核心组件（Master, RegionServer, Zookeeper）分配合适的 JVM 堆内存。们通过修改 hbase-env.sh 文件来设置（也可以通过 Docker 环境变量如 HBASE_MASTER_OPTS 等方式传入）。

在 conf/hbase-env.sh 文件中添加或修改以下行：

# ==============================================================================
# JVM Heap Settings for HBase Components
# ==============================================================================# 设置 HBase Master 最大堆内存为 3GB
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -Xmx3g"# 设置 HBase RegionServer 最大堆内存为 6GB
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -Xmx6g"# 设置 HBase 管理的 Zookeeper 最大堆内存为 1GB (仅对内嵌 ZK 有效)
export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS -Xmx1g"# ==============================================================================
# 可选: 设置初始堆大小 (-Xms) 与最大堆大小一致以提高性能
# ==============================================================================
# export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -Xms3g"
# export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -Xms6g"
# export HBASE_ZOOKEEPER_OPTS="$HBASE_ZOOKEEPER_OPTS -Xms1g"

应用方式:

• 将修改后的 hbase-env.sh 文件通过 Docker Volume 挂载到容器的 /path/to/hbase/conf/hbase-env.sh 位置。
• 或者，基于 HBase 镜像构建一个新镜像，在 Dockerfile 中将修改后的文件 COPY 进去。

重要: 修改配置后，需要重启对应的 HBase 容器才能生效。同时，确保为 Docker 容器本身分配了足够的内存（例如，使用 docker run --memory 或 docker-compose.yml 中的 deploy.resources.limits.memory）来容纳设置的 JVM 堆以及其他开销。

问题三：Snappy 压缩表创建失败 - “previously failed test”

HBase服务启动成功后。尝试创建一个使用 Snappy 压缩的表：

create 'test_snappy_1', {NAME => 'cf1', COMPRESSION => 'SNAPPY'}

没想到，RegionServer 日志中又出现了错误：

2025-04-26T05:19:20.671847592Z 2025-04-26 05:19:20,490 ERROR [RS_OPEN_REGION-...] handler.OpenRegionHandler: Failed open of region=test_snappy_1...
2025-04-26T05:19:20.671852492Z org.apache.hadoop.hbase.DoNotRetryIOException: Compression algorithm 'snappy' previously failed test.
2025-04-26T05:19:20.671857792Z 	at org.apache.hadoop.hbase.util.CompressionTest.testCompression(CompressionTest.java:93)# ... (堆栈跟踪)

错误信息 Compression algorithm 'snappy' previously failed test 指示 HBase 在尝试使用 Snappy 压缩时，其内部的压缩算法测试失败了。

原因分析与纯 Java Codec:

根据 HBase 官方文档，HBase 支持多种压缩算法，包括 Snappy。默认情况下，SNAPPY 算法通常映射到 org.apache.hadoop.io.compress.SnappyCodec 这个实现。这个实现依赖于 Hadoop Native Library。在 Docker 环境中，如果：

• 基础镜像没有包含 Hadoop Native Library；
• 包含的 Native Library 版本与操作系统或 JVM 不兼容；
• Native Library 因为某些原因加载失败；

那么，依赖 Native Library 的 Snappy Codec 就会在 HBase 的 CompressionTest 中失败。

幸运的是，新版的HBase支持纯 Java 实现的压缩 Codec，它们不依赖于操作系统级别的 Native 库，从而可以避免这类环境兼容性问题：

• 官方介绍的Java 实现
• 2.5.x才支持的jira说明

由于小子使用的是 HBase 2.5.11，这些纯 Java 实现都是可用的。不想再引入HDFS，所以使用纯 Java 实现是理想的选择。

解决方案：配置使用 Aircompressor Snappy Codec

在 hbase-site.xml 中添加以下配置，明确指定 SNAPPY 压缩算法使用 Aircompressor 提供的纯Java 实现：

<property><name>hbase.io.compress.snappy.codec</name><value>org.apache.hadoop.hbase.io.compress.aircompressor.SnappyCodec</value>
</property>

然后务必重启 HBase Master 和所有 RegionServer 进程。

重启完成后，再次尝试创建 Snappy 压缩表：

create 'test_snappy_1', {NAME => 'cf1', COMPRESSION => 'SNAPPY'}

这一次，命令成功执行，表成功创建！

也可以使用以下命令验证：

$HBASE_HOME/bin/hbase org.apache.hadoop.hbase.util.CompressionTest file:///tmp/test.txt snappy

结语

在 Docker 中部署和运行 HBase 2.5.11 的过程充满了挑战，但也收获颇丰。小子也顺手记录，以飨各位看官，欢迎留言交流！

---