博客 - HTAP 数据库如何同时支撑交易和分析？行列混存与查询路由机制

摘要

传统架构中，交易系统（OLTP）和分析系统（OLAP）通常使用不同的数据库，通过 ETL 管道同步数据，导致数据延迟高、架构复杂、运维成本大。HTAP（Hybrid Transactional/Analytical Processing）数据库通过行列混存和智能查询路由，在同一数据库中同时支撑交易和分析负载。本文深入解析 HTAP 的技术实现原理与 TiDB 的工程实践。

本文适合谁：正在评估 HTAP 方案、考虑简化数据架构的 CTO、架构师和 DBA。

一、HTAP 的技术挑战

在一个数据库中同时支撑 OLTP 和 OLAP，面临以下核心挑战：

1.1 资源竞争

挑战	说明	影响
IO 争抢	分析查询扫描大量数据，占用磁盘 IO	事务读写延迟升高
CPU 争抢	分析聚合计算消耗大量 CPU	事务处理能力下降
内存争抢	分析查询需要大量内存做 Hash Join/Sort	事务缓存被挤压
网络带宽	分析查询产生大量数据传输	事务通信延迟

1.2 数据一致性

OLTP 和 OLAP 看到同一份数据是 HTAP 的核心价值，也是最大挑战：

分析查询需要看到 已提交的事务数据，而非进行中的中间状态
分析数据的新鲜度要求：从秒级（实时大屏）到分钟级（报表），不同场景要求不同
数据同步机制需要 不影响事务性能

1.3 存储模型冲突

存储模型	优势	劣势
行存（Row-store）	单行读写快，适合 OLTP	全表扫描慢，列聚合效率低
列存（Column-store）	列聚合快，压缩率高，适合 OLAP	单行读写慢，不适合事务

HTAP 的核心思路：同时维护行存和列存，让不同负载各取所需。

二、行列混存实现

TiDB 的 HTAP 架构通过两个互补的存储引擎实现行列混存：

2.1 架构全景

                        TiDB Cluster (HTAP)
┌──────────────────────────────────────────────────┐
│                                                  │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐   │
│  │  TiDB     │  │  TiDB     │  │  TiDB     │   │
│  │  Server    │  │  Server    │  │  Server    │   │
│  │  (SQL +   │  │  (SQL +   │  │  (SQL +   │   │
│  │   CBO)    │  │   CBO)    │  │   CBO)    │   │
│  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘   │
│        │              │              │          │
│        ▼              ▼              ▼          │
│  ┌─────────────────────────────────────────┐   │
│  │         CBO 优化器（查询路由）            │   │
│  │   → 事务查询 → TiKV                     │   │
│  │   → 分析查询 → TiFlash (MPP)            │   │
│  └─────────────────────────────────────────┘   │
│        │                              │         │
│        ▼                              ▼         │
│  ┌───────────┐                ┌───────────┐      │
│  │   TiKV    │   Raft        │  TiFlash  │      │
│  │  (行存)    │◄──Learner────►│  (列存)    │      │
│  │  Region   │   同步         │  MPP 节点  │      │
│  └───────────┘                └───────────┘      │
│        │                              │         │
│        ▼                              ▼         │
│      磁盘                           磁盘        │
└──────────────────────────────────────────────────┘

2.2 TiKV：行存引擎

基于 RocksDB 的 LSM-Tree 存储
数据按行组织，单行读写延迟 < 5ms（P99）
通过 Raft 协议保证副本间强一致性
适合点查、范围查询、事务性写入

2.3 TiFlash：列存引擎

基于 Delta Lake 设计理念的列式存储引擎
数据按列组织，压缩率通常为行存的 3-10 倍
通过 Raft Learner 角色从 TiKV 同步数据（不参与投票，不影响事务）
支持 MPP（大规模并行处理） 分布式计算

2.4 Raft Learner 同步机制

TiFlash 以 Raft Learner 身份加入 Raft Group：

TiKV Leader ──Raft Log──► TiKV Follower (Voter)
                │
                └──Raft Log──► TiFlash (Learner)
                                    │
                                    ▼
                               Apply to 列存

关键特性：

Learner 不参与投票：不影响 TiKV 的 Raft 多数派写入延迟
异步但可控延迟：同步延迟通常在 数百毫秒到数秒，可通过配置调优
数据一致性保证：TiFlash 通过 Raft Log 保证数据与 TiKV 的最终一致性

三、查询路由机制

TiDB 的 CBO（基于成本的优化器）是 HTAP 的智能核心，自动决定查询走哪个引擎。

3.1 路由决策逻辑

SQL 查询 → CBO 优化器
              │
              ├── 事务型查询（点查、小范围扫描）
              │     └──→ TiKV（低延迟）
              │
              ├── 分析型查询（全表扫描、聚合、Join）
              │     └──→ TiFlash MPP（高吞吐）
              │
              └── 混合查询（部分表走 TiKV，部分走 TiFlash）
                    └──→ TiKV + TiFlash 混合执行

3.2 TiFlash MPP 执行

当查询路由到 TiFlash 时，TiDB 会将查询计划拆分为多个子任务，在 TiFlash 节点间分布式执行：

MPP 执行示例：
SELECT region, SUM(amount), COUNT(*)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY region;

