不是所有数据库都天生适合“海量写入 + 海量查询”这种矛盾场景，尤其在电商这种用户行为数据每时每刻都在产生的业务里。HBase 之所以能成为很多大厂用户行为存储的标配方案，核心就是它把“写路径”简化到了极致，同时通过 Rowkey 设计和预分区把“读路径”控制在了可预期的范围内。这篇内容不聊虚的，直接拆解 HBase 在电商行为数据场景下的设计方案、Java 开发细节和落地时的真实坑点。

1. 电商用户行为数据的存储困境与 HBase 的定位

1.1 行为数据到底有多“大”，为什么传统关系型数据库扛不住

先看一组电商场景下的典型数据特征。用户行为包括浏览、点击、搜索、加购、下单、收藏、支付成功等，一个中等规模的电商平台（日活百万级别），每天产生的行为日志量大约在 5 亿到 20 亿条之间。单条记录不大，几十到几百字节，但问题是总量大、增速猛、峰值写入集中。

MySQL 这类关系型数据库在这个场景下有几道过不去的坎：

• 写入瓶颈：单机写入 TPS 在几千到一万左右就到头了，行为日志这种动不动每秒几万到几十万条写入的流量，直接打爆主库。
• 存储成本：行为数据要保留很长时间做用户画像、推荐模型训练、运营分析，动辄几十 TB 甚至 PB 级别，MySQL 的存储成本和运维成本都扛不住。
• 扩展性差：分库分表能缓解一部分问题，但行为数据的查询维度（按用户、按时间范围）和关系型建模天然不匹配，分片键设计非常痛苦。
• Schema 固定：行为数据的事件类型、字段会随着业务迭代频繁新增，MySQL 改表结构成本高、风险大。

这时候 HBase 的价值就很清晰了。它是一个稀疏的、分布式的、面向列族的 NoSQL 数据库，建立在 HDFS 之上，用 Java 写的，天生就是为海量结构化或半结构化数据设计的。单表可以存百亿行、PB 级数据，写入性能在合理设计下能轻松支撑每秒几十万次 Put，而且扩容就是加机器的事，不需要像 MySQL 那样做数据重分布。

1.2 HBase 为什么适合“用户行为”这个具体场景

用户行为数据有一个鲜明特点：一次写入，多次读取，极少更新。用户的浏览记录一旦产生就是事实，后续不会修改（顶多标记无效），这和 HBase 的存储模型非常契合。HBase 不支持完整的事务和复杂 Join，但行为分析根本不需要这些，它只需要一个高性能的 Key-Value 存储，外加一个能按 Rowkey 范围扫描的模型。

另外，HBase 的列族设计天然支持“按需读取”。一条行为日志可能有几十个字段，但分析时往往只需要其中几个。HBase 按列族、按列存储数据，查询时只需指定需要的 Column Family 甚至 Qualifier，读出来的数据量远小于一行全字段，这在海量数据下能显著减少 IO。

我常用一个类比来解释 HBase 和关系库的差异：MySQL 像一本装订好的 Excel 账本，每行格式一致，查询靠索引；HBase 像一个无限大的货架仓库，每个货架（Region）上有无数个编号唯一的包裹（Rowkey），包裹里按格子（列族）分类存放物品。你要找某个用户的全部行为，直接奔着那个编号（Rowkey 前缀）去，取出来就是。没有 Join 的必要，因为所有数据都已经按“用户”这个维度摆好了。

2. Rowkey 设计：决定表性能的生死线

2.1 Rowkey 在 HBase 中的核心地位

HBase 的所有查询都依赖 Rowkey，它决定了数据落在哪个 Region、以什么顺序存储。设计 Rowkey 是 HBase 应用开发里最重要的一环，没有之一。一个差的 Rowkey 能让集群写入热点化、查询全表扫描；一个好的 Rowkey 则让读写均匀分布、查询精确命中。

Rowkey 设计有几个基本原则：

