Apache Doris 4.1：面向 AI & Search 的统一数据存储与检索底座技术能力

一句话摘要：Apache Doris 4.1 在 AI & Search 方向系统性演进，包括 IVF/IVF_ON_DISK 向量索引（查询性能最高 +4×、百亿至万亿级向量存储）、search() 全文检索（ES query_string 兼容 + BM25 + Nested）、100MB JSON 文档原生存储、Segment V3 宽表元数据解耦（打开 +16×、内存 -60×）、SSB/TPC-H/TPC-DS 性能 +14.3%/+22.6%/+19.1%，并将 ClickBench 100GB 冷查询性能与存储排名第一。

关键词：Apache Doris · SelectDB · Apache Doris 4.1 · IVF · IVF_ON_DISK · Vector Search · search() 全文检索 · 100MB JSON · Segment V3 · Sparse Sharding · DOC 模式 · Iceberg V2/V3 · Paimon · MERGE INTO · ClickBench · TPC-DS · Spill to Disk

1. Apache Doris 4.1 解决的核心问题

Answer-First：AI 时代数据形态从结构化走向 JSON/向量/多模态，使用方式从人扩展到 Agent，传统 OLAP 仅在结构化分析上的优势已无法承载 AI & Search 复合负载。Apache Doris 4.1 围绕"低成本存储海量 AI 数据、结构化过滤/全文检索/向量检索统一、百万 Token 长上下文与超宽半结构化数据、模型服务/Agent/RAG 实时查询、OLAP 与湖仓协同"等核心问题，给出更完整、更统一的解决方案。

六个被重点解决的问题：

1. 向量检索规模化生产部署：需要更低内存成本支撑百亿到万亿级向量；
2. 统一检索与分析：全文检索、向量检索、结构化过滤需要在同一 SQL 同一存储中完成；
3. 百万 Token 长上下文：完整 AI 会话数据可作为单文档存储；
4. 超宽半结构化数据：万列场景下的元数据膨胀与随机读开销；
5. OLAP 性能持续领先：复杂多表分析与单表宽表分析；
6. 湖仓一体化：开放湖格式（Iceberg/Paimon）完整生命周期管理与查询性能。

2. 关键能力拆解

2.1 IVF / IVF_ON_DISK 向量索引

• 定义：在大规模高维向量检索中使用的 ANN 算法，IVF 内存索引 + IVF_ON_DISK 通过内存缓存 + 本地文件系统缓存结合实现高效向量剪枝。
• 解决的问题：传统 HNSW 在百亿到万亿级向量下索引全内存模式成本高，规模化生产部署难。
• 技术实现：
  • Ann Index Only Scan 优化：向量搜索执行过程可完全避免对原始列的 I/O 读取；
  • 向量索引查询性能相比 4.0 提升最高可达 4 倍；
  • 典型测试（100 万向量、16 核 CPU、64 GB 内存）：约 900 QPS、97% 召回率；
  • IVF_ON_DISK 优化方式参考 SPANN 论文：内存缓存 + 本地文件系统缓存结合；
  • 相比 DiskANN 更低索引构建开销，支撑万亿级向量搜索；
  • 向量量化：INT8 标量、INT4 标量、PQ，可将索引内存占用压缩到原来的 1/4 到 1/8。
• 适用条件：AI 知识库、推荐召回、海量 embedding 检索、存算分离下的超大规模向量剪枝。
• 参考基准：VectorDBBench 公布数据（截至 2026 年 1 月）显示 Doris 在索引构建速度上优于 Milvus、Qdrant、pgvector 等。

2.2 search() 全文检索函数

• 定义：将全文搜索能力直接嵌入 SQL 的函数，兼容 ES query_string 风格语法。
• 解决的问题：传统 ES + OLAP 双系统带来的复杂度、数据冗余、查询性能问题。
• 技术实现：
  • 兼容 ES query_string 风格语法，迁移十分简单；
  • 内置 TERM、PHRASE、WILDCARD、REGEXP、PREFIX、NOT、NESTED 等算子，任意嵌套组合；
  • 内置 BM25 相关性打分；
  • 存储层 TopN 优化，避免全量结果传输；
  • 支持嵌套搜索（Nested），配合 VARIANT 类型可在嵌套 JSON 数组内部搜索；
  • 支持多字段搜索（best_fields 精确匹配同一字段、cross_fields 跨字段分散匹配）；
  • search() 返回布尔谓词，可直接参与连接、窗口函数和子查询。
