TiFlash列存引擎：HTAP的分析利器

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

HTAP：一套系统两本账

想象一家日接待上千桌的连锁餐厅。店面收银台要最快速度记下每桌的菜名、金额、桌号，这是 OLTP——在线交易处理；而总部每周要复盘：哪道菜毛利最高？哪个城市翻台率最好？这是 OLAP——在线分析处理。过去，老板不得不维护两套系统：一套前台收银，一套把数据搬运到总部仓库做统计，中间存在着运输延迟。

TiDB 的野心就是打破这个局面。它把“交易型工作负载”和“分析型工作负载”放进同一套数据库：所有数据默认以行存形式存在于 TiKV 节点上，服务高频点单；同时用户可以给任意表增加 TiFlash 列存副本，让它承担分析型查询。这种在同一系统内同时支撑两类负载的架构，业界称为 HTAP，即混合事务与分析处理。

从一张表来看，行存相当于一本按时间顺序写的流水账，列存则像一本按“菜名”“金额”“城市”重新编排的分类账。行存扫描一张 20 列的表，哪怕只想要其中 2 列，也要把 20 列都读一遍；列存则直接走向那 2 列。这里的加速效果可以量化：

HTAP 的目标，就是让交易与分析在同一个集群内并行不悖：交易保持亚毫秒级延迟，分析也能在秒级返回。在 TiDB 生态中，TiKV 提供强一致、高可用的行存；TiFlash 提供列存与向量化分析能力；TiDB Server 负责 SQL 解析与优化，自动决定把查询发往哪一端。这就是后面每一节展开的地基。有了“两本账”的直觉，我们再看账本内部是怎么排版的。

列存原理：分类账本的艺术

分类账本之所以高效，关键在于“同类信息放在一起”。列式存储把同一列的所有值连续排在磁盘上，而不是把整行数据排在一起。看一个小例子：订单表（订单号、客户、金额、品类、城市、时间）。行存磁盘上的顺序大致是：订单号1、客户1、金额1、品类1、城市1、时间1、订单号2、客户2……列存则是：所有订单号连续一段，接着是所有客户，再是所有金额，各占一段连续区域。

这样的排版带来两个直接好处。第一是 IO 更少：分析查询只需读取涉及的列，比如只统计金额和品类，就完全跳过客户、城市等无关列。第二是压缩更高效：同一列数据往往重复度很高，城市列大量出现“北京”“上海”，用字典编码能省出很大空间；数字列用差分编码或通用压缩也能压到几分之一。此外，TiFlash 还支持筛选下推：像 WHERE city = 'beijing' 这样的过滤条件，会下推到列存层提前执行，只返回满足条件的行，进一步减少上层处理的数据量。

但列存的痛点在于写入。随机小写入如果直接改大列块，代价会很高。TiFlash 用 Delta Tree 解决：新写入的数据先进入一个小的 Delta 暂存区，读取时同时读 Delta 区和主列存区；当 Delta 区积累到阈值，再后台合并进大的列块。这样既保留了列存的高压缩与高性能扫描，又让写入不必频繁重写大列文件。回到比喻：分类账本旁边搁着一叠待誊录的便签条，写完一批菜就抽空工整地抄进大账本；合账之前，算账的人两处都要看。账本主体始终整洁，便签条让新记录随到随记。

Raft Learner：不投票的传菜单副手

分类账本不能凭空变出来，它需要持续从收银流水账本同步。Raft 是 TiKV 实现多副本一致性的协议：一个 Leader 负责接收写请求，若干 Follower 同步日志；写入必须获得多数派，也就是超过一半投票节点的确认，才能提交。

TiFlash 想要这份数据，却不希望自己的存在拖慢收银台。它可以加入 TiKV 的 Raft 组，但以 Learner 身份加入。Raft Learner 是一个只复制日志、不参与投票的特殊角色：它持续从 Leader 拉取日志并应用数据，但在选举和提交确认中没有任何话语权。这意味着主链路的确认节点数完全由 TiKV 的投票成员决定，无论添加多少个 TiFlash 节点，前台写入的等待时间都不会多一秒。这就是“链路隔离”：同步分析副本的动作被完美隔离在交易链路之外。

注意，这个公式里的 n 只数 TiKV 的投票节点，TiFlash Learner 数量不进入 n。即使给 20 张表各配 3 个 TiFlash 副本，前台交易确认速度依然由 TiKV 自己的多数派决定。用故事收尾：餐厅前台和收银系统是核心链路，传菜单的副手只是默默把每一单背下来，不参与收银台找零确认，自然不会让顾客多等一秒。

强一致读：时间戳与日志位置对齐

副手把菜单一份份背回总部，但他可能比前台慢半拍。如果老板恰好在这半拍里打开账本，会不会看到缺了一两单的旧数据？TiFlash 用两样东西来保证不看到旧账：全局时间戳和 Raft 日志位置。

TiDB 的每个事务在开始时都会从 TSO 全局授时中心申请一个递增的时间戳，作为这个事务的“生效时刻”。TiKV 在 Raft 日志中写入数据时，该日志项就带着这个时间戳；TiFlash 从 Raft 日志复制数据时，会记录自己已经应用到的日志位置，也就是 apply index 对应的最大时间戳。当一个查询要读取某个快照时间 t 的数据时，TiFlash 把这个 t 与本地已应用时间比较：如果快照时间不大于本地进度，说明所有 t 之前的修改都已落账，直接读即可；如果快照时间太新，本地还没追上，引擎会等待日志继续同步，或者把查询转发给 TiKV，让行存来接这个查询。无论哪条路，对用户来说拿到的都是强一致的结果。

