在线离线一体化：HTAP 场景的真实体验与边界

在线离线一体化：HTAP 场景的真实体验与边界

「实时数仓」「HTAP 一栈式」「在线分析不用再等 T+1」——这些宣传词背后是一个真实的工程趋势：OLTP 和 OLAP 从两套系统走向一套。但真实项目里，一体化是分级别的，每一级都有它的适用边界和代价。本文按从轻到重讲四条路径的真实体验，帮你判断该停在哪一级。

一、先想清楚：你的「实时分析」到底要多实时

多数团队提出「实时分析」需求时，实际需要的是这四种之一：报表数据分钟级新鲜度（运营看实时大盘）、用户维度的实时明细查询（客服查用户最近行为）、实时风控（交易时反查用户近 7 天行为）、ad-hoc 自由探索（分析师临时查询）。这四种的解法完全不同，混在一起谈「HTAP」就会过度建设。先对齐需求，再选级别。

二、Level 1：只读副本——最低成本的一体化

OLTP 数据库（MySQL/PostgreSQL）自带只读副本，把分析查询引到只读实例上。这就是最小的一体化——数据零搬运（数据库自动复制），分析 SQL 和业务 SQL 同方言，开发成本接近零。

真实边界：副本解决的是「分析查询不影响主库」这一件事，不解决「分析查询跑不动」——大表聚合、多表 join、窗口函数在 OLTP 数据库上（行存储、B+ 树索引）该慢还是慢。亿行表 count distinct 跑 10 分钟，只读副本也一样。判断标准：分析查询 P95 在 10 秒内且并发很低，Level 1 够用；超过就要升 Level。

细节：只读副本的复制延迟（毫秒到秒级）对报表场景无碍；分析大查询会打满副本的 IO 影响其他读——副本按用途拆（报表专用副本 + 服务读副本）是基本操作。

三、Level 2：列存加速——数据库内的列存引擎

在 OLTP 数据库内加列存能力（PG 上的 Citus 列存扩展、MySQL HeatWave、Oracle In-Memory），或者用云厂商的 HTAP 版本（同一份数据自动同步到列存节点）。

这一级的真实收益：聚合查询（sum/count/group by）快 10~100 倍，列存的压缩让大表扫描不再全靠 IO。报表类查询（固定维度聚合）在这一级基本够用。代价：内存成本（列存常驻内存的代价）、join 能力仍然有限（复杂 join 不是列存引擎的强项）、和 OLTP 的隔离只是「部分隔离」（同一集群资源的争抢仍在）。

适合：报表查询为主、数据量亿级以内、不想引入新系统的团队。这是「最后一站式的性价比级」——很多团队做完发现 Level 2 已经满足 90% 需求，剩下的 10% 长尾用导出到 Excel 解决。

四、Level 3：CDC 到分析引擎——主流的「实时数仓」

第三级回到两套系统，但用 CDC（binlog 订阅）打通：OLTP（业务库）→ Flink CDC → 实时数仓引擎（Doris/StarRocks/ClickHouse），秒到分钟级延迟。

这一级是当前事实标准的原因：分析引擎的聚合、join、并发能力是数据库内列存达不到的（MPP 架构横向扩展），而 CDC 链路成熟（Flink CDC 全量+增量一体化）。运营大盘、实时指标、用户行为分析在这一级都能做好。

真实代价不在引擎在链路：a. 同步链路运维——表结构变更要同步改数仓模型、字段类型映射、乱序处理、延迟监控，这些是持续成本（每加一张业务表就要扩一条同步链路）；b. 数据口径治理——同一指标在业务库和数仓算出来不一样（时间窗口定义、去重口径），指标口径字典的治理比技术难；c. 成本翻倍——数据存了两份（OLTP 一份 + 数仓一份），数仓的存储和计算是新增成本。

适合：数据量亿级以上、分析场景多样（报表 + ad-hoc + 明细查询）、有数据平台团队维护链路。这级开始，「一体化」其实是「自动化 ETL 的双系统」。

五、Level 4：真正的 HTAP 单引擎

TiDB（TiFlash 列存副本）、SingleStore 这类「一个引擎同时跑 TP 和 AP」的架构：行存跑事务，列存副本跑分析，优化器自动路由查询到对应存储。

真实体验：概念上最优（一套 SQL、一份元数据、自动路由），实践里的边界——a. 分析性能与专用分析引擎仍有差距（TiFlash 的 join 并发能力弱于 Doris）；b. TP 负载高峰时 AP 查询互相影响（资源隔离靠调度不靠物理）；c. 团队要同时懂 TP 和 AP 的调优。适合绿地项目（新系统直接选它）、或 TP 规模中等且 AP 需求明确的场景。存量的分库分表 MySQL 业务迁移到 HTAP 引擎解决分析需求，迁移成本要单独评估。

六、选型决策树

需求 → 级别：分析查询少而轻 → 不动（业务库直接查 + 限流）；固定报表 → Level 1/2（只读副本或列存）；亿级数据 + 多场景分析 → Level 3（CDC + Doris/StarRocks）；新项目 + 不想维护两套 → Level 4 评估。

最后一个实践建议：别一步到位。从 Level 1 起步，让真实的分析负载跑起来，用量化数据（最慢查询的 P95、每天分析查询的量、分析师的投诉）决定升级到哪一级。多数系统死在「为了想象中的分析需求建了 Level 3 的全链路，结果分析查询每天只有 50 次还是报表」——技术能力和业务需求的匹配，永远是选型的第一原则。