摘要：2025年9月1日至9月5日，作为数据库顶会之一的 VLDB 2025在伦敦如期召开。在此次会议中，众多数据库领域的第一梯队科技公司纷纷投稿，展现其在 Analytic Processing（分析型数据处理）工业化之路上的成果，其中囊括了 Databricks

会议背景

2025年9月1日至9月5日，作为数据库顶会之一的 VLDB 2025在伦敦如期召开。在此次会议中，众多数据库领域的第一梯队科技公司纷纷投稿，展现其在 Analytic Processing（分析型数据处理）工业化之路上的成果，其中囊括了 Databricks 的 Delta Sharing、Snowflake 的 Data Cloud 等。作为字节跳动唯一一款 TP&AP 高度集成的 HTAP 数据库，数据库团队与基础技术团队的论文 veDB-HTAP：a Highly Integrated， Efficient and Adaptive HTAP System也被其收录其中。

这是字节跳动 HTAP 团队继 VLDB 2022 论文 ByteHTAP：ByteDance’s HTAP System with High Data Freshness and Strong Data Consistency后，TP&AP 融合系统在字节的进一步工业化落地成果。

veDB-HTAP 诞生背景

随着市场数字化转型的深入，企业对数据处理的实时性与一致性需求日益严苛。在传统数据架构中，联机事务处理（OLTP）与联机分析处理（OLAP）系统的分离部署导致数据孤岛、同步延迟等问题，难以满足业务系统实时决策的场景需求。在此背景下，混合事务分析处理（HTAP）技术应运而生，其核心目标是通过单一架构同时支持高并发事务与复杂分析查询，实现“一份数据、两种能力”的集成化处理。从技术演进来看，HTAP 系统经历了从“松耦合集成”（如基于 ETL 的数据同步）到“紧耦合融合”（如共享存储引擎）的发展阶段，但早期字节的 ByteHTAP 方案在语义一致性、路由效率与扩展性方面仍存在显著瓶颈。

作为字节跳动内部早期的 HTAP 系统，ByteHTAP 在实践中暴露出三大核心局限：其一，语义差异问题，OLTP 与 OLAP 引擎采用独立元数据管理，导致表结构变更同步延迟，引发查询结果不一致的风险；其二，规则路由低效，基于静态配置的查询路由策略无法动态感知数据分布与系统负载，在高并发场景下易出现资源争抢或算力浪费；其三，Flink 引擎扩展性不足，作为实时计算核心组件，Flink 在面对超大规模数据（如千万级表）时，任务启动耗时与资源占用显著增加，难以支撑秒级查询时延的实时性需求。随着字节业务的上量，分离架构下数据同步延迟与资源冗余的问题、以及在查询语义一致性、动态适应性与横向扩展能力上的缺陷日渐突显。

针对上述问题与挑战，我们延续 ByteHTAP 的 TP->AP 复制下沉的存算分离架构，将上层的 TP/AP 计算引擎做进一步集成融合，孕育出 veDB-HTAP 系统——以“突破集成架构瓶颈、满足企业级规模需求”为设计目标，重点围绕语义统一、智能路由与引擎架构创新三大方向展开技术探索与工业化落地，此外，该系统需同时满足“支持千万数据表”的元数据管理能力与亚秒级分析响应延迟。

因此，字节跳动数据库和基础技术团队进一步推动 HTAP 集成架构的发展，成就了 veDB-HTAP 这一系统的工业化落地。

HTAP 技术演进与相关工作研究

根据架构设计范式的差异，当前业界 HTAP 系统可分为三类主流技术路线，其核心特性对比与技术演进逻辑如下：

传统集成架构：单机内存优化的局限性

以 SAP Hana 为代表的传统集成架构，通过内存列式存储实现事务与分析的混合处理，其核心优势在于消除 I/O 瓶颈，支持毫秒级复杂查询。但该架构受限于单机内存容量，扩展性差，且强一致性依赖单机事务机制，难以满足分布式场景下的高可用需求。

分布式分离架构：扩展性突破与一致性挑战

