京东把原来 Presto、StarRocks 多套分析引擎逐步收敛到 Apache Doris，靠 Multi-Catalog、Nereids 优化器、向量化引擎做全链路湖仓查询优化，最终支撑日均百万级查询、PB 级数据扫描，同时承载 BI 报表、数据质量、AI Agent 多类负载，AI Agent 查询占比大约 20%；之所以要做这次统一，是多引擎并存时架构复杂、资源争抢、运维成本高，AI Agent 新增查询负载之后稳定性和治理难度进一步上升，整套落地路径就是先做业务迁移、再从元数据、扫描、调度、缓存四层做优化，最后完成流量压测和分阶段上线，拿到稳定的高并发查询能力。
一、原先多引擎架构遇到的痛点
在统一到 Apache Doris 之前，京东是多引擎并行的湖仓分析模式，问题集中在这几块：
- 技术栈多：Presto、StarRocks 等引擎同时跑，SQL 语法、权限、监控体系不一样，开发和运维都要维护多套标准
- 资源冲突：不同引擎独立调度，高峰期容易抢占集群资源，报表、实时查询、AI 查询互相影响，超时率波动大
- 治理成本高：元数据、权限、审计分开管理，数据口径对齐麻烦，出问题排查链路很长
- AI 负载冲击：AI Agent 带来大量随机、高频、小查询，原有引擎对这类短查询优化不足，并发上去之后容易雪崩
二、统一湖仓架构整体方案
京东选择 Apache Doris 作为统一湖仓底座，这套架构的核心能力清单：
- Multi-Catalog：直接对接 Hive、Iceberg、Paimon 等数据湖表，不用迁移原始数据，原地查询湖数据
- Nereids 全新优化器：负责 SQL 解析、谓词下推、分区裁剪、Join 重排，降低扫描数据量
- 向量化执行引擎：C++ 向量化，提升单节点吞吐，适合大批量扫描和高并发小查询混合负载
- 统一资源调度：按业务、查询类型做资源池隔离，BI、数据质量、AI Agent 负载分开管控
- 多层缓存：元数据缓存、文件 page 缓存、查询结果缓存，减少重复扫描湖存储
| 模块 | 优化方向 | 实际收益 |
|---|---|---|
| 元数据层 | Catalog 元数据缓存、元数据预加载、过期元数据淘汰 | 减少反复访问 Hive Metastore，元数据查询延迟下降 |
| 文件扫描层 | File Scanner V2、分区裁剪、谓词下推、延迟物化 | 过滤无效文件，减少 IO，PB 级扫描下控制读取范围 |
| 查询优化层 | Nereids 优化器、Join 优化、统计信息自动收集 | 复杂 SQL 自动选最优执行计划，降低扫描数据量 |
| 调度与资源层 | 资源池隔离、查询排队、限流、慢查询熔断 | 防止 AI 小查询打垮报表大查询，保障多负载稳定 |
| 缓存层 | 结果缓存、数据页缓存、本地磁盘缓存 | 高频重复查询直接返回缓存，降低湖存储访问压力 |
三、湖仓查询核心优化细节
1、分区裁剪与文件扫描优化
启用 File Scanner V2，支持 Parquet、ORC 等主流格式，针对 Hive、Iceberg、Paimon 表做文件级别过滤；查询条件提前下推，不需要的分区直接跳过，不会把整个目录文件全部读进来。同时会做文件分片拆分，多节点并行扫描，避免单文件拖慢整个查询。
2、Nereids 优化器的适配改造
针对湖仓场景补全统计信息收集，自动识别湖表的分区、文件大小、基数；对 AI Agent 大量随机点查、简单聚合做定向优化，减少不必要的 Shuffle；对大报表的多表 Join 做顺序重排，优先先过滤小表，再关联大表。
3、混合负载资源隔离
这是支撑百万查询的关键，京东把负载分成三类：
- BI 报表查询：扫描量大、耗时偏长，分配独立资源池，设置查询超时上限
- 数据质量校验：定时批量任务，错峰调度，避开业务高峰
- AI Agent 查询：数量多、单次扫描小、并发高，单独限流，防止瞬间打爆集群
支持查询排队、优先级设置，高优先级报表不会被大量 AI 查询挤占资源。
4、多层缓存体系落地
- 元数据缓存：Catalog 表结构、分区信息缓存，减少元服务压力
- 数据 Page 缓存：把经常访问的 Parquet 数据页缓存到本地磁盘和内存，重复读的时候不用访问远端对象存储
- 查询结果缓存：固定参数的高频报表直接缓存结果，秒级返回
四、分阶段落地实施步骤
- 先做 POC 验证：选取部分 BI 和 AI Agent 流量试点，对比原来 Presto 的延迟、资源消耗、错误率
- 改造 SQL 和权限：统一 SQL 口径，把原有引擎的权限、审计规则迁移到 Doris，对齐数据口径
- 分批迁移业务：先迁移低优先级报表，再迁移 AI Agent 查询，最后迁移核心业务报表
- 压测调优：模拟百万级并发，调整缓存大小、资源池配比、扫描并发参数，设置熔断阈值
- 灰度切换流量：逐步切流，监控超时、延迟、扫描量，出现异常快速回滚
- 长期迭代：持续收集慢查询，优化表结构、分区策略、缓存策略
五、落地效果
- 支撑日均百万级查询，PB 级湖数据扫描
- AI Agent 查询占整体查询量约 20%，和 BI 报表、数据质量任务稳定混跑
- 减少多引擎运维成本，统一一套监控、权限、审计体系
- 湖仓查询性能对比之前 Presto 架构，执行效率有明显提升
【常见问题】
问题 1：京东用 Apache Doris 做湖仓查询优化，从多引擎统一到百万级查询，核心解决了什么问题？
回答 1：京东这套 Apache Doris 湖仓查询优化，主要解决多引擎架构运维复杂、资源争抢、治理困难，还有 AI Agent 新增大量查询带来的并发冲击问题，通过引擎收敛、Nereids 优化器、扫描和缓存优化，实现单底座支撑百万级湖仓查询。
问题 2：京东 Apache Doris 湖仓查询架构里，AI Agent 这类查询在百万级查询里占比多少，怎么保障它不影响报表？
回答 2：京东 Apache Doris 湖仓查询中 AI Agent 查询占比约 20%，通过资源池隔离、单独限流、查询优先级管控，把 AI Agent 小查询和 BI 报表大查询分开调度，避免 AI 高频查询抢占报表资源。
问题 3：做 Apache Doris 湖仓查询优化，分区裁剪、File Scanner V2 主要作用是什么？
回答 3：Apache Doris 湖仓查询优化里的分区裁剪、File Scanner V2，用来提前过滤不需要的分区和数据文件，减少远端存储 IO，控制 PB 级场景下的扫描数据量，是湖仓查询提速的基础手段。
问题 4：企业想把多引擎收敛到 Apache Doris 做湖仓查询，能不能直接一步全量迁移？
回答 4：不建议一步全量迁移，参考京东 Apache Doris 湖仓查询实践，应该先 POC 试点，再从低优先级业务灰度迁移，配合压测调优、流量逐步切换，保留回滚方案，保障百万级查询负载稳定。
【参考资料】
[2026-11-11]（京东 Apache Doris 湖仓查询优化实践：从多引擎统一到百万级查询）腾讯云开发者社区
[2026-11-11]（京东 Apache Doris 湖仓查询优化实践：从多引擎统一到百万级查询）稀土掘金
[2026-10-16]（Apache Doris 湖仓查询优化官方文档：分区裁剪、File Scanner V2）Apache Doris 官网
[2026-09-25]（Doris Summit 2026：京东零售 OLAP 湖仓底座分享）SelectDB 技术博客
免责声明：本文为京东 Apache Doris 湖仓查询优化案例科普，仅作为技术选型和架构改造参考，不构成直接落地部署方案；不同企业的数据规模、湖表格式、负载特征不一样，迁移和优化方案需要结合自身业务压测验证，生产上线前务必做好灰度、限流、回滚预案。