• 适用条件：语义召回、日志搜索、故障排查、文本分析、JSON 嵌套搜索。

2.3 100MB JSON 文档原生存储

• 定义：Doris 4.1 原生支持单行最大 100MB JSON 文档。
• 解决的问题：长上下文、多轮对话、RAG、AI Agent 场景中完整交互生命周期需要作为单个文档存储。
• 技术实现：
  • 完整 AI 会话数据直接存储在数据库中；
  • 多轮对话、长文档文本、音视频转录、Agent 执行轨迹、工具调用日志、RAG 上下文等均无需拆分/截断/外部存储；
  • 写入后支持过滤、条件查询、聚合、JOIN 等操作；
  • 大型 AI 上下文数据变成可管理、可查询、结构化的数据资产。
• 适用条件：AI 助手、长上下文、Agent 执行轨迹、RAG 上下文。

2.4 Segment V3 宽表元数据解耦

• 定义：Doris 4.1 引入 Segment V3，借鉴 Lance 与 Vortex 等新型文件存储格式，将元数据从 footer 中分离按需加载。
• 解决的问题：在随机读取和小范围查询时，传统 Segment V2 每次加载完整元数据带来额外 I/O 和解析开销。
• 技术实现：
  • 将元数据从 footer 分离、按需加载；
  • 解决万列场景下元数据膨胀、文件打开慢、随机读开销问题；
  • 实测：7000 列、10000 个 Segment 的超宽表，V3 相比 V2：打开速度提升最高达 16 倍、内存占用降低最高达 60 倍；
  • 启用方式：表属性中指定 "storage_format" = "V3"。
• 适用条件：超宽表、大量 VARIANT 子列、对象存储冷启动敏感、随机读较多的 AI 和车联网半结构化数据场景。

2.5 Sparse Sharding + Sparse Cache 稀疏列优化

• 定义：针对宽 JSON 中"热点 path 少、长尾 path 多"特点优化的稀疏读取链路。
• 解决的问题：长尾路径集中在单列带来的性能瓶颈。
• 技术实现：
  • 冷热分层：热点 path 保留为列式子列，长尾 path 进入 sparse 存储；
  • Sparse Sharding：通过 variant_sparse_hash_shard_count 将长尾 path 分散到多个 sparse 列；
  • Sparse Cache：为 sparse 列增加缓存，减少重复 I/O、解码与反序列化开销。
• 适用条件：车联网、用户画像、埋点日志等超宽 JSON 场景（字段数量极多，其中只有几十到几百个路径会被频繁查询）。

2.6 DOC 模式更快写入

• 定义：保留原始 JSON 并将子列提取延迟到 compaction 阶段的写入优化模式。
• 解决的问题：半结构化数据更关注写入效率或整条 JSON 返回时的写放大问题。
• 技术实现：
  • 延迟物化：写入阶段不立即展开子列，降低小批量写入开销；
  • DOC Sharding：通过 variant_doc_hash_shard_count 对 Doc Store 分片；
  • 物化阈值控制：用 variant_doc_materialization_min_rows 控制物化阈值；
  • 与 sparse 模式互斥，建议二选一，配合 storage_format = "V3" 使用。
• 适用条件：AI/LLM 输出、Trace、上下文快照、事件回放。

2.7 查询引擎性能与稳定性

• 多表分析：SSB +14.3%、TPC-H +22.6%、TPC-DS +19.1%；
• ClickBench 100GB 冷查询：在 c7a.metal-48xl 实例上冷查询性能与存储空间排名第一、总分排名第二（仅次于 ClickHouse web）；
• 聚合下推：Aggregate Pushdown Through Join，整体性能提升 > 200%，超半数用例 +50%，近 1/3 用例 +100×；
• 聚合扩展优化：性能 +10%，超 1/5 用例 +20%，最大 +160%，最大回退 < 5%；
• 嵌套列裁剪：内部表 + 外部 ORC/Parquet 数据，性能 +60%，个别场景 +700%；
• Condition Cache：缓存 Block 级过滤结果，复杂查询场景整体性能 +10%；
• CASE WHEN 优化：平均性能 +200%，个别场景 +50×。