TiDB 等分布式分离架构采用计算存储分离设计，通过分布式 KV 存储（如 RocksDB）与 MPP 计算引擎的组合，实现横向扩展。但其一致性模型依赖 2PC 协议，在高并发事务场景下存在性能损耗，且查询路由需跨节点协调，增加了延迟[1]。

云原生增强架构：弹性优化与数据新鲜度权衡

PolarDB、AlloyDB 等云原生系统利用共享存储池与弹性计算节点，显著提升资源利用率。然而，为平衡分析性能，这类系统常采用读副本异步同步机制，导致分析数据存在秒级延迟（如 PolarDB 读副本的 RPO 通常为 1～2 秒），难以满足实时性要求高的场景。

veDB-HTAP 系统架构

veDB-HTAP 在吸收上述架构经验的基础上，以“架构高度集成”为主线，通过三层架构创新实现 OLTP 与 OLAP 工作负载的深度融合，构建了兼具集成性、扩展性与一致性的新一代 HTAP 系统，系统架构如下图所示：

基于 MySQL Secondary Engine 的高度集成架构

区别于 OLTP 主库+独立分析集群的分离架构，veDB-HTAP 采用社区 MySQL 二级引擎（Secondary Engine）扩展模式，将分析引擎深度集成至 MySQL 内核。事务数据写入时，通过 Binlog 实时同步至分析存储（列式引擎），避免跨集群数据移动开销。这种设计使分析查询可直接访问最新事务数据，且无需修改 MySQL 原有生态工具链，兼容性显著优于独立部署方案。

分布式 MPP 的弹性扩展能力

针对传统 MPP 集群资源固定、扩缩容复杂的问题，veDB-HTAP 采用无状态计算节点+共享存储架构。计算节点可根据查询负载弹性扩缩，通过统一元数据服务实现动态负载均衡。测试数据显示，在100节点规模下，其分析性能随节点数呈近线性增长，扩展效率较 TiDB 提升约30%。

多粒度 LSN 对齐的 Read Committed 隔离

为解决云原生架构数据新鲜度不足的问题，veDB-HTAP 提出多粒度 LSN（日志序列号）对齐机制：在事务提交时，同时记录行级与表级 LSN，分析引擎通过 LSN 快照精确对齐事务一致性视图。与 PolarDB-SCC 的“库级快照”相比，该机制将数据新鲜度从秒级降至亚毫秒级，且避免了全表锁开销，在 TPC-C 混合负载测试中，事务吞吐量下降幅度控制在 5%以内。

veDB-HTAP 通过“内核级集成+弹性计算+精细一致性控制”的三重创新，突破了传统架构在兼容性、扩展性与实时性上的三角困境，尤其适用于金融风控、实时报表等对事务一致性与分析实时性均有高要求的场景。

通过与三类主流架构的对比可见，HTAP 技术正从“单一优化”向“系统级协同”演进，而 veDB-HTAP 的设计路径为平衡集成性、扩展性与一致性提供了新的技术范式。

veDB-HTAP：TP&AP 集成

veDB-HTAP 系统的核心设计围绕引擎协同、计算优化与资源治理三大维度展开：

OLTP 与 OLAP 的集成： veDB-HTAP Plugin 的协同机制

系统通过 veDB-HTAP Plugin实现双引擎的无缝衔接，该插件作为核心协调层，具备三大关键功能：分布式查询计划生成、LSN 日志对齐与智能重试机制。在查询计划生成阶段，Plugin 会根据 SQL 语义自动判断工作负载类型——对写密集型事务直接路由至 OLTP 引擎，对复杂分析查询则分解为混合执行计划，将扫描算子下推至 OLAP 引擎。LSN（Log Sequence Number）对齐技术确保 OLAP 节点的数据与 RW（Read-Write）主节点保持实时一致，通过解析 WAL 日志的 LSN 偏移量，RO（Read-Only）副本可精准同步增量数据，避免传统 HTAP 系统中“数据可见性延迟”问题。针对分布式环境下的网络抖动或节点故障，Plugin 内置的自动重试机制会基于事务 ID 进行幂等性处理，确保查询执行的原子性。

