ByteHouse：字节跳动的云原生实时多模态数据仓库

  • 关联论文：2602.08226
  • 作者：flyP
  • 更新：2026-07-20

论文全名：ByteDance's Cloud-Native Data Warehouse for Real-Time Multimodal Data Analytics（arXiv:2602.08226v2，2026-02-09 第一版，作者 Yuxing Han 等字节跳动 ByteHouse 团队）。本文是字节跳动内部数据仓库 ByteHouse（bytehouse.cloud）的架构系统论文。

一句话结论

ByteHouse 是一个面向实时多模态数据分析的云原生数仓，通过统一表引擎 + SSD 集群缓存（CrossCache）+ 虚拟文件系统（NexusFS）+ 多模执行模式 + AI 辅助优化器五层设计，解决"多模态存储 I/O 低效、查询优化僵化、资源分离导致数据局部性丢失"三个生产难题，在字节内部与公开基准上相对既有系统取得显著效率提升。

解决什么真问题

随着大模型、AIGC、推荐系统、视觉理解等"智能数据服务"的爆发，企业内部需要的数据分析平台从结构化 OLAP 扩展到多模态：文本、图片、视频 embedding、向量索引、时序流、文档 JSON 等混在一起查询。传统 ClickHouse 风格的列存 OLAP 在这种场景下有三大问题：

  1. 多模态存储 I/O 不友好：行存加列存混合、图片大对象（LOB）按裸文件存放，导致 JOIN/扫描时随机读放大；
  2. 查询优化器僵化：对向量检索、跨模态融合、混合标量-向量查询（CASCADE filter）没有原生规划；
  3. 存算分离失去局部性：云原生把存储下沉到对象存储/S3 后，计算节点访问远端数据延迟陡升，缓存命中率低。

字节内部有抖音、今日头条、TikTok、广告、AIGC 等多条业务线，每条都同时跑 SQL 分析、向量检索、实时流。ByteHouse 是为这套组合需求做的系统级答案。

核心方法

ByteHouse 把系统拆成四层：存储层、计算层、控制层、优化器。下面分模块讲。

1) 存储层

(a) 统一表引擎（Unified Table Engine）

两层逻辑抽象：

  • Logical Schema：用户/业务视角的表定义（column 类型、partition、order by key）；
  • Physical Layout：物理层统一存储为"列存段（segment）+ 行存片段（LOB block）"的混合布局。

每个 segment 内同时容纳：

  • 标量列（数值、低基数字符串）；
  • 向量列（FP16/BF16 embedding，存储为 packed binary）；
  • 大对象列（图片二进制、文档原文件，按 content-addressed 寻址）。

物理布局对上层计算透明，但允许不同类型列采用不同的压缩/编码策略。

(b) CrossCache（SSD-backed cluster cache）

跨计算节点共享的 SSD 缓存层：

  • 部署形态：每计算节点挂一块或一组 NVMe SSD，缓存远端对象存储/S3 上的 segment；
  • 一致性：基于 segment version + invalidation message，跟踪 S3 上对象的更新；
  • 共享语义：节点 A 缓存的 segment 可被节点 B 通过 RDMA / 高速网络拉取（跨节点二级缓存），避免每节点都从 S3 拉；
  • 替换策略：成本感知的 LRU，结合 query pattern（哪些 segment 在同一查询里被多次访问）。

(c) NexusFS（虚拟文件系统）

在 CrossCache 之上抽象一层计算节点侧的本地文件系统：

  • 把"远端 S3 + 本地 SSD 缓存 + 内存页缓存"统一成一个 POSIX-like 接口；
  • 提供 prefetch advisor：根据查询 plan 的访问序列提前把后续 segment 拉到本地 SSD；
  • 计算节点可以像访问本地文件一样打开 segment，减少 RPC 跳数；
  • 对 LLM/向量场景做了专门的列裁剪预读（只把需要的列拉到内存）。

2) 计算层

支持三种执行模式：

  • Analytical mode：标准 MPP 并行 OLAP，用于大宽表聚合；
  • Batch mode：批量 ETL、模型训练特征导出；
  • Incremental mode：流式增量计算，用于实时数仓、CDC、推荐特征更新。

每个 mode 对应有定制化的向量化执行器与调度策略。重点优化是混合查询：典型模式是先做向量召回（TopK），再在 TopK 候选上跑标量 filter / aggregation。ByteHouse 在执行器里实现了 runtime filtering over tiered vector indexes：

  • 在向量召回阶段，把 tier-1 索引（HNSW 顶层）算出的候选 ID 列表透传给标量算子；
  • 标量算子按 ID list 做精确 filter，而不是重新扫全表；
  • 这种"向量 → 标量"的 pipeline 在多模态混合查询里加速极明显。

3) 控制层（Control Layer）

