破壁 OLTP 与 OLAP：TiDB 如何用“双引擎”与“异步魔法”重塑数据库架构！

作者： Root 先锋原文来源：https://tidb.net/blog/7fc7c986

长久以来，数据库领域存在着一道鸿沟：为快速、高并发的事务处理（OLTP）而设计的系统，与为复杂、大规模的数据分析（OLAP）而构建的系统，在底层设计上截然不同，仿佛来自两个世界。前者通常采用行式存储，优化单行读写；后者则采用列式存储，优化批量数据扫描和聚合。这导致了企业数据架构的普遍分裂——一套用于在线业务，另一套用于离线分析，中间通过 ETL 过程连接，带来了延迟、成本和复杂性。TiDB 的 HTAP 架构，正是为了终结这场“战争”，通过精巧的设计将两个世界无缝融合。

1. 双引擎传奇：TiKV（行存）与 TiFlash（列存）

TiDB HTAP 架构的核心，在于其创新的双引擎设计，它没有试图创造一个“万金油”式的单一存储引擎，而是务实地承认了 OLTP 和 OLAP 负载的根本差异，并为它们各自提供了最优解。

• TiKV：事务处理的心跳，TiKV 是 TiDB 的分布式事务型行存引擎。它的设计目标是处理高并发的 OLTP 负载，快速的单点查询（如 SELECT… WHERE id =?）、小范围扫描和高频的增删改操作。在底层，每个 TiKV 节点都使用高性能的嵌入式存储引擎 RocksDB 来持久化数据。数据的可靠性和一致性由 Raft 共识协议保证，数据被切分为多个 Region，每个 Region 及其副本构成一个 Raft Group，确保任何写入操作都在多数副本间同步，实现了金融级的高可用。TiKV 的行式存储结构，意味着一行的数据在物理上是连续存放的，这对于需要快速获取整行记录的事务性操作极为高效。

• TiFlash：分析引擎的动力，TiFlash 则是 TiDB 的列存扩展，是其强大 OLAP 能力的源泉。与 TiKV 相反，TiFlash 采用列式存储，即将同一列的数据连续存放在一起。这种布局对于分析查询（如 SELECT SUM(amount) FROM orders WHERE date > ‘…‘）具有压倒性优势。因为这类查询通常只关心少数几列，列存引擎只需读取相关列的数据，极大地减少了 I/O 量。同时，相同类型的数据连续存储，也为数据压缩和向量化计算（利用 CPU SIMD 指令并行处理一批数据）创造了绝佳条件，TiDB 正是借鉴了 ClickHouse 成熟的向量化执行引擎来实现这一点，从而获得了极致的分析性能。

这种双引擎并存的架构决策，体现了深刻的工程智慧。与其在一个引擎中对两种截然不同的访问模式做出妥协，不如构建两个高度专业化的引擎，然后专注于解决它们之间的协同问题。这个协同问题的答案，正是 TiDB HTAP 架构的精髓所在。

2. 同步的魔法：Raft Learner 协议

解决了存储引擎的专业化问题后，下一个挑战是如何保证行存 TiKV 和列存 TiFlash 之间的数据同步，既要实时、强一致，又不能拖累核心的 OLTP 业务。TiDB 的答案是巧妙地利用了 Raft 协议的一个扩展角色：Learner。

在标准的 Raft 协议中，一个 Raft Group 由一个 Leader 和多个 Follower 组成。任何写入请求都必须由 Leader 处理，并同步到大多数 Follower 节点，得到确认后才能向客户端返回成功。这意味着每个参与投票的成员（Follower）的响应速度都会影响整个写入链路的延迟。如果将 TiFlash 节点作为常规的 Follower 加入 TiKV 的 Raft Group，那么 TiFlash 的任何抖动（如进行数据转换或分析查询导致的高负载）都会直接拖慢在线交易，这是不可接受的。

Raft Learner 角色完美地解决了这个问题。TiFlash 节点以 Learner 的身份加入 TiKV 对应 Region 的 Raft Group。作为一个 Learner，它会接收与 Follower 完全相同的 Raft 日志流，但它不参与投票，也不计入“大多数”的法定人数中。这意味着，Leader 向 Learner 同步日志是一个异步过程，Leader 无需等待 Learner 的确认即可提交事务。

