HBase表设计避坑指南：从Rowkey到预分区全解析

如果有人问你做大数据最常踩的坑是什么，我大概率会先说一句：表设计没想清楚就急着建表，后面全在补窟窿。尤其是HBase，它和MySQL、PostgreSQL完全是两个物种，你把关系型数据库那套建模思路搬过来，十有八九会在Rowkey、热点、GC延迟上栽跟头。这篇博文我就把HBase表设计这件事掰开揉碎讲清楚，从底层逻辑到Rowkey设计，从列族规划到预分区落地，再到和GC延迟、读写性能的关系，全是我在真实项目里摸爬滚打出来的经验。不管你是刚接触HBase的新手，还是已经上线过几个集群的开发，这篇内容都值得你花十分钟从头看一遍。

1. 先从数据模型反推设计：忘了SQL，记住“键值对”

1.1 一张HBase表到底长什么样

HBase表结构大多数人第一眼看会觉得和关系型数据库很像：有表、有行、有列。但本质上，它是一张“稀疏的多维有序Map”。理解这件事，是做好表设计的起点。

我们先拆一个例子。假设要存用户行为日志，写入一条数据后，在HBase里的物理形态大概是这样的：

Rowkey: user_10001_20240101120000

注意，同一行的两个列族数据在物理上可能存放在完全不同的HFile里，甚至不在同一个RegionServer上。所谓“行”只是逻辑上的概念，物理上，每个列族是独立存储的。这就是为什么HBase官方手册反复强调“一个表最多不要超过两到三个列族”，因为一旦列族数量太多，一次随机读可能要跨多个文件目录去访问，Region的MemStore也要在内存里维护多份引用，读写放大非常严重。

再说列。你在创建表的时候不需要预先定义列名，写数据的时候，随便指定一个列名就能写进去。每一列的值在底层是一条KeyValue，完整格式是：

Rowkey + ColumnFamily + Qualifier + Timestamp + Type -> Value

这意味着就算同一个列名下有100个历史版本，HBase也会把它们全部存下来。你读数据时如果不指定时间戳，默认拿到的就是最新版本。这个设计逻辑回答了“列要不要提前设计”的问题：一般只设计列族，列可以随着业务动态扩展，但扩展得太多会对扫描和缓存造成额外压力。

1.2 为什么不能照搬关系型数据库的建模方式

我在不少团队见过这种场景：业务方交付一份MySQL表结构，里面有几张关联表，开发同学照着字段就把HBase表建了，还设置了二级索引，然后开始用Filter做各种联表扫描，最后性能惨不忍睹。

问题的根源在于HBase没有Join，也没有二级索引原生支持（Co-Processor算半个）。它的读路径强依赖Rowkey的定位能力，如果一次查询不能通过Rowkey快速定位到少数几行，而去全表扫描，那么底层就是RegionServer在逐个读取HFile并做合并扫描，数据量一上来，这个开销几乎是灾难级的。

所以HBase表设计的核心不是“有什么字段”，而是“怎么查”。常见的落地做法是“宽表+多版本”，也就是把一次业务查询所需的数据尽可能放在一行里，行内靠不同列承载不同属性。这样，读一条记录，只需要定位一个Rowkey。对于需要多种查询视角的场景，比如既要按用户查，又要按商品查，那就得准备两张表，或者利用列值反查，再通过异步任务做拼接。这是以空间换时间，也是HBase分布式架构下的必然选择。

对新人，我建议画一张访问模式表：列出所有高频查询，把每条查询的过滤条件、结果字段、排序字段写清楚，然后再开始设计表结构。没有这张表，后面所有设计都是在赌博。

1.3 先定访问模式，再谈表结构

确定访问模式时，有几个问题要反复问自己：