RW 节点与 RO 节点采用读写分离架构：RW 节点专注于处理 OLTP 事务，维护行存数据与索引结构；RO 节点则搭载 MPP 分析引擎，通过列存格式加速复杂查询。二者通过 Plugin 实现元数据与数据日志的双向同步，形成“事务写入-日志同步-分析可用”的闭环流程。如图 1 所示，组件交互呈现三层数据流：RW 节点的事务日志经 Plugin 解析后，通过 LSN 对齐通道推送至 RO 节点；RO 节点生成的分析结果经 Coordinator 聚合后返回客户端；Cluster Manager 则动态调节节点资源配比，确保双引擎负载均衡。

MPP OLAP 引擎：Stateless 计算架构的性能突破

系统的 OLAP 能力基于无状态 MPP 处理器（stateless MPP processor）构建，其架构设计突破传统分布式计算框架的局限。在计算调度层，Coordinator 节点负责全局查询优化，通过代价模型生成分布式执行计划：首先对 SQL 进行语义解析与重写，再基于数据分布统计信息（如分区键、数据倾斜度）进行算子拆分，最终将任务片段分配至 Data Server 集群。与 Flink 等流批一体框架相比，veDB-HTAP 的 MPP 引擎在批处理场景下表现出显著优势——Flink 基于“持续计算”模型设计，其 Checkpoint 机制会引入毫秒级延迟，且状态存储依赖本地磁盘导致扩展性受限；而 stateless MPP processor 采用无状态设计，所有中间结果通过网络 shuffle 传输，配合向量化执行引擎，单节点可实现每秒千万级行的扫描性能。

veDB-HTAP 的 Data Server 节点作为并行执行单元，采用 Shared Nothing 架构，每个节点独立管理本地列存数据分片。在执行阶段，Data Server 会对下推的算子进行向量化编译，将过滤（Filter）、聚合（Aggregate）等操作转化为 SIMD 指令，大幅提升 CPU 利用率。针对多表关联场景，系统支持哈希连接（Hash Join）与排序合并连接（Sort Merge Join）的自适应选择，并通过动态负载均衡算法避免热点节点，确保分布式计算资源的高效利用。

统一存储与资源治理：Disaggregated Storage 与多租户隔离

存储层采用分离式存储（disaggregated storage）架构，将计算节点与存储介质解耦，通过分布式块存储系统（如 Ceph 或 veStore）提供统一数据访问接口。该架构的核心优势在于谓词下推（predicate pushdown）能力：存储节点可直接解析查询中的过滤条件（如 WHERE 子句），在数据读取阶段完成无效记录过滤，使传输至计算层的数据量减少 60%-80%。同时，分离式存储支持按需扩展存储容量，无需中断计算服务，解决传统一体机“存储与计算绑定”导致的资源浪费问题。

资源管理层面，Cluster Manager 通过资源组隔离机制实现多租户环境下的精细化管控。管理员可基于租户优先级创建资源组，为每个组分配 CPU 核数、内存配额与 IOPS 上限，通过 Linux cgroups 实现硬隔离。当某租户触发资源超限时，系统会自动降级其非核心查询（如将复杂报表查询队列优先级调低），确保高优先级事务不受影响。此外，Cluster Manager 支持资源弹性伸缩，基于实时负载监控（如 CPU 利用率、查询队列长度）动态调整资源组配额，使整体资源利用率提升至 85% 以上。

综上所述，veDB-HTAP 通过如下：

引擎协同：veDB-HTAP Plugin 通过 LSN 对齐与智能重试实现双引擎数据一致性与高可用

计算优化：stateless MPP processor 消除状态依赖，配合向量化执行提升分析性能

存储创新：disaggregated storage 的 predicate pushdown 大幅减少数据传输开销

资源治理：资源组隔离与弹性伸缩保障多租户环境的稳定性与资源效率

实现了 OLTP 与 OLAP 工作负载的原生集成，其计算-存储分离与无状态 MPP 处理的技术组合，为企业级 HTAP 场景提供了兼具高性能与灵活性的解决方案。

veDB-HTAP：高度协同