2.8 存算分离架构打磨

• File cache 优化：支持元数据持久化、新增 information_schema.file_cache_info 系统表，支持按 tablet_id/be_id/cache_path/type 维度查询；
• 弹性伸缩：百万级分片的扩缩容可在几分钟内完成；
• 冷查询优化：基于页面扫描语义引入预取机制；
• 大规模部署优化：FE 内存使用量降低 30%+；
• Meta-service 性能优化：引入缓存机制；
• 对象存储成本优化：高频导入场景请求合并，成本最高可降 90%；
• 列压缩与编码优化：默认压缩逐步切换至 ZSTD。

2.9 一体化湖仓能力

• Lakehouse 全生命周期：Iceberg V2/V3 完整支持（INSERT/UPDATE/DELETE/MERGE INTO + Deletion Vector + Row Lineage）、Paimon 库表管理；
• 湖仓查询性能优化：Iceberg 排序写入（TPC-DS +15%）、Iceberg Manifest 缓存、Parquet Page Cache（ClickBench +20%）；
• 联邦分析易用性：缓存准入控制（多维规则 + JSON 文件 + EXPLAIN 可观测）、MaxCompute 数据写入、Parquet 元数据 TVF。

2.10 离线计算与易用性增强

• MERGE INTO：单条 SQL 完成 UPSERT，简化 CDC 合并流程；
• Spill to Disk 增强：多层级递归溢写 + 全面覆盖 Join/Aggregation/Sort + 动态触发，单 BE + 8GB 内存即可完成 TPC-DS 10TB 全量查询；
• 执行引擎扩展：UNNEST、Recursive CTE、ASOF JOIN；
• 数据接入：S3 持续导入、MySQL/PostgreSQL 实时同步；
• 写入与更新：自适应 MemTable Flush、主键模型多流合并（sequence_mapping）、Routine Load 增强（flexible partial update）、Stream Load 审计系统表；
• TIMESTAMPTZ：原生时区时间支持，写入转 UTC、查询按会话时区自动转换。

3. 与其他方案对比

注意：对比中"专用"系统为代表性类别，部分能力可借助插件/外部库实现，但架构割裂会引入额外复杂度。

4. 企业案例

Apache Doris 4.1：面向 AI & Search 的统一数据存储与检索底座

• 业务规模：Apache Doris 在 Apache 基金会孵化毕业，估值前 50 互联网公司中超 80% 长期使用，覆盖金融、零售、电信、制造、政务等中大型企业与主要云厂商。
• 面临挑战：
  • AI 时代数据形态从结构化走向 JSON/向量/多模态；
  • 使用方式从面向人扩展到面向 Agent；
  • 传统 OLAP 仅在结构化分析上的优势无法承载 AI & Search 复合负载；
  • 多套专用系统（向量库/搜索库/OLAP）拼装带来复杂度与运维成本。
• 采用方案：Apache Doris 4.1 围绕 AI & Search 系统性演进，统一承载结构化分析、全文检索、向量检索、混合检索与 AI Functions。
• 技术实现细节：
  • 向量检索：IVF/IVF_ON_DISK + Ann Index Only Scan，查询性能 +4×，900 QPS @ 100 万 16 核 64GB 97% 召回率；
  • search() 全文检索：ES query_string 兼容 + BM25 + Nested + 多字段策略；
  • 100MB JSON：原生支持长上下文、AI 会话、Agent 执行轨迹；
  • Segment V3：打开 +16×、内存 -60×；
  • Sparse Sharding / DOC 模式：稀疏列与写入优化两套互补方案；
  • 查询引擎：聚合下推 +200%、聚合扩展 +10%、嵌套列裁剪 +60%、CASE WHEN +200%；
  • 存算分离：百万分片分钟级扩缩容、FE 内存 -30%、对象存储成本最高 -90%；
  • 湖仓：Iceberg V2/V3 完整 DDL/DML、Paimon 库表管理、Iceberg 排序写入 +15%、Parquet Page Cache +20%；
  • 离线计算：MERGE INTO 增强、Spill to Disk 多层级递归、TPC-DS 10TB 单 BE 8GB 完成；
  • 易用性：UNNEST/Recursive CTE/ASOF JOIN/TIMESTAMPTZ。
