前阵子陪一位做数据平台的朋友聊新系统选型，备选名单里躺着一对熟悉的名字：HBase 和 TiDB。我上来没急着做对比，先问了一句话：你们到底想解决什么问题？对方回答：既要秒级响应的分布式实时写入和查询，又想顺手在同一份数据上跑点聚合分析。这两个需求一撞车，本质上就是在问 HTAP 数据库怎么选。选型讨论到这一步才有意思——HBase 和 TiDB 虽然都顶着“分布式存储”的帽子，但血统、架构、开发心智完全不是一个物种。很多团队在这两个方案之间反复横跳，不是因为某个数据库不行，而是用错了比较维度和场景预设。这篇文章我想从平时帮团队做选型评审的角度，把它们背后那层逻辑拆开讲清楚，顺带把我这些年见过的方案、踩过的坑、压测过的配置都摆出来，给正在犹豫的朋友一个可落地的参考。
1. 第一条分水岭，藏在数据模型里
1.1 HBase的底层真相：LSM树与稀疏宽表
HBase 出身于 Hadoop 生态，它本质上不是一个“数据库”，而是一个分布式键值存储系统。你往 HBase 里写一条数据，核心操作就是 Put 一个 rowkey 对应的一个或多个列族字段，读数据也是 Get 这个 rowkey，或者 Scan 一段 rowkey 范围内的记录。它的存算结构用 LSM 树实现，写入先落内存中的 MemStore，攒到一定阈值再刷成不可变的 HFile 文件，后台再做多层级合并。这个机制可以用一个生活类比理解：记手账的时候先拿草稿纸快速记，等草稿纸写满再往正式本子上誊，本子多了就按日期合并整理。这样做的好处是写入路径上几乎没有随机磁盘IO，顺序追加占绝对主导，所以 HBase 面对极高吞吐的写入场景非常能打。
能力边界也藏在设计里：HBase 的查询能力强依赖 rowkey 的设计。rowkey 前缀一旦覆盖不了查询条件，Scan 就会演变成全表扫描。官方文档里讲的数据访问模型就是 get、multi-get、scan 三种，想按非 rowkey 字段查询，只能自己搭二级索引或者引入 Elasticsearch 之类的组件做辅助检索。列族是逻辑分组，不是关系模式里的“字段约束”，稀疏表是默认形态，某一行今天写入5个列明天写入10个列毫无压力，这和关系型数据库的 schema 是两种世界观。
1.2 TiDB的底层真相：分布式SQL与行存引擎
TiDB 走的是另一条路线。它对用户暴露的是 MySQL 兼容协议，你写 DDL、DML 都跟平时用 MySQL 一样，SQL 层接到请求后会做解析、优化、生成执行计划，再把任务下推到分布式的 TiKV 存储引擎。TiKV 底层虽然也依赖 RocksDB 这类 LSM 存储，但往上是按 Raft 协议做多副本强一致的 Region 分片，每个 Region 通过 Raft 同步日志保证数据不丢，Region 又会根据数据量自动分裂或调度到不同节点。这套设计保留了 HBase 那种“容量横向扩展能力强”的优点，同时补上了关系模型、事务和完整索引能力。
TiDB 的事务模型采用 Percolator 的两阶段提交思路，提供快照隔离级别下真正的分布式事务。对开发团队来说，这意味着可以像写 MySQL 一样写带事务的业务系统，账户扣款、订单状态流转这类强一致场景，在 HBase 方案里得呕心沥血去设计补偿逻辑，在 TiDB 里只要把 SQL 写对就行。TiKV 之上还叠加了 TiFlash 列存储副本，分析类查询可以自动路由到列存副本，这就是后面我会专门展开的 HTAP 能力基础。
1.3 数据模型选择决定了团队日常的开发心智
我见过不少团队从 HBase 迁移到 TiDB 以后，最明显的感受不是性能提升多少，而是“开发终于像个人样了”。在 HBase 里做业务，先要想清楚 rowkey 怎么编码、前缀要不要倒置、要不要用 salt 做分区散列、二级索引怎么同步到外部组件，光维护索引一致性就是一堆调度任务。在 TiDB 里做同样的事，主键、普通索引、唯一索引、复合索引随便建，执行计划直接看 EXPLAIN，想分析数据还能直接跑 MPP 模式聚合。模式差异带来的开发效率不在一个量级。
但这并不意味着 HBase 就没价值了。HTAP 这个被追问最多的话题，继续往下拆才能真正分出它们的适用边界。
2. “HTAP”这个词，听着好听，落地处处是博弈
2.1 为什么HTAP这么难实现
HTAP 的意思是系统能同时承载事务型处理和分析型处理。难在哪？事务型场景要求毫秒级低延迟，分析型场景是海量数据的大扫描和聚合，两者对资源的消耗方式完全相反。一个查询框架要同时满足在线业务和离线分析，最简单粗暴的思路是把数据双写进两套系统， OLTP 用业务库、OLAP 用数仓，中间再搭 ETL/数据管道。这个方案成熟但延迟高，实时性上不去。HTAP 的卖点就是消灭这个“管道延迟”，让分析直接跑在新鲜数据上，同时不让大查询拖垮在线事务。
但如果只在一套系统里做两件事，资源隔离、并发控制、查询路由都是绕不开的硬骨头。查一个十亿行的聚合如果占满 CPU，正常业务请求的延迟马上恶化。真正的 HTAP 架构必须在引擎层面做区分，而不是简单让一套计算引擎“既支持小查询又支持大查询”。
2.2 TiDB的HTAP落地逻辑：一套数据，双引擎协作
TiDB 的做法是把行存储副本和列存储副本放在同一个集群里。行存副本（TiKV）负责在线事务，列存副本（TiFlash）以异步复制的方式从 Raft 日志同步数据，弥补实时性，同时承担分析查询。TiFlash 的存在让大聚合查询不会挤占 TiKV 的 CPU 和 IO，系统会根据 SQL 优化器自动判断是否将查询下推到列存副本，或者在列存与行存之间做代价估算，选择合适的执行路径。同一份逻辑数据，物理存储上兄弟分工，互不阻塞。
这个方案的工程代价是磁盘和内存多占一份，但对实时分析需求的收益非常直接：业务写入完成后，延迟极低，分析就能看到数据。相比“业务库到数仓”那个全套管道链路，维护成本直线下降。很多团队选 TiDB 的理由不是“性能绝对碾压”，而是“复杂度可以被系统消化掉”。
2.3 HBase在HTAP版图里的真实位置
HBase 本身更像一个高性能实时写入与点查存储层，自带 HTAP 能力很弱。你能在 HBase 上很轻松地做到高并发 Put 指定 rowkey 的详情数据，但想跑几个表之间的 join、做按月汇总的 group by 聚合，直接操作 HBase 原生 API 基本无从下手。现实中的 HBase HTAP 方案通常长这样：用 HBase 存实时写入的明细数据，用 Elasticsearch 同步建索引做检索，再用 Spark/Flink 定期读 HBase 做批计算或流计算，把聚合结果落到另一套查询服务里。
烟囱式的组件堆叠不是不行，我在很多公司见过跑得很稳的架构，但每加一个组件就多一份副本一致性负担。上游写入抖动、同步任务重放、索引字段变更，一个环节出问题都可能导致查询结果和明细对不上。团队如果只有三五个人，光是维护组件间数据链路就要耗费大量精力。
2.4 什么业务才会认真追问HTAP
最典型的一个场景是某游戏运营数据分析平台：玩家行为日志要实时写入，运营后台要看今日实时在线、拉取指定用户的行为明细、按渠道和版本聚合指标查询。以前我这个任务典型的选型组合是 HBase 落明细 + Elasticsearch 做检索 + Flink 做实时聚合，三套系统协同，架构图上画得密密麻麻。如果换用 TiDB 做明细存储和实时轻度聚合，同时上 TiFlash 做分析副本，链路至少砍掉一半，写一个 SQL 就能同时拿到明细和聚合结果，运营提个新需求也不用陪着改管道。
不过也要清醒：TiDB 的 HTAP 适合“实时业务+轻度分析”，如果一个查询要跑几分钟、处理PB级历史数据，那 TiFlash 也不是万能钥匙，更应该直接进离线数仓。HTAP 解决的是实时性和查询复杂度之间的最优平衡，大而全的历史分析不该由它背锅。
3. 正面硬刚：HBase和TiDB核心能力实测对比
3.1 查询能力和SQL支持，差距比想象中大
HBase 原生查询就是 Get 和 Scan。Get 按 rowkey 做点查，速度很稳定，Scan 可以指定 startRow 和 stopRow 做范围扫描，但只能在 rowkey 前缀上做高效过滤。你把 rowkey 设计成userId_reverse + timestamp，那按用户维度扫他的历史记录就很快；想按订单号、设备ID、地域维度去查，必须全表 Scan 或者带 Filter，数据量一大就是灾难。HBase 没有 join、没有 group by、没有子查询，想在 SQL 层面补救可以部署 Phoenix，但它也只是在 HBase 上封装了一层 SQL 解析器和二级索引实现，遇到复杂关联查询和大聚合时同样力不从心。
TiDB 这边是完整的关系模型。索引体系包括主键、普通索引、唯一索引、复合索引和覆盖索引，SQL 解析、执行计划优化、算子下推这些能力全部内置。TiDB 的 MPP 模式是分析查询的加速器：优化器会把聚合、连接操作拆分到多个节点并行执行，然后汇总结果。我们之前压测过一千万行数据的聚合查询，TiDB 在 HBase + 手工实现聚合方案面前，从查询开发效率和执行耗时的综合表现都要好不少。查询能力这项，两者很清楚不在同一赛道。
3.2 事务和一致性，一个可以用，一个想用要用命换
HBase 的原子性只提供到行级别：同一行的多个列更新是原子的，跨行跨表操作则完全没有原生事务保障。要在 HBase 上做“写订单+扣库存+写流水”三个动作的原子性，只能靠客户端代码自己包装、自己回滚，一旦某一步失败，补救逻辑极其痛苦。TiDB 内置完整分布式事务，ACID 特性在多种 Raft 副本上落得扎实。快照隔离保证了并发事务互不干扰，时间戳分配、锁管理和提交协议都由系统完成。
这一条对很多业务是决定性的。订单、支付、账户、库存这类需要强一致的应用，我几乎不会考虑 HBase 当主存储。相反，日志明细、事件流水、用户行为轨迹这类允许最终一致、覆盖写或追加写的数据，HBase 的事务短板就无关痛痒。换个角度总结：你需要强一致变更事务就选 TiDB，只需要高性能写入的流水场景优先看 HBase。
3.3 扩展能力和读写模型，各有各的玩法
HBase 的扩展性来自 Region 自动分裂。一个 Region 数据量超过阈值就分裂成两个，新 Region 会被 RegionServer 自动平衡到集群各节点。整个 HBase 集群可以轻松跑到数百台规模，每台机器在垃圾回收参数调优到位的情况下，写入吞吐非常惊人。我以前给一个告警监控系统搭过 HBase 集群，6台节点能稳定吞下每秒几十万条告警写入，在线查询按告警ID点查也稳定在两毫秒左右。这个性能表现，TiDB 的默认配置不一定能直接复现，TiDB 需要小心设计主键和表结构，避免热点分片。
TiDB 的横向扩展靠 TiKV 的自动分片调度，容量和性能都是线性增长。但 TiDB 要处理 Hot Region 问题：如果你的表主键是自增 ID，写请求全部落在尾部 Region，热点就来了。解决方案包括让主键变成随机 ID、用 SHARD_ROW_ID_BITS 打散隐式主键、业务层面做 hash 分片。HBase 也有写入热点问题，处理思路更多依赖 rowkey 加盐或反转前缀。这个维度的对比总结就是，两者都能水平扩展，但 HBase 把应对热点的工具交给应用层，TiDB 也要求开发者懂一点存储分布原理才行。
3.4 生态和运维，不是小问题
生态这块，HBase 和 TiDB 都不想输但赢在不同方向。HBase 是 Hadoop 生态的御用存储，和 Hive、Spark、Flink 的集成非常顺滑，需要跑批分析时可以非常方便地把 HBase 数据作为数据源喂给计算引擎。TiDB 在 MySQL 生态上做文章，MySQL 协议意味着几乎所有 ORM 框架、数据库管理工具、监控系统都能无痛接入，数据迁移和同步工具有配套的 CDC、导入导出组件。餐厅类比举一个：HBase 像生鲜批发市场，供给能力强，但是买回去要自己加工烹饪；TiDB 像半成品净菜，拿到就能直接下锅，想吃预包装味道还得自己做点搭配。
4. 选型决策：不是比好坏，而是比对复杂度的控制能力
4.1 一张决策检查表，直接对照打分
把选型维度摊开看，能过滤掉大部分空对空的争论。我习惯用一张检查表让团队逐项打钩：
| 维度 | HBase | TiDB |
|---|---|---|
| 数据模型 | 分布式KV，稀疏宽表 | 分布式关系型，完整SQL |
| 查询能力 | Get/Scan，依赖rowkey设计，无join | SQL，索引完整，支持MPP分析 |
| 事务能力 | 行级原子性 | 分布式ACID，快照隔离 |
| HTAP | 基本不具备，需自己搭组件 | 行存+列存副本，实时分析可用 |
| 开发效率 | 低，需设计rowkey和外部索引 | 高，兼容MySQL心智 |
| 扩展性 | Region自动分裂，成熟稳定 | TiKV自动分片，需防热点 |
| 生态集成 | Hadoop生态顺手 | MySQL生态顺手 |
| 运维成本 | 组件多，链路复杂 | 集群自包含，组件相对少 |
这张表的结果不会告诉你“哪个好”，但会告诉你“你愿意接受哪边的复杂度”。HBase 把复杂度藏在开发层，TiDB 把复杂度消化在系统层。团队能力强不强，决定这些复杂度落到谁能承担。
4.2 该选HBase的典型画像
适合 HBase 的场景往往有几个特征：需要海量实时写入，数据以键值为主，查询模式固定且能预知，基本只需要按主键读取，对跨行事务没有要求。典型业务包括：用户行为日志、IoT 设备上报数据、推荐系统的特征存储、爬虫抓取结果的存储层、监控指标的时间序列数据。这类场景还有个普遍特点：rowkey 可以提前设计好，查询需求基本不超过三种前缀模式，团队里通常有 Java/Hadoop 系工程师，愿意投入精力编写客户端或封装模块。
4.3 该选TiDB的典型画像
适合 TiDB 的场景是业务系统类：用户中心、订单系统、账户系统、配置中心、在线交易平台。这类系统要求的核心是关系模型、事务、实时一致性，还需要灵活查询和运维扩容。当 MySQL 集群拆库拆表拆得心累，或者需要跨库 join 和异地多活能力时，TiDB 是迁移的好去处。另外，如果一个团队想做“实时写入+供运营查询的分析”但没有额外人力搭建 HBase + ES + Flink 链路，TiDB 的单集群模型能显著降低系统架构复杂度。
4.4 混合架构的真实答案，远比单选题好看
有的系统复杂到我真不建议非此即彼。某个业务里既有海量日志流，又有在线交易需求，完全可以两套并存：TiDB 承载业务数据，支撑在线事务和实时分析；HBase 扮演明细归档层，接收超高吞吐的审计日志与埋点，被分析时再通过固定任务把关键字段同步到 TiDB 或数仓。分布式世界的关键是数据路由加复制链路，而不是把所有数据硬塞进一个系统里。我见过不少最终演变成混合架构的团队，它们都有一个共同点：数据流图画的极其清晰，每个系统知道自己只负责哪一段，没有模糊地带。
5. 迁移和实操中踩过的那些真实坑
5.1 把HBase的rowkey设计习惯带进TiDB，捅出热点
有一个团队从 HBase 迁 TiDB，表主键直接沿用了 HBase 里的userId_reversed + timestamp格式。结果业务一上线，TiKV 集群出现明显热点，所有写请求都集中在少数几个 Region 上。排查时我们分析后发现根因是主键前缀分布不均：userId 反转后高位仍然是部分 userId 区间占优，加上 timestamp 在高并发下几乎同时，hash 打散效果很差。解决办法改成业务 ID 做 64 位 hash 主键，同时启用SHARD_ROW_ID_BITS=4将隐式主键打散到16个分片，热点消失，写入吞吐稳定提升数倍。这个坑提醒所有迁移团队：TiDB 兼容 MySQL 协议，但物理分布原理和 HBase 非常相似，随意的表结构设计照样会导致分片倾斜。
5.2 对TiDB分析能力过分乐观导致生产事故
另一个典型错误是看到 TiDB 有 TiFlash 就以为能跑全量数仓。某团队把6亿行历史数据直接放进 TiDB，然后让业务同事在上面跑十几个维度的自由交叉分析，结果列存副本 CPU 持续飘高，实时交易延迟被拖到秒级。复盘时我把过滤条件拆开看了看，发现大部分查询没有可下推的空间，优化器被迫把大量数据拉上计算节点，把在线资源浪费在大扫描上。调整动作分两步：一方面将分析查询路由到专门的一套 TiDB 集群（业务和分析环境物理隔离），另一方面把固定报表的预聚合任务放入独立数仓，TiDB 只负责 T+0 的实时明细查询。这个案例告诉我，HTAP 是定位成“轻分析”，不是“全量分析”的万金油方案。
5.3 从TiDB回看HBase的客户端设计，迁移要双跑
做跨系统迁移时最怕只盯着“迁移完成那一刻”。稳妥做法是并行运行至少两周：新老系统同时写入，双跑任务做全量+增量数据校验，比对不一致时以源库为准回放增量，直到连续几天偏差为零再切换读流量。我们迁移一个订单中心时还做了回滚预案：在双跑期间保留旧集群的写入口，切流后发现 TiDB 某类查询慢，立刻回切到 HBase 的旧方案，应用侧改动只有配置中心一个开关切换，全程没有给用户造成可见影响。HBase 迁移到 TiDB 本身不难，难的是在两层系统之间设计好对账任务和容灾开关。
5.4 备份、监控、压测，忘一件就等着深夜救火
无论选 HBase 还是 TiDB，日常运维绝不能靠默认配置走天下。HBase 要关注 MemStore 刷写参数、HFile 合并策略、RegionServer 的 JVM 堆大小和 GC 日志；TiDB 要关注 Region 大小阈值、TiFlash 副本数量、GC 时间窗、TiKV 线程池大小等。建议在压测阶段把所有关键参数跑一遍，用类似生产规模的数据量和并发量做基准测试，不要拿一条 select 1 当测试用例。备份方面，HBase 一般配合 Snapshot 和 HDFS 复制，TiDB 用 BR 工具做备份恢复，恢复速度要定期演练。监控指标以 HBase 为例优先看 RegionServer 读延迟、写队列长度、Region 数量，TiDB 则优先看 TiKV 的 CPU 使用率和写入延迟、TiFlash 的同步滞后量。
6. 最后说一点个人的感受和建议
前前后后陪不同团队做过不少次 HBase 和 TiDB 的选型评估，我最大的体会是：比的从来不是“谁比谁强”，而是“谁更能驾驭哪种复杂度”。HBase 把复杂性丢给了应用层和运维层，但它给了你极致写入性能和成熟生态；TiDB 把复杂性吃进了系统内部，用分布式事务和 HTAP 引擎换来了关系模型和开发效率。站在技术选型角度，两者都不是完美的，完美从来不在选项里，只在你对业务的理解里。
最后再分享一个小技巧：无论最后选了谁，上线前都做一轮为期一周的全链路压测，专门验证“写入峰值+在线查询+分析查询”三种负载同时发生的表现。很多团队上线后翻车，都是因为在测试环境只压了其中一两种负载，没模拟真实业务的混合场景。数据库没有万能选项，把每种负载的表现摸透，比看十篇评测文章更有说服力。