veDB-HTAP 系统在 OLTP 与 OLAP 引擎协同设计中面临两大核心挑战：消除引擎语义差异与提升查询路由准确性。通过创新性的快照对齐机制与智能路由框架，系统实现了事务处理与分析处理的高效协同，为混合负载场景提供了底层技术支撑。

语义一致性保障：基于 LSN 的跨引擎快照对齐

OLTP 与 OLAP 引擎的原生差异导致数据快照一致性难以保障，veDB 通过物理日志记录逻辑 LSN 与流水线等待+细粒度 LSN 检查的双层机制解决这一问题。在日志层面，系统突破传统物理日志仅记录页级修改的限制，创新性地在物理日志条目中嵌入逻辑事务的日志序列号（LSN），使 OLAP 引擎能够直接通过物理日志追踪逻辑事务的提交状态，避免因日志格式转换导致的一致性偏差。在快照同步层面，采用流水线等待策略减少 OLAP 查询对 OLTP 事务的阻塞——当 AP 查询请求快照时，系统通过预计算事务依赖关系，仅等待关键 LSN 推进而非完整事务提交；同时引入细粒度 LSN 检查机制，在 AP 引擎回放日志时逐段验证 LSN 连续性，确保快照版本与 TP 引擎的事务状态精确匹配。实验数据表明，该机制在保证 RC（Read Committed）隔离级别的前提下，将查询延迟增加控制在200ms以内，实现了一致性与性能的平衡。

智能路由创新：从成本基到学习基的范式升级

查询路由的准确性直接决定 HTAP 系统的资源利用率。传统成本基路由依赖预定义的代价模型估算执行成本，但在复杂混合负载场景下存在显著局限性。查询涉及多表关联或非均匀数据分布时，成本模型的估算值与实际执行时间偏差可达 30%以上，导致路由决策失效。

veDB-HTAP 提出基于 Tree-CNN 模型的学习路由框架，通过深度学习技术实现 TP/AP 计划的精准编码与比较。该模型将查询计划树结构转化为多层张量，利用卷积神经网络提取计划特征（如操作符类型、数据分布、谓词复杂度等），并通过孪生网络架构对比 TP 与 AP 引擎的计划特征向量，最终输出路由决策。学习路由的 workflow 包括四个核心阶段：首先，系统对输入查询进行语法解析，生成 TP 引擎与 AP 引擎的候选执行计划树；随后，Tree-CNN 模型将计划树转化为结构化张量，通过卷积层与池化层提取层级特征；接着，通过余弦相似度对比 TP 与 AP 计划的特征向量，判断哪个引擎更适合执行该查询；最后输出路由决策，将查询分发至最优引擎。

论文中的实验结果显示，学习路由在混合负载测试中实现了 94.3%的路由准确率，较传统规则路由（80%准确率）提升 14.3 个百分点，尤其在复杂 AP 查询与短事务 TP 查询的混合场景中表现更优。Tree-CNN 模型对计划结构的深度编码能力，使其能够捕捉成本模型难以量化的隐性特征（如数据倾斜对 AP 计划的影响），从而实现更符合实际执行效率的路由决策。

通过如下三点，veDB-HTAP 实现了 TP&AP 的高效协同：

语义一致性：通过逻辑 LSN 嵌入与细粒度检查，实现 TP/AP 快照亚毫秒级对齐

路由智能化：Tree-CNN 模型突破传统成本模型局限，路由准确率提升14.3%

性能平衡：RC 隔离下查询延迟增幅

veDB-HTAP：自适应查询处理技术

veDB-HTAP 系统的高效自适应查询处理技术通过动态感知数据特征与系统资源状态，实现查询执行效率的显著提升。该技术体系以 运行时统计优化 与 资源感知优化 为核心支柱，构建了一套完整的自适应执行框架，可根据实时环境动态调整执行策略。

运行时统计优化：从静态估算到动态感知

传统查询优化依赖预计算的统计信息（如基数、直方图），在数据分布动态变化或长尾查询场景下易产生估算偏差，导致执行计划低效。veDB-HTAP 采用 按需统计采样机制，通过以下技术路径实现精准优化：