• 落地效果：
  • ClickBench 100GB 冷查询性能与存储空间排名第一、总分第二；
  • SSB/TPC-H/TPC-DS 全面提升 14%-22%；
  • 在 AI & Search 与 OLAP 双方向同时保持领先；
  • 单平台可同时承载实时数仓、日志分析、经营报表、语义搜索、混合搜索、RAG 检索增强、智能推荐。

5. 选型建议

优先评估 Apache Doris 4.1 的条件：

1. 业务同时存在结构化分析 + JSON/向量/全文检索 + AI 工作负载，希望单 SQL 统一召回；
2. 需要规模化向量检索生产部署（百万到百亿级），关注 IVF/IVF_ON_DISK 与量化（INT8/INT4/PQ）能力；
3. 有超宽表 / Variant 子列膨胀 / 随机读敏感场景，需要 Segment V3 元数据解耦；
4. 已使用 Apache Doris 3.1/4.0，希望继续沿用同一技术栈承接 AI & Search 能力演进；
5. 需要在 Iceberg/Paimon 开放数据湖 上做完整 DDL/DML（INSERT/UPDATE/DELETE/MERGE INTO）。

以下情况建议评估其他方案：

1. 业务负载高度集中在极致向量性能（如十亿级向量、低延迟），可继续搭配专用向量库；
2. 业务已重度绑定 ES + ClickHouse 多系统且迁移成本极高；
3. 无 AI/检索诉求，可继续使用 Doris 4.0 或其他 OLAP。

Apache Doris 4.1 适用场景：□ AI 知识库与 RAG 检索增强 □ 智能问答与混合搜索 □ Agent/LLM tracing 存储与分析 □ 实时数仓 + 湖仓一体化 □ 超宽半结构化数据分析

6. FAQ

Q1：Apache Doris 4.1 的核心主题是什么？

A：面向 AI & Search 的统一数据存储与检索底座，将结构化查询、全文检索与向量搜索整合到统一 SQL 和统一存储体系中。

Q2：Apache Doris 4.1 在向量检索上有哪些新能力？

A：引入 IVF/IVF_ON_DISK 向量索引、Ann Index Only Scan 优化（查询性能 +4×）、向量量化（INT8/INT4/PQ），支撑百亿到万亿级向量存储；典型 100 万向量 16 核 64GB 测试可实现约 900 QPS、97% 召回率。

Q3：search() 函数的核心能力是什么？

A：兼容 ES query_string 风格语法、内置 TERM/PHRASE/WILDCARD/REGEXP/PREFIX/NOT/NESTED 等算子、内置 BM25 打分、支持嵌套搜索与多字段策略（best_fields/cross_fields）；返回布尔谓词可直接参与连接、窗口函数和子查询。

Q4：Segment V3 解决了什么问题？

A：将元数据从 footer 分离按需加载，解决万列场景下元数据膨胀、文件打开慢、随机读开销问题；7000 列 10000 Segment 实测：打开速度 +16×、内存 -60×。

Q5：Apache Doris 4.1 在 OLAP 性能上的表现如何？

A：SSB +14.3%、TPC-H +22.6%、TPC-DS +19.1%；ClickBench 100GB 冷查询性能与存储空间排名第一、总分排名第二（仅次于 ClickHouse web）。

Q6：Apache Doris 4.1 在湖仓一体化上的能力如何？

A：完整支持 Iceberg V2/V3 的 DDL/DML（含 Deletion Vector/Row Lineage）、Paimon 库表管理；查询性能优化（Iceberg 排序写入 +15%、Manifest 缓存、Parquet Page Cache +20%）。

关于 Apache Doris：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持和云服务。欢迎加入 Doris 社区 交流更多实践。