第一次在赫兹威客的测试环境里跑 HBase 伪分布式我以为start-hbase.sh敲下去jps里多出 HMaster 就算过关。结果第一次往表里写数据就卡住查了一下午发现 WAL 目录不在我以为的位置RegionServer 的端口又被另一个进程占着。后来我把整套流程重新拆了一遍从版本匹配、端口清单、目录规划到 shell 写入、预分区、自动拆分、Sqoop 导数全部跑通之后才敢说伪分布式 HBase 的测试重点不在“启动成功”而在“链路可用”。这篇教程按单机伪分布式来写适合三类人刚搭完 Hadoop 想练 HBase 的、准备面试想自己复现 WAL/端口/拆分机制的、以及做数据导入导出测试时想把 Sqoop 也接进来的。我不复读概念直接给出一套能在赫兹威客这类环境里一步步复现的测试流程。你不需要额外买服务器一台机器、几个配置文件、一个 HBase shell 就能完成大部分关键验证。1. 伪分布式测试到底在测什么先别把单机看简单了1.1 伪分布式不是“单机版”很多人把 HBase 的 standalone 模式和伪分布式混在一起这是测试时最容易理解偏的地方。standalone 模式下 HBase 不依赖 HDFS数据直接写本地文件进程也只有一个说白了就是一个能跑put/get的演示程序。它验证不了分布式环境下真正关心的问题数据到底怎么落盘、WAL 写到哪里、RegionServer 挂了以后如何恢复。伪分布式就不同了。HBase 会以分布式模式运行Master 和 RegionServer 是独立进程只是都跑在同一台机器上。关键在于hbase.rootdir指向的是 HDFS所以 WAL、HFile、Region 的元数据全部走了一遍“真实”的分布式存储路径。测试完这套环境你至少能回答写入一条数据之后HDFS 上发生了什么Region 超过阈值后HBase 如何拆分HMaster 和 RegionServer 各占哪些端口。1.2 一套环境能覆盖哪些测试项我在赫兹威客这类单机构建环境里做过一轮完整测试实际能覆盖的有这么几项HBase 与 HDFS 的集成验证确认 rootdir 指向正确、WAL 落盘到 HDFS、region 数据可以 flush。HBase Shell 操作练习建表、删除表、put、get、scan、flush、split。预分区创建多 region 表观察 rowkey 如何按拆分点分布。自动拆分与手动拆分通过调低阈值触发自动拆分或者用split命令主动拆分。周边工具链路用 Sqoop 把 MySQL 数据导入 HBase验证 Java 客户端写入路径。这一套东西在完全分布式集群上也能跑只是排错成本高。伪分布式时所有日志都在本地机器出了问题直接看 HBase 和 Hadoop 的日志目录就能定位特别适合当测试沙盒。当然伪分布式有一个硬边界它测不了跨节点故障转移、网络分区、多 RegionServer 负载均衡这类真正和“分布式”强相关的问题。你心里得有数别把单机测试结论直接套到生产集群上。2. 动手之前定三个参数版本组合、端口清单、数据目录2.1 版本组合别追新跑 HBase 伪分布式第一个大坑是版本乱搭。HBase 通过 Hadoop 的 FileSystem API 读写 HDFS版本不兼容时经常出现UnsupportedOperationException或者 RPC 协议不匹配。我的建议是不要凭感觉选最新版先看 HBase 官方文档里的兼容矩阵再选一套别人已经踩过坑的组合。下面是我在伪分布式环境里比较稳的组合可以参考组件建议版本说明JDK8 或 11HBase 2.x 对 JDK 8 支持最稳JDK 11 也可以但别直接上太高版本Hadoop3.1.x / 3.2.x能稳定支撑 HBase 2.xHDFS 端口默认是 9000 或 8020HBase2.3.x / 2.4.x2.x 系列配置项和端口比 1.x 清晰社区资料多ZookeeperHBase 内置测试环境直接让 HBase 管理自己的 ZK少一个配置项安装路径也要固定。我在赫兹威客环境里用/opt/hadoop和/opt/hbase所有环境变量写进/etc/profile.d/bigdata.sh避免后面启动脚本找不到HADOOP_HOME。2.2 端口清单先背熟伪分布式测试时端口冲突是最常见、又最容易被忽略的问题。HBase 2.x 默认端口如下建议动手前先列成表格贴到终端旁边服务进程RPC 端口Web 端口说明HBase MasterHMaster1600016010Master 对外 RPC 和 Web UIHBase RegionServerHRegionServer1602016030数据读写和 Web UIZookeeperHQuorumPeer2181-HBase 自己维护 ZK 时会出现HDFS NameNodeNameNode9000 或 80209870取决于fs.defaultFS配置网上不少老教程会写 60010、60030那是 HBase 1.x 的默认端口。如果你用 2.x 却对着老端口排查会白白浪费很多时间。检查端口是否被占用用一条命令就能完成ss -lntp | grep -E 16000|16010|16020|16030|21812.3 数据目录和配置文件是最容易出错的一环HBase 的配置主要在$HBASE_HOME/conf/hbase-site.xml。伪分布式最少要配清楚 rootdir、分布式模式、ZooKeeper 地址这三项。先看一份我常用的最小配置configuration property namehbase.rootdir/name valuehdfs://localhost:9000/hbase/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.zookeeper.quorum/name valuelocalhost/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /property property namehbase.zookeeper.property.dataDir/name value/home/bigdata/hbase-zk/value /property /configurationhbase.cluster.distributed必须为true否则 HBase 不会连接 HDFS。hbase.rootdir的值要和 Hadoop 的fs.defaultFS保持一致我这边 NameNode RPC 端口是 9000所以写hdfs://localhost:9000/hbase。你要是用的 8020就把端口改掉别照抄。ZooKeeper 的dataDir放在本地磁盘即可测试环境不需要单独搭 ZK 集群。另外Windows 上跑伪分布式有一个额外注意点Hadoop 依赖winutils.exe这类本地库直接跑 shell 脚本很容易报Failed to locate the winutils binary。如果你必须在 Windows 下测试建议用 WSL 或者提前把winutils.exe放到 Hadoop 的bin目录否则后面的启动验证环节会劝退你。3. 启动后先体检进程、Web端口和WAL落盘路径一次过3.1 启动命令与进程清单配置没问题后先启动 HDFS再启动 HBasestart-dfs.sh start-hbase.sh等一两分钟用jps看进程。伪分布式环境下正常情况下应该能看到NameNode、DataNode、SecondaryNameNode、HMaster、HRegionServer如果 HBase 自己管理 ZK还会有一个 HQuorumPeer。NameNode DataNode SecondaryNameNode HMaster HRegionServer HQuorumPeer如果只有 HMaster 没有 HRegionServer多半是启动脚本认为 RegionServer 已经启动或者端口被占用。这时不要反复执行start-hbase.sh先用jps确认残留进程再用stop-hbase.sh清掉最后看日志定位。HBase 日志路径在$HBASE_HOME/logs/文件名类似hbase-bigdata-master-xxx.log和hbase-bigdata-regionserver-xxx.log。启动失败时最重要的是先看 master 日志最后 50 行而不是盲目调配置。3.2 Web UI 和端口确认进程齐全后浏览器打开两个页面HMaster Web UIhttp://localhost:16010RegionServer Web UIhttp://localhost:16030HMaster 页面能看到表列表、region 分布、RegionServer 是否在线。HRegionServer 页面能看到 store 文件数、memstore 大小、region 数量。伪分布式测试里我建议每次写数据前后都刷新一下 RegionServer 页面观察 region 数量变化这对理解拆分和 flush 很有帮助。如果页面打不开先看端口是否监听ss -lntp | grep 16010 ss -lntp | grep 16030有些环境里防火墙会把端口拦住测试时可以直接在 HBase 的启动账号下用curl -I http://localhost:16010验证能通就说明是防火墙问题。3.3 WAL落盘路径验证WAL 路径是测试里最容易“想当然”的地方。我刚跑通 HBase 2.x 时总以为 WAL 写在 RegionServer 的本地磁盘后来查 HDFS 才发现完全不是这样。HBase 的 WAL 默认在hbase.rootdir下的WALs目录路径结构是这样的/hbase/WALs/RegionServer主机名,端口,启动时间/WAL文件名注意目录名是WALs大小写敏感。有些老资料会写.logs或wals那是旧版本或者不同实现的目录你在 2.x 里照着找会扑空。启动完成后可以先用 HDFS 命令验证hadoop fs -ls /hbase hadoop fs -ls /hbase/WALs如果 HBase 已经正常运行/hbase下至少有.tmp、WALs、data等目录。WALs下面会出现一个以 RegionServer 命名的子目录。这时候还没有任何业务数据WAL 目录可能只有一个空目录。真正要验证 WAL 是否工作需要往表里写数据。我习惯写一行数据后立刻去 HDFS 看hbase shell create default:wal_test, cf put default:wal_test, row1, cf:name, test然后回到 HDFShadoop fs -ls -R /hbase/WALs | tail -20如果看到 WAL 文件体积从 0 变大说明写入链路是通的。这一步能帮你快速区分“HBase 进程活着”和“HBase 数据链路正常”是两回事。3.4 Shell 状态检查最后用 HBase Shell 做一次健康检查hbase shell status status detailed version list_namespacestatus会显示 RegionServer 数量和请求数status detailed会列出每个表的 region 分布。这个命令在本篇后面观察预分区和自动拆分时会反复用到建议养成习惯。4. 实例验证基于Shell的批量写入、预分区与拆分观察4.1 建表与基础写入Shell 验证从建表开始。我先建一个带命名空间的表create_namespace test create test:user, cf接着写几行数据put test:user, 1001, cf:name, zhangsan put test:user, 1002, cf:age, 25 get test:user, 1001 scan test:user这里能直接看到 HBase 的行是按 rowkey 字典序排列的。如果我只写少量数据你会注意到scan是从小到大输出。这本不是什么高级操作但它是后面理解预分区和热点问题的基础。4.2 预分区为什么要拆怎么拆默认建表时HBase 只创建一个 region所有写入都由这唯一一个 region 承担。测试时数据量大一点你就会看到单 region 的 flush 压力、读请求集中在一个 RegionServer 上。生产环境里这叫热点问题解决思路之一就是预分区。预分区就是在建表时把一张表的范围分成多个 region。HBase Shell 支持直接写拆分点create test:user_pre, cf, SPLITS [1000, 2000, 3000]这个命令会创建 4 个 region拆分范围大致是(-∞, 1000]、(1000, 2000]、(2000, 3000]、(3000, ∞)。建完后用status detailed或 HMaster 页面就能看到这张表有 4 个 region。预分区的拆分点是按 rowkey 字节比较的不是按数值大小。所以如果 rowkey 是1001、1002这种字符串它们会落在(1000, 2000]这个区间但如果 rowkey 是2和1001字典序结果是1001 2因为字符1比字符2小。测试时一定要想清楚 rowkey 规则不然预分区效果会和你预期完全不同。还有一种更偷懒的方式指定 region 数量和切分算法create test:user_hash, cf, {NUMREGIONS 6, SPLITALGO HexStringSplit}这种方式适合 rowkey 是哈希值或十六进制字符串的场景。伪分布式测试里只有一台 RegionServer预分区不会带来性能提升但它能让你直观看到 region 的划分逻辑这部分理解透了后面线上扩容就有底了。4.3 自动拆分实验调低阈值批量写入自动拆分是 HBase 面试里经常被问到、但很多人没亲手验证过的机制。生产环境默认阈值是 10GB你不可能在测试环境里等到一个 region 涨到 10GB所以需要把阈值调小。我建议在hbase-site.xml里加上这一项property namehbase.hregion.max.filesize/name value10485760/value /property这里设置的是 10MB。改完配置必须重启 HBasestop-hbase.sh start-hbase.sh然后建一张表用 Shell 的 Ruby 循环批量写入hbase shell create test:split_demo, cf for i in 1..300000 do put test:split_demo, rk_ i.to_s, cf:value, val_ i.to_s end flush test:split_demo这一步数据量大约几十 MB写入过程中 HBase 会自动触发 flush把 memstore 刷成 HFile。flush 后由于 HFile 大小超过了我们设的 10MB 阈值RegionServer 的后台线程会检查并触发拆分。查看拆分是否发生status detailed输出里test:split_demo这一段会显示多个 region。你也可以去 HMaster 的 Web UI 页面看表详情region 数量比刚建表时多就说明自动拆分已经生效。如果等了很久还是没拆分常见原因有两个一是数据量不够HFile 还没到阈值二是没有触发 flush导致 RegionServer 没做拆分检查。解决了这两点自动拆分基本都能复现。4.4 手动拆分作为自动拆分的补充自动拆分观察不到时可以用手动拆分的split命令split test:split_demo, rk_150000这条命令会在 rowkey 为rk_150000的位置把 region 一分为二。拆分是异步的执行后稍等几秒再看status detailed或 Web UIregion 数量会增加。手动拆分的好处是可控适合测试拆分点选择、观察 region 边界也适合在自动拆分还没触发时快速验证拆分链路。我在实际测试中会把自动拆分和手动拆分结合起来先降低阈值触发一次真实自动拆分再用手动拆分验证指定 rowkey 的边界移动。两轮下来HBase 的拆分机制基本就摸清了。5. 把MySQL导进HBaseSqoop环节的常见坑和验证方法5.1 Sqoop 操作 HBase 的基本命令很多项目里HBase 不算数据源头而是作为查询层。最常见的链路是 MySQL 业务库数据通过 Sqoop 导入 HBase这个环节在伪分布式环境里也一定要测通。Sqoop 导入 HBase 的原理是MapReduce 任务读取 MySQL 表把每条记录包装成 HBase 的 Put再通过 HBase 客户端写入目标表。我有一个测试用的 MySQL 表user_info字段是id、name、age。导入命令如下sqoop import \ --connect jdbc:mysql://localhost:3306/testdb \ --username root \ --password 123456 \ --table user_info \ --hbase-table test:user_from_mysql \ --column-family cf \ --hbase-row-key id \ --hbase-create-table \ -m 1参数含义不复杂--hbase-table指定导入的目标表--column-family指定列族--hbase-row-key指定把 MySQL 的哪一列作为 rowkey--hbase-create-table表示目标表不存在时自动创建。这里我刻意加了-m 1。伪分布式测试数据量不大一个 mapper 就够如果数据量大多个 mapper 并发写 HBase 会导致 region 热点更明显反而不利于观察问题。5.2 常见报错与处理Sqoop 操作 HBase 最常见的报错是启动 MapReduce 任务时找不到 HBase 相关类报错形如ClassNotFoundException: org.apache.hadoop.hbase.client.Connection。原因很简单Sqoop 启动后MapReduce 任务跑在 Hadoop 环境里而 Hadoop 的 classpath 里没有 HBase 的依赖。处理办法是把 HBase 的 lib 加进 Hadoop classpathexport HBASE_HOME/opt/hbase export HADOOP_CLASSPATH$HADOOP_CLASSPATH:$HBASE_HOME/lib/*除了 classpath还要确认 MySQL 的 JDBC 驱动 jar 放在$SQOOP_HOME/lib目录下否则会卡在连不上 MySQL。测试时用-m 1还有一个好处可以降低对 MySQL 并发读的压力小表场景下没必要开多个 mapper。5.3 导入结果验证导入完成后去 HBase Shell 里扫描目标表hbase shell scan test:user_from_mysql能看到 MySQL 的每一行都变成了 HBase 里的一行rowkey 是 MySQL 的id列名为cf:name、cf:age。注意MySQL 的数值字段导入后会按字节数组存进 HBaseShell 里显示的是字符串形式这是预期行为。如果不想让 Sqoop 自动建表也可以先在 HBase 里手动建好预分区表再在 Sqoop 命令中去掉--hbase-create-table。这样数据导入时会直接落到多个 region 上更接近生产写入模式。6. 这些细节面试常问也是伪分布式测试里最容易翻车的地方6.1 我踩过的最典型几个坑第一个坑是 WAL 路径大小写。HBase 2.x 的 WAL 目录是/hbase/WALs我一开始写的是/hbase/wals在 HDFS 上怎么查都查不到。测试时要先hadoop fs -ls /hbase看实际目录名不要凭记忆敲路径。第二个坑是 HDFS 安全模式。Hadoop 刚启动时 NameNode 可能处于安全模式HBase 的 RegionServer 能起来但写数据会一直卡住或报错。遇到写入超时先执行hadoop dfsadmin -safemode leave再写一次很多“HBase 写入失败”的问题其实出在它下面的 HDFS。第三个坑是端口被旧进程占用。HBase 启动失败后jps里可能还有 HMaster 残留。不要直接再启一次先stop-hbase.sh确认进程都退干净再重新启动。伪分布式环境里我见过太多人反复启动导致 ZK 数据目录错乱最后只能清掉dataDir重新来。第四个坑是修改配置后没停干净。改完hbase-site.xml有些人只重启 HBase但旧的 ZK 数据和 HDFS 上的临时目录还在启动后行为很诡异。稳妥做法是stop-hbase.sh jps # 如果还有 HMaster/HRegionServer手动 kill hadoop fs -rm -r /hbase/.tmp 2/dev/null start-hbase.shWindows 上的第五个坑前面提过Hadoop 缺少winutils.exe会直接导致 HBase 起不来。如果你一定要在 Windows 里做这套测试用 WSL 是最省事的方案别和自己过不去。6.2 如果面试被问到怎么回答这几个点WAL 路径问题标准回答是 WAL 位于 HBase 的hbase.rootdir下的WALs目录RegionServer 写数据时先顺序写 WAL再写 memstoreRegionServer 故障后可以重放 WAL 恢复数据。端口清单问题直接说 HBase 2.x 的 Master RPC 是 16000Master Web 是 16010RegionServer RPC 是 16020RegionServer Web 是 16030ZooKeeper 默认 2181。如果项目里改过端口以hbase-site.xml为准。自动拆分问题默认阈值是hbase.hregion.max.filesize生产默认较大测试时调小阈值才能观察到自动拆分。拆分发生后HFile 会按 rowkey 分为不同 regionShell 的status detailed能看到结果。伪分布式和完全分布式问题伪分布式用一台机器模拟集群进程在同一台机器上能验证 HDFS 集成、WAL、region 拆分等核心机制但验证不了跨节点故障恢复和网络分区。回答时先承认这个边界再强调你在伪分布式里完整跑过写入、拆分、Sqoop 导入会更有说服力。我个人的习惯是把每一次伪分布式测试都当一次“故障演习”故意写错一个配置、占掉一个端口、关掉一个进程然后自己从头排查一遍。这种折腾带来的记忆比看十篇文档都牢固。当你把 WAL 路径、端口清单、拆分配置这些细节都亲手验证过一遍再去面试或者搭真实集群心里会踏实很多。