选择性估算与 NDV 近似：针对高基数列或倾斜数据分布，系统在查询执行期间触发动态采样，通过分层抽样算法快速获取数据分布特征，实时修正选择性估算误差。对于基数（NDV）估算，结合 HyperLogLog 与稀疏采样技术，在1%采样率下即可将 NDV 误差控制在5%以内，显著优于传统静态统计。

哈希表选择逻辑：根据实时数据量与内存负载动态切换哈希表实现：在低负载因子（

运行时过滤成本模型：基于实时统计数据构建动态过滤决策模型，通过评估过滤条件的选择性收益与计算开销，决定是否在执行过程中插入中间过滤算子。例如，对于包含多表连接的复杂查询，系统会优先过滤高选择性条件的表，将后续连接数据量减少60%～80%。

核心性能收益：在 TPC-H 1TB 数据集测试中，按需统计优化使整体查询执行时间从 1415 秒降至 379 秒，性能提升 2.7 倍；针对 Q3 等包含复杂过滤条件的查询，运行时过滤策略单独贡献了 13% 的性能提升，主要源于减少了无效数据的 I/O 与计算开销。

资源感知优化：系统状态驱动的执行调整

面对 HTAP 场景下混合负载带来的资源竞争（如 OLTP 事务与 OLAP 分析的资源抢占），veDB-HTAP 设计了资源感知执行引擎，通过以下创新策略实现系统资源的动态调度：

自适应磁盘溢出机制：区别于传统基于固定阈值（如内存使用率 90%）的被动溢出，veDB-HTAP 采用“软限制+硬限制+选择性溢出”三级策略：软限制阶段通过 LRU 淘汰低访问频率数据释放内存；硬限制触发时，根据数据块的“重计算成本”（如聚合中间结果 vs 原始数据）选择性溢出，优先保留高价值中间数据。该策略在 TPC-DS 测试中，将溢出导致的性能损耗从传统方法的 40% 降至 15% 以内。

CPU 负载感知的谓词下推：系统实时监控 CPU 核心利用率，当检测到 CPU 负载超过 80% 时，自动调整谓词下推深度——暂停复杂表达式（如正则匹配、数学函数）的下推，转而在内存中进行轻量级过滤；负载低于 50% 时则恢复全量下推，充分利用计算资源。在混合读写场景下，该机制使系统 QPS 提升 20%，同时将查询延迟波动控制在 10% 以内。

多租户内存超配场景适配：在 multi-tenant memory overcommit 场景中，资源感知优化通过动态调整查询并行度与内存分配粒度，避免了传统共享内存架构下的“内存踩踏”问题。例如，当检测到租户内存超配率超过 120% 时，系统会为长查询启用“内存预算制”，严格限制单查询内存占用，保障小查询的响应延迟（P99 延迟降低 35%）。

自适应执行工作流：技术路线可视化

veDB-HTAP 的自适应查询处理技术通过统一的执行框架串联上述优化策略：

查询解析与初始计划生成：基于静态元数据生成 baseline 执行计划

运行时统计收集：执行过程中实时采集数据分布（选择性、NDV）与系统状态（CPU/内存使用率）

动态计划调整：根据统计数据触发哈希表切换、谓词下推调整等优化

资源冲突仲裁：若检测到资源紧张（如内存不足、CPU 过载），启动溢出控制或并行度调整

结果返回与统计反馈：执行完成后，将运行时统计结果反馈至优化器，迭代优化后续查询。

该 workflow 实现了“监控-决策-执行-反馈”的闭环，使 veDB-HTAP 能够在复杂 TP/AP 混合负载环境中保持高效稳定的查询性能。

技术创新与未来展望

创新总结

veDB-HTAP 系统通过五大核心技术创新构建了融合事务处理与分析能力的新型数据管理架构，有效解决了传统 HTAP 系统面临的兼容性、性能与资源隔离难题。

