HTAP混合事务分析架构设计

可视化演示

展示行列混存双引擎、Raft日志实时同步与资源隔离查询路由的交互演示

事务分析起源

陈叔的茶餐厅，点单靠收银台，看报表靠总部“夜班会计”。每晚 11 点打烊，店长拍下所有手写单，会计忙到凌晨，把订单一张张录成电子表格。这种“白天做生意，晚上做账”的模式，在数据库世界有一个熟悉的名字：ETL。ETL 就像那个夜班会计，负责把业务系统（OLTP）一整天的流水搬运到分析系统（OLAP）。问题是，老板第二天看到的永远是“昨天”的数据——今天想调整菜单、想补货，已经来不及了。

数据库世界里，OLTP 是收银台：处理订单、扣库存、记余额，要求快、准、稳。OLAP 是总部的经营分析室：汇总几万家店的销量、利润、趋势，要求能扫描海量数据、做复杂聚合。两者负载完全不同，所以传统架构把它们拆成两套系统，中间用 ETL 搬运数据。这个搬运过程就是“隔夜报表”的来源：数据从产生到可见，至少要经过一个批处理周期。

HTAP（混合事务与分析处理）想做的事情，就是让一套系统同时具备“收银台”和“分析室”的能力。它不再需要每晚搬运数据，而是让业务写入之后，数据以近乎实时的方式同步到分析侧。这就像陈叔给店里装了一个“后厨大屏”，前台每接一单，大屏上的销量立刻跳动，不用再等会计熬夜。

所以，HTAP 的本质不是把 ETL 变快，而是尽可能让它消失。陈叔也不想要那个夜班会计了，他想要的是“刚下的单，大屏上立刻就能看到”。这正是混合事务分析架构要解决的核心诉求。

行存事务特征

收银台前，陈叔记流水账的习惯是一页一行：时间、菜品、数量、金额，一行就是一个完整的订单。想查“3 号桌点了什么”，翻到那一行就行，特别快。但如果想统计“今天冻柠茶卖了多少杯”，就得把整本流水账从头翻到尾，每一行都要看一遍，效率很低。这个流水账，就是数据库里的行存（行式存储）：一行数据挨着放，主键索引能让人快速定位到某条记录。

行存结构把一条记录的所有字段存在一起，所以“按主键查单行”非常高效。这也正是 OLTP 事务的典型场景：下单、改库存、扣余额，每次只操作少量行，但要保证原子性、一致性、隔离性、持久性，也就是 ACID 事务。行存天然适合这种“一点一滴精准改”的负载，因为它把一条记录的上下文都放在一起，加锁、回滚都方便。

但行存的软肋在于聚合查询。假设订单表有 100 列，而你想统计每道菜卖了多少，数据库也得一行行读入 100 列的数据，哪怕你只关心“菜品名”和“数量”两列。读入的数据量等于行数乘以全行宽度，浪费巨大。

所以，行存是“翻单小能手”，却不是“算账好手”。陈叔的流水本适合前台点单，不适合后厨统计。这也是为什么数据库世界需要另一种存储形态，去承载分析型负载。

列存分析特征

后来陈叔在后厨装了一块大屏，大屏不记流水账，而是每一项菜品单独占一行，旁边列出销量、金额、门店。比如第一行写“冻柠茶 12 元 3200 杯”，第二行写“云吞面 22 元 1800 碗”。大屏想算总销售额，只需把“金额”这一列从上到下扫一遍，不需要看每个订单的原始明细。这种把相同字段归到一起的存储方式，就是列存（列式存储）。

列存最大的优势是“按需取列”。分析查询通常只关心少数几个列，比如菜品名、金额、时间，列存可以只读这些列，跳过其余几十个无关列。另外，同一列的数据类型相同，内容相似度高，压缩率非常可观。一个存着“朝阳店”“海淀店”的门店列，重复值一压缩，体积立刻缩水很多。读取量小，压缩比高，聚合自然就快。

但是，列存不是万能的。如果要在列存里修改一行记录，需要同时触及该行分布在各个列文件中的位置，更新成本极高；加上事务控制复杂，列存完全不适合高频小事务。后厨大屏擅长“看全局”，不擅长“改一笔”。

所以，行存管“每一笔”，列存管“每一面”。陈叔的店里，流水本和看板各有分工。HTAP 的野心，就是让两者在同一个屋檐下协作，而连接它们的枢纽，就是日志同步。

Raft日志同步

鑫记茶餐厅有一个传菜口，服务员下单后把单子夹在转盘上，转盘一转，后厨大屏立刻显示“新订单：2 号桌冻柠茶两杯”。这个“转盘”就像分布式系统里的 Raft 日志：它把前台产生的新订单，按顺序广播给所有需要知道的地方。

