前阵子陪一位做数据平台的朋友聊新系统选型备选名单里躺着一对熟悉的名字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 一张决策检查表直接对照打分把选型维度摊开看能过滤掉大部分空对空的争论。我习惯用一张检查表让团队逐项打钩维度HBaseTiDB数据模型分布式KV稀疏宽表分布式关系型完整SQL查询能力Get/Scan依赖rowkey设计无joinSQL索引完整支持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_BITS4将隐式主键打散到16个分片热点消失写入吞吐稳定提升数倍。这个坑提醒所有迁移团队TiDB 兼容 MySQL 协议但物理分布原理和 HBase 非常相似随意的表结构设计照样会导致分片倾斜。5.2 对TiDB分析能力过分乐观导致生产事故另一个典型错误是看到 TiDB 有 TiFlash 就以为能跑全量数仓。某团队把6亿行历史数据直接放进 TiDB然后让业务同事在上面跑十几个维度的自由交叉分析结果列存副本 CPU 持续飘高实时交易延迟被拖到秒级。复盘时我把过滤条件拆开看了看发现大部分查询没有可下推的空间优化器被迫把大量数据拉上计算节点把在线资源浪费在大扫描上。调整动作分两步一方面将分析查询路由到专门的一套 TiDB 集群业务和分析环境物理隔离另一方面把固定报表的预聚合任务放入独立数仓TiDB 只负责 T0 的实时明细查询。这个案例告诉我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 引擎换来了关系模型和开发效率。站在技术选型角度两者都不是完美的完美从来不在选项里只在你对业务的理解里。最后再分享一个小技巧无论最后选了谁上线前都做一轮为期一周的全链路压测专门验证“写入峰值在线查询分析查询”三种负载同时发生的表现。很多团队上线后翻车都是因为在测试环境只压了其中一两种负载没模拟真实业务的混合场景。数据库没有万能选项把每种负载的表现摸透比看十篇评测文章更有说服力。 
长河君 · 2026/10/20 14:52:08 · 阅读 1.2k HBase与TiDB深度对比：分布式数据库选型与HTAP实战解析
前阵子陪一位做数据平台的朋友聊新系统选型备选名单里躺着一对熟悉的名字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 一张决策检查表直接对照打分把选型维度摊开看能过滤掉大部分空对空的争论。我习惯用一张检查表让团队逐项打钩维度HBaseTiDB数据模型分布式KV稀疏宽表分布式关系型完整SQL查询能力Get/Scan依赖rowkey设计无joinSQL索引完整支持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_BITS4将隐式主键打散到16个分片热点消失写入吞吐稳定提升数倍。这个坑提醒所有迁移团队TiDB 兼容 MySQL 协议但物理分布原理和 HBase 非常相似随意的表结构设计照样会导致分片倾斜。5.2 对TiDB分析能力过分乐观导致生产事故另一个典型错误是看到 TiDB 有 TiFlash 就以为能跑全量数仓。某团队把6亿行历史数据直接放进 TiDB然后让业务同事在上面跑十几个维度的自由交叉分析结果列存副本 CPU 持续飘高实时交易延迟被拖到秒级。复盘时我把过滤条件拆开看了看发现大部分查询没有可下推的空间优化器被迫把大量数据拉上计算节点把在线资源浪费在大扫描上。调整动作分两步一方面将分析查询路由到专门的一套 TiDB 集群业务和分析环境物理隔离另一方面把固定报表的预聚合任务放入独立数仓TiDB 只负责 T0 的实时明细查询。这个案例告诉我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 引擎换来了关系模型和开发效率。站在技术选型角度两者都不是完美的完美从来不在选项里只在你对业务的理解里。最后再分享一个小技巧无论最后选了谁上线前都做一轮为期一周的全链路压测专门验证“写入峰值在线查询分析查询”三种负载同时发生的表现。很多团队上线后翻车都是因为在测试环境只压了其中一两种负载没模拟真实业务的混合场景。数据库没有万能选项把每种负载的表现摸透比看十篇评测文章更有说服力。