• 查询是点查（get）还是范围查（scan）？点查走的是索引定位，快；范围查如果用不到Rowkey前缀，那就是灾难。
• 数据是按时间递增写入，还是随机写入？这个是后续Rowkey设计的热点风险来源。
• 需不需要按多个维度过滤？如果需要，很可能要引入二级索引方案或者用列值+Filter，但Filter性能通常不理想。
• 更新频率高不高？HBase没有真正意义上的Update，每次写入都是一个新版本，频繁更新会带来大量新KeyValue，磁盘占用和查询扫描都会涨。
• 过期数据是否需要自动清理？TTL如果设置不合理，过期的KeyValue会一直压在HFile里，直到触发Major Compaction，这个会影响读写性能。

设计之前先回答问题，至少能避开一半的坑。

2. Rowkey设计：HBase表设计的灵魂

2.1 Rowkey的三大基础规则：唯一、散列、不要过长

Rowkey在HBase里就是物理数据分布的核心。Region按Rowkey的字典序切分，所以相同前缀Rowkey的数据会连续存储在同一个Region里。这意味着Rowkey的设计直接决定数据的写入分布是否均匀，以及查询是否能命中尽量少的Region。

Rowkey设计有三大基础规则，大多数最佳实践都可以归结到这三点上：

第一，唯一性。同一张表里Rowkey重复就是同一条记录，后面的写入会追加成新版本，不会覆盖，除非你在调用时自己指定了相同时间戳。业务上如果希望相同逻辑ID的数据不断更新覆盖，就要保证Rowkey不变，配合读取时取最大版本。

第二，散列性。这是防写热点的关键。如果业务ID本身是一个自增序列，直接拿它当Rowkey前缀的话，新数据必然长时间打在同一个Region上，形成所谓的“写热点”，其它Region空闲，整个集群的写入吞吐被一个RegionServer拖垮。解决的思路是加盐、加哈希或者反转，目的是让连续的Rowkey落在不同的Region上。

第三，长度控制。Rowkey会作为KeyValue的一部分存放在所有相关的索引和缓存里，过长会直接放大内存和磁盘负载。HBase官方说Rowkey上限是64KB，但实践里我们通常控制在几十字节以内。一个常见反例是直接把整条URL当Rowkey，结果HFile体积翻倍，RegionServer的BlockCache压力也跟着涨。如果内容确实长，先做一次MD5或SHA-1再做Base64截断，这个很有效。

2.2 四个常用Rowkey模式：加盐、哈希、反转、组合

这几种模式我全部在线上项目里用过，这里说说它们的适用场景和坑。

**加盐（Salting）**是最大白话的办法：在Rowkey前面加一个随机前缀。比如用户ID是10001，前缀取0-9的随机一位，最后Rowkey是3_10001、7_10001。这样同一用户的不同请求可能分散到不同Region，写入均衡了，但对这个用户的点查就尴尬了：你得扫描0-9全部前缀再合并结果，扫描次数放大了10倍。所以加盐一般用在“对读取的实时性要求不高，但写入量极大且不需要按原始前缀连续扫描”的场景。

**哈希（Hash）**是我最推荐的一种方案，做法是把Rowkey的唯一部分做哈希，然后把哈希值拼接在原Rowkey前面。比如md5(user_10001).substring(0,4) + user_10001。哈希值随机且分散均匀，问题在于你失去了按原始时间或者用户ID连续扫描的能力。因此它适合点查偏多的场景。我在做用户画像表时用的就是这种模式：先定向查一个用户的全量画像，哈希前缀完全不影响，只要知道用户ID就能重算前缀。

**反转（Reversed Key）**专门应对自增、时间戳这类尾部变化的数据。做法是把业务前缀倒过来。一个很经典的例子是订单号，直接自增加前缀会全打到最后一个Region上。你把订单号反转，比如10001变成10001倒过来读为10001，那末位数字反而成了Rowkey的前缀，这样不同末尾的数字会分配到不同Region，写热点就被打散了。缺点也很明显，如果你需要按原始订单号范围扫描，几乎没法做到，因为反转后的字典序和原始序完全没关系了。