Raft 是一种共识算法，用来让多台机器就“日志顺序”达成一致。在 HTAP 架构里，行存主库收到事务后，先把操作写进 Raft 日志，日志按顺序同步给列存副本；列存副本拿到日志，像后厨大屏刷新一样，把这些更改重放到自己的列文件上。这样一来，列存数据持续追踪行存的变化，分析查询随时都能看到最新的数据。

这就把传统 ETL 的“夜间批量搬运”转变成了“实时增量同步”。不需要再等打烊，不需要再攒批，每一笔事务提交后，日志同步在毫秒级完成。TiDB 的 TiFlash 就是通过 Raft 日志从 TiKV 行存同步数据的典型实现。同步窗口小，数据新鲜度从“隔天”变成了“现在”。

跑单铃一响，看板就动。陈叔终于不用等夜班会计把单据搬进 Excel 了，因为每一张新单都会通过“转盘”实时同步到后厨大屏。日志同步，就是 HTAP 的灵魂传送带。

行列混存架构

陈叔的店里现在有两样东西：收银台的流水本，还有后厨的大屏看板。流水本一行一行记录新订单，大屏把各项菜的销量列成表。两者各司其职，中间靠传菜口转盘联动。这就是 HTAP 的行列混存架构：一套数据库，同时部署行存引擎和列存引擎。

以 TiDB 为例，TiKV 是行存引擎，掌管事务写入和主键点查；TiFlash 是列存引擎，专门服务分析查询。两个引擎并不孤立：TiKV 中产生的数据变更，通过 Raft 日志实时同步到 TiFlash，让列存副本持续保持最新。用户发出 SQL 时，优化器会自动判断：点查走 TiKV，聚合分析走 TiFlash，甚至同一张表的不同查询也能分流到不同引擎。CockroachDB 同样用 Raft 日志驱动副本同步，在分布式 SQL 层提供类似 HTAP 能力。

这就像一个数据库里有两个部门：业务部负责接单，分析部负责出报表，而 Raft 日志是两部门之间的“对讲机”。对用户来说，他们只面对同一个数据库入口，不需要关心数据被拆到了哪个引擎。

既有流水本，又有看板，还有联动机制，这就是“一库双引擎”的行列混存架构。对陈叔来说，他不需要分别经营两套系统，只需要一个前台、一个后厨，然后让传菜口把两者连起来。

一致性保障

陈叔有一个习惯：每天下午三点，他要在手机上看看各分店实时销售。他特别怕看到一半，数字突然跳来跳去——比如刚看到“冻柠茶 1000 杯”，下一秒变成 998 杯，再下一秒又变成 1002 杯。他希望每一眼看到的都是“三点整那一刻”的稳定快照。HTAP 里的快照隔离，就是为这种需求设计的。

在分布式系统中，数据分散在多个节点，行存和列存也在不断同步，如何保证一个查询看到“一致的瞬间”？答案是全局时间戳。每个查询开始时，向中心时钟服务申请一个时间戳 TSO，这个查询只读取提交时间早于该时间戳的数据版本。无论数据同步到哪一步，查询永远基于同一个时间点构建快照，不会看到正在写入的中间状态。

配合分布式事务协议，行存写入和日志同步都带有明确的时间顺序，列存副本重放日志后，就能提供与行存一致的历史快照。这种机制让“读分析副本”和“读交易主库”得到的数据逻辑一致，只是时效上有一个毫秒级的同步窗口。

就像陈叔的三点快照：一到三点，账房“咔嚓”一声把所有账页拍下来，之后即使前台又接了几十单，也不影响他分析三点那一刻的经营状况。一致性保障，让“实时看板”既新又稳。

架构权衡取舍

双本账很好用，但陈叔在推行的过程中发现了问题：首先，多一套大屏看板意味着多一份设备成本；其次，传菜口转盘虽然快，但传送带也会偶尔卡顿，需要保养；最后，如果要确保前后台任何时候看到的数字都完全一致，就得给每道菜装上更复杂的“确认按钮”，让出菜速度变慢一些。

对应到 HTAP 架构，这些就是设计取舍：行存和列存同时存储一份数据的逻辑内容，磁盘成本必然上涨；日志同步虽然快，但网络和副本状态仍可能带来毫秒级延迟；强一致性要求更高，分布式事务和共识协议的开销也更大。一个 HTAP 系统不可能在所有维度都做到最优。