执行计划：
TiFlash-1: 扫描 orders (region=A/B) → 本地聚合 → 发送到 TiDB
TiFlash-2: 扫描 orders (region=C/D) → 本地聚合 → 发送到 TiDB
TiFlash-3: 扫描 orders (region=E/F) → 本地聚合 → 发送到 TiDB
TiDB:     接收所有本地聚合结果 → 全局聚合 → 返回结果

3.3 引导优化器选择

-- 强制使用 TiFlash（测试用）
SELECT /*+ READ_FROM_STORAGE(TIFLASH[orders]) */ region, SUM(amount)
FROM orders GROUP BY region;

-- 查看执行计划，确认查询路由
EXPLAIN ANALYZE
SELECT region, SUM(amount) FROM orders GROUP BY region;
-- 如果输出中包含 tiflash 表示走了列存引擎

四、资源隔离

为了避免分析查询影响事务性能，TiDB 提供了 Resource Control 机制：

4.1 Resource Group

-- 创建资源组
CREATE RESOURCE GROUP oltp_group
  RU_PER_SEC = 100000
  PRIORITY = HIGH;

CREATE RESOURCE GROUP olap_group
  RU_PER_SEC = 200000
  PRIORITY = LOW;

-- 将用户绑定到资源组
ALTER USER app_user RESOURCE GROUP oltp_group;
ALTER USER analyst_user RESOURCE GROUP olap_group;

参数	说明	推荐值（事务）	推荐值（分析）
`RU_PER_SEC`	每秒 Request Unit 额度	根据业务 QPS 估算	根据分析频率估算
`PRIORITY`	资源优先级	HIGH	LOW

4.2 资源隔离效果

通过 Resource Control，当集群资源紧张时：

HIGH 优先级的事务请求 优先获得 CPU、IO 资源
LOW 优先级的分析查询 被限流或排队，不会饿死事务
两类负载共享同一份数据，无需 ETL 同步

五、HTAP 最佳实践

5.1 表设计建议

建议	说明
为需要分析的大表创建 TiFlash 副本	`ALTER TABLE orders SET TIFLASH REPLICA 2`
合理设置分区	大表分区可提升分析查询并行度
避免过度冗余字段	列存压缩率与数据去重程度正相关
注意 TiFlash 不支持的功能	如暂不支持外键约束、部分数据类型

5.2 资源配比建议

场景	TiKV : TiFlash	说明
事务为主，少量报表	3 : 1	TiFlash 仅承载报表
事务分析均衡	1 : 1	典型 HTAP 场景
分析为主，实时分析	1 : 2	大屏、实时报表场景

5.3 监控指标

TiFlash 同步延迟：`tiflash_schema_apply_duration`（正常 < 1s）
MPP 查询延迟：`tidb_session_query_duration`（按存储引擎区分）
TiFlash 磁盘使用率：列存通常为行存的 1/3-1/5
Resource Group 使用率：`pd_resource_group_ru_consumption`

FAQ

Q1：HTAP 的分析性能和专用 OLAP 差多少？

TiFlash 的列存 + MPP 架构在大多数场景下可达到专用 OLAP（如 ClickHouse、Apache Doris）70%-90% 的性能。对于单表扫描和简单聚合，TiFlash 性能接近 ClickHouse；对于复杂多表 Join，差距可能稍大。但 HTAP 的核心优势在于 零 ETL、零数据延迟，这在实时分析场景中价值远大于纯粹的查询速度。

Q2：如何判断查询走哪个引擎？

通过 `EXPLAIN ANALYZE` 查看执行计划：

如果执行计划中出现 `tiku/XXX` 信息，说明走了 TiKV
如果执行计划中出现 `tiflash/XXX` 信息，说明走了 TiFlash
也可以通过 `EXPLAIN FORMAT='dot'` 获取更直观的可视化执行计划

Q3：TiFlash 多少副本合适？

建议至少 2 个 TiFlash 副本，以保证高可用（单个 TiFlash 节点故障不影响分析查询）。对于分析负载较重的场景，可增加到 3 个副本。TiFlash 的存储压缩率通常为 TiKV 的 3-10 倍，实际磁盘开销较小。

Q4：HTAP 如何处理写入瓶颈？

HTAP 的写入瓶颈在 TiKV 侧（行存引擎），而非 TiFlash 侧。TiFlash 作为 Raft Learner 不参与写入投票，不会增加事务写入延迟。如果写入成为瓶颈，建议：扩容 TiKV 节点、优化热点分布、使用批量写入代替逐行写入。

总结

HTAP 数据库通过行列混存（TiKV 行存 + TiFlash 列存）和智能查询路由（CBO 优化器自动选择引擎），在同一数据库中同时支撑事务和分析负载。Raft Learner 同步机制保证了数据一致性且不影响事务性能，Resource Control 实现了两类负载的资源隔离。对于希望简化数据架构、消除 ETL 管道的业务，TiDB HTAP 是一个成熟的工程选择。

下一步行动

试用 TiDB HTAP：前往 TiDB Cloud 免费试用，体验事务分析一体化
申请 Demo 演示：预约 TiDB HTAP 一对一 Demo
获取 HTAP 白皮书：下载 TiDB HTAP 技术白皮书

HTAP 数据库如何同时支撑交易和分析？行列混存与查询路由机制

摘要