HBase分布式列式存储实战：架构原理、Rowkey设计与热点排查

做大数据开发这几年，HBase 一直是我又爱又恨的组件。爱的是它天生就是为海量数据设计的，分布式存储和列式模型的组合，在面对几十亿行数据时依然能保持良好的读写性能；恨的是它概念不少，部署繁琐，用不好就各种 Region 热点、读写毛刺、数据倾斜。网上讲 HBase 的教程其实很多，但大多停留在“怎么装”“shell 怎么敲”这种层面，真正把架构原理、设计思路、常见坑串起来讲的太少。这篇文章我就结合自己的实际经验，把 HBase 的分布式列式存储这件事从头到尾捋一遍，落到代码和操作上，希望能帮你少踩点坑。

这套内容适合谁看？如果你刚接触 HBase，想搞明白它和 MySQL 这种行式存储到底有什么本质区别，或者你正在准备 HBase 相关的面试题，再或者你在生产环境里遇到 Region 热点、写数据速度上不去这类问题，这篇都能给出参考。我会从核心概念、架构原理讲到安装配置、Shell 操作、Java API 开发，再到预分区、Rowkey 设计、分布式事务一致性这些进阶话题，最后附上常见问题的排查思路。说句实话，很多面试题问的东西，实际工作里真的会遇到，只是当时没人告诉你该那么想。

1. 先搞清楚概念：列式存储的底层逻辑

1.1 行式存储和列式存储的本质差别

我们传统的 MySQL、Oracle 这类关系型数据库，数据是按“行”为单位存储的。一张表的一条记录，它的所有字段在磁盘上通常是不分的，想拿出来就是一行完整的数据。这非常适合 OLTP 场景，因为业务上我们经常要查一个订单的所有信息，行式存储一次 IO 就能把整条数据捞出来。

但列式存储就不一样了。它是把同一列的数据放在一起，物理上按列族（Column Family）组织。HBase 一个表可以定义多个列族，每个列族其实就是一个独立的存储单元。这样做带来的直接好处是：你在做分析查询的时候，如果只需要某几列，根本不用去扫其他列的数据，IO 量大幅下降。我举个生活化的例子，行式存储就像超市按“小票”记录——每个顾客买了什么都记在同一张纸上；列式存储就像超市按“货架”分类——所有牛奶摆在一排，所有面包摆在一排。你要是想统计今天牛奶卖了多少，直接去牛奶那排看就行，不用翻遍每张小票。

不过要注意，HBase 并不是纯碎的列式存储，严格说它是“面向列族”的存储。每个列族里面，数据还是按行键排列的，同一行的列族数据不一定要存在一起。这一点和 Parquet、ORC 这种真正的列式文件格式还有区别。HBase 的底层用 HFile 文件存储，文件里面又有列式编码的特征，所以业界习惯把它归到列式存储这一类，但你要知道它的独特之处：稀疏存储、动态列、多版本，这些才是精髓。

1.2 稀疏存储和动态列到底是什么

MySQL 建表的时候，字段基本是固定的，每一行即使某个字段值为 NULL，这个字段的位置也占了。但 HBase 的表中，你不需要预先定义很多列，每一行都可以有不同的列组合。我在实际项目里做过物联网设备数据存储，传感器上报的数据很杂，有些设备上报温度，有些上报湿度，有些上报电量，列还不一样。用 HBase 就非常爽，每行按设备 ID + 时间戳作为 Rowkey，温度、湿度、电量作为不同的列，完全不用管其他设备有没有这些列。数据不存在的列就不占存储空间，这就是稀疏存储。

动态列怎么理解呢？你在写数据的时候可以随时新增一个列，不需要像 MySQL 那样执行 ALTER TABLE 去加字段。HBase 的 Cell 就是由 Rowkey + 列族 + 列限定符（Qualifier）+ 时间戳 + 值组成的，写入的时候只要把列限定符带上，不需要的列就空着。这给架构设计带来了很大的灵活性，特别是业务字段经常变动的场景，HBase 基本不用改表结构。

1.3 为什么分布式能力是它的灵魂

光有列式存储还不够，HBase 的单机版几乎没有意义，它的灵魂在于分布式架构。存储层依赖 HDFS，把数据分片放到多台机器上；计算层通过 Region 的概念做数据分片和负载均衡。所以你看，HBase 的整个设计目标就是：在廉价机器集群上，支撑超大规模数据集的高并发读写。单台服务器撑不住的量，HBase 通过横向扩展就能解决，这是它和传统数据库最本质的分水岭。