因此，架构师需要按业务场景选择平衡点。核心交易系统对一致性要求极高，但分析负载不大；实时风控系统希望数据尽量新，但偶尔读到延迟几百毫秒也可接受；轻量经营报表追求全链路简单，不需要复杂的数仓建模。理解了权衡，才能明白为什么很多系统默认用异步复制或弱一致性来换性能。

最后陈叔只给爆款菜和重点分店装了大屏，普通小店的经营数据仍然用每日报表。这就是基于场景的取舍：全面的 HTAP 是理想，落地时永远要算清成本账。

实时应用前景

装好双本账之后，陈叔的办公方式彻底变了。以前他每周开一次经营会，看一堆 Excel。现在他可以端着一杯冻柠茶，盯着手机上的实时看板：早高峰哪个分店爆单，哪道菜在午市突然走量，哪个门店库存快见底，都一目了然。他还能在直播带货的瞬间，看到某个门店的实时销量冲高，立刻调度中央厨房加货。

这样的实时能力，在行业里正被广泛需要。实时风控是典型场景：支付系统一边处理交易事务，一边用列存分析近期交易模式，在毫秒级识别异常，而不是等事后跑批才拦截。实时经营分析让连锁零售、电商运营团队按分钟观测渠道效果，快速调整策略。HTAP 还大幅简化了数据链路：不再需要维护复杂的 ETL 任务和两套数据库，一套系统完成读写与分析，运维成本随之下降。

这套架构之所以能带来这些价值，是因为它将“事务”、“同步”、“分析”三段链路压缩到了一套系统内。业务请求从写入到分析可见，经过的每一步都可以被度量和优化。

陈叔的茶餐厅从一个靠“隔夜账”经营的连锁店，进化成了“实时看板”驱动的敏捷组织。HTAP 的未来，正是让更多企业从“事后诸葛亮”走向“现在就能拍板”。

AI 应用场景

Python 演示

"""HTAP 最小模拟：一套账本同时支撑事务与实时分析。"""import timefrom collections import defaultdict  class OrderRowStore:    """行存储账本：一笔订单追加一行，适合点查。"""     def __init__(self):        self.order_records = []        self.log_entries = []     def add_order(self, branch, dish, amount):        record = {            "id": len(self.order_records) + 1,            "branch": branch,            "dish": dish,            "amount": amount,            "ts": time.time(),        }        self.order_records.append(record)        self.log_entries.append(("INSERT", record))     def query_order(self, order_id):        for item in self.order_records:            if item["id"] == order_id:                return item        return None  class SaleColumnStore:    """列存储看板：按列聚拢数据，承接分析查询。"""     def __init__(self):        self.branch_map = defaultdict(list)        self.dish_map = defaultdict(list)        self.amount_list = []        self.log_offset = 0     def replay(self, row_store):        """模拟 Raft 日志同步：把新日志重放到列存。"""        while self.log_offset < len(row_store.log_entries):            _, item = row_store.log_entries[self.log_offset]            self.branch_map[item["branch"]].append(item["id"])            self.dish_map[item["dish"]].append(item["id"])            self.amount_list.append(item["amount"])            self.log_offset += 1     def aggregate_by_dish(self):        total_map = {}        for dish, ids in self.dish_map.items():            total_map[dish] = sum(self.amount_list[i - 1] for i in ids)        return total_map  def main():    row_store = OrderRowStore()    col_store = SaleColumnStore()    orders = [        ("朝阳店", "冻柠茶", 12),        ("朝阳店", "云吞面", 22),        ("海淀店", "冻柠茶", 12),        ("朝阳店", "冻柠茶", 12),        ("海淀店", "牛腩饭", 35),    ]    for branch, dish, amount in orders:        row_store.add_order(branch, dish, amount)     time.sleep(0.1)    print("传统 ETL 方式：等批处理 0.1 秒后，报表才能看到新订单")     col_store.replay(row_store)    print("HTAP 方式：日志同步完成，实时聚合结果如下")    for dish, total in col_store.aggregate_by_dish().items():        print("  {} 总销售额：{} 元".format(dish, total))     order = row_store.query_order(1)    print("行存点查订单 1：{}".format(order["dish"]))  if __name__ == "__main__":    main()

1. self.log_entries.append(("INSERT", record))每笔新订单都要追加一条日志，作为后续同步的“传菜单”。
2. def replay(self, row_store)把行存中尚未同步的日志逐条重放到列存，对应 HTAP 的实时同步环节。
3. self.log_offset += 1记录同步进度，避免重复读取旧日志。
4. total_map[dish] = sum(self.amount_list[i - 1] for i in ids)列存只聚合“金额列”，对应压缩后高效分析。
5. row_store.query_order(1)行存仍然保留主键点查优势，一套系统里两种能力并存。

常见误区

面试题