组合Key则是把业务字段拼成一个长Key，常见形式是userId + timestamp或timestamp + userId。这种设计的关键是排序字段放前面还是放后面，取决于查询条件。要查某个用户最近N天记录，可以设计为userId_reverse(timestamp)，Reverse的部分是为了避免同一用户大批量数据顺序写入时卡在一个Region。组合Key的坑是容易忽略分隔符。比如user1_20240101和user10_20240102，如果你没加固定宽度或分隔符，user1前缀会被user10影响到，造成数据错排。所以组合字段最好定长，或者加一致的分隔符，并且要对边界情况多做测试。

2.3 一个实战Rowkey设计复盘

我曾负责过一个用户行为日志的存储方案，原始需求是：

• 能查某个用户在某个时间范围内的行为序列；
• 能按时间倒序拉取；
• 数据来自App端埋点，量大。

第一版设计的Rowkey是userId + action_time。上线后写入经常告警，去看Web界面，发现最后一个Region的写请求量是其他Region的几十倍。原因很简单：用户行为日志天然按时间递增生成，同一userId下面时间戳只管往后走，Rowkey字典序几乎总是落在当前最后一个Region里。这就是典型的写热点。

后来改成md5(userId).substring(0,2) + userId + Long.MAX_VALUE - actionTime。

解释一下：

• 前两位是userId的哈希前缀，保证同一用户的所有行为落在0-99这100个可能前缀中的一个，不同用户随机散到不同Region，写入就均衡了。
• 中间是userId，保证点查一个用户时，可以简单拼接Rowkey前缀去Get。
• 时间戳用Long.MAX_VALUE - timestamp倒排，这样scan时从前缀开始读，先拿到的是最新数据。Scan时只需要指定startRow为前缀加倒排起点，stopRow为前缀加终点。
• 用定长的十进制时间戳，绝对不掺可变长度字段。

优化后，写入热点消失，用户行为列表查询RT稳定在30ms以内。这个案例说明一个问题：Rowkey设计一定不只有一种答案，贴着自己的访问模式反复推演才是正路。

3. 列族、列与单元格：容易被忽略的性能杀手

3.1 列族数量：能少就少，最好一个

HBase官方文档明确建议：列族最多不超过两个或三个，而且大多数场景下一个就够了。我见过有人按业务模块拆了五个列族，理由是不同数据分开管理。实际跑起来之后，Region的MemStore写路径上要同时维护多个列族的MemStore，flush和compaction也会更频繁。更麻烦的是，如果某个列族数据量巨大，另一些列族数据量很小，底层HFile数量会失衡，导致读请求花大量时间做文件集合合并。

如果你最初的目的是“不同数据设置不同的TTL”，其实也有办法：要么分表，要么在一定范围内通过多个列但是相同的TTL模拟。HBase本身不支持同一列族里的不同列单独设置TTL，所以当业务差异实在太大，不如直接拆表，而不是在一个表里堆列族。设计表时，你可以反推一个规则：如果两个列族里的数据不会在同一个业务请求中被同时读取，那就分表；会被同时读取，那就尽量放同一个列族。

3.2 列名的长度陷阱

很多人只关心Rowkey长度，忽略了Qualifier列名也是每个KeyValue里必带的内容。假设你有100亿行，每行有10个列，每列的Qualifier平均长20字节，那就意味着仅仅列名就要占用200GB的存储空间（这里还未算HFile重复存储列名的开销）。虽然HBase底层有压缩，但压缩也消耗CPU，且读取时必须先解压。规则很简单：列名要短，能叫a就别叫user_action_type。但是短列名有自己的可读性问题，还是建议在HBase的TableDescriptor里放一个描述说明文件，或者用公司内部的元数据管理平台维护一个映射表。实际项目中，合理的做法是短列名只在核心高吞吐表里用，普通报表表直接写全名，避免接手的人看代码时候一脸茫然。

3.3 版本数、TTL与删除标记