2. 分布式架构的核心机制：Region 和 RegionServer

2.1 一张表是怎么被拆开的

HBase 表的数据在逻辑上按 Rowkey 有序排列，物理上被横向切割成一个个 Region。Region 是 HBase 分布式存储和负载均衡的最小单位。一个 Region 里包含表中某一段 Rowkey 范围的数据，比如 Rowkey 从 001 到 100 的数据放在 Region A，101 到 200 的数据放在 Region B。每个 Region 只能由一个 RegionServer 提供服务，但一个 RegionServer 可以服务多个 Region。

这个机制就是分布式能力的核心。因为数据按 Rowkey 范围分割，写的时候可以精准找到该由哪个 RegionServer 负责。同时 Region 可以分裂，比如某个 Region 的数据量达到阈值，会自动裂成两个子 Region，分别由不同的 RegionServer 管理，这样数据和负载就一起分摊出去了。我见过新手最常犯的错误，就是建完表不预分区，所有数据刚开始都挤在同一个 Region 上，写入全部打到一个 RegionServer，形成所谓的“热点”，性能惨不忍睹。

2.2 RegionServer 内部到底在忙什么

每个 RegionServer 内部的逻辑其实非常清晰，主要包括几个关键组件：

• WAL（Write-Ahead Log）：写数据前先写日志，保证数据不丢失，这机制和 MySQL 的 Redo Log 很相似。
• MemStore：内存中的写入缓冲区，数据先写到内存中，达到一定大小才刷盘，相当于一个“蓄水池”。
• BlockCache：读缓存，热点数据在内存中直接命中，不用走磁盘。
• HFile：数据最终落盘的文件格式，存储在 HDFS 上。

整个写入流程是这样的：客户端请求写入 -> 先写 WAL 日志 -> 再写 MemStore -> 当 MemStore 达到阈值（默认 128MB）就会 Flush 成 HFile 文件 -> HFile 文件越来越多之后触发 Compaction（合并压缩）。读流程的话，客户端先查 BlockCache，没命中查 MemStore，再没命中才去读 HFile，优先级从旧到新。这套机制决定了 HBase 的一些调优方向，比如写多读少的场景，可以适当调整 MemStore 大小和 Flush 频率、考虑 WAL 的同步级别；读多写少的场景，就想办法提高 BlockCache 命中率。

2.3 分布式协调与元数据管理

HBase 管理 Region 位置信息靠的是 ZooKeeper 和 HBase 内部的元数据表（hbase:meta，老版本里叫 -ROOT- 和 .META.）。ZooKeeper 负责集群的协调，比如 RegionServer 的心跳、Master 的选举。客户端读写数据的时候，并不是直接问 RegionServer 数据在哪，而是先访问 ZooKeeper，找到 hbase:meta 表的位置，再从 hbase:meta 表里查到目标 Rowkey 对应的 Region 和 RegionServer 地址。

这套分层设计好处很明显：元数据量小、查询速度快，而且 ZK 保证了高可用。不过也带来一个问题——第一次访问某行数据的路径比较长，所以生产环境里一定要用连接池，尽量复用连接，避免每次请求都重新走一遍“找位置”的流程。我记得有个项目刚开始性能上不去，排了半天发现是每次读写都新建 Connection，HBase 的 Connection 创建本来就是个重量级操作（要连接 ZK，拉取元数据），后来改成连接池复用，性能直接翻了几倍。

3. 环境准备：HBase 安装与配置的要点

3.1 伪分布式与集群部署的选择

学习阶段最快速的方式是搭一个伪分布式环境，也就是在一台机器上模拟出 Master 和 RegionServer 进程，依赖也是单机版的 HDFS 和 ZooKeeper。但我要提醒一句，伪分布式只能用来学习流程和调试代码，别拿它的性能数据去评估生产环境，因为单机环境下网络开销、磁盘 IO 的竞争情况完全和真集群不同。很多同学在伪分布式上测试觉得“还行”，上了生产才发现完全不是一回事。

生产环境建议至少三台机器，一主两从，每个节点都要有独立的磁盘。部署方式可以考虑用 Ambari 或者 Cloudera 这种管理平台，也可以手工部署。我个人的经验是：手工部署虽然初期累一点，但是能帮你把 HBase 的组件依赖、配置文件细节理得很清楚。遇到问题的时候，你对集群的掌控力会强很多。用平台部署的优势是省事，升级和监控方便，适合团队规模大、分工明确的情况。