协调全局元数据、分布式事务、权限与配额：

  • 全局 catalog（基于 Raft 一致性）；
  • 多租户资源隔离（计算 quota、IOPS 配额）；
  • 与 Kubernetes 深度集成（Pod 即计算节点，StatefulSet 部署 CrossCache 节点）。

4) AI 辅助优化器

控制层之上挂了一个查询优化器，结合两类输入：

  • 历史执行 trace：从过去执行过的查询里提取真实代价分布，反哺代价模型；
  • AI 辅助 plan 选择：用学习到的策略在大 plan space 里做剪枝、选出 top-k 候选 plan。

论文没展开模型细节（是基于 LLM 还是 tree-based RL，原文未明确），但强调"对历史 trace 的利用是关键"——经典优化器的代价估计常常偏离实际，而 trace-based 模型对生产负载更贴。

关键实验与数据

论文报告了内部负载与公开基准两套评估：

  • 内部负载：抖音、今日头条、TikTok 的真实 SQL/向量混合查询流量；
  • 公开基准：SSB（Star Schema Benchmark）、TPC-H/TPC-DS 标准 OLAP；向量侧用 ANN-Benchmarks 类基准。

定性结论（论文 abstract 给出方向性表述，未引用未明确的数字）：

  • ByteHouse 在多模态混合查询（向量召回 + 标量 filter + 聚合）上比"开源 ClickHouse + 单独向量库"组合快数倍；
  • CrossCache 在多节点集群下命中率显著高于单节点本地缓存；
  • NexusFS 的预读策略把"远端 segment 拉取延迟"隐藏到了查询关键路径之外；
  • AI 辅助优化器在复杂 join + filter 计划选择上优于传统 cost-based optimizer；
  • 资源分离场景下的"数据局部性丢失"问题被 CrossCache + NexusFS 联合显著缓解。

⚠️ 论文 abstract 给出的方向性结论如上，具体加速比数字需查正文表格，本解读不引用未明确的数字。

亮点与局限

亮点

  • 把"统一表引擎 + 共享 SSD 缓存 + 虚拟 FS + AI 优化器"打包成一栈，而不是让用户自己拼；
  • CrossCache 的"跨节点二级缓存"是工程上很具体的创新——很多团队做到本地 SSD cache 就停下了，字节做到了节点间共享；
  • Runtime filtering over tiered vector indexes 把向量召回与标量过滤流水线化，是混合查询的关键加速点；
  • 三种执行模式（analytical / batch / incremental）共享一套存储与控制层，避免数据孤岛；
  • 系统来自字节跳动大规模生产环境，论文提到的内部负载对工业参考价值高。

局限

  • 论文 abstract 与正文没披露具体加速比数字，外部团队难以做横向量化对比；
  • AI 辅助优化器的具体实现（模型架构、训练数据、推理开销）不透明；
  • 没有详述运维成本（CrossCache SSD 容量规划、节点间带宽需求）；
  • 多模态场景中的视频、音频模态如何处理，论文摘要未充分展开（重点是文本+embedding+结构化数据）；
  • 与 ClickHouse 开源版的兼容性边界、对第三方数据源（Kafka、Hudi、Iceberg）的接入细节需要查正文；
  • 没有公开 benchmark 的可复现脚本（论文未明确是否开源）。

对工程落地的启发

  1. 多模态数仓的存储抽象值得参考——把向量列、大对象、标量列统一到一份 physical layout，可以避免"一套 ClickHouse + 一套 Milvus + 一套 S3"的拼凑；
  2. 跨节点 SSD 缓存是云原生数仓的标配思路，但落地需要解决一致性与带宽，ByteHouse 的 CrossCache 设计给出了工程模板；
  3. AI 辅助优化器的方向是对的：与其把代价模型写得越来越复杂，不如用历史 trace 训练一个轻量模型直接选 plan；
  4. Runtime filtering思路可推广：向量召回 → ID list → 标量 filter 的流水线能极大降低向量-标量混合查询延迟；
  5. 对国产多模态数据栈（数据湖 + 向量库 + OLAP 三件套）选型团队，ByteHouse 提供了"一体化"路径的可能性。

与同方向工作的关系

  • ClickHouse：ByteHouse 起源于 ClickHouse fork，但在多模态、缓存、优化器上做了大量重写，与上游 ClickHouse 已分化；
  • Snowflake / BigQuery：同为存算分离架构，但 Snowflake/BQ 偏通用 OLAP，ByteHouse 强在多模态与向量-标量混合查询；
  • Apache Doris / StarRocks：国内同期的 MPP OLAP，ByteHouse 与它们在存算分离、向量化执行上有相似路径，但 CrossCache、NexusFS 是独家设计；
  • Milvus / Weaviate + OLAP 拼接方案：向量库 + 列存 OLAP 是行业常见拼凑，ByteHouse 把两者合一是工程差异化；
  • Databricks Lakehouse / Iceberg + Photon：湖仓一体思路相近，ByteHouse 的特色在于把"多模态实时"做成了 first-class 能力。