• 长度控制：Rowkey 越短越好，尽量控制在 8~16 字节。每条 Rowkey 都会随数据冗余存储，100 亿行数据，Rowkey 多 10 字节就是 100GB 的额外存储开销。
• 散列性：取模、哈希或用可逆算法处理前缀，避免顺序递增带来的写入热点。
• 查询友好：把查询场景中恒定不变的维度放在 Rowkey 前缀，让 Scan 能按前缀快速定位。

2.2 三大经典 Rowkey 模式：倒序、加盐、哈希

倒序模式处理的是“最新数据最常查”的场景。电商平台看用户行为，百分之九十的情况是查最近几天的。如果 Rowkey 是userId + timestamp，那同一个用户的数据会顺序写入，最新数据排在 Region 尾部，老数据在前面。查询最新行为时要 Scan 大半个 Region，效率很低。把时间戳倒过来，变成userId + (Long.MAX_VALUE - timestamp)，最新的行为就排在最前面，Scan limit N 就能直接拿到最新 N 条，效率极高。

加盐模式处理的是“写入热点”问题。如果用userId直接做 Rowkey 前缀，头部活跃用户（大 V、爆款商品）的数据会集中砸向同一个 Region，形成热点。做法是在前缀加一个散列值，比如MD5(userId).subString(0,4) + userId + timestamp。数据按哈希值均匀分布，写入压力被打散，但查询时也能直接算出同一个用户的前缀哈希值，Scan 不受影响。这是一个用一点额外字节换取系统稳定性的典型取舍。

哈希模式适合那些前缀本身没有顺序特性的业务键。比如商品维度的行为统计表，用商品 ID 做前缀时，如果商品 ID 是自增整数，写入会集中在尾部 Region。用reverse(商品ID)或前缀加固定长度哈希，把数据打散到所有 Region。代价是查询时也要先算一遍哈希。

2.3 电商用户行为表的 Rowkey 落地设计

结合电商实际情况，我会推荐“用户维度 + 行为时间倒序”的主表方案：

Rowkey = MD5(userId).substring(0,4) + userId + (Long.MAX_VALUE - eventTime)

列族设计成两个：

• cf_event：存储事件本身属性，Qualifier 用eventType、pageUrl、productId、categoryId、duration、device等。每个 Qualifier 都是一个单元格，独立存储，查询时按需拉取。
• cf_meta：存储辅助信息，比如eventId（全局唯一 ID）、traceId（链路追踪）、ft（前端埋点校验字段）。

查询“某用户最近 100 条行为”的语义变成：Scan startRow = MD5前缀 + userId，stopRow = MD5前缀 + userId + 0xFF，limit = 100，一次 Scan 精准命中。统计“某用户今天浏览了多少次商品”时，直接用 Get 拿到该用户某个时间段的全部行为，再做计数。这套 Rowkey 我在实际项目中用过，200 亿行的表，单次前缀 Scan 响应在 20ms 以内，稳定得很。

常见误区：直接用user_md5 + userId做前缀，这等效于在开头又加了一次随机散列，查询时还要额外存一份映射关系。正确做法是用固定的 4 字节哈希前缀保证分布，再用原始 userId 保证可拼接、可反解。

3. 存储方案设计：从数据模型到 Compaction 调优

3.1 列族规划与版本控制

HBase 列族的数量建议控制在 1~3 个，不要学习关系库建十几个列族的习惯。每个列族会对应到 HDFS 上的一个目录，列族越多，Region 打开的文件数越多，Compaction 和 Flush 的联动也越复杂。行为数据这种场景，一个列族就够用，最多加一个 meta 列族做辅助字段。

版本数（VERSIONS）默认保留 3 个版本，这是为支持“同一 Rowkey 多次更新保留历史值”设计的。但行为数据是 append-only 的，同一 Rowkey 不会重复写入，所以把版本数设置为 1 是合理的，能省掉不少读路径上的版本比较开销。