3.2 核心配置参数逐个说清楚

hbase-site.xml 里有些参数几乎是必调的，我在自己部署的过程中会重点看这几个：

还有一个容易踩坑的点是 hbase-env.sh 里的 HBASE_HEAPSIZE 和 HBASE_OFFHEAPSIZE。默认堆内存可能只有 1GB，你在生产处理大批量数据的时候根本不够用，至少要调整到 16GB 以上。不过在调大之前，你要先看看机器的物理内存有多少，通常 RegionServer 的堆内存不要超过物理内存的 2/3，剩下的留给操作系统页缓存，读数据会用到文件系统缓存，不是说堆内存越大就一定越好。

3.3 端口清单和进程检查

HBase 的端口很容易和其它组件搞混，我在前期排查问题的时候吃过亏，整理一下：

需要注意，老版本（1.x）用的是 60000、60010 这些端口，新版本（2.x）才改成 160xx。你如果在网上查资料，一定要看清楚版本。检查集群是否正常，可以执行 hbase hbck 来检查元数据和 Region 的一致性，也可以用 jps 查看进程是否齐全：HMaster、HRegionServer、HQuorumPeer（ZooKeeper 进程）都要在。

3.4 Shell 基本操作：建表、写数据、读数据

HBase Shell 是理解数据模型最快的方式。进去之后，最常用的操作如下：

code复制# 建表，指定列族
create 'user_info', 'base', 'detail'

# 查看表结构
describe 'user_info'

# 插入一行数据
put 'user_info', '1001', 'base:name', '张三'
put 'user_info', '1001', 'base:age', '30'
put 'user_info', '1001', 'detail:address', '北京市朝阳区'

# 读取一行
get 'user_info', '1001'

# 指定列读取
get 'user_info', '1001', {COLUMN => 'base:name'}

# 扫描全表（生产环境慎用！数据量大时全表扫描会压爆所有 RegionServer）
scan 'user_info'

# 删除表
disable 'user_info'
drop 'user_info'

Shell 最大的价值是让你快速验证 HBase 的数据模型：插入的三列，可能 base 和 detail 是两个不同列族的数据，物理存储分离。如果你之前只用过关系型数据库，一开始会觉得这逻辑很别扭，习惯之后就会喜欢上这种灵活。

4. Java API 开发：用代码操作 HBase

4.1 连接配置和版本坑

HBase 的 Java API 在不同版本之间有一些变化。2.x 版本推荐使用 ConnectionFactory 获取 Connection，然后通过 connection.getTable() 拿到 Table 对象；1.x 版本还有 HTable 这个类可以直接 new，但 2.x 里已经不建议直接使用 HTable。

我建议你在 pom.xml 里引入的依赖版本一定要和集群版本保持一致。这是非常容易踩的坑——客户端 jar 包版本跟服务端不一致，连不上集群或者 RPC 协议不兼容，报错信息还很隐晦。我自己遇到过一次，客户端用的是 hbase-client 2.3.0，服务端是 2.1.0，结果连接时一直报 Connection reset by peer，查了半天才发现是版本不匹配。客户端版本最好略低于服务端版本，这样协议兼容性风险最小。

4.2 建表和预分区的一次到位写法

用 Java 实现建表的时候，最关键的就是要不要指定预分区。前面说过，不预分区的后果是初期所有数据落在一个 Region，写入就出现热点。我在建表的时候，一般会提前估算数据量，然后设计 Region 数量。比如预估一年有 2 亿行数据，单 Region 存储上限在 10GB 到 20GB，那么预分区数量大约在 20 到 30 之间比较合理。

以下是构建表的 Java 代码示例：

java复制Configuration conf = HBaseConfiguration.create();
conf.set("hbase.zookeeper.quorum", "hadoop01,hadoop02,hadoop03");
conf.set("hbase.zookeeper.property.clientPort", "2181");

try (Connection conn = ConnectionFactory.createConnection(conf);
     Admin admin = conn.getAdmin()) {

    TableName tableName = TableName.valueOf("sensor_data");
    TableDescriptorBuilder builder = TableDescriptorBuilder.newBuilder(tableName);

    ColumnFamilyDescriptor family = ColumnFamilyDescriptorBuilder.newBuilder(
        Bytes.toBytes("cf")).setMaxVersions(3).build();
    builder.setColumnFamily(family);

    // 手动预分区：0123456789ab 各作为分区键
    String[] splitKeys = new String[] {"1", "4", "7", "a"};
    byte[][] splitPoints = new byte[splitKeys.length][];
    for (int i = 0; i < splitKeys.length; i++) {
        splitPoints[i] = Bytes.toBytes(splitKeys[i]);
    }
    builder.setValue(TableDescriptorBuilder.SPLIT_POINTS, splitPoints);

    admin.createTable(builder.build());
    System.out.println("表创建成功，已预分区");
}

