HTAP从概念到架构落地摘要HTAP 经常被简化成“一套数据库同时支持 OLTP 和 OLAP”但真正值得追问的是为什么过去必须把交易库和分析库拆开行存与列存如何在一套系统里协作TiDB、OceanBase 这类产品各自走了一条怎样的技术路线本文从问题起点出发把 HTAP 的动机、核心矛盾、主流架构、查询执行链路和落地边界串成一条可以推理的线。一、先回到问题为什么会出现 HTAP在传统数据架构里交易和分析天然被放在两条链路上业务应用OLTP 交易库MySQL / PostgreSQLCDC / 定时 ETL数据仓库 ODS明细层 / 汇总层BI / 报表 / 数据产品这条链路能工作但它把“实时”这个词拆成了多个系统之间的数据搬运问题。1. 延迟来自数据搬运而不只是查询慢当业务想看“最近 5 分钟订单量”“当前库存扣减后的实时可售数”“支付完成后的实时对账”时OLTP 可以很快写入OLAP 却不一定能很快看到。传统方案的问题不是 SQL 写不出来而是问题具体表现数据延迟ETL 通常是分钟级、小时级甚至 T1口径漂移交易库和数仓的字段、枚举、去重逻辑可能不同链路复杂CDC、消息队列、调度、数仓、任务依赖构成一条长链路成本重复同一份订单数据可能在 MySQL、Kafka、Hive、ClickHouse 多份存在故障面扩大任何一个同步任务失败报表就会停更2. OLTP 与 OLAP 的诉求天然冲突这两个词背后不是“快慢”的区别而是完全不同的访问模式维度OLTPOLAP主要操作点查、短事务、高频更新大范围扫描、聚合、关联数据量单次读取少量行单次扫描百万甚至亿级行延迟要求毫秒级、稳定秒级到分钟级允许批量数据新鲜度实时写入即可见通常可接受一定延迟存储偏好行存按主键访问列存按列扫描和压缩并发模型大量短小并发请求少量重型分析请求因此一个朴素想法是把行存和列存放进同一套系统让交易请求走行存让分析请求走列存。这个想法就是 HTAP 的起点。二、HTAP 到底在解决什么HTAP 是 Hybrid Transactional/Analytical Processing 的缩写核心不是“一个数据库会两种 SQL”而是同一份可更新数据 交易型写入路径 分析型读取路径 较短的可见性延迟 可接受的资源隔离更准确地说HTAP 的价值不在“替代数仓”而在缩短从业务发生到数据可分析之间的时间。典型价值场景实时经营看板订单、支付、库存、履约等指标分钟级更新。实时对账交易完成后立刻检查资金、库存、渠道状态。实时风控规则和简单特征在交易数据上即时计算。操作型分析客服、运营、商户后台查询较新的明细和汇总。减少同步链路用一套系统承接一部分原本要落到 ClickHouse、Doris 或 Hive 的查询。HTAP 并不是要消灭数据仓库。离线复杂分析、历史归档、跨主题宽表和机器学习特征工程仍然更适合数仓或数据湖。三、四个核心技术矛盾HTAP 听起来很自然但真正落地时会碰到四类冲突。1. 存储格式行存与列存不可兼得行存适合点查和更新因为一行数据通常在一起列存适合扫描和聚合因为同一列数据连续存放可以跳过无关列并高效压缩。如果把所有数据同时维护成行存和列存写入成本会上升存储空间也会增加。HTAP 系统必须决定是维护多个副本每个副本采用不同格式还是在同一存储引擎内部同时组织行格式与列格式。2. 数据新鲜度实时不是自动发生“同一份数据”不等于“每一毫秒都强一致可见”。列存副本可能落后于行存主副本具体落后多少取决于同步机制同步写入一致性强但可能拖慢交易延迟。异步复制交易快但分析结果可能短暂滞后。基于日志重放接近实时但需要处理顺序、版本和合并开销。3. 资源竞争分析查询会拖垮交易一条扫描几十亿行的分析 SQL可能占满 CPU、内存和磁盘 IO。如果没有隔离交易延迟会瞬间恶化。因此 HTAP 不只是存储问题还必须有副本级隔离把分析查询导到独立的列存副本。租户或资源组隔离限制分析查询使用的 CPU、内存、IO。查询准入拒绝或排队超过资源上限的 SQL。4. 一致性分析结果必须可解释分析查询需要回答“这个结果对应哪个时间点”。如果一边写入一边扫描结果可能既不是旧快照也不是新快照。多数 HTAP 系统借助 MVCC 和全局时间戳让分析查询读取一个一致快照。真正难的是这个快照离最新写入有多远业务是否接受。四、两种主流架构路线1. 双引擎副本行存主副本 列存分析副本这条路线的代表是 TiDB 的 TiKV TiFlash以及类似的行列分离架构。Raft 日志同步业务应用SQL 层TiDB Server行存引擎TiKV在线交易列存引擎TiFlash实时分析特点交易写入先落在行存路径短、延迟低。列存副本通过日志持续追赶分析请求读列存。优化器根据 SQL 成本选择行存或列存。行存和列存职责清晰但需要管理副本同步和一致性。2. 内核统一同一存储引擎同时维护行与列这条路线的代表是 OceanBase 4.x 之后的行列混合存储以及一些内存型 HTAP 产品。业务应用SQL 路由层OBProxyOBServer行存基线 列存基线行存点查 / 短事务 / 更新列存扫描 / 聚合 / 实时分析特点行存和列存处于同一套数据库内核中不依赖独立分析集群。事务、副本、租户、资源隔离可以统一管理。减少了“两套引擎 一条同步链路”的运维面。对存储格式、Compaction 和查询路由的要求更高。3. 路线对比维度双引擎副本内核统一写入路径行存优先分析副本异步追赶行存为主列存能力由内核调度查询路由优化器决定走行存或列存数据库内部决定访问行存或列存一致性列存可接近实时通常存在短暂追赶窗口可基于 MVCC 读取一致快照隔离能力分析副本天然隔离依赖租户、Unit、资源池或副本策略优势架构边界清楚分析扩展独立组件更少统一运维代表TiDB / TiFlash 类架构OceanBase 类架构五、以 TiDB 为例一条查询如何落到 TiFlash下面不是完整实现而是帮助理解“列存分析副本”参与查询的关键环节。TiKV行存按 Region 分布使用 Raft 保证多副本 TiFlash列存作为 Raft Learner 持续接收 TiKV 的日志 TiDBSQL 层负责解析、优化、执行计划选择当业务提交一个分析 SQLSELECTregion,COUNT(*)ASorder_cnt,SUM(amount)AStotal_amountFROMordersWHEREcreated_atNOW()-INTERVAL1HOURGROUPBYregionORDERBYtotal_amountDESC;TiDB 会做几件事判断查询是否适合走列存例如是否包含大范围扫描、聚合、分组。根据统计信息和成本模型在 TiKV 行存计划与 TiFlash 列存计划之间选择。如果走 TiFlash会把请求发送到包含相关 Region 列存副本的节点。TiFlash 按列读取、过滤、聚合必要时使用 MPP 模式在多节点并行执行。返回结果并尽量保证读取一个一致快照。这里的关键是列存不是“同步出来的另一套数仓”而是数据库内部可被优化器选择的副本。六、以 OceanBase 为例行列共存与资源隔离OceanBase 不是先做一个 MySQL再外挂一个 ClickHouse而是在数据库内部把行存和列存统一起来。行存主键点查、高频更新、短事务 列存大范围扫描、聚合、实时报表 OceanBase同一套 OBServer统一存储、事务和副本它的 HTAP 能力通常体现为行存与列存可以在同一租户内协作。分析查询不必然离开交易集群减少数据同步。通过租户、Resource Unit、资源池限制分析查询资源。使用 MVCC 读取一致快照避免分析结果处于中间状态。这也解释了为什么“支持列存”和“真正可用的 HTAP”之间还有距离没有资源隔离列存查询仍然可能拖垮在线业务。七、一个完整的 HTAP 查询生命周期把不同产品抽象一下一次实时分析大致经历并行执行引擎列存分析副本行存主副本元数据与统计信息SQL 优化器业务/BI并行执行引擎列存分析副本行存主副本元数据与统计信息SQL 优化器业务/BIalt[点查 / 短事务][扫描 / 聚合 / 实时分析]发起分析 SQL获取表结构、分区、统计信息判断点查还是扫描估算成本访问行存主副本返回少量行访问列存副本分片并行扫描与聚合返回部分结果汇总返回这个生命周期里最重要的不是“用了列存”而是三个决策查询应该走行存还是列存。列存副本的新鲜度是否满足业务要求。分析查询的资源是否被隔离是否会影响交易。八、不是所有查询都该进 HTAPHTAP 最适合“交易数据刚刚发生就要马上参与分析”的场景。但它并不是万能入口。场景是否优先 HTAP说明实时经营看板、实时对账是数据新鲜度要求高查询相对短操作型分析、客服明细查询是贴近业务系统响应要快超大数据量离线统计否数据仓库和数据湖更成熟复杂 ETL、宽表加工否调度、回刷和任务管理仍适合数仓历史归档与跨主题分析否数据组织方式与分析语义更复杂高频交易写后立刻读最新值是但要控制一致性语义仍要以 OLTP 路径为主一个更稳的判断是如果查询需要“较新的交易数据 扫描聚合 秒级响应”HTAP 价值最高。 如果查询主要处理“全量历史数据 复杂加工 可重跑”数据仓库仍然更合适。九、落地前要回答的五个问题1. 真正需要多“实时”不是所有指标都需要秒级。若 5 分钟延迟可以接受传统 CDC 到 OLAP 的链路可能成本更低。2. 分析查询和交易高峰是否重叠如果两者同时发生必须优先设计资源隔离而不是只验证功能能跑通。3. 数据量级和查询形态HTAP 更适合大量中小型分析查询。超大规模离线任务、复杂多轮依赖和全量重算仍应留在数仓。4. 一致性与新鲜度语义业务要区分最新已提交数据一秒前一致快照可接受的分析延迟。这三者在产品文档里可能都叫“实时”但含义完全不同。5. 运维团队是否能理解第二套执行路径引入 HTAP 后问题排查不再只是“SQL 慢”还要判断它走了行存还是列存、副本是否追赶上、资源是否被隔离。十、选型与实施清单如果已经确认需要 HTAP可以按以下顺序推进先挑 1 到 3 个高价值场景例如实时 GMV、实时对账、客服订单明细。明确数据新鲜度要求、查询延迟要求和并发规模。用真实交易流量测试写入放大、存储放大和资源竞争。对分析 SQL 做分级小查询直接跑大查询限流或进入独立资源组。观察列存副本延迟而不是只看功能是否返回结果。建立监控交易延迟、分析延迟、副本滞后、资源使用率、SQL 路由。对离线复杂分析保留数据仓库链路不让 HTAP 承担所有历史任务。评估时可以参考指标关注点数据新鲜度列存副本落后多少毫秒或秒写入影响维护列存后交易 P99 是否抬升查询收益实时报表从分钟级降低到秒级的比例资源隔离大查询出现时交易延迟是否稳定存储成本行存 列存带来的额外空间运维复杂度路由、同步、资源管理是否可观测十一、结论HTAP 的本质不是“一个数据库既能写又能查”而是重新安排同一份数据在交易路径和分析路径之间的协作方式。理解 HTAP可以抓住三句话它要解决的核心问题是数据从交易到分析的延迟和链路复杂度。它的技术难点不是列存而是存储格式、数据新鲜度、一致性和资源隔离的平衡。它的落地边界很清晰适合实时、较新、偏操作型分析不必然替代离线数据仓库。所以下一次看到“支持 HTAP”时更值得问的是列存副本如何同步 分析查询如何路由 能读到多新的快照 大查询是否会和交易争抢资源把这些问清楚HTAP 才从一个宣传词变成可推理、可验证、可落地的架构。