TTL 的设置更关键。用户行为数据一般有明确的生命周期：实时分析要最近 1 小时的，离线画像要最近 90 天的，运营分析可能要 180 天的。HBase 原生支持按列族设置 TTL，过期数据会被自动删除，不需要业务方写定时任务一遍遍 Scan 删除老数据。建议把主行为表的 TTL 设置为 180 天，明细超过 180 天直接交给数据仓库归档。

3.2 预分区：不预分区就等于慢性自杀

HBase 建表时默认只有一个 Region，所有写入先涌向这个 Region，直到它超过阈值触发分裂（Split）。分裂过程会伴随 Region 下线、重新分配，在线业务在这段时间可能出现写入毛刺甚至超时。行为数据这种高写入场景，必须在大流量来临前通过预分区把 Region 数量铺开。

预分区数量的估算公式并不复杂。假设单 Region 的合理数据量是 10GB（默认 10GB 触发分裂，建议控制在 5~6GB），预计 30 天产生 1.5TB 数据，那就需要1500GB / 5GB ≈ 300个 Region。再开一个冗余系数，比如 360~400 个 Region。每个 Region 一个 SplitKey，Rowkey 前缀哈希值是 16 进制 0 到 f，共有 65536 种组合，按65536 / Region数划分区间就行。

建表时用 HBase Shell 就能完成：

create 'user_event_behavior', {NAME => 'cf_event', VERSIONS => 1, TTL => 15552000, BLOOMFILTER => 'ROW'}, {NAME => 'cf_meta', VERSIONS => 1, TTL => 15552000}, {SPLITS => ['0000', '0016', '0032', ...]}

实际项目里，我会写一个脚本按 Region 数均匀生成 SplitKey 列表，配合自动化平台在建表时一次传入。注意SPLITS =>这里是数组，传入的是每个分区的起始 Rowkey，Region 数量等于 SplitKey 数量加一，别算错。

3.3 BloomFilter 与 BlockCache 的关键调优

BloomFilter 是 HBase 读路径上容易被忽视的加速器。它解决的是“判断一个数据是否存在”的问题，存在误判但不会漏判。行为数据的查询模式是按用户 ID 精确 Get 或短前缀 Scan，把 BloomFilter 类型设为 ROW，会在读取时先过滤掉大量根本不包含目标数据的 HFile，显著减少磁盘随机读。

对行为数据场景，BlockCache 大小调大一点收益明显。读行为多集中在用户最近行为上，缓存命中率上去了，Scan 的 P99 延迟能降一半。RegionServer 堆内存的 40%~50% 分配给 BlockCache 是常见配置，hfile.block.cache.size=0.45左右。如果同时有较重的大 Scan 任务，可以开 BucketCache 结合堆外内存做分层缓存。

# RegionServer 关键配置示例 hfile.block.cache.size=0.45 hbase.regionserver.global.memstore.size=0.35 hbase.hregion.memstore.flush.size=536870912 hbase.hregion.memstore.block.multiplier=4

MemStore 内存占比要保证写缓冲足够，同时避免 Flush 频繁触发。行为数据写入量大，如果 MemStore 太小，会频繁触发小 Flush，产生大量小 HFile，后续 Compaction 压力剧增。flush.size设成 512MB，配合block.multiplier=4，能让 MemStore 在 2GB 时才触发阻塞写入，给 Flush 留出缓冲时间。

4. Java 开发实录：从建表到批量写入、前缀级联 Scan

4.1 基础客户端环境配置与连接池

HBase 的 Java 客户端开发，最核心的类是org.apache.hadoop.hbase.client.Connection。这个对象是重资源，内部维护了 RPC 连接池、ZK 会话和元数据缓存，整个应用应该只创建一个共享实例，不要每次请求都创建。实际生产里见过不少同学在函数里 new Connection，直接把 RegionServer 连接数打到上限，RegionServer 报 Blocked 异常，业务全部超时。

用 HBase 2.x 的 API 创建连接：