HBase一个单元格可以存多个版本，默认版本数是1。如果需要保留历史，可以调VERSIONS参数，但这要付出存储和读取代价。扫描时只会返回指定版本的记录，但底层那些过期版本的数据会在compaction时才会真正被清理，在清理前它们始终占用磁盘、参与scan的文件合并。

TTL是按列族设置的，超过TTL的KeyValue在读取时会被忽略，并在下一次Major Compaction时物理清除。很多性能问题其实都来自“删不掉”：

• 你调用了Delete接口，HBase并不会立即删除旧数据，而是在KeyValue上写入一条类型为Delete的墓碑标记。扫描时会跳过这些数据，但物理文件仍然在，磁盘空间不会下降。直到Region执行Major Compaction，墓碑标记和它标记的数据才一起被清理掉。
• TTL过期也是同理，数据过了TTL只是逻辑不可见，物理删除靠compaction。

所以表设计必须把“清理策略”纳入考虑。如果线上表要做频繁更新和删除，得配置好compaction策略，并且避开业务高峰期手动触发major_compact，不然compaction占用的IO会让整个集群读写延迟都飙起来。关于GC相关问题后面专门讲。

3.4 用列族和列实现“动态宽表”

HBase官方没有原生二级索引，所以在很多“明细流水”类场景中，我习惯把“宽表”设计成“固定前缀+动态列”的结构。比如存储一个订单的所有事件：订单创建、支付、发货、签收。你可以把事件时间戳作为列限定符的一部分，create_1690000000、pay_1690001000、ship_1690002000。这样每次新事件其实就变成给同一行增加一个新列，不需要预先定义。读取时可以通过ColumnPrefixFilter快速取到某类型事件。

不过要注意，动态列会带来Region侧数据局部性变好、但读取时要拼凑一大堆列的情况。设计时尽量把状态常驻列和一次性事件列放成不同列族或不同名称前缀，但不要拆太多列族。那种“一行记录随着时间不断增长”的模型，最怕你读的时候无意间把一个巨大的宽行全部加载回来，结果内存和带宽都烧在没用的历史数据上了。

4. 预分区与热点：表设计落地后的第一道防线

4.1 为什么建表时就要规划Region数量

HBase新表默认只会有一个Region，数据量上涨后会自动分裂。问题在于自动分裂是个异步过程，分裂期间涉及Region下线、元数据更新、数据重新分布，如果流量一直很大，这个过程会很被动，而且分裂出的Region数你完全不可控。更常见的坑是，在没有预分区的情况下写入一批大量数据，所有压力先打在单个RegionServer上，等它触发分裂时，IO和RPC线程可能已经过载了。

所以，建表之前必须根据数据量和访问模式估算出Region数量，把分裂的“时机”提前到上线阶段。操作上，可以在建表时直接指定预分区边界，或者用org.apache.hadoop.hbase.util.RegionSplitter工具去切。

一个粗略估算公式（具体还得看单Region容量上限和机器配置，这个不是固定标准）：

code复制预估数据量总大小 = 行数 × 每行KeyValue平均大小
目标Region单Region数据量 = 10GB ~ 20GB（常见配置范围，也可以更小或更大）
Region数量 = 预估数据总大小 / 目标单Region数据量 × 冗余系数

其中冗余系数一般取1.3～2.0，理由是HFile有副本、列名、版本、compaction临时空间都算进去。我在一个日增500GB的日志场景里，单Region定10GB左右，冗余系数1.5，最后Region数大概控制在几十个，再配合预分区跑得很稳。

4.2 Region大小不是越大越好

有一个常见的误解是“Region越大，顺序Scan性能越好”。理论上说，大Region可以减少RegionServer上的Region个数，降低管理开销，但对单个Region热点是致命的。如果一个大Region正好承担了所有写流量，那么热点就会被无限放大。如果Region数量过多，也会导致zk和Master上的元数据操作变多、Region切分冷启动增多。所以Region大小要在容量、热点容忍度和元数据开销之间平衡，我建议观察线上Region的存储占用和读写量数据来迭代调参。