这一机制带来了决定性的优势：

• 隔离性：TiFlash 节点的可用性或性能波动，完全不会影响 TiKV 上 OLTP 业务的性能和延迟。在线交易链路被彻底保护起来。

• 实时性：尽管是异步复制，但 TiFlash 接收的是实时的 Raft 日志流，数据延迟极低。

• 强一致性：TiDB 通过一种“Raft 索引验证”机制来保证读取数据的一致性。当 TiFlash 收到一个分析查询时，它会向对应的 Raft Leader 发起一个轻量级的 RPC 请求，确认自己的数据复制进度是否已经包含了查询时间点（Timestamp）之前的所有数据。只有在确认数据足够新之后，查询才会被执行。这保证了在 TiFlash 上执行的分析查询，能够读到与 TiKV 上完全一致的、最新的数据快照，实现了快照隔离（Snapshot Isolation）级别的一致性。

Raft Learner 协议是连接 TiKV 和 TiFlash 的桥梁，它优雅地解耦了 TP 和 AP 负载，在物理上实现了隔离，同时在逻辑上保证了实时和强一致，是 TiDB HTAP 架构的基石。

3. 智能指挥家：基于成本的优化器

拥有了两个强大的引擎和高效的同步机制后，还需要一个智能的大脑来决定何时使用哪个引擎。这个大脑就是 TiDB 的基于成本的优化器（Cost-Based Optimizer, CBO）。

当用户提交一条 SQL 查询时，他们无需关心底层是行存还是列存。TiDB 的优化器会自动接管。它会收集关于数据分布的详细统计信息（如列的基数、直方图等），并基于这些信息，对一个查询的多种可能执行方式进行成本估算。

例如，对于一条 SELECT * FROM user WHERE user_id = 123 的查询，优化器会估算出通过 TiKV 的索引进行点查的成本极低，而通过 TiFlash 进行全表扫描的成本则高得多，因此它会生成一个访问 TiKV 的执行计划。反之，对于 SELECT country, COUNT(*) FROM user GROUP BY country 这样的查询，优化器会判断出，通过 TiFlash 的列存进行全表扫描和聚合的成本，远低于在 TiKV 上进行全表扫描的成本，于是它会选择 TiFlash 来执行。

更强大的是，优化器甚至可以在同一个查询中混合使用两个引擎。例如，一个复杂的 JOIN 查询，可能一部分通过 TiKV 的索引快速定位小表数据，另一部分通过 TiFlash 扫描大表数据，最后再将结果汇集起来。用户可以通过 EXPLAIN 命令查看优化器生成的执行计划，如果计划中包含了 TableFullScan 且 store type 为 tiflash，就表明查询利用了列存引擎的优势。

这种对用户透明的、自动的智能选择，是 TiDB HTAP“一站式”体验的关键。它将底层的复杂性完全屏蔽，让开发者和数据分析师只需专注于业务逻辑，用最自然的 SQL 语言与数据交互。

4. 一致性保证：分布式 ACID 事务

最后，作为一款根植于事务处理的数据库，TiDB 提供了完整的分布式 ACID 事务保证。其事务模型借鉴了 Google 的 Percolator，采用“两阶段提交（2PC）”协议，并由 PD 作为全局的“时间戳预言机（Timestamp Oracle, TSO）”来为所有事务分配唯一的时间戳，从而实现全局的事务排序和冲突检测。

这意味着，即使用户的业务横跨多个节点、多个 Region，TiDB 依然能保证事务的原子性、一致性、隔离性和持久性。这是 TiDB 能够承载金融等核心交易系统的根本所在，也是其 HTAP 能力区别于许多最终一致性分析系统的关键——分析的数据，是与事务严格一致的实时数据。

5. 总结

综上所述，TiDB 通过双引擎设计、Raft Learner 同步、智能优化器和强大的分布式事务模型，构建了一个无缝、高效、一致的 HTAP 架构。它不是对现有技术的简单堆砌，而是一套经过深思熟虑的、优雅的系统工程，真正终结了 TP 与 AP 之间长达数十年的技术鸿沟。