基于 MySQL Secondary Engine 的深度集成架构实现了与 MySQL 生态的无缝对接，通过复用 MySQL 成熟的事务处理引擎（InnoDB）作为 OLTP 层，同时在 Secondary Engine 层构建列式存储分析引擎，避免了数据双写与一致性维护的复杂性。这种架构设计使现有 MySQL 用户无需重构应用即可平滑扩展分析能力，显著降低了迁移成本与技术门槛。

Tree-CNN 驱动的跨引擎查询路由机制突破了传统规则式路由的局限性，通过树形卷积神经网络（Tree-CNN）对 SQL 查询的语法树结构进行深度特征提取，结合历史执行性能数据动态预测最优执行引擎（OLTP 或 OLAP）。该模型在 TPCH 测试集上实现了 92% 的查询路由准确率，将跨引擎查询平均响应时间缩短 40% 以上。

统计与资源双维度自适应执行框架构建了多层次优化体系：在统计维度，通过实时收集表数据分布、索引选择性等统计信息调整执行计划；在资源维度，基于 CPU、内存、I/O 负载动态分配计算资源。实验表明，该框架在混合负载场景下的系统吞吐量较静态配置提升 35%，且查询延迟波动降低 28%。

分离式存储的谓词下推与日志同步技术实现了存储层的高效协同。列式存储引擎支持细粒度谓词下推，将过滤操作下沉至存储层减少数据传输量；基于物理日志（PHY-LOG）的同步机制确保 OLTP 与 OLAP 引擎数据一致性，同步延迟控制在毫秒级，解决了传统 ETL 同步的时效性瓶颈。

多租户资源隔离与弹性扩展机制通过轻量级虚拟化技术（如容器化资源切片）实现租户间 CPU、内存、I/O 资源的硬隔离，隔离度达99.9%。结合动态资源调度算法，系统可根据租户负载变化在 30 秒内完成资源弹性伸缩，满足高并发场景下的租户差异化需求。

现存技术局限

尽管 veDB-HTAP 系统在架构创新上取得突破，仍存在两方面关键局限：其一，学习路由的模型更新策略面临实时性与准确性的权衡，当前离线训练 + 定期更新模式难以适应数据分布剧变场景（如促销活动导致的查询特征突变），可能引发路由决策偏差；其二，磁盘溢出的决策延迟优化不足，当内存不足以容纳中间结果时，现有基于阈值的溢出触发机制存在 200-500 毫秒决策延迟，影响大规模复杂查询的执行效率。

未来探索之路

面向下一代 HTAP 系统发展需求，结合“LLM for query optimization”技术趋势，veDB-HTAP 将会在以下方向深化研究：

AI 增强的自适应计划生成：利用大语言模型（LLM）的语义理解能力解析复杂查询意图，结合查询历史与数据特征库动态生成跨引擎执行计划。例如，通过 LLM 将自然语言查询转换为最优 SQL 语句，并自动选择 OLTP/OLAP 执行路径，实现“意图-计划-执行”全链路智能化。

端到端自动化运维体系：构建基于多模态监控数据（性能指标、日志、告警）的 AI 运维平台，通过 LLM 分析系统异常根因并自动执行修复操作（如索引推荐、参数调优、故障自愈），将运维响应时间从小时级压缩至分钟级。

存算分离架构升级：探索基于全闪存储与计算节点解耦的分布式架构，结合 RDMA 高速网络实现存储层的弹性扩展，解决当前分离式存储在超大规模数据集下的元数据管理瓶颈，进一步提升系统吞吐量与容错能力。

关于产品

veDB MySQL 版是字节跳动自研的基于计存分离架构的云原生分布式数据库，100%兼容 MySQL 5.7、MySQL 8.0。支持一主多备部署，具备高弹性、高并发、高可用的企业级数据库能力，历经字节跳动内部业务与外部的丰富场景与海量流量打磨。在字节跳动内部，veDB MySQL 在关系型数据库领域占比超过70%，总实例数10万级，数据量百 PB 级，支撑所有业务线（抖音/电商/财经/广告/番茄小说/懂车帝/豆包/飞书等），覆盖全球7个服务区。在春晚红包雨活动中，全国一共发起了703亿次红包雨互动，veDB MySQL 集群承接读写 QPS 峰值超过800万。

来源：字节跳动技术团队