还要关注一个点：预分区的“预”字。预分区只是解决了初始分布和一部分自动分裂压力，但业务数据分布如果非常不均衡，一段时间后某些Region数据量还是会远超其他Region。这时候就需要定期分析Region大小分布，必要时做一些手动split或者balance。集群里的资源均衡是一个持续动作，不是一次建表就能结束的。

4.3 预分区实操：两种常用方法

用HBase Shell可以这样建一张预分区表：

bash复制# 指定分裂点，创建表orders，按rowkey前缀：0000,0010,0020 ... 0100，总共11个区间
create 'orders', 'info', {SPLITS => ['0000','0010','0020','0030','0040','0050','0060','0070','0080','0090']}

如果不想手动算，可以用HBase自带的Splitter工具，它利用RowKey数字化算法帮你自动生成分区边界：

bash复制hbase org.apache.hadoop.hbase.util.RegionSplitter orders -c 10 -f info

-c 10表示预建10个Region，-f info表示表里有info这个列族。这里特别注意，预分区边界要跟Rowkey设计匹配。如果Rowkey前缀并不会落在你的分区边界上，预分区等于白做，数据照样倾斜。比如你Rowkey前缀是00-99，但预分区边界用的是0000、0010这类，没对齐，就会导致大量前缀落在同一个分区。一个更正确的对齐方式是：先确认Rowkey前缀的取值范围，然后用均匀步长去创建split，再在写数据时保证前缀覆盖率和split边界一致。我在生产环境做“订单全域扫描表”时，把分区边界设定为00|,01|,...,99|，共100个分区，因为Rowkey就是两位哈希前缀 + 业务ID。这样每个分区在字典序上恰好对应一个哈希前缀区间，无论数据写入还是全表Scan都不会有倾斜。

5. 影响读写性能的表级参数：块、布隆过滤器与压缩

5.1 BlockSize到底设多大合适

HBase读过程底层是把HFile中的数据块加载到内存做扫描。HFile的BlockSize默认是64KB，它决定了一次IO从磁盘拉多少数据到BlockCache。对于点查为主的场景，把BlockSize调小到16KB或32KB，读某个Rowkey时加载的无效邻居数据更少，命中率更高。对于Scan为主的场景，尤其顺序全表扫描，在大BlockSize下顺序读效率更高，比如128KB。

我推荐这样开始：

参数可以在建表或变更表时设置：

bash复制create 't1', {NAME => 'cf', BLOCKSIZE => '32768'}

临时变更可以用：

bash复制alter 't1', {NAME => 'cf', BLOCKSIZE => '65536'}

注意alter操作会触发Region重新上线，建议在业务低峰操作。

5.2 BloomFilter：给随机读做快速过滤

BloomFilter是表设计里最容易被忽视但性价比极高的选项。它解决的问题是：读一条数据时，RegionServer需要判断这条Rowkey到底在哪些HFile里。如果没有BloomFilter，它只能去每个文件的Index里查找，甚至逐个Block扫描，读放大会很严重。开启BloomFilter后，它会用极小的内存代价告诉你“这个Rowkey大概率不在这个文件里”。

设置方式：

bash复制create 't1', {NAME => 'cf', BLOOMFILTER => 'ROW'}

还有ROWCOL级别，它对“Rowkey+Qualifier”做成布隆索引，适合点查列数量少且固定列的场景，精度更高但构建时开销更大。我通常在纯点查表上选择ROWCOL，在Scan多的表上选择ROW，因为Scan本身需要跨多个列，Row级别的过滤就够了。启用BloomFilter之后的代价是MemStore flush时会额外为每个HFile生成布隆索引，增加少量CPU和内存，但对随机读的收益远大于这点代价。

5.3 压缩：数据量、IO和CPU的三角权衡