这里说下分区键的选择。最简单的预分区方案是按字符串协议拆分，比如 Rowkey 前缀从 0 到 z，分成 36 份。但要注意的是——如果 Rowkey 是随机字符串，这样分没问题；如果 Rowkey 是数字加业务前缀，你就要按实际分布去切。我通常的做法是先从业务数据里抽样出一批 Rowkey，统计分布后设计 split key，再去建表。不要偷懒，网上很多文章直接给 0123456789ab 这种，你在测试数据上能跑，不代表你的业务也合适。

4.3 写入数据实战：PUT 与 Buffer

单条写入的性能不理想，不要频繁 put 一条 flush 一次。正确姿势是攒一批使用 setAutoFlush(false) 提交。HBase 客户端有一个 BufferedMutator 机制，调用 mutator.mutate(List<Put>) 之后，数据先缓存在客户端，由后台线程批量发送到 RegionServer，吞吐量能提升好几倍。

来看一段实际写入示例：

java复制try (Table table = conn.getTable(TableName.valueOf("sensor_data"));) {
    table.setWriteBufferSize(6 * 1024 * 1024); // 6MB 缓冲
    List<Put> puts = new ArrayList<>();
    for (int i = 0; i < 10000; i++) {
        String rowKey = String.format("device_%d_%d", i % 1000, System.currentTimeMillis());
        Put put = new Put(Bytes.toBytes(rowKey));
        put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("temperature"), Bytes.toBytes(36.5 + i));
        put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("humidity"), Bytes.toBytes(60 + i));
        puts.add(put);
        if (puts.size() >= 1000) {
            table.put(puts);
            puts.clear();
        }
    }
    if (!puts.isEmpty()) {
        table.put(puts);
    }
    System.out.println("批量写入完成");
}

实际写入中要注意的是：Put 里的列族名必须和建表时一致，否则会抛 NoSuchColumnFamilyException。另外，每条 Put 都会有一个行键，行键的设计直接决定写入分布。如果你的 Rowkey 以时间戳开头，且时间是递增的，那么同一时间窗口的写入请求统统打到同一个 Region 上，热点问题立刻出现。我见过一个项目把时间戳直接当 Rowkey 前缀，结果每秒几万条消息全落在后面几个 Region，部分 Region 忙死，部分 Region 闲死。

4.4 读取数据实战：GET、SCAN 与过滤器

读取逻辑比写入要复杂不少。按行查询用 Get，按范围查询用 Scan，范围太大就要配合 Filter 做过滤。比较常见的过滤条件是行键前缀过滤和值过滤。

java复制try (Table table = conn.getTable(TableName.valueOf("sensor_data"))) {
    // 单行查询
    Get get = new Get(Bytes.toBytes("device_0_1699999999999"));
    Result result = table.get(get);
    for (Cell cell : result.listCells()) {
        System.out.println("列族:" + Bytes.toString(CellUtil.cloneFamily(cell)) +
                           " 列:" + Bytes.toString(CellUtil.cloneQualifier(cell)) +
                           " 值:" + Bytes.toString(CellUtil.cloneValue(cell)));
    }

    // 范围扫描
    Scan scan = new Scan();
    scan.withStartRow(Bytes.toBytes("device_0_1699990000000"));
    scan.withStopRow(Bytes.toBytes("device_0_1700000000000"));
    scan.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("temperature"));
    try (ResultScanner scanner = table.getScanner(scan)) {
        for (Result rs : scanner) {
            byte[] value = rs.getValue(Bytes.toBytes("cf"), Bytes.toBytes("temperature"));
            System.out.println(Bytes.toString(rs.getRow()) + " 温度=" + Bytes.toDouble(value));
        }
    }
}

Scan 的时候如果不设 StartRow 和 StopRow，默认就是全表扫描，在测试库上没感觉，在生产环境可以看下扫描的规模和耗时，几十亿行的全表扫描要是没有分布式计算框架配合，能在线上压垮 RegionServer。所以业务上凡是能带 Rowkey 范围尽量带上，这是 HBase 性能的第一原则：尽量把 Scan 操作缩小到一个数据分片，而不是全表跑。

5. 进阶话题：事务一致性、分布式锁与常见坑

