冷热分离这四个字我在各种架构文档里见过不下十次真正把它从一期的“把老数据删干净”推进到二期“把冷数据搬进 HBase 还能查”还是扎扎实实埋了三天。这三天里我对着白板把写入链路、查询链路、回滚方案推演了一遍又一遍中间推翻过两版设计也把几个想当然的假设用压测数据按在地上摩擦。这篇文章就是那三天推演过程的完整还原包括我最后为什么选了 HBase、RowKey 到底怎么切、老接口怎么做到业务方无感、以及上线后第一批真实问题是怎么冒出来的。内容偏实操适合正在做数据分层、历史数据治理、单表膨胀治理的后端同学也适合刚接触 HBase、想知道它到底该放在架构里哪个位置的读者。看完你至少能拿走一套可以照着抄的表结构、一份迁移校验清单以及几个能帮你少熬两个通宵的坑位提醒。1. 先把冷热分离讲透它到底在解决什么问题1.1 从一次库表膨胀说起热数据被热数据拖垮的体感我接手的那套系统核心是一张业务明细表五年前设计的字段二十来个主键自增索引六个。业务量平稳增长问题不是某一天爆发的而是慢慢渗透出来的先是列表页从 80ms 变成 400ms然后 DBA 开始抱怨备份窗口拉长接着某次大促前做压测发现写入 TPS 上不去慢查询日志里全是同一个模式的分页 count。去翻表的数据分布结论很典型近 90 天的数据只占全表 6%但承担了 98% 的访问剩下 94% 的存量数据一年里被访问的次数加起来不到四位数基本都是客服查历史、财务对账、风控回溯这几类低频但必须能查的场景。这 94% 的数据不走索引就得一直维护Buffer Pool 就一直被污染备份就永远慢。这就是冷热分离要解决的核心矛盾不是数据太多了而是不该待在一起的数据待在了一起。热数据要求低延迟、强一致、支持复杂条件查询、支持事务冷数据要求低成本、大容量、能按主键或少量条件取回、可以接受秒级延迟。这两类需求放在同一张表上必然有一方要妥协而现实中妥协的永远是热数据那一方。我当时给团队下的定义很直白冷热分离不是一次技术升级是一次数据生命周期治理。它要回答四个问题——什么算冷、冷数据搬去哪、搬过去还能不能查、搬错了能不能退回来。这四个问题任何一个没答案这事就不该上线。1.2 冷热分离的本质是数据分层不是数据删除一期我们做的是“归档 删除”把超过 180 天的数据导成文件扔到对象存储然后从主库删掉。听着挺清爽实际跑起来问题一堆客服工单里只要出现“帮我查一下去年那笔”就得走人工提数流程平均响应两小时财务季度对账要把文件拉回来重新入库一次几十 GB折腾一整天更麻烦的是有些业务方开始自己偷偷存一份数据副本形成新的数据孤岛。所以二期的第一原则我定得很死冷数据必须在线可查只是查得慢一点。慢是可以接受的不可查是不可接受的。这条原则直接决定了存储选型的方向——对象存储 离线计算虽然便宜但它满足不了“按主键随机取一条”的诉求纯 Hive 表虽然能查但点查延迟秒级以上客服场景撑不住。这里有个容易被忽略的点数据分层的粒度。按整行分、按字段分、按时间分效果完全不同。按字段分把大字段如快照 JSON 拆到冷库解决的是行宽问题不解决行数问题按时间分解决的是行数问题但会带来跨期查询的复杂度。我们最后采用的是按时间 按状态双条件只归档“创建时间超过 180 天”且“流程已终结”的数据把还在流转中的老数据留在热库避免归档后又要回写。注意状态条件一定要选不可逆的终态。我见过有团队按“最后更新时间”归档结果一个沉睡半年的单子突然被激活热库里已经没这行了直接引发线上写失败。1.3 二期为什么不能沿用一期的思路一期是纯离线归档架构上很轻定时任务扫表、导文件、删数据没有任何在线依赖。二期要在线可查复杂度是几何级上升的主要卡在三个地方。第一是查询入口的收敛。系统里查这张表的地方有二十多处有走 ORM 的、有拼 SQL 的、有走数据访问中间件的还有些是报表平台直接连库。如果每个入口都改一遍判断逻辑改完还要回归测试工期不可控。所以二期必须做一个统一的读路由层让老代码尽量少动。第二是写入的一致性问题。一期归档是批量搬走搬完就完事二期要求数据在热库存一份、冷库存一份或者至少在搬家过程中不能丢。只要涉及双写就必须回答“热写成功冷写失败怎么办”“冷写成功热写回滚怎么办”。第三是查询语义的兼容。老接口里有分页、有 count、有多条件组合、有排序这些在关系型数据库里是白送的在 HBase 里全要自己实现。这一点我在第三节会展开讲也是我推翻第一版设计的主要原因。想清楚这三点之后我才敢开始画架构图。顺序很重要——先想查询怎么收敛再想写入怎么保证最后才选存储。反过来做十有八九会选出一个查询能力撑不住业务的存储。2. 存储选型为什么冷数据最后落到 HBase2.1 把候选方案摆上桌逐个挑刺选型这件事最怕拍脑袋。我把当时能想到的方案列了六个每个都按我们真实的访问模式打分而不是看谁的名气大。方案一MySQL 归档表。同实例建一张结构相同的归档表冷数据挪过去。优点是改造成本几乎为零SQL 原样复用缺点是它根本没解决问题——索引还在、备份还在、连接池还在只是把一张大表拆成两张中表主库压力一点没减。Pass。方案二独立 MySQL 冷库实例。把归档表放到另一个低配实例上。这个方案在小数据量下是最省事的我们一期其实就想这么干。但按容量估算冷数据三年后会到 8 亿行左右单实例扛不住分库分表又要引入中间件运维复杂度上去了收益却只是“能查”。备选。方案三Hive / 数据仓库。离线分析场景无敌点查场景灾难。客服查一条记录要等十几秒不可接受。它更适合做对账、跑批、月末报表这个我们后来确实用上了作为 HBase 的补充而不是替代。方案四ClickHouse。列存、压缩率高、聚合快按时间范围扫的性能极好。但它擅长的是“扫一批”我们的主场景是“按单号取一条”而且 ClickHouse 的更新和点查不是强项运维上还要额外的集群。Pass。方案五Elasticsearch。多条件组合查询、模糊搜索都很舒服能解决 HBase 最大的短板。但存储成本高冷数据本身就大全量放 ES 性价比太低。我们最后把它做成了“索引层”只存关键字段不带明细这个组合后面会讲。方案六HBase。按 RowKey 点查极快、水平扩展、存储成本低、支持 TTL 和版本控制、天然适合海量稀疏数据。缺点是只能按 RowKey 高效查复杂条件查询基本抓瞎运维门槛也不低。2.2 用一张表把选型标准量化光靠文字描述容易自说自话我干脆做了一张评分表把权重也标出来。业务方看到这张表之后讨论效率高了很多。维度权重MySQL 冷库HiveClickHouseESHBase主键点查延迟30%51345多条件组合查询20%53351存储成本每 TB20%25414水平扩展能力15%25445运维复杂度越高越好10%53232与现有技术栈契合度5%53233加权得分3.853.03.153.353.65按这张表HBase 和 MySQL 冷库其实咬得很紧。最后拍板选 HBase 的决定性因素不在表里而在容量曲线MySQL 冷库在 3 亿行以内很舒服超过之后分库分表的运维成本是跳变式上升的HBase 的扩展是线性的加 RegionServer 就行对业务的感知几乎为零。我们预估冷数据三年后接近 10 亿行所以选了一条起点更陡、但天花板更高的路。这里我要多说一句选型表的价值不在于算出那个分数而在于逼所有人把权重讲清楚。当时有个争论是“多条件查询”到底占多重业务方觉得很重要运维觉得无所谓。后来我们把线上真实查询日志扒了一遍发现 87% 的请求带主键或准主键单号、流水号只有 13% 是纯条件组合而这 13% 里大部分集中在月末几天。权重一下子就从 35% 降到 20%选型的结论也就清晰了。用数据吵架比用感觉吵架有效得多。2.3 HBase 赢在哪又输在哪赢的地方很硬核。第一是按 RowKey 定位是常数级先查 Region 再查 MemStore/BlockCache最后落到 HFile路径短且可预测P99 稳定在几十毫秒。第二是存储成本可控HFile 本身就有块压缩我们实测用 SNAPPY 压缩比在 3:1 到 5:1 之间换成 ZSTD 还能再降一点同样数据量下磁盘占用只有 MySQL 的三分之一左右。第三是稀疏存储列可以动态增加老数据不需要的字段不占空间这对我们这种字段逐年加的业务特别友好。输的地方同样硬核而且每一条都得用工程手段补。短板一不能按非 RowKey 字段查。想按“用户ID 时间范围”查RowKey 里没这个组合就废了。解法是建索引表或者把常用查询维度揉进 RowKey。短板二不支持跨行事务和聚合。没有 count、没有 sum、没有 order by。我们后来把 count 改成了“预估 精确两段式”列表页只给“是否有下一页”不给总数产品经理一开始不接受看到性能数据之后妥协了。短板三分页很难受。PageFilter 在跨 Region 时行为不精确翻到后面容易出现漏数据或者重复。这块我踩得最狠第七节细说。短板四运维门槛。Region 分裂、热点、Compaction、RegionServer 内存这些都得有人盯。我们把监控面板做了两版才把关键指标捋顺。2.4 什么情况下我会劝你别用 HBase这话我得说在前面因为踩过这个坑的团队不少。如果你的冷数据总量在 2 亿行以内、单行不超过 2KB、查询条件比较固定那用 MySQL 分表 冷库实例是性价比最高的方案别为了技术先进性硬上 HBase。我见过一个团队为了“架构统一”把 3000 万行数据搬进 HBase结果多了一整套集群要维护查询性能反而因为跨服务调用变差了最后又搬回来。还有两种情况要谨慎。一是需要频繁更新冷数据的HBase 的更新本质是写新版本频繁改同一个 RowKey 会产生大量小文件Compaction 压力大二是强一致读场景HBase 读默认不是强一致的虽然单行读在多数情况下可接受跨集群复制场景下更要注意。3. 二期整体架构设计四条链路想清楚再动手3.1 数据分级规则按时间切还是按状态切分级规则是整个方案的地基定错了后面全白干。我见过三种常见切法各有适用面。纯时间切超过 N 天的全部归档。实现最简单一个定时任务扫时间范围就行。缺点是会把还在流转中的数据也搬走比如一个审批走了三个月的单子搬走之后审批人点进去就查不到了。纯状态切只归档终态数据。语义最安全但归档量不稳定某些业务线的单子可能永远不到终态越积越多。时间 状态双条件这才是生产可用的写法。我们定的规则是create_time now - 180d AND status IN (终态集合)两个条件同时满足才归档。这样既控制了数据量又避免了活跃数据被搬走。还有一个容易被忽略的细节分级规则要可配置、可灰度。我们把它做成配置中心里的一个表达式按业务线分别配置窗口天数先在小业务线上跑两周确认没问题再放开到核心业务。千万别把 180 这个数字硬编码在代码里后面调窗口的时候你会哭。提示分级规则上线前一定要用真实数据跑一遍“如果按这个规则归档过去半年会有多少条数据被搬走、其中有多少条在搬走后 30 天内被访问过”。这个反查能帮你提前发现规则漏洞我们跑出来发现有 2000 多条数据搬走后一周内就被查了全是客服工单于是把终态集合里的“待退款”状态去掉了。3.2 写入链路双写、异步补偿、离线归档三种姿势写入是冷热分离里最容易出事的地方因为写路径上多了一个不确定的依赖。三种姿势我全都试过最后选的是组合方案。姿势一同步双写。业务写热库成功后同步写冷库两个都成功才返回。一致性最好但延迟翻倍而且冷库抖动会直接传导到业务。我们压测时把 HBase 人为降速业务接口 P99 从 120ms 涨到 900ms直接否决。姿势二异步消息补偿。业务只写热库同时发一条消息到队列消费者写冷库。业务延迟不受影响但存在消息丢失和重复的风险需要做幂等。这是我们主力采用的方式。姿势三离线归档。定时任务扫热库的过期数据批量写冷库写完删热库。适合存量数据搬迁也适合作为增量链路的兜底。我们把它做成 T1 的兜底任务每天扫一遍“应该归档但冷库没有”的数据补进去。组合起来就是实时走消息、存量走离线、每天做一次对账。这个组合的关键在于对账它把前两条链路的不确定性收敛掉了。对账逻辑很简单按天统计热库中符合归档条件但仍在库的行数、冷库中当天新增的行数两个数字应该能对上对不上就告警。3.3 查询链路路由层怎么判断该查谁这是二期最核心的设计。我最终做的是一个读路由层夹在业务代码和数据源之间对外暴露的接口签名和原来完全一致。路由判断的优先级是这样请求里如果带了明确的时间范围且范围完全落在冷数据窗口内直接路由到冷库范围完全落在热数据窗口内路由到热库跨越分界线的拆成两次查询再合并。如果请求没带时间但带了主键先查热库热库没有再查冷库这个兜底查询很重要能救回那些因为消息延迟还没同步的数据。跨越分界线的合并查询是最麻烦的因为涉及排序和分页。我们的做法是两个数据源各取“offset limit”条在内存里归并排序后截取。这在深分页时会退化所以我们对这类查询做了限制——最多支持前 100 页超过就提示用户缩小时间范围。产品一开始不同意我把深分页的耗时数据甩过去第 500 页时单次查询 4 秒讨论就结束了。路由层还承担了一个额外职责降级开关。冷库不可用时路由层直接把冷数据查询转成“返回空 提示查询超时”保证主流程不受影响。这个开关在上线第二周救过一次场后面会讲。3.4 一致性与回滚冷数据的后悔药怎么留冷数据一旦删了热库的副本回滚就只能靠冷库自己。所以我们做了三层保险。第一层是冷库不删只标记。归档时给每行打一个archive_version如果发现归档规则有问题可以按版本号批量回迁不用重新从备份恢复。第二层是热库延迟删除。数据进冷库之后热库不立即删而是标记一个archived时间戳由独立任务在 7 天后物理删除。这 7 天就是后悔窗口期间任何回迁都是一条 update。第三层是快照备份。HBase 的 Snapshot 功能可以在秒级对表做快照成本极低。我们每天凌晨做一次保留 7 天。真出大事故从快照恢复比从 Hive 重导快得多。回滚操作也演练过。我让人真的执行了一次“把某天归档的 500 条数据回迁到热库”全程 3 分钟业务无感。这个演练比写十页文档都管用因为它暴露了两个隐藏问题回迁时的唯一键冲突没处理、回迁后热库的索引没重建。这俩问题在上线前修掉了。4. HBase 表设计RowKey 是命门4.1 RowKey 设计的三个硬约束HBase 的所有性能问题八成能追到 RowKey 上。我在设计时给自己定了三条硬约束违反任何一条就推倒重来。约束一必须能覆盖最高频的查询维度。我们的高频查询是“按单号查”和“按用户 时间范围查”所以 RowKey 至少要支持这两种访问模式。一个 RowKey 没法同时满足那就建两张表一张主表、一张索引表。约束二必须打散写入热点。HBase 按 RowKey 字典序分区如果 RowKey 是单调递增的比如时间戳前缀、雪花ID所有写入都会砸到最后一个 Region 上前面几十个 Region 全程围观。这个问题在批量归档时尤其致命我们第一版用的就是时间戳前缀批量导入时单个 RegionServer 的写请求队列直接打满。约束三长度要控制。RowKey 会存在每个 Cell 里太长会显著放大存储。官方建议控制在几十字节以内我们主表的 RowKey 是 32 字节左右。最终的方案是哈希前缀 业务主键 反转时间的组合。以订单明细为例RowKey 结构是hash(userId) 取前2字节 userId 反转后的createTime orderId。哈希前缀负责打散userId 保证同用户数据聚集范围查询友好反转时间让同一用户下的数据按时间倒序排列最新的在前符合列表页习惯。反转时间的写法很简单用Long.MAX_VALUE - timestamp就行。这样字典序从小到大扫拿到的就是时间从新到旧。这个技巧看着小实际很实用省掉了一次内存排序。4.2 列族、版本数、TTL 参数怎么定列族数量直接决定了写放大倍数。HBase 的 Flush 和 Compaction 是以列族为单位的两个列族意味着同样的行数会产生两倍的 MemStore 和两倍的 HFile。我们的原则是能一个列族解决就绝不用两个。主表只设了一个列族d所有业务字段都放里面。有人会问冷热字段要不要分开我们的答案是不要因为冷数据整体都是一次性读出来的分列族只会增加 IO 次数。版本数设成 1。默认也是 1但我要显式写出来防止有人后面为了“留个历史”改成 3那存储直接翻三倍。冷数据的历史版本应该由业务层的归档版本号来管不该交给 HBase。TTL 这里有个取舍。理论上冷数据要长期保留我们的合规要求是 5 年设 TTL 会导致数据自动消失。但完全不设 TTLCompaction 就没有清理依据。我们的做法是不设 TTL改用按年分表每年一张表命名带年份后缀过期表整体下线。这样既满足了保留期要求又避免了单表无限膨胀。BlockCache 和 MemStore 的比例按读写比调。冷数据是典型的读多写少归档是批量的查询是零散的所以 BlockCache 给到堆内存的 40%MemStore 给 30%剩下留给系统。这个比例不是拍脑袋是压测出来的我们把 BlockCache 从 20% 调到 40%点查 P99 从 45ms 降到 18ms效果非常明显。注意MemStore 不要给太大。单个 MemStore 越大Flush 时的停顿越长而且 Region 分裂的触发点也会变。我们一开始给了 40%结果 RegionServer 的 GC 停顿明显变长调回 30% 就正常了。4.3 预分区与压缩上线前必须做的两件事预分区这事不做就是给自己埋雷。新建表默认只有 1 个 Region所有写入全打在这一个上等它涨到 10GB 才分裂中间这段时间性能是灾难级的。我们建表时按 RowKey 的哈希前缀直接预分 32 个 Region写入瞬间就打散了。预分区的 split keys 要跟哈希前缀对齐。如果前缀是 2 字节那 32 个 Region 就按哈希值的高位均匀切。计算方法是把哈希值的字节范围均分比如 0x00、0x08、0x10……一直到 0xF8。这里一定要确认哈希函数分布均匀我们用的是 MurmurHash实测 32 个桶的偏差在 5% 以内。压缩也不能省。HFile 的块压缩对冷数据效果极好因为冷数据的重复度高、字段长、JSON 快照多。我们在测试环境对比过不压缩 300GBSNAPPY 压缩后 92GBZSTD 压缩后 71GB。ZSTD 的 CPU 开销比 SNAPPY 高一些但冷数据写入量小、读取也不频繁这点 CPU 完全可以接受。最终选的是 ZSTD。还有一个开关容易被忘布隆过滤器。点查场景下开ROW级别的布隆过滤器能把不存在的数据直接挡在 HFile 之外减少无效 IO。我们的点查里有一部分是“查了但不存在”开了之后这类请求的延迟从 12ms 降到 2ms。4.4 一份可落地的表结构示例把上面的结论落成具体配置大概是这样建表语句我用伪代码写不同发行版语法略有差异表名: order_detail_archive_2024 RowKey: hash2(userId) userId(16) (Long.MAX_VALUE - createTime)(8) orderId(12) 列族: d 属性: VERSIONS 1 COMPRESSION zstd BLOOMFILTER ROW BLOCKCACHE true BLOCKSIZE 65536 IN_MEMORY false DATA_BLOCK_ENCODING FAST_DIFF 预分区: [0x00, 0x08, 0x10, ..., 0xF8] 共 32 个 无 TTL按年分表列族里的字段设计上我做了两个决定。一是把高频检索字段冗余进去比如状态、金额、创建人避免为了拿一个状态再去查一次明细二是把大字段单独放一个 qualifier比如d:snapshot读取时用addColumn精确指定不读这个列就不会产生 IO。HBase 是按列族读的但指定了 qualifier 之后Filter 层能跳过不含该列的 HFile block实际效果接近按列读。这套配置上线后跑了三个月单表 2.1 亿行平均点查延迟 15msP99 38msRegion 数量稳定在 40 个左右没有出现热点。5. 迁移实操从存量到增量的完整流程5.1 存量数据离线迁移的步骤与校验存量迁移是最耗时的环节也是最容易翻车的地方。我把它拆成了六步每一步都有验收标准。第一步容量评估。从热库统计符合条件的行数、平均行宽、大字段占比估算出压缩后的存储量。我们算出来是 1.8 亿行、平均 1.2KB、压缩比 3.5:1实际占用约 620GB加上三副本和预留申请了 2TB。第二步建表并预分区。就是上一节那套配置建完先灌 10 万行测试数据验证 RowKey 分布是否均匀看每个 Region 的 storefile 大小是否接近。第三步小批量试导。取 100 万行用 BulkLoad 方式导入。这里强烈建议用 BulkLoad 而不是逐条 Put——BulkLoad 直接生成 HFile 再挂到表上绕过了写路径不占 MemStore、不触发 Flush速度能快十倍以上。100 万行大概跑了 4 分钟。第四步全量导出导入。按天分批每天一批每批导入完做一次校验。分批的好处是出问题只影响一天不用全量重来。全量 1.8 亿行跑了大约 6 小时。第五步数据校验。这一步不能省。我们做了三层校验行数对账源表 count vs 目标表 count、抽样字段比对随机抽 1 万条逐字段比对、关键字段聚合对账按天统计金额总和两边比对。三层都过才算完。第六步确认无误后标记热库归档。注意这里只是标记不是删除物理删除要等 7 天。5.2 增量同步怎么写才不漏增量部分走的是消息链路核心是幂等和顺序两个问题。幂等好办HBase 的 Put 本身就是按 RowKey 覆盖同一条数据重复写多次结果一样。但要注意时间戳——如果启用了自定义时间戳重复写入可能产生多版本我们用默认时间戳VERSIONS1重复写会覆盖天然幂等。顺序问题麻烦一些。同一条数据如果先收到“更新”再收到“创建”最后的状态就不对。我们的解法是在消息里带上数据的更新时间戳消费时先读冷库当前行的版本如果消息里的时间更早就直接丢弃。这多了一次读但保证了最终状态正确。还有一个坑是消息积压。归档任务是批量触发的一次可能产生几十万条消息消费端如果处理不过来就会积压。我们给消费端做了限流和批量提交攒够 500 条或者等 200ms 就批量 Put 一次把写请求合并吞吐从 2000 TPS 提到了 15000 TPS。5.3 灰度与开关设计灰度这件事我坚持做成了四级开关从粗到细都能控。第一级是业务线开关控制哪些业务线的数据参与冷热分离。先开一个小业务线跑两周。第二级是读开关控制读请求是否允许路由到冷数据。这个开关是独立于写开关的意思是数据可以先归档过去但读还是走热库此时热库还没删相当于双读验证。第三级是写开关控制热库数据是否物理删除。这个开关打开之前热库数据一直保留随时能退。第四级是单请求级别的降级就是 3.3 节说的那个降级。这四级开关的组合使用顺序是先开写归档但不删→ 开读路由到冷库→ 双读对账跑一周 → 关双读、开删。整个过程大概三周比预想的长但一次事故都没出。5.4 双读对账怎么验证冷库真的对双读对账是我认为整个方案里性价比最高的一个设计。做法很简单读开关打开后前一万个请求同时查热库和冷库比对结果不一致就记日志。这个对账帮我们抓到三个问题一是某个字段在归档时漏了代码里 if 分支写错了二是时间戳精度丢失导致排序不一致热库是毫秒冷库存成了秒三是有一条数据在冷库里查不到消息消费失败但没重试。第三个问题最值得说。它是这么暴露的对账发现某条数据的冷库查询返回空但热库有。顺着查下去发现是消费端在处理某类消息时抛了异常异常被 catch 住了但没重试。如果没有对账这个问题要等到用户投诉才会被发现。后来我们加了消费失败自动重试三次 死信队列这个问题就再没出现过。对账跑了一周前一万个请求的不一致率从 0.3% 降到 0.002%我们才敢开删。6. 查询改造老接口怎么无感切换6.1 分页查询在 HBase 里为什么是个坑这是整个二期最让我头疼的地方也是我推翻第一版设计的原因。关系型数据库的分页是LIMIT offset, size语义清晰。HBase 的 Scan 虽然也有setStartRow和setLimit但它的语义是“从某个 RowKey 开始扫 N 条”没有 offset 的概念。HBase 自带的 PageFilter 看着像分页实际行为是“每个 Region 单独计数”跨 Region 的时候计数会不准翻几页就开始出现数据缺失或重复。我第一版设计用的是 PageFilter测试环境数据少看着没问题。压测时用真实数据量一跑第 20 页就开始漏数据第 50 页的漏数据率到了 30%。这个问题如果上线业务方会直接炸锅。最终的方案是游标分页前端不传页码传上一页最后一条的 RowKey加密后后端从这条 RowKey 之后扫 limit1 条多取的那一条用来判断“还有没有下一页”。这样无论翻到多深每次查询的代价都是恒定的。这个改造对前端是有影响的需要把“页码组件”换成“加载更多”或者“上一页/下一页”。我们和产品沟通了两轮用“深分页性能对比”的数据说服了他们改造前第 100 页要 8 秒改造后稳定在 40ms。提示如果业务方死活要页码可以做折中——前 10 页用 offset 转 RowKey 的方式算起始位置需要先缓存每页的起始 RowKey10 页之后只给“下一页”。这个方案我们做过一版复杂度高不少最后没采用。6.2 二级索引的三种补法HBase 只认 RowKey那 13% 的非主键查询怎么办我们试了三种补法最后是三种混用。补法一建索引表。单独建一张表RowKey 是“查询维度 原表 RowKey”值里只存原表 RowKey或者干脆什么都不存RowKey 自带。查询时先查索引表拿到主键再回原表取明细。这是最经典的做法写入时要同步维护索引表成本是双写。补法二把维度揉进 RowKey。如果某个查询维度是固定的比如按商家查可以直接把商家 ID 作为 RowKey 的一部分牺牲一点写入打散效果换取查询能力。我们主表的 RowKey 其实已经揉进了 userId就是这个思路。补法三ES 做二级索引。把关键字段同步到 ES复杂条件查询先走 ES 拿主键列表再回 HBase 取明细。这个方案最灵活能支持模糊匹配、多条件组合、聚合统计但引入了新的组件和数据同步链路。我们的实际组合是单号查询走主表 RowKey用户维度查询走主表里的 userId 前缀商家维度、状态维度、金额范围这些走索引表报表类的复杂条件走 ES。三种方式各有各的适用面关键是想清楚每个查询的 QPS 和延迟要求QPS 高的走 RowKeyQPS 低的走 ES中间地带用索引表。6.3 汇总统计类查询怎么办COUNT(*)、SUM(amount)、GROUP BY status这些在 MySQL 里白送的在 HBase 里全要自己算。我们的策略是分级处理。列表页的“共 N 条”改成“是否有下一页”彻底去掉 count。这是最有效的一刀省掉了最贵的查询。必须给总数的场景比如财务报表走预聚合每天凌晨跑批把各维度的统计数据算好写进一张小的汇总表查询时直接读汇总表。代价是数据延迟一天财务场景能接受。实时的、临时的统计需求走ES 或 Hive。ES 的聚合性能在大数据量下也不差Hive 适合跑批。HBase 在这类查询上直接放弃不做无谓挣扎。这个分级策略我跟业务方讲了很多遍核心观点是冷数据的查询能力本来就是要打折的关键是打掉哪些、保留哪些这个必须提前和业务方对齐。最怕的是方案都上线了业务方才发现某个查询不能用了那时候改起来成本极高。7. 线上真实踩坑记录与排查手册7.1 常见问题速查表下面这张表是我从三个月的告警记录里整理出来的按出现频率排序。现象可能原因排查手段处理办法点查延迟从 15ms 涨到 300msRegion 热点或 Compaction 堆积看 RegionServer 的 compactionQueueSize、各 Region 的请求分布手动 major compact 或调整预分区查询返回空但数据明明存在消息消费失败、归档任务漏跑对比热库和冷库的对应行看归档日志手动补录检查消费端异常日志写入 TPS 突然掉到十分之一MemStore 打满触发频繁 Flush看 memStoreSize、flushQueueLength降低单批写入量或扩容 RegionServer深分页第 N 页开始数据重复PageFilter 跨 Region 计数不准用同一个起始 RowKey 反复扫看返回是否稳定改游标分页RegionServer 频繁 GC堆内存分配不合理BlockCache 过大看 GC 日志和堆内存分布调小 BlockCache或拆分 RegionServer归档任务跑不完超时单批数据量过大看任务日志的批次耗时缩小批次按天甚至按小时切分同一 RowKey 查到多条记录VERSIONS 被改成了大于 1检查表的列族配置改回 1并做一次 major compact7.2 三个我踩过的坑每个都值一个通宵坑一时间戳精度丢失导致排序错乱。热库里 createTime 是毫秒我在写 HBase 时为了省空间存成了秒。结果同一秒内的多条数据排序不稳定列表页每次刷新顺序都不一样。这个问题很隐蔽因为大部分时候看着是对的只有同一秒有多条数据时才暴露。后来改成存毫秒RowKey 长度多了 4 字节存储成本涨了不到 1%值。坑二批量导入把集群打挂。第一次全量迁移我用的是逐条 Put没有限流。跑起来十分钟之后RegionServer 的写队列打满整个集群的读请求也开始超时因为读写共用同一个队列。最后是紧急停掉任务、重启集群才恢复。教训是批量导入一定要限流而且最好走 BulkLoad。后来我加了 5000 TPS 的限流配合 BulkLoad同样的数据量对线上几乎零影响。坑三降级开关的默认值写反了。这个坑最丢人。降级开关的语义是“开启降级”我写成了if (degradeSwitch) { 正常查询 }逻辑反了。上线第二天冷库有个 Region 短暂不可用降级开关被自动打开结果所有请求都去打那个不可用的 Region雪崩了三分钟。后来我们加了开关的单元测试并且把所有开关的语义统一成“开关为 true 表示关闭某能力”。7.3 监控告警要看哪几个指标监控面板我改了两版最后收敛到八个核心指标多了看不过来少了抓不到问题。第一组是延迟类点查 P99、扫描 P99、写 P99。这三个是业务最直观的感受。第二组是容量类Region 数量、单 Region 最大 storefile 大小、HFile 数量。Region 数量突然暴涨通常意味着分裂异常HFile 数量过多意味着 Compaction 跟不上。第三组是资源类RegionServer 堆内存使用率、BlockCache 命中率、Compaction 队列长度。BlockCache 命中率掉到 80% 以下就要警惕了通常是某个大 Scan 把缓存冲掉了。第四组是业务类归档任务成功行数、消费失败消息数、双读不一致率。这三个是业务链路的健康度。告警阈值这块我的经验是别设太敏感。一开始 P99 超过 50ms 就告警一天几十条很快就没人看了。后来改成 P99 超过 200ms 才告警配合持续 5 分钟的判定告警量降到一周两三条每条都是真问题。8. 上线节奏与容量规划8.1 分阶段推进的时间表整个二期从设计到全量上线我排了六周实际用了七周。多出来的一周全花在对账和问题修复上这个预留非常必要。第一周做方案设计和评审把四个核心问题的答案写进文档拉上业务方、DBA、运维一起过一遍。这周最重要的产出是那张选型评分表和分级规则。第二周做表设计和迁移工具开发包括 BulkLoad 脚本、校验脚本、对账脚本。这周可以在测试环境把全流程跑通。第三周做读路由层和查询改造这是代码量最大的一周。重点是游标分页和索引表查询。第四周做小流量灰度选一个日增数据量小的业务线全流程跑一遍。第五周放开到主要业务线做双读对账修问题。第六周开物理删除观察一周。第七周收拾残局补文档、清理临时脚本、把监控面板交接给运维。8.2 容量估算的具体算法容量算不准申请资源的时候要么不够要么浪费。我用的算法是这样以我们的订单明细为例。先算原始数据量1.8 亿行 × 平均行宽 1.2KB 216GB。这个行宽是包含所有字段的包括几个大的 JSON 快照字段。再算压缩后按 ZSTD 实测压缩比 3.5:1216GB ÷ 3.5 ≈ 62GB。然后算副本HBase 默认三副本62GB × 3 186GB。再算写入放大Compaction 过程中会有临时的文件膨胀一般按 1.3 倍预留186GB × 1.3 ≈ 242GB。最后算增长按每月新增 3000 万行、年增长 25% 估算三年后总量约 4.5 亿行对应约 600GB 有效数据、1.8TB 三副本、2.3TB 含放大。所以申请了 3TB。这个算法里有一个容易漏的点索引表也要算容量。索引表虽然只存 RowKey但行数和主表一样RowKey 长度加上开销大概是主表的 15%。我们一开始忘了算导致第一批资源申请少了。8.3 上线检查清单最后给一份我实际用的检查清单上线前逐项打勾能挡掉大部分低级失误。分级规则的表达式在配置中心可改且有默认值兜底表的预分区数量与 RegionServer 数量匹配建议 2 到 3 倍压缩算法、布隆过滤器、VERSIONS 全部显式配置不依赖默认归档任务有批次大小限制和失败重试重试次数不超过 3 次消费端有幂等逻辑、有死信队列、有限流读路由层的降级开关语义经过测试默认值是“不降级”深分页已改为游标分页或至少限制最大页数双读对账已跑通不一致率低于 0.01%热库物理删除有 7 天延迟且延迟任务可暂停冷库表有每日 Snapshot保留 7 天监控面板八个指标全部配好告警阈值经过一轮调优回迁脚本演练过一次全程耗时在可接受范围内业务方已知悉冷数据查询的能力边界无 count、深分页受限、复杂条件走 ES这份清单里我觉得最容易被跳过的是最后一条。技术上做得再完善如果业务方不知道“这个查询变慢了是设计如此”那上线之后还是一堆工单。我当时的做法是给业务方做了一次半小时的宣讲把冷热分离的原理、哪些查询会受影响、受影响之后怎么办全讲了一遍还留了一份答疑文档。这半小时省掉了后面大概两周的扯皮。我个人在实际推进这个项目的过程里最大的体会是冷热分离的难点从来不在 HBase 本身。HBase 的表设计、预分区、RowKey网上资料一大把照着抄基本不会错。真正耗时间的是那些边界情况——一条数据归档了但业务方还要改、一个查询跨越了分界线、一个开关的默认值写反了。这些事情没有现成答案只能靠提前想、靠对账兜、靠灰度试。如果让我重来一次我会把更多时间花在“和业务方对齐查询能力边界”以及“把回滚路径真的跑一遍”上而不是花在调 HBase 参数上。另外分享一个小技巧归档任务上线前先跑一次「只统计不执行」的演练模式把所有会被归档的数据行主键打到日志里然后拿这份日志去比对最近一个月的访问日志看看有多少条是刚归档就被访问的。我们跑出来有 2000 多条全是客服在查历史工单于是把客服常用的几个查询加进了白名单让它们强制走热库。这个小动作把上线首周的咨询量压到了个位数。
冷热分离这四个字我在各种架构文档里见过不下十次真正把它从一期的“把老数据删干净”推进到二期“把冷数据搬进 HBase 还能查”还是扎扎实实埋了三天。这三天里我对着白板把写入链路、查询链路、回滚方案推演了一遍又一遍中间推翻过两版设计也把几个想当然的假设用压测数据按在地上摩擦。这篇文章就是那三天推演过程的完整还原包括我最后为什么选了 HBase、RowKey 到底怎么切、老接口怎么做到业务方无感、以及上线后第一批真实问题是怎么冒出来的。内容偏实操适合正在做数据分层、历史数据治理、单表膨胀治理的后端同学也适合刚接触 HBase、想知道它到底该放在架构里哪个位置的读者。看完你至少能拿走一套可以照着抄的表结构、一份迁移校验清单以及几个能帮你少熬两个通宵的坑位提醒。1. 先把冷热分离讲透它到底在解决什么问题1.1 从一次库表膨胀说起热数据被热数据拖垮的体感我接手的那套系统核心是一张业务明细表五年前设计的字段二十来个主键自增索引六个。业务量平稳增长问题不是某一天爆发的而是慢慢渗透出来的先是列表页从 80ms 变成 400ms然后 DBA 开始抱怨备份窗口拉长接着某次大促前做压测发现写入 TPS 上不去慢查询日志里全是同一个模式的分页 count。去翻表的数据分布结论很典型近 90 天的数据只占全表 6%但承担了 98% 的访问剩下 94% 的存量数据一年里被访问的次数加起来不到四位数基本都是客服查历史、财务对账、风控回溯这几类低频但必须能查的场景。这 94% 的数据不走索引就得一直维护Buffer Pool 就一直被污染备份就永远慢。这就是冷热分离要解决的核心矛盾不是数据太多了而是不该待在一起的数据待在了一起。热数据要求低延迟、强一致、支持复杂条件查询、支持事务冷数据要求低成本、大容量、能按主键或少量条件取回、可以接受秒级延迟。这两类需求放在同一张表上必然有一方要妥协而现实中妥协的永远是热数据那一方。我当时给团队下的定义很直白冷热分离不是一次技术升级是一次数据生命周期治理。它要回答四个问题——什么算冷、冷数据搬去哪、搬过去还能不能查、搬错了能不能退回来。这四个问题任何一个没答案这事就不该上线。1.2 冷热分离的本质是数据分层不是数据删除一期我们做的是“归档 删除”把超过 180 天的数据导成文件扔到对象存储然后从主库删掉。听着挺清爽实际跑起来问题一堆客服工单里只要出现“帮我查一下去年那笔”就得走人工提数流程平均响应两小时财务季度对账要把文件拉回来重新入库一次几十 GB折腾一整天更麻烦的是有些业务方开始自己偷偷存一份数据副本形成新的数据孤岛。所以二期的第一原则我定得很死冷数据必须在线可查只是查得慢一点。慢是可以接受的不可查是不可接受的。这条原则直接决定了存储选型的方向——对象存储 离线计算虽然便宜但它满足不了“按主键随机取一条”的诉求纯 Hive 表虽然能查但点查延迟秒级以上客服场景撑不住。这里有个容易被忽略的点数据分层的粒度。按整行分、按字段分、按时间分效果完全不同。按字段分把大字段如快照 JSON 拆到冷库解决的是行宽问题不解决行数问题按时间分解决的是行数问题但会带来跨期查询的复杂度。我们最后采用的是按时间 按状态双条件只归档“创建时间超过 180 天”且“流程已终结”的数据把还在流转中的老数据留在热库避免归档后又要回写。注意状态条件一定要选不可逆的终态。我见过有团队按“最后更新时间”归档结果一个沉睡半年的单子突然被激活热库里已经没这行了直接引发线上写失败。1.3 二期为什么不能沿用一期的思路一期是纯离线归档架构上很轻定时任务扫表、导文件、删数据没有任何在线依赖。二期要在线可查复杂度是几何级上升的主要卡在三个地方。第一是查询入口的收敛。系统里查这张表的地方有二十多处有走 ORM 的、有拼 SQL 的、有走数据访问中间件的还有些是报表平台直接连库。如果每个入口都改一遍判断逻辑改完还要回归测试工期不可控。所以二期必须做一个统一的读路由层让老代码尽量少动。第二是写入的一致性问题。一期归档是批量搬走搬完就完事二期要求数据在热库存一份、冷库存一份或者至少在搬家过程中不能丢。只要涉及双写就必须回答“热写成功冷写失败怎么办”“冷写成功热写回滚怎么办”。第三是查询语义的兼容。老接口里有分页、有 count、有多条件组合、有排序这些在关系型数据库里是白送的在 HBase 里全要自己实现。这一点我在第三节会展开讲也是我推翻第一版设计的主要原因。想清楚这三点之后我才敢开始画架构图。顺序很重要——先想查询怎么收敛再想写入怎么保证最后才选存储。反过来做十有八九会选出一个查询能力撑不住业务的存储。2. 存储选型为什么冷数据最后落到 HBase2.1 把候选方案摆上桌逐个挑刺选型这件事最怕拍脑袋。我把当时能想到的方案列了六个每个都按我们真实的访问模式打分而不是看谁的名气大。方案一MySQL 归档表。同实例建一张结构相同的归档表冷数据挪过去。优点是改造成本几乎为零SQL 原样复用缺点是它根本没解决问题——索引还在、备份还在、连接池还在只是把一张大表拆成两张中表主库压力一点没减。Pass。方案二独立 MySQL 冷库实例。把归档表放到另一个低配实例上。这个方案在小数据量下是最省事的我们一期其实就想这么干。但按容量估算冷数据三年后会到 8 亿行左右单实例扛不住分库分表又要引入中间件运维复杂度上去了收益却只是“能查”。备选。方案三Hive / 数据仓库。离线分析场景无敌点查场景灾难。客服查一条记录要等十几秒不可接受。它更适合做对账、跑批、月末报表这个我们后来确实用上了作为 HBase 的补充而不是替代。方案四ClickHouse。列存、压缩率高、聚合快按时间范围扫的性能极好。但它擅长的是“扫一批”我们的主场景是“按单号取一条”而且 ClickHouse 的更新和点查不是强项运维上还要额外的集群。Pass。方案五Elasticsearch。多条件组合查询、模糊搜索都很舒服能解决 HBase 最大的短板。但存储成本高冷数据本身就大全量放 ES 性价比太低。我们最后把它做成了“索引层”只存关键字段不带明细这个组合后面会讲。方案六HBase。按 RowKey 点查极快、水平扩展、存储成本低、支持 TTL 和版本控制、天然适合海量稀疏数据。缺点是只能按 RowKey 高效查复杂条件查询基本抓瞎运维门槛也不低。2.2 用一张表把选型标准量化光靠文字描述容易自说自话我干脆做了一张评分表把权重也标出来。业务方看到这张表之后讨论效率高了很多。维度权重MySQL 冷库HiveClickHouseESHBase主键点查延迟30%51345多条件组合查询20%53351存储成本每 TB20%25414水平扩展能力15%25445运维复杂度越高越好10%53232与现有技术栈契合度5%53233加权得分3.853.03.153.353.65按这张表HBase 和 MySQL 冷库其实咬得很紧。最后拍板选 HBase 的决定性因素不在表里而在容量曲线MySQL 冷库在 3 亿行以内很舒服超过之后分库分表的运维成本是跳变式上升的HBase 的扩展是线性的加 RegionServer 就行对业务的感知几乎为零。我们预估冷数据三年后接近 10 亿行所以选了一条起点更陡、但天花板更高的路。这里我要多说一句选型表的价值不在于算出那个分数而在于逼所有人把权重讲清楚。当时有个争论是“多条件查询”到底占多重业务方觉得很重要运维觉得无所谓。后来我们把线上真实查询日志扒了一遍发现 87% 的请求带主键或准主键单号、流水号只有 13% 是纯条件组合而这 13% 里大部分集中在月末几天。权重一下子就从 35% 降到 20%选型的结论也就清晰了。用数据吵架比用感觉吵架有效得多。2.3 HBase 赢在哪又输在哪赢的地方很硬核。第一是按 RowKey 定位是常数级先查 Region 再查 MemStore/BlockCache最后落到 HFile路径短且可预测P99 稳定在几十毫秒。第二是存储成本可控HFile 本身就有块压缩我们实测用 SNAPPY 压缩比在 3:1 到 5:1 之间换成 ZSTD 还能再降一点同样数据量下磁盘占用只有 MySQL 的三分之一左右。第三是稀疏存储列可以动态增加老数据不需要的字段不占空间这对我们这种字段逐年加的业务特别友好。输的地方同样硬核而且每一条都得用工程手段补。短板一不能按非 RowKey 字段查。想按“用户ID 时间范围”查RowKey 里没这个组合就废了。解法是建索引表或者把常用查询维度揉进 RowKey。短板二不支持跨行事务和聚合。没有 count、没有 sum、没有 order by。我们后来把 count 改成了“预估 精确两段式”列表页只给“是否有下一页”不给总数产品经理一开始不接受看到性能数据之后妥协了。短板三分页很难受。PageFilter 在跨 Region 时行为不精确翻到后面容易出现漏数据或者重复。这块我踩得最狠第七节细说。短板四运维门槛。Region 分裂、热点、Compaction、RegionServer 内存这些都得有人盯。我们把监控面板做了两版才把关键指标捋顺。2.4 什么情况下我会劝你别用 HBase这话我得说在前面因为踩过这个坑的团队不少。如果你的冷数据总量在 2 亿行以内、单行不超过 2KB、查询条件比较固定那用 MySQL 分表 冷库实例是性价比最高的方案别为了技术先进性硬上 HBase。我见过一个团队为了“架构统一”把 3000 万行数据搬进 HBase结果多了一整套集群要维护查询性能反而因为跨服务调用变差了最后又搬回来。还有两种情况要谨慎。一是需要频繁更新冷数据的HBase 的更新本质是写新版本频繁改同一个 RowKey 会产生大量小文件Compaction 压力大二是强一致读场景HBase 读默认不是强一致的虽然单行读在多数情况下可接受跨集群复制场景下更要注意。3. 二期整体架构设计四条链路想清楚再动手3.1 数据分级规则按时间切还是按状态切分级规则是整个方案的地基定错了后面全白干。我见过三种常见切法各有适用面。纯时间切超过 N 天的全部归档。实现最简单一个定时任务扫时间范围就行。缺点是会把还在流转中的数据也搬走比如一个审批走了三个月的单子搬走之后审批人点进去就查不到了。纯状态切只归档终态数据。语义最安全但归档量不稳定某些业务线的单子可能永远不到终态越积越多。时间 状态双条件这才是生产可用的写法。我们定的规则是create_time now - 180d AND status IN (终态集合)两个条件同时满足才归档。这样既控制了数据量又避免了活跃数据被搬走。还有一个容易被忽略的细节分级规则要可配置、可灰度。我们把它做成配置中心里的一个表达式按业务线分别配置窗口天数先在小业务线上跑两周确认没问题再放开到核心业务。千万别把 180 这个数字硬编码在代码里后面调窗口的时候你会哭。提示分级规则上线前一定要用真实数据跑一遍“如果按这个规则归档过去半年会有多少条数据被搬走、其中有多少条在搬走后 30 天内被访问过”。这个反查能帮你提前发现规则漏洞我们跑出来发现有 2000 多条数据搬走后一周内就被查了全是客服工单于是把终态集合里的“待退款”状态去掉了。3.2 写入链路双写、异步补偿、离线归档三种姿势写入是冷热分离里最容易出事的地方因为写路径上多了一个不确定的依赖。三种姿势我全都试过最后选的是组合方案。姿势一同步双写。业务写热库成功后同步写冷库两个都成功才返回。一致性最好但延迟翻倍而且冷库抖动会直接传导到业务。我们压测时把 HBase 人为降速业务接口 P99 从 120ms 涨到 900ms直接否决。姿势二异步消息补偿。业务只写热库同时发一条消息到队列消费者写冷库。业务延迟不受影响但存在消息丢失和重复的风险需要做幂等。这是我们主力采用的方式。姿势三离线归档。定时任务扫热库的过期数据批量写冷库写完删热库。适合存量数据搬迁也适合作为增量链路的兜底。我们把它做成 T1 的兜底任务每天扫一遍“应该归档但冷库没有”的数据补进去。组合起来就是实时走消息、存量走离线、每天做一次对账。这个组合的关键在于对账它把前两条链路的不确定性收敛掉了。对账逻辑很简单按天统计热库中符合归档条件但仍在库的行数、冷库中当天新增的行数两个数字应该能对上对不上就告警。3.3 查询链路路由层怎么判断该查谁这是二期最核心的设计。我最终做的是一个读路由层夹在业务代码和数据源之间对外暴露的接口签名和原来完全一致。路由判断的优先级是这样请求里如果带了明确的时间范围且范围完全落在冷数据窗口内直接路由到冷库范围完全落在热数据窗口内路由到热库跨越分界线的拆成两次查询再合并。如果请求没带时间但带了主键先查热库热库没有再查冷库这个兜底查询很重要能救回那些因为消息延迟还没同步的数据。跨越分界线的合并查询是最麻烦的因为涉及排序和分页。我们的做法是两个数据源各取“offset limit”条在内存里归并排序后截取。这在深分页时会退化所以我们对这类查询做了限制——最多支持前 100 页超过就提示用户缩小时间范围。产品一开始不同意我把深分页的耗时数据甩过去第 500 页时单次查询 4 秒讨论就结束了。路由层还承担了一个额外职责降级开关。冷库不可用时路由层直接把冷数据查询转成“返回空 提示查询超时”保证主流程不受影响。这个开关在上线第二周救过一次场后面会讲。3.4 一致性与回滚冷数据的后悔药怎么留冷数据一旦删了热库的副本回滚就只能靠冷库自己。所以我们做了三层保险。第一层是冷库不删只标记。归档时给每行打一个archive_version如果发现归档规则有问题可以按版本号批量回迁不用重新从备份恢复。第二层是热库延迟删除。数据进冷库之后热库不立即删而是标记一个archived时间戳由独立任务在 7 天后物理删除。这 7 天就是后悔窗口期间任何回迁都是一条 update。第三层是快照备份。HBase 的 Snapshot 功能可以在秒级对表做快照成本极低。我们每天凌晨做一次保留 7 天。真出大事故从快照恢复比从 Hive 重导快得多。回滚操作也演练过。我让人真的执行了一次“把某天归档的 500 条数据回迁到热库”全程 3 分钟业务无感。这个演练比写十页文档都管用因为它暴露了两个隐藏问题回迁时的唯一键冲突没处理、回迁后热库的索引没重建。这俩问题在上线前修掉了。4. HBase 表设计RowKey 是命门4.1 RowKey 设计的三个硬约束HBase 的所有性能问题八成能追到 RowKey 上。我在设计时给自己定了三条硬约束违反任何一条就推倒重来。约束一必须能覆盖最高频的查询维度。我们的高频查询是“按单号查”和“按用户 时间范围查”所以 RowKey 至少要支持这两种访问模式。一个 RowKey 没法同时满足那就建两张表一张主表、一张索引表。约束二必须打散写入热点。HBase 按 RowKey 字典序分区如果 RowKey 是单调递增的比如时间戳前缀、雪花ID所有写入都会砸到最后一个 Region 上前面几十个 Region 全程围观。这个问题在批量归档时尤其致命我们第一版用的就是时间戳前缀批量导入时单个 RegionServer 的写请求队列直接打满。约束三长度要控制。RowKey 会存在每个 Cell 里太长会显著放大存储。官方建议控制在几十字节以内我们主表的 RowKey 是 32 字节左右。最终的方案是哈希前缀 业务主键 反转时间的组合。以订单明细为例RowKey 结构是hash(userId) 取前2字节 userId 反转后的createTime orderId。哈希前缀负责打散userId 保证同用户数据聚集范围查询友好反转时间让同一用户下的数据按时间倒序排列最新的在前符合列表页习惯。反转时间的写法很简单用Long.MAX_VALUE - timestamp就行。这样字典序从小到大扫拿到的就是时间从新到旧。这个技巧看着小实际很实用省掉了一次内存排序。4.2 列族、版本数、TTL 参数怎么定列族数量直接决定了写放大倍数。HBase 的 Flush 和 Compaction 是以列族为单位的两个列族意味着同样的行数会产生两倍的 MemStore 和两倍的 HFile。我们的原则是能一个列族解决就绝不用两个。主表只设了一个列族d所有业务字段都放里面。有人会问冷热字段要不要分开我们的答案是不要因为冷数据整体都是一次性读出来的分列族只会增加 IO 次数。版本数设成 1。默认也是 1但我要显式写出来防止有人后面为了“留个历史”改成 3那存储直接翻三倍。冷数据的历史版本应该由业务层的归档版本号来管不该交给 HBase。TTL 这里有个取舍。理论上冷数据要长期保留我们的合规要求是 5 年设 TTL 会导致数据自动消失。但完全不设 TTLCompaction 就没有清理依据。我们的做法是不设 TTL改用按年分表每年一张表命名带年份后缀过期表整体下线。这样既满足了保留期要求又避免了单表无限膨胀。BlockCache 和 MemStore 的比例按读写比调。冷数据是典型的读多写少归档是批量的查询是零散的所以 BlockCache 给到堆内存的 40%MemStore 给 30%剩下留给系统。这个比例不是拍脑袋是压测出来的我们把 BlockCache 从 20% 调到 40%点查 P99 从 45ms 降到 18ms效果非常明显。注意MemStore 不要给太大。单个 MemStore 越大Flush 时的停顿越长而且 Region 分裂的触发点也会变。我们一开始给了 40%结果 RegionServer 的 GC 停顿明显变长调回 30% 就正常了。4.3 预分区与压缩上线前必须做的两件事预分区这事不做就是给自己埋雷。新建表默认只有 1 个 Region所有写入全打在这一个上等它涨到 10GB 才分裂中间这段时间性能是灾难级的。我们建表时按 RowKey 的哈希前缀直接预分 32 个 Region写入瞬间就打散了。预分区的 split keys 要跟哈希前缀对齐。如果前缀是 2 字节那 32 个 Region 就按哈希值的高位均匀切。计算方法是把哈希值的字节范围均分比如 0x00、0x08、0x10……一直到 0xF8。这里一定要确认哈希函数分布均匀我们用的是 MurmurHash实测 32 个桶的偏差在 5% 以内。压缩也不能省。HFile 的块压缩对冷数据效果极好因为冷数据的重复度高、字段长、JSON 快照多。我们在测试环境对比过不压缩 300GBSNAPPY 压缩后 92GBZSTD 压缩后 71GB。ZSTD 的 CPU 开销比 SNAPPY 高一些但冷数据写入量小、读取也不频繁这点 CPU 完全可以接受。最终选的是 ZSTD。还有一个开关容易被忘布隆过滤器。点查场景下开ROW级别的布隆过滤器能把不存在的数据直接挡在 HFile 之外减少无效 IO。我们的点查里有一部分是“查了但不存在”开了之后这类请求的延迟从 12ms 降到 2ms。4.4 一份可落地的表结构示例把上面的结论落成具体配置大概是这样建表语句我用伪代码写不同发行版语法略有差异表名: order_detail_archive_2024 RowKey: hash2(userId) userId(16) (Long.MAX_VALUE - createTime)(8) orderId(12) 列族: d 属性: VERSIONS 1 COMPRESSION zstd BLOOMFILTER ROW BLOCKCACHE true BLOCKSIZE 65536 IN_MEMORY false DATA_BLOCK_ENCODING FAST_DIFF 预分区: [0x00, 0x08, 0x10, ..., 0xF8] 共 32 个 无 TTL按年分表列族里的字段设计上我做了两个决定。一是把高频检索字段冗余进去比如状态、金额、创建人避免为了拿一个状态再去查一次明细二是把大字段单独放一个 qualifier比如d:snapshot读取时用addColumn精确指定不读这个列就不会产生 IO。HBase 是按列族读的但指定了 qualifier 之后Filter 层能跳过不含该列的 HFile block实际效果接近按列读。这套配置上线后跑了三个月单表 2.1 亿行平均点查延迟 15msP99 38msRegion 数量稳定在 40 个左右没有出现热点。5. 迁移实操从存量到增量的完整流程5.1 存量数据离线迁移的步骤与校验存量迁移是最耗时的环节也是最容易翻车的地方。我把它拆成了六步每一步都有验收标准。第一步容量评估。从热库统计符合条件的行数、平均行宽、大字段占比估算出压缩后的存储量。我们算出来是 1.8 亿行、平均 1.2KB、压缩比 3.5:1实际占用约 620GB加上三副本和预留申请了 2TB。第二步建表并预分区。就是上一节那套配置建完先灌 10 万行测试数据验证 RowKey 分布是否均匀看每个 Region 的 storefile 大小是否接近。第三步小批量试导。取 100 万行用 BulkLoad 方式导入。这里强烈建议用 BulkLoad 而不是逐条 Put——BulkLoad 直接生成 HFile 再挂到表上绕过了写路径不占 MemStore、不触发 Flush速度能快十倍以上。100 万行大概跑了 4 分钟。第四步全量导出导入。按天分批每天一批每批导入完做一次校验。分批的好处是出问题只影响一天不用全量重来。全量 1.8 亿行跑了大约 6 小时。第五步数据校验。这一步不能省。我们做了三层校验行数对账源表 count vs 目标表 count、抽样字段比对随机抽 1 万条逐字段比对、关键字段聚合对账按天统计金额总和两边比对。三层都过才算完。第六步确认无误后标记热库归档。注意这里只是标记不是删除物理删除要等 7 天。5.2 增量同步怎么写才不漏增量部分走的是消息链路核心是幂等和顺序两个问题。幂等好办HBase 的 Put 本身就是按 RowKey 覆盖同一条数据重复写多次结果一样。但要注意时间戳——如果启用了自定义时间戳重复写入可能产生多版本我们用默认时间戳VERSIONS1重复写会覆盖天然幂等。顺序问题麻烦一些。同一条数据如果先收到“更新”再收到“创建”最后的状态就不对。我们的解法是在消息里带上数据的更新时间戳消费时先读冷库当前行的版本如果消息里的时间更早就直接丢弃。这多了一次读但保证了最终状态正确。还有一个坑是消息积压。归档任务是批量触发的一次可能产生几十万条消息消费端如果处理不过来就会积压。我们给消费端做了限流和批量提交攒够 500 条或者等 200ms 就批量 Put 一次把写请求合并吞吐从 2000 TPS 提到了 15000 TPS。5.3 灰度与开关设计灰度这件事我坚持做成了四级开关从粗到细都能控。第一级是业务线开关控制哪些业务线的数据参与冷热分离。先开一个小业务线跑两周。第二级是读开关控制读请求是否允许路由到冷数据。这个开关是独立于写开关的意思是数据可以先归档过去但读还是走热库此时热库还没删相当于双读验证。第三级是写开关控制热库数据是否物理删除。这个开关打开之前热库数据一直保留随时能退。第四级是单请求级别的降级就是 3.3 节说的那个降级。这四级开关的组合使用顺序是先开写归档但不删→ 开读路由到冷库→ 双读对账跑一周 → 关双读、开删。整个过程大概三周比预想的长但一次事故都没出。5.4 双读对账怎么验证冷库真的对双读对账是我认为整个方案里性价比最高的一个设计。做法很简单读开关打开后前一万个请求同时查热库和冷库比对结果不一致就记日志。这个对账帮我们抓到三个问题一是某个字段在归档时漏了代码里 if 分支写错了二是时间戳精度丢失导致排序不一致热库是毫秒冷库存成了秒三是有一条数据在冷库里查不到消息消费失败但没重试。第三个问题最值得说。它是这么暴露的对账发现某条数据的冷库查询返回空但热库有。顺着查下去发现是消费端在处理某类消息时抛了异常异常被 catch 住了但没重试。如果没有对账这个问题要等到用户投诉才会被发现。后来我们加了消费失败自动重试三次 死信队列这个问题就再没出现过。对账跑了一周前一万个请求的不一致率从 0.3% 降到 0.002%我们才敢开删。6. 查询改造老接口怎么无感切换6.1 分页查询在 HBase 里为什么是个坑这是整个二期最让我头疼的地方也是我推翻第一版设计的原因。关系型数据库的分页是LIMIT offset, size语义清晰。HBase 的 Scan 虽然也有setStartRow和setLimit但它的语义是“从某个 RowKey 开始扫 N 条”没有 offset 的概念。HBase 自带的 PageFilter 看着像分页实际行为是“每个 Region 单独计数”跨 Region 的时候计数会不准翻几页就开始出现数据缺失或重复。我第一版设计用的是 PageFilter测试环境数据少看着没问题。压测时用真实数据量一跑第 20 页就开始漏数据第 50 页的漏数据率到了 30%。这个问题如果上线业务方会直接炸锅。最终的方案是游标分页前端不传页码传上一页最后一条的 RowKey加密后后端从这条 RowKey 之后扫 limit1 条多取的那一条用来判断“还有没有下一页”。这样无论翻到多深每次查询的代价都是恒定的。这个改造对前端是有影响的需要把“页码组件”换成“加载更多”或者“上一页/下一页”。我们和产品沟通了两轮用“深分页性能对比”的数据说服了他们改造前第 100 页要 8 秒改造后稳定在 40ms。提示如果业务方死活要页码可以做折中——前 10 页用 offset 转 RowKey 的方式算起始位置需要先缓存每页的起始 RowKey10 页之后只给“下一页”。这个方案我们做过一版复杂度高不少最后没采用。6.2 二级索引的三种补法HBase 只认 RowKey那 13% 的非主键查询怎么办我们试了三种补法最后是三种混用。补法一建索引表。单独建一张表RowKey 是“查询维度 原表 RowKey”值里只存原表 RowKey或者干脆什么都不存RowKey 自带。查询时先查索引表拿到主键再回原表取明细。这是最经典的做法写入时要同步维护索引表成本是双写。补法二把维度揉进 RowKey。如果某个查询维度是固定的比如按商家查可以直接把商家 ID 作为 RowKey 的一部分牺牲一点写入打散效果换取查询能力。我们主表的 RowKey 其实已经揉进了 userId就是这个思路。补法三ES 做二级索引。把关键字段同步到 ES复杂条件查询先走 ES 拿主键列表再回 HBase 取明细。这个方案最灵活能支持模糊匹配、多条件组合、聚合统计但引入了新的组件和数据同步链路。我们的实际组合是单号查询走主表 RowKey用户维度查询走主表里的 userId 前缀商家维度、状态维度、金额范围这些走索引表报表类的复杂条件走 ES。三种方式各有各的适用面关键是想清楚每个查询的 QPS 和延迟要求QPS 高的走 RowKeyQPS 低的走 ES中间地带用索引表。6.3 汇总统计类查询怎么办COUNT(*)、SUM(amount)、GROUP BY status这些在 MySQL 里白送的在 HBase 里全要自己算。我们的策略是分级处理。列表页的“共 N 条”改成“是否有下一页”彻底去掉 count。这是最有效的一刀省掉了最贵的查询。必须给总数的场景比如财务报表走预聚合每天凌晨跑批把各维度的统计数据算好写进一张小的汇总表查询时直接读汇总表。代价是数据延迟一天财务场景能接受。实时的、临时的统计需求走ES 或 Hive。ES 的聚合性能在大数据量下也不差Hive 适合跑批。HBase 在这类查询上直接放弃不做无谓挣扎。这个分级策略我跟业务方讲了很多遍核心观点是冷数据的查询能力本来就是要打折的关键是打掉哪些、保留哪些这个必须提前和业务方对齐。最怕的是方案都上线了业务方才发现某个查询不能用了那时候改起来成本极高。7. 线上真实踩坑记录与排查手册7.1 常见问题速查表下面这张表是我从三个月的告警记录里整理出来的按出现频率排序。现象可能原因排查手段处理办法点查延迟从 15ms 涨到 300msRegion 热点或 Compaction 堆积看 RegionServer 的 compactionQueueSize、各 Region 的请求分布手动 major compact 或调整预分区查询返回空但数据明明存在消息消费失败、归档任务漏跑对比热库和冷库的对应行看归档日志手动补录检查消费端异常日志写入 TPS 突然掉到十分之一MemStore 打满触发频繁 Flush看 memStoreSize、flushQueueLength降低单批写入量或扩容 RegionServer深分页第 N 页开始数据重复PageFilter 跨 Region 计数不准用同一个起始 RowKey 反复扫看返回是否稳定改游标分页RegionServer 频繁 GC堆内存分配不合理BlockCache 过大看 GC 日志和堆内存分布调小 BlockCache或拆分 RegionServer归档任务跑不完超时单批数据量过大看任务日志的批次耗时缩小批次按天甚至按小时切分同一 RowKey 查到多条记录VERSIONS 被改成了大于 1检查表的列族配置改回 1并做一次 major compact7.2 三个我踩过的坑每个都值一个通宵坑一时间戳精度丢失导致排序错乱。热库里 createTime 是毫秒我在写 HBase 时为了省空间存成了秒。结果同一秒内的多条数据排序不稳定列表页每次刷新顺序都不一样。这个问题很隐蔽因为大部分时候看着是对的只有同一秒有多条数据时才暴露。后来改成存毫秒RowKey 长度多了 4 字节存储成本涨了不到 1%值。坑二批量导入把集群打挂。第一次全量迁移我用的是逐条 Put没有限流。跑起来十分钟之后RegionServer 的写队列打满整个集群的读请求也开始超时因为读写共用同一个队列。最后是紧急停掉任务、重启集群才恢复。教训是批量导入一定要限流而且最好走 BulkLoad。后来我加了 5000 TPS 的限流配合 BulkLoad同样的数据量对线上几乎零影响。坑三降级开关的默认值写反了。这个坑最丢人。降级开关的语义是“开启降级”我写成了if (degradeSwitch) { 正常查询 }逻辑反了。上线第二天冷库有个 Region 短暂不可用降级开关被自动打开结果所有请求都去打那个不可用的 Region雪崩了三分钟。后来我们加了开关的单元测试并且把所有开关的语义统一成“开关为 true 表示关闭某能力”。7.3 监控告警要看哪几个指标监控面板我改了两版最后收敛到八个核心指标多了看不过来少了抓不到问题。第一组是延迟类点查 P99、扫描 P99、写 P99。这三个是业务最直观的感受。第二组是容量类Region 数量、单 Region 最大 storefile 大小、HFile 数量。Region 数量突然暴涨通常意味着分裂异常HFile 数量过多意味着 Compaction 跟不上。第三组是资源类RegionServer 堆内存使用率、BlockCache 命中率、Compaction 队列长度。BlockCache 命中率掉到 80% 以下就要警惕了通常是某个大 Scan 把缓存冲掉了。第四组是业务类归档任务成功行数、消费失败消息数、双读不一致率。这三个是业务链路的健康度。告警阈值这块我的经验是别设太敏感。一开始 P99 超过 50ms 就告警一天几十条很快就没人看了。后来改成 P99 超过 200ms 才告警配合持续 5 分钟的判定告警量降到一周两三条每条都是真问题。8. 上线节奏与容量规划8.1 分阶段推进的时间表整个二期从设计到全量上线我排了六周实际用了七周。多出来的一周全花在对账和问题修复上这个预留非常必要。第一周做方案设计和评审把四个核心问题的答案写进文档拉上业务方、DBA、运维一起过一遍。这周最重要的产出是那张选型评分表和分级规则。第二周做表设计和迁移工具开发包括 BulkLoad 脚本、校验脚本、对账脚本。这周可以在测试环境把全流程跑通。第三周做读路由层和查询改造这是代码量最大的一周。重点是游标分页和索引表查询。第四周做小流量灰度选一个日增数据量小的业务线全流程跑一遍。第五周放开到主要业务线做双读对账修问题。第六周开物理删除观察一周。第七周收拾残局补文档、清理临时脚本、把监控面板交接给运维。8.2 容量估算的具体算法容量算不准申请资源的时候要么不够要么浪费。我用的算法是这样以我们的订单明细为例。先算原始数据量1.8 亿行 × 平均行宽 1.2KB 216GB。这个行宽是包含所有字段的包括几个大的 JSON 快照字段。再算压缩后按 ZSTD 实测压缩比 3.5:1216GB ÷ 3.5 ≈ 62GB。然后算副本HBase 默认三副本62GB × 3 186GB。再算写入放大Compaction 过程中会有临时的文件膨胀一般按 1.3 倍预留186GB × 1.3 ≈ 242GB。最后算增长按每月新增 3000 万行、年增长 25% 估算三年后总量约 4.5 亿行对应约 600GB 有效数据、1.8TB 三副本、2.3TB 含放大。所以申请了 3TB。这个算法里有一个容易漏的点索引表也要算容量。索引表虽然只存 RowKey但行数和主表一样RowKey 长度加上开销大概是主表的 15%。我们一开始忘了算导致第一批资源申请少了。8.3 上线检查清单最后给一份我实际用的检查清单上线前逐项打勾能挡掉大部分低级失误。分级规则的表达式在配置中心可改且有默认值兜底表的预分区数量与 RegionServer 数量匹配建议 2 到 3 倍压缩算法、布隆过滤器、VERSIONS 全部显式配置不依赖默认归档任务有批次大小限制和失败重试重试次数不超过 3 次消费端有幂等逻辑、有死信队列、有限流读路由层的降级开关语义经过测试默认值是“不降级”深分页已改为游标分页或至少限制最大页数双读对账已跑通不一致率低于 0.01%热库物理删除有 7 天延迟且延迟任务可暂停冷库表有每日 Snapshot保留 7 天监控面板八个指标全部配好告警阈值经过一轮调优回迁脚本演练过一次全程耗时在可接受范围内业务方已知悉冷数据查询的能力边界无 count、深分页受限、复杂条件走 ES这份清单里我觉得最容易被跳过的是最后一条。技术上做得再完善如果业务方不知道“这个查询变慢了是设计如此”那上线之后还是一堆工单。我当时的做法是给业务方做了一次半小时的宣讲把冷热分离的原理、哪些查询会受影响、受影响之后怎么办全讲了一遍还留了一份答疑文档。这半小时省掉了后面大概两周的扯皮。我个人在实际推进这个项目的过程里最大的体会是冷热分离的难点从来不在 HBase 本身。HBase 的表设计、预分区、RowKey网上资料一大把照着抄基本不会错。真正耗时间的是那些边界情况——一条数据归档了但业务方还要改、一个查询跨越了分界线、一个开关的默认值写反了。这些事情没有现成答案只能靠提前想、靠对账兜、靠灰度试。如果让我重来一次我会把更多时间花在“和业务方对齐查询能力边界”以及“把回滚路径真的跑一遍”上而不是花在调 HBase 参数上。另外分享一个小技巧归档任务上线前先跑一次「只统计不执行」的演练模式把所有会被归档的数据行主键打到日志里然后拿这份日志去比对最近一个月的访问日志看看有多少条是刚归档就被访问的。我们跑出来有 2000 多条全是客服在查历史工单于是把客服常用的几个查询加进了白名单让它们强制走热库。这个小动作把上线首周的咨询量压到了个位数。