HBase支持的常用压缩编码包括GZ、Snappy、LZO、ZSTD。生产环境最常见的是Snappy，它在压缩比和压缩速度之间平衡较好，适合大多数在线查询。如果磁盘成本敏感性高，数据冷热差距不大，可以考虑ZSTD，压缩比更高，但在CPU较弱的机器上可能会有额外延迟。这里我提醒一句：压缩编码不是写进去就不能改，你可以后期alter表来切换，只是切换也要触发重写，后台大压缩会占带宽。

表设计阶段就顺手把压缩方案定了，避免上线后数据量膨胀到几百G才想起要加压缩，那时候一次全量compaction非常耗时。建表SQL示例：

bash复制create 'event_log', {NAME => 'info', COMPRESSION => 'SNAPPY', BLOOMFILTER => 'ROW'}

6. HBase GC延迟太高？表设计脱不了干系

6.1 GC问题如何和表结构关联

很多人遇到HBase GC延迟高，第一反应是先调JVM参数，比如改-Xmx、G1HeapRegionSize，但忽略了一个源头：表结构和读写模型本身。RegionServer内存主要由三块组成，MemStore用于缓存新写入，BlockCache用于缓存热读数据，剩下的就是分配给各种索引和临时对象。GC压力大往往意味着对象分配和晋升太频繁。

从表结构触发GC问题主要有几条路径：

• BlockSize设置不合理，每次读都会把过多的相邻数据拉进内存，BlockCache命中率上不去，缓存淘汰频繁，Old Gen对象反复晋升。
• 行数据过大。单行几十MB的大对象会直接导致内存碎片，Flush和Compaction时候JVM可能要为大数组分配连续内存，频繁GC停顿。
• 列数量极多且动态变化，KeyValue数量巨大，导致Scan时创建大量Cell对象，Young GC和Old GC都会被推高。
• BloomFilter误判率太高，某类读查询不得不扫描大量HFile，内存缓存压力大增。

所以治理GC延迟，应该先做表结构体检。如果某张表的单行大小过大，建议拆键值，把大字段挪到对象存储，只在HBase里留路径或摘要。

6.2 压垮GC的常见表设计操作

我再补充几个和HBase直接相关的“危险操作”：

• 未限制版本数，同时每次更新都写入整行数据。比如某张表默认版本数设成Integer.MAX_VALUE，因为某次业务事故，然后又高频写入同一条Rowkey不同列，结果同一行积累了几百上千个无效版本。Scan时内存中一次性要组装上万个Cell，GC直接爆炸。
• Region数量多且MemStore无法及时flush。RegionServer会周期检查Region的MemStore大小，但如果单Region写入太大，MemStore就保持在较高水位，长时间不flush，最终触发阻塞性flush，全RegionServer阻塞等待，GC加剧。

我处理过一个案例：某后台报表任务每隔10分钟就全量更新一次某个用户的状态，写法是每回Delete旧行再Put新行，而表VERSIONS=3，TTL还设得很大。最终在一天内生成了数百万的墓碑标记和过期数据，HFile数量指数上升，RegionServer上的老年代GC经常超过5秒。最终方案是改写成upsert方式，并控制TTL为30天，同时减少不必要的历史版本。这个改动比调任何JVM参数都管用。

6.3 配合HBase Web UI和Linux层排查思路

在线排查HBase GC问题时，HBase Web UI（默认端口16010，老版本是60010）能提供非常直观的RegionServer状态。不要只看Memory指标，要关心：

• Compaction Queue Length：如果持续不为0，说明compaction跟不上写入。
• MemStore Size和Cache Hit Ratio：MemStore过大，说明flush压力大；Cache命中率低，说明读到大量未缓存数据。
• Region数以及大Region占比：发现某几个Region特别大，而其它Region很小，就是数据倾斜，GC和读写延迟都会不均匀。

在Linux层，可以用top观察RegionServer进程CPU，用jstat -gcutil <pid> 1000看FGC次数和时间。如果FGC频繁且单次很长，借助GC日志（-Xlog:gc*）确认是哪个阶段耗时长。这时候不要急着一顿参数调优，最好先结合表结构去看是不是某些读请求把过多Block拉入了内存。