5.1 HBase 的事务能力边界

很多人面试时被问“HBase 支持事务吗”容易答错。实际上，HBase 支持行级原子性，也就是说同一行的多列写入要么全部成功要么全部失败。但跨行、跨表事务它天生不支持。如果你要实现跨行跨表的事务一致性，需要依赖外部方案，比如 Tephra、Apache Phoenix 的某些组件，或者自己在业务层做补偿事务。

在订单库存这类场景中，单纯靠 HBase 不行，要考虑分布式事务方案。我自己的做法是：尽量把需要在同一个事务里更新的数据设计在同一行。例如订单表和订单明细表，如果需求允许，就把明细放在同一个 Rowkey 下的多列，这样利用行级原子性就实现了事务需求；如果确实无法合并，再考虑 TCC 或者基于消息队列的最终一致性方案。这个思路在多个项目里都帮了大忙，把原本复杂的分布式事务问题降级为简单的单行原子性问题。

5.2 实现分布式锁的正确姿势

HBase 自身的行级原子性可以设计出简单的分布式锁。思路是用一个特定的 Rowkey 作为锁记录，多个客户端通过 checkAndPut 操作（只有满足条件才写入）来竞争创建锁记录。put 里带上临时标识和过期时间，如果创建成功说明抢到锁，释放就删除该行。

这里的关键是 checkAndPut 这个操作具备原子性。比如：

java复制byte[] lockRow = Bytes.toBytes("lock_order_1001");
Put put = new Put(lockRow);
put.addColumn(Bytes.toBytes("lock"), Bytes.toBytes("holder"), Bytes.toBytes("instance_abc"));
// 检查 lock 列不存在时才写入，因为锁列还未存在，所以只有一个客户端可以成功
boolean executed = table.checkAndMutate(lockRow, Bytes.toBytes("lock"))
    .qualifier(Bytes.toBytes("holder"))
    .ifNotExists()
    .thenPut(put);

这段代码的语义就是“当 lock:holder 这一列不存在时，才写入当前实例的标识”。多个客户端同时执行，只有一个能成功。释放锁就是删除这一列。不过要注意锁的过期时间，客户端如果执行到一半挂了，没有主动释放锁，就会死锁。所以锁的值里要带上时间戳，其他客户端发现锁超时后可以强制删除。这个方案可以用在分布式定时任务的抢占上，避免多台机器同时执行同一任务——热词里有“分布式定时任务”的搜索，其实原理就是这个。

5.3 分布式 ID 的生成建议

分布式环境下生成全局唯一 ID 是个绕不开的问题。HBase 的 Rowkey 设计经常需要唯一 ID。由于随机 ID 会导致数据写入分散在不同 Region，从写入均衡来说是好事，但是从查询角度就不友好，因为你是按业务维度查，很难直接定位到 Rowkey。业界常用方案是 Snowflake 雪花算法，生成一个 64 位长整型 ID，其中包含时间戳、机器 ID、序列号。生成出来的 ID 基本趋势递增，但又不是纯递增前缀，结合其他业务字段可以做到比较均衡的分布。

我自己的实践是：给每条数据设计 Rowkey 的时候，把业务查询字段放在前面，后面拼接雪花 ID。比如订单场景，用 userId_reverse + orderId 作为 Rowkey，userId_reverse 是把用户 ID 倒序，可以让每个用户的订单尽量集中，减少扫描范围；再加上 orderId 是雪花 ID，全局唯一没问题。这个方案既能保证写入均衡，又能保证查询高效。类似“分布式 uuid”这类关键词，实际在 HBase 里的核心思路就是：Rowkey 不能太随机，也不能太顺序，要找到一个折中点。

5.4 热点问题的彻底解决方案

热点问题（Hotspotting）是 HBase 应用中最常见的问题，表现为某个 RegionServer 负载过高、写入超时。根本原因是 Rowkey 设计导致数据集中到某个 Region。解决思路有四种：

拿反转 Rowkey 举个例子：传感器设备上报的 Rowkey 原本是 timestamp_deviceId，每秒上报，导致同一秒所有数据都写到同一个 Region。改造成 deviceId_reverse(timestamp) 之后，同一台设备的写入分散到了不同 Region，热点就消失了。但代价是同一设备的顺序查询变得困难，扫描范围变大。所以没有完美的方案，业务决定一切。

5.5 面试高频题：从原理到答案

结合热词里的“HBase 面试题”，我把工作里真实问过和听到过的高频点整理一下：