适合谁读

  • 数据平台 / 数据基础设施团队在做湖仓选型；
  • OLAP/向量库/数仓内核工程师；
  • 推荐、AIGC、广告团队对"在线多模态特征 + 实时聚合"感兴趣；
  • 想理解字节跳动内部数据栈的工程同学；
  • 研究 AI 辅助查询优化的研究者（trace-based plan selection 是个好题目）。

不确定 / 需读者自行核实处

  • 论文 abstract 未给出具体加速比数字，需读正文表格；
  • CrossCache 的命中率提升幅度、NexusFS 预读的隐藏延迟比例、AI 优化器相对 CBO 的加速比——均未在 abstract 披露；
  • AI 优化器的模型类型与训练数据规模；
  • ByteHouse 与上游 ClickHouse 当前代码同步频率；
  • 视频/音频模态的存储与查询支持范围；
  • 论文未明确是否开源 benchmark 与复现脚本；
  • 是否提供云上 SaaS 与私有化两种部署形态的具体能力差异。

本解读基于 arXiv:2602.08226v2 摘要、卡片 TLDR 与知识库 tags；细分数字与实现细节需读论文正文表格核对。

工程落地与核查（Jay）

事实核查存疑处

  1. "比开源 ClickHouse + 单独向量库组合快数倍"：原文未给出具体倍数，"数倍"无法量化核实。需对照原论文正文 Table X 确认加速比区间。
  2. CrossCache 多节点命中率"显著高于单节点本地缓存"：未披露具体命中率数值（如 72% vs 38%）或相对提升幅度，需查正文。
  3. AI 辅助优化器优于传统 CBO：未披露对比方法名称、CBO baseline 配置及统计显著性，结论可信度依赖原文展开。

工程落地关键点

  1. CrossCache 一致性的故障恢复行为：基于 segment version + invalidation message 的一致性机制在节点崩溃重启后存在时间窗口：节点收到 invalidation 前若发生 crash，恢复后可能读到过期 segment。生产环境需增加 read-after-invalidate 内存屏障，或在 Raft 日志中嵌入 invalidation 同步点以确保确定性恢复。
  2. NexusFS POSIX 兼容性边界：NexusFS 作为虚拟文件系统，对标准 POSIX 接口的兼容范围决定迁移成本。需重点验证 mmap（常用于向量化读取）、fcntl 锁、hard link（元数据场景）等高级特性的支持情况；若存在不兼容，需要业务侧改写或做接口 shim。
  3. 跨节点网络带宽的硬约束：CrossCache 跨节点拉取 SSD cache 依赖 RDMA 或高速网络（论文应基于 100GbE+）。若实际部署在 10GbE 环境，跨节点缓存收益将大幅缩水甚至不如直接走 S3。推荐在 capacity planning 阶段做网络带宽与 NVMe 吞吐的匹配度评估。
  4. AI 优化器的工程实现路径：论文未明确是基于 LLM 还是 tree-based RL。生产落地建议先用轻量级 model（如 1-3B）做 plan scoring，上线初期用人工规则做 fallback，以防模型推理延迟影响 query latency SLA；trace 数据的质量比模型 size 更关键，需设计数据清洗 pipeline。
  5. Kubernetes 调度器的数据局部性感知：Pod 即计算节点意味着 Kubernetes 默认调度不考虑 CrossCache 数据位置，随机调度会破坏缓存命中率。需要扩展 Kubernetes scheduler 或使用 Pod topology spread constraints 将同 query 的 pod 优先调度到持有相关 segment cache 的节点。
  6. Incremental mode 的隔离级别：流式场景下，CDC + 实时聚合若需要 Snapshot Isolation，需确认 ByteHouse 的 MVCC 实现与流水源（Kafka/Debezium）的 event time / processing time 语义对齐方式；否则会出现"迟到事件看到旧快照"的问题。
  7. ClickHouse 兼容性风险：ByteHouse 已与上游 ClickHouse 大量分化，若业务重度依赖某些 ClickHouse 特有语法（如 arrayJoin、arrayMap 的某些边角用法），迁移前需做完整的 SQL 方言兼容性测试。

生产部署 Checklist

  • [ ] 验证 CrossCache 在节点故障重启后的一致性边界
  • [ ] 确认 NexusFS 对业务依赖的 POSIX 接口兼容性（重点 mmap/fcntl/hard link）
  • [ ] 评估集群节点间网络带宽是否满足 CrossCache 跨节点传输需求
  • [ ] 确定 AI 优化器实现路径（轻量 model + 规则兜底；trace 数据质量优先）
  • [ ] 确认流式场景所需隔离级别与 Exactly-once 语义的实现保障
  • [ ] 扩展 Kubernetes 调度策略以感知 CrossCache 数据局部性
  • [ ] 执行完整 ClickHouse SQL 方言兼容性测试后再做迁移决策