所谓“异步复制”绝不意味着“弱一致读”。餐厅里的副手虽然晚半拍，但端菜前会仔细核对手上单据的更新时间，如果发现缺的正是客人点的招牌菜，他会让客人稍等或者直接跑到前台拿最新菜单——顾客永远不会看到上一轮的旧菜单。

向量化执行：大锅铲批量烹饪

账本建好了，怎么快速算账？如果会计一行一行地看订单、一列一列地加总，速度肯定跟不上老板的实时提问。TiFlash 采用向量化执行引擎，把数据按批处理，而不是按行处理。

所谓向量化，是指每次操作面对的是一个批次的数据，比如 1024 行。传统执行器像一个嵌套循环：每来一行，执行一次表达式、做一次条件判断；向量化执行器则把一批数据放入连续内存，循环体内部没有分支，批量做算术、批量比较、批量聚合。得益于这套设计，TiFlash 的列式算子可以逐个批次处理数据，而不是逐行调用函数。

从底层硬件看，CPU 的 SIMD 指令让向量化如虎添翼。现代 CPU 的寄存器可以同时装多个数：例如 AVX2 的 256 位寄存器一次能放下 8 个 32 位浮点数。标量代码一次算 1 个，向量代码一次算 8 个，理论加速比就是 8 倍。再加上批量数据在内存中连续紧凑排列，让 CPU 缓存命中率极高，进一步减少了等待内存的时间。

回到厨房：与其一份牛排一块煎板慢慢煎，不如把十块牛排同时放进一个超大平底锅，锅铲一挥，十块一起翻面。CPU 的 SIMD 就是这把大锅铲，向量化执行就是那个超大平底锅。

应用实践：从账本到实时决策

账本和厨房都备齐了，餐厅老板终于可以随时翻开分类账本回答实时问题。TiFlash 最常见的落地场景是“实时数仓”。传统数仓通常是 T+1，每天夜里的任务把业务库数据同步到数仓，白天看到的都是昨天的数据。引入 TiFlash 后，业务库 TiKV 的数据通过 Raft Learner 实时流到列存副本，秒级可见，BI 报表可以做到近实时刷新，运营不必再等一天。

第二个典型场景是“混合负载隔离”。在线交易系统白天压力最大，如果此时运营发起一个全表聚合大查询，很容易拖垮交易。TiDB 的优化器会自动识别分析型查询，并把这类查询派发给 TiFlash 执行，交易继续走 TiKV，互不干扰。副本管理的灵活性也值得一提：DBA 可以执行 ALTER TABLE orders SET TIFLASH REPLICA 2 来为订单表增加两个列存副本，也可以随时调整副本数量，整个过程不需要重启集群，副本数据会由后台任务自动补齐。

三者相加通常在秒级以内，远小于传统 T+1 的“天”级。现代 HTAP 的真正价值，不是把数仓搬得更近，而是让分析查询与交易数据在时间维度几乎零距离——老板刚收到钱，账本上就已经能算出这一桌的毛利了。

AI 应用场景

Python 演示

import random class RowStore:    """行式存储, 一行的所有字段挨着存"""     def __init__(self):        self.rows = []     def insert(self, row):        self.rows.append(row)     def scan(self, cols):        cost = 0        result = []        for row in self.rows:            cost += len(row)  # 读整行 6 个字段            result.append((row[cols[0]], row[cols[1]]))        return result, cost  class ColumnStore:    """列式存储, 每个字段单独存一列"""     def __init__(self):        self.columns = {}     def insert(self, row):        for k, v in row.items():            self.columns.setdefault(k, []).append(v)     def scan(self, cols):        cost = 0        result = []        for c in cols:            cost += len(self.columns[c])  # 只读需要的列            result.append(self.columns[c])        return result, cost  def make_order(i):    return {        "order_id": i,        "customer": "user%d" % random.randint(1, 5000),        "amount": random.randint(1, 1000),        "category": random.choice(["food", "cloth", "digital", "book"]),        "city": random.choice(["beijing", "shanghai", "shenzhen", "hangzhou"]),        "ts": random.randint(1600000000, 1700000000),    }  def main():    row_store = RowStore()    col_store = ColumnStore()    for i in range(100000):        order = make_order(i)        row_store.insert(order)        col_store.insert(order)     selected = ("amount", "category")    _, row_cost = row_store.scan(selected)    _, col_cost = col_store.scan(selected)    print("行存读取格子数: %d" % row_cost)    print("列存读取格子数: %d" % col_cost)    print("列存节省比例: %.1f%%" % (1 - col_cost / float(row_cost)))  if __name__ == "__main__":    main()

1. self.columns.setdefault(k, []).append(v)新订单各字段分别落到自己的列列表，天然形成列存结构
2. for row in self.rows:行存扫描从第一行遍历到最后一行，所有字段都逃不过
3. cost += len(row)整行的 6 个字段都被“读进内存”，即使只需要其中 2 个字段
4. cost += len(self.columns[c])列存只统计被选中列的长度，与表的总列数完全无关
5. result.append(self.columns[c])直接取整个列数据块，不需要逐行过滤
6. row_store.scan(selected)虽然只查询 2 列，行存依然全表扫描
7. col_store.scan(selected)列存按列名直达数据区，只读取需要的两列
8. print("列存节省比例: %.1f%%" % ...)输出行存读取格子数与列存的量化对比，演示 IO 加速比

常见误区

面试题