import org.apache.hadoop.hbase.HBaseConfiguration; import org.apache.hadoop.hbase.TableName; import org.apache.hadoop.hbase.client.*; import org.apache.hadoop.conf.Configuration; import java.io.IOException; public class HBaseConnectionManager { private static volatile Connection connection; public static Connection getConnection() throws IOException { if (connection == null || connection.isClosed()) { synchronized (HBaseConnectionManager.class) { if (connection == null || connection.isClosed()) { Configuration conf = HBaseConfiguration.create(); conf.set("hbase.zookeeper.quorum", "zk1:2181,zk2:2181,zk3:2181"); conf.set("hbase.zookeeper.property.clientPort", "2181"); // 开启 RPC 压缩，行为数据多为文本 JSON，压缩收益明显 conf.set("hbase.client.rpc.compress", "true"); connection = ConnectionFactory.createConnection(conf); } } } return connection; } }

HBase 客户端的核心端口是 2181（ZooKeeper）、16020（RegionServer RPC）、16010（RegionServer Web UI）、16030（HMaster Web UI）。如果是 HBase 1.x，RegionServer 的 RPC 端口可能是 60020。排查端口问题时，先telnet一下 2181 确认 ZK 正常，再看 16020 是否通，这两个端口是客户端连接有没有问题的分水岭。

4.2 建表 API 与预分区写入

用 Java 建表和 HBase Shell 效果一致，API 更灵活，适合集成到自动化平台里。下面是预分区建表的代码：

public static void createTable(Connection conn, String tableName, int regionCount) throws IOException { TableName tn = TableName.valueOf(tableName); try (Admin admin = conn.getAdmin()) { if (admin.tableExists(tn)) { return; } TableDescriptorBuilder builder = TableDescriptorBuilder.newBuilder(tn); // 行为事件列族 ColumnFamilyDescriptor eventFamily = ColumnFamilyDescriptorBuilder .newBuilder(Bytes.toBytes("cf_event")) .setMaxVersions(1) .setTimeToLive(15552000) // 180 天 .setBloomFilterType(BloomType.ROW) .setCompressionType(Compression.Algorithm.SNAPPY) .build(); // 元信息列族 ColumnFamilyDescriptor metaFamily = ColumnFamilyDescriptorBuilder .newBuilder(Bytes.toBytes("cf_meta")) .setMaxVersions(1) .setTimeToLive(15552000) .build(); builder.setColumnFamily(eventFamily); builder.setColumnFamily(metaFamily); // 预分区，按 65536 均匀切分 byte[][] splitKeys = generateSplitKeys(regionCount); admin.createTable(builder.build(), splitKeys); } } private static byte[][] generateSplitKeys(int regionCount) { int interval = 65536 / regionCount; byte[][] splits = new byte[regionCount - 1][]; for (int i = 0; i < regionCount - 1; i++) { int value = interval * (i + 1); splits[i] = Bytes.toBytes(String.format("%04d", value)); } return splits; }

注意setCompressionType(Compression.Algorithm.SNAPPY)。行为数据以文本和 JSON 为主，Snappy 压缩率通常在 30%~50%，而且压缩提升的写入速度往往抵消掉 CPU 开销。生产环境不开压缩，等于把磁盘 IO 白白浪费在冗余数据上。

4.3 批量写入：BufferedMutator 的正确姿势

写入行为数据最高效的方式不是 Table.put 单线程循环，而是使用BufferedMutator做异步批量提交。

public class EventWriter { private final BufferedMutator mutator; public EventWriter(Connection conn) throws IOException { this.mutator = conn.getBufferedMutator(TableName.valueOf("user_event_behavior")); // 单次 RPC 打包 10MB 数据 this.mutator.getBufferedMutatorParams() .writeBufferSize(10 * 1024 * 1024); } public void write(Event event) throws IOException { String rowkey = buildRowkey(event); Put put = new Put(Bytes.toBytes(rowkey)); // 行为列族写入业务字段 put.addColumn(Bytes.toBytes("cf_event"), Bytes.toBytes("eventType"), Bytes.toBytes(event.getEventType())); put.addColumn(Bytes.toBytes("cf_event"), Bytes.toBytes("productId"), Bytes.toBytes(event.getProductId())); put.addColumn(Bytes.toBytes("cf_event"), Bytes.toBytes("duration"), Bytes.toBytes(event.getDuration())); // meta 列族写入辅助信息 put.addColumn(Bytes.toBytes("cf_meta"), Bytes.toBytes("eventId"), Bytes.toBytes(event.getEventId())); mutator.mutate(put); } private String buildRowkey(Event event) { String md5Prefix = MD5Util.getMD5Prefix(event.getUserId()); long reverseTime = Long.MAX_VALUE - event.getEventTime(); return md5Prefix + event.getUserId() + reverseTime; } }

写入路径有个细节：尽量把 Mutation 数量攒到writeBufferSize再 flush。BufferedMutator 内部会按 buffer 大小自动批量发送 RPC，每批次几百到几千条，网络效率比逐条 Put 高一个数量级。如果直接调mutate后不关心 flush，应用退出前要记得mutator.flush()，否则内存里积压的数据会丢。

生产环境用 Kafka 消费行为日志，到 HBase 写入这一步，消费线程数控制在 RegionServer 处理能力的 60%~70%，给 Flush/Compaction 留出余量。曾踩过大坑：消费线程开太多，写入洪峰直逼 RegionServer 的 MemStore 上限，数据 Flush 到 HDFS 的速度跟不上，Block 了写入，消费端堆积，最后是连环雪崩。

4.4 支持“最近行为列表”的前缀级联 Scan

读路径最核心的操作是“查某用户最近 N 条行为”。这里要写对 startRow 和 stopRow，查错了就是全表扫描。

public List<Event> getRecentEvents(String userId, int limit) throws IOException { String prefix = MD5Util.getMD5Prefix(userId) + userId; byte[] startRow = Bytes.toBytes(prefix); // 前缀后加一个永远不会出现的高值字节，形成范围上界 byte[] stopRow = Bytes.toBytes(prefix + "\uFFFF"); Scan scan = new Scan(); scan.withStartRow(startRow); scan.withStopRow(stopRow); scan.setCaching(100); // 每次 RPC 拉取 100 条 scan.setLimit(limit); // 限制返回条数 scan.addFamily(Bytes.toBytes("cf_event")); Table table = conn.getTable(TableName.valueOf("user_event_behavior")); try (ResultScanner scanner = table.getScanner(scan)) { List<Event> events = new ArrayList<>(); for (Result result : scanner) { events.add(parseResult(result)); if (events.size() >= limit) break; } return events; } }

注意几个点：

• withStartRow和withStopRow在 HBase 2.x 中是含头不含尾的。stopRow 设成前缀 + "\uFFFF"，能覆盖该用户下所有数据。
• setLimit是 HBase 2.0 后新增的接口，语义是“每张表最多返回多少行”，能有效减少 ResultScanner 空跑。
• ResultScanner 必须关闭，最好放进 try-with-resources。忘了关闭会让 RegionServer 上的 Scan 资源一直占着，久了把堆内存拖垮。

setCaching(100)控制一次 RPC 从 RegionServer 拉几行到客户端。行为列表场景数据量不大，100 是合理值。如果是全表大 Scan，caching 反而要调小，比如 500~1000 行，太大的缓存会导致 RegionServer 一次给你返回海量数据，客户端 GC 压力飙升。

4.5 复杂分析场景的补充方案：协处理器与二级索引

行为数据不止按用户查，运营分析还会按“事件类型+时间段”“商品维度”查。HBase 原生不支持二级索引，面对这类查询只能全表 Scan，效率没法接受。

两个补充方案：

• Phoenix：在 HBase 之上封装 SQL 层，自动把 SQL 查询转换成 HBase Scan，支持创建二级索引（Covered Index）。团队里有 SQL 背景同学时，Phoenix 可以显著降低开发成本。但要注意 Phoenix 的索引表本身也依赖 HBase，会有额外写入开销。
• 自建索引表：写行为数据时同时写一张“事件类型 + 日期”为 Rowkey 的统计表，存储该维度下的用户 ID 集合。查询时先查索引表拿到 userId 列表，再回到主表按前缀 Scan。这和 MySQL 建联合索引的思路一致，但完全自主可控，不引入额外组件，生产实践最稳。

5. 运维排坑实录：写入热点、Region 分裂与 Scan 超时

5.1 写入热点：Rowkey 前缀设计不当的真实案例

一次线上事故排查记录。某个活动页在晚高峰时写入 TPS 达到了 30 万，但 HBase 集群一个 Region 的写入延迟飙升到 5 秒，其他 Region 空闲。现象是典型的写入热点。

定位方法有三个：

1. HBase Master Web UI 里看 Region 的requests计数，如果某个 Region 的写请求数远超其他 Region 平均值，基本实锤热点。
2. RegionServer 日志里搜Blocking、MemstoreFlushSize相关字样，热点 Region 的 MemStore 会频繁触发 blocking flush。
3. 客户端埋点看单 Region 分区耗时，分布式 Trace 里能直接看到那个 Region 的长尾。

排查结果：开发同学把 Rowkey 写成了userId + timestamp，而当时平台对头部用户做了流量扶持，头部用户的请求量占到总流量的 40%，全部打在同一个 Region 上。修复方案就是前面说的加盐前缀：MD5(userId).substring(0,4)。上线后热点消失，Region 请求分布均匀。

避坑提醒：加盐前缀位数不宜超过 4 字节。前缀太长会降低同一用户的 Scan 效率，因为每次查询都要拼接并扫描多余字节。4 字节提供 65536 种分布，对绝大多数场景足够了。

5.2 Region 分裂风暴与预分区之后的问题

Region 分裂是 HBase 运维里最琐碎也最影响稳定性的事。分裂时 Region 会短暂下线，RPC 重试会放大延迟。我遇到过一次比较极端的场景，数据模型从全量快照改为增量追加时没有重新评估预分区，导致 3 天内 Region 分裂了 1000 多次，分裂日志刷屏，RegionServer 频繁因文件句柄超限重启。

应对策略：

• 新表上量前严格按数据增长量计算预分区。
• 线上表如果实在没预分区，用hbase shell的split命令手动触发分裂，尽量选择凌晨低峰期。
• 分裂导致 Region 数过多时，合并小 Region，用merge_region命令。Region 数量不是越多越好，Region 管理本身有内存成本，单 RegionServer 维护 1000 个 Region 会让堆内存压力很大。

5.3 Scan 慢查询：缓存命中率与 RPC 压缩的效果

行为数据读取慢，大多数情况不是 HBase 慢，而是 Scan 的设计让 RegionServer 做了大范围扫描。排查思路和优化路径我整理成表：

这里重点说一下 RPC 压缩。行为数据在 HBase 里以文本为主，压缩率非常高。开启 RPC 压缩后，客户端到 RegionServer 的网络传输量能下降 50% 以上。代价是两端各多一次 CPU 压缩/解压。如果你的集群 CPU 有余量，强烈建议开启；如果 CPU 已经跑满 80% 以上，先加机器或关压缩。

5.4 一把梭的 BulkLoad：大批量初始化的推荐路径

从数据仓库或离线日志往 HBase 导历史行为数据，如果走 Put API 硬写，几千万行要跑几个小时，还挤占在线读写资源。正确做法是先写好 HFile，再直接 BulkLoad 到 HBase，跳过写 WAL 和 MemStore 的过程，速度能提升数倍。

// 用 MapReduce 或 Spark 生成 HFile Configuration conf = HBaseConfiguration.create(); Job job = Job.getInstance(conf, "GenerateHFile"); job.setMapOutputKeyClass(ImmutableBytesWritable.class); job.setMapOutputValueClass(Put.class); HFileOutputFormat2.configureIncrementalLoad(job, conn.getTable(TableName.valueOf("user_event_behavior")), conn.getRegionLocator(TableName.valueOf("user_event_behavior")));

生成 HFile 后，用LoadIncrementalHFiles工具批量导入：

hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles \ /tmp/hfile_output user_event_behavior

BulkLoad 有两点要提前准备好：一是 HFile 的 Key 顺序必须和表的分区边界一致（HFileOutputFormat2 会自动按照 SplitKey 生成对应 HFile）；二是导入前先做一次 Major Compaction，不然表里会有大量延迟合并的小 HFile，读性能短时间会很差。

实测数据，单机 BulkLoad 一小时能导 2000 万行，是 Put 写入的 4 到 6 倍速，非常适合做历史数据迁移、离线回填。

5.5 面试会被问的重点：HBase 数据模型与读写路径

顺带整理几个行为数据场景里常被追问的 HBase 核心问题，实际项目中理解这些能少走很多弯路：

• HBase 和 HDFS 的关系：HBase 是构建在 HDFS 上的一层分布式 KV 数据库。HDFS 负责最终存储，HBase 在它上面实现了随机读写能力，本质是靠内存缓冲（MemStore）+ 顺序写（HLog）+ 定期落盘（HFile）这套机制。
• Region 和 RegionServer 怎么对应：表被水平切分成多个 Region，Region 分布在不同 RegionServer 上。Region 是数据分布和负载均衡的最小单位，RegionServer 决定了一个表能有多少并发读写在物理上同时发生。
• 写入流程五步：Client 找 ZK 获取元数据 → 定位目标 RegionServer → 写 WAL → 写 MemStore → 异步 Flush 成 HFile。这五步里 WAL 保证不丢数据，MemStore 保证高吞吐。
• 读取为什么要查 BloomFilter：HFile 默认是顺序写的，精确点查时不知道目标数据在哪个文件、哪个块。BloomFilter 是每个 HFile 自带的小索引，先过滤掉无关文件，再用 BlockIndex 定位数据块，每一层都在减少磁盘 IO。

说实话，好多人在 HBase 上栽跟头，不是 API 不会写，而是对“数据怎么分布在 Region 里、查询怎么命中 Region”心里没底。把上面这几个问题真正想透，写起来基本不会跑偏太多。

6. 存储方案的整体效果与后续演进的思考空间

回到开头那个命题：电商海量用户行为数据，HBase 究竟解决了什么问题？我经历过一次从 MySQL 分库分表迁移到 HBase 的过程，效果非常直观。同样 50 亿行的用户行为数据，MySQL 那套方案晚高峰写入 P99 已经到 3 秒，磁盘接近写满，扩容要动一堆分片。迁移到 HBase 后，写入 P99 稳定在 10ms 内，存储空间因为 Snappy 压缩直接缩了 60%，扩存储就是加节点，一个下午的事。

但这个方案不是银弹。HBase 在行为数据上的劣势也很明确：不支持事务性更新，不能做复杂聚合。如果业务场景既要“存行为明细”又要“行为发生后实时修改状态”，HBase 就不如 MySQL 或 Redis 好使。所以我的习惯是行为数据全部进 HBase，业务状态数据留 MySQL，两边靠 Kafka 异步同步，各取所长。

个人踩过几次坑之后最深的体会是：HBase 项目成功与否，七分靠设计，两分靠运维，一分靠代码。Rowkey 和预分区设计在开发阶段多花一天想清楚，能少写一个月的问题排查文档。行为数据这个场景本身足够简单纯粹，把写入路径打散、读路径固定、生命周期管好，这套方案能扛住绝大多数电商平台体量。后续如果业务上来了，还可以把 HBase 和 Elasticsearch、ClickHouse 做分层，HBase 留最热的明细，ES 做检索，CK 做分析，但那是另一个话题了。