• HBase 和 Hive 的区别在哪里？—— Hive 是离线的数据仓库工具，适合批量分析，依赖 MapReduce/Spark，延迟高；HBase 是在线存储，适合高并发随机读写，延迟低。两者经常搭配用：Hive 做批计算，HBase 做查询服务。
• Region 分裂过程是怎么样的？—— 当 Region 的 StoreFile 总大小超过阈值，触发分裂，先把 Region 下线，再分为两个子 Region，更新 meta 表，最后上线。这个过程会短暂影响读写，所以生产上要监控分裂频次。
• 为什么 HBase 的读比写慢？—— 正常，因为写只需要走内存，读可能要查 MemStore、多个 HFile、BlockCache，HFile 多了还要做 Compaction，路径长且涉及磁盘 IO。
• MemStore 为什么要做 Flush？—— 内存有限，同时把数据分批落盘后可以异步合并，形成有序 HFile，读的时候可以按序查找。Flush 之前有 WAL 保证不丢数据。

面试答得好不好，关键在你能不能口述出整个数据流的路径。我以前招人的时候，不会问背得下 API 的人，而是问“一条数据从客户端写进来，经过哪些组件，哪些写磁盘哪些写内存，为什么这么设计”。这个如果讲不清楚，开发水平基本就那样了。

5.6 分布式事务在 HBase 其他场景的近亲

热词里还有“分布式事务、订单与库存分布式事务”。HBase 在这个领域更多扮演的是最终一致性的持久化层。比如订单状态和库存扣减，你可以先把操作日志写入 HBase（行级原子性写操作保证日志不丢），然后通过异步任务去推进库存扣减，如果失败则依靠日志重试。这比直接用两阶段提交要简单得多，也能满足大部分业务的要求。两阶段提交在分布式环境里性能损耗大、协调者单点问题突出，而 HBase 的“日志先行 + 异步补偿”模式反而更实用，这也是我在设计分布式系统时倾向于选方案之一。

5.7 Region 热点时分析定位手段

遇到性能毛刺时，不要瞎猜，先看数据指标。RegionServer 的 Web UI 上可以看到每个 Region 的请求数、StoreFile 大小等；也可以执行 hbase top 命令（新版支持）来查看实时的请求热点；还要结合业务日志看慢查询。我自己定位一个线上热点问题时，过程是这样的：

1. 先用 hbase top 查看哪个 RegionServer 的 Region 请求数异常高。
2. 从 ZK 的 meta 信息里查到对应 Region 的 StartKey。
3. 解码 StartKey，发现是某个设备 ID 前缀开头的，而这个设备是个高频上报设备。

定位到具体设备后，解决方案就是给该设备的 Rowkey 加哈希前缀，例如 CRC32(deviceId) % 100 取前两位拼到 Rowkey 前，将写入分散到 100 个前缀段位。改完之后，热点消失，写入时间从超时降到几十毫秒。

6. 常见问题排查速查表

把我在实际运维和开发中遇到过的问题整理成一张表，你可以直接截图保存，遇到问题先照着查。

major_compact 是一个很常用的运维操作，可以把一个 Region 的多个 HFile 合并成一个大文件，读取性能提升明显，但注意这个操作非常消耗 IO，尽量在业务低峰期做。另外，频繁 major_compact 反过来会增加写放大，也不能天天跑。

7. 从实际业务中总结的几条心得

项目做多了，有些体会得靠踩坑才深刻。第一条，HBase 的 Rowkey 设计占了这个组件 70% 的成败，你花两天设计的 Rowkey 方案，可能比调十个参数都管用；反过来，Rowkey 拍脑袋定，后面改起来极其痛苦，因为表重建成本高、数据迁移麻烦。第二条，测试环境的数据量必须和线上差距不大，否则测试结果没有参考价值。我见过有人在几百万条数据的测试库上扫描秒回，然后上线几亿条数据后页面直接超时。第三条，HBase 命令和 API 背后的原理比命令本身重要得多，理解数据从哪来、到哪去，你才能真正定位问题。

最后分享一个小技巧：给 HBase 集群配上监控，RegionServer 的 JVM 内存、WAL 写入延迟、Region 分裂次数，这四类指标全都要实时看。Region 分裂如果短时间出现太多次，不仅会拖慢读写性能，还会在 HDFS 上产生大量小文件。提前配置好告警，比你半夜被叫起来排查要舒服得多。这套东西你搭好之后，后续不管是做数据平台还是 AI 训练前的数据预处理，都能省下很多心力。