7. 表设计落地后的验收与运维清单

7.1 上线前必须做完的八项检查

一个表设计草稿变成生产表之前，我通常会对照这份清单过一遍，缺一项都要抽时间补齐：

1. 是否画清了核心查询的Rowkey访问模式，有没有哪条查询会触发全表Scan？
2. Rowkey是否满足唯一、散列、长度控制三原则？
3. 数据量在1个月、半年、一年后分别达到什么量级，Region数和磁盘估算过没有？
4. 列族数量是否控制在3个以内，列名长度是否已优化？
5. 每个列族的TTL和版本数是否明确设置，而不是用默认值糊弄？
6. 是否配置了BloomFilter、压缩编码和合适的BlockSize？
7. 预分区边界是否和Rowkey前缀语义对齐？
8. 是否计划好了定期巡检、Region均衡和Major Compaction窗口？

这里尤其要强调第1条和第7条。很多生产事故追到根因，都不是代码bug，而是“设计时没想明白查询主键”和“预分区边界与实际Rowkey前缀不一致”这种低级错误。

7.2 从监控数据反推表结构问题

上线后，我推荐在监控面板上至少保留这几项指标：

• RegionServer的写请求数按Region维度分布。如果某个Region或某台机器的写请求量远超其他，优先怀疑Rowkey散列失效。
• 单个Region的Storefile大小和数量。Region数量失衡或Storefile文件数过多，考虑做compaction或重分区。
• BlockCache命中率。如果命中率长期低于80%，读路径延时可能很高，需要考虑优化Rowkey模式或者增加RegionServer内存。
• GC平均和最大暂停时间。超过1秒的最大暂停要警惕，超过3秒基本会影响线上RPC超时。
• Region自动split次数。如果频繁触发自动split，说明预分区规划不足，应思考是否要手动管理分区策略。

这些指标反推回去，会让你知道当前表设计到底能不能支撑未来两年的业务增长。

7.3 我这些年踩过的三个最隐蔽的坑

第一个坑是全表没设置合理的压缩。早期我一个业务表上线半年，数据量膨胀到2TB，才发现节点磁盘快满了。后来加上ZSTD压缩，数据直接降到700GB。压缩不是可选项，而是必选项，应该在第一天就加。

第二个坑是没考虑HFile的基础膨胀。HBase的存储并不是“一份数据只存一份”，它会有多副本、HFile中自带索引和布隆结构，还有历史版本。如果你按原始数据量估算磁盘，多半会低估30%甚至更高。所以容量规划一定要留足冗余。

第三个坑是过度依赖“默认值”。HBase默认BlockSize是64KB、默认不开启BloomFilter、默认VERSIONS=1。它们看着都能用，但在真实读写特征下未必合理。一位老前辈说过一句话我一直记得：你不去主动设计，系统就会用默认参数替你设计。默认不是错误，但大概率不是最优。

8. 最后再分享一点项目落地时的个人体会

HBase表设计这件事，说到底是“以最少的集群资源满足最核心的业务访问”。我在真正扛过几次大促流量之后就明白了，任何参数调优都救不了一个结构不对的业务表。先把Rowkey和预分区想透，再把列族、压缩、布隆过滤器这些细节配好，最后配合监控手段持续观察和调整，这样你的HBase集群才能睡得踏实。

做新表推荐你用这套流程：先画访问模式矩阵，再定Rowkey结构，然后建预分区表并验证数据分布，最后配上压缩、BloomFilter和TTL。每一步都不复杂，但组合起来需要完整考虑。真遇到自己解决不了的问题，优先去HBase Master的Web UI看Region分布和RegionServer日志，通常问题都会浮出水面。

这个表设计最佳实践本身也是一个可以不断迭代的模板。如果你正在为手头的业务设计HBase表，我建议直接按前文的清单过一遍，相信我，这比到处找现成脚本和“调优大全”更有效。