网易云音乐Doris实战：统一OLAP底座，查询延迟降至800ms

在近期举办的 Doris 技术峰会上，网易云音乐数据平台团队首次系统性披露了其“实时数据中台”如何借助 Apache Doris 完成从“离线批处理”到“流批一体、湖仓融合”的架构跃迁。面对 2000+ 流任务、10万+ 批任务、数百 PB 存储 的复杂局面，他们用一套 Doris 集群，实现了 核心查询 P99 延迟从 1.2 秒降至 800 毫秒、关键数据加载耗时压缩 70%+、机器资源节省超 40% 的显著成效。

本文将基于官方分享内容，深度还原这场“统一 OLAP”实践的完整路径——涵盖核心场景、落地步骤、关键优化、血泪避坑与未来规划，为正在构建实时数仓的你提供一份可复用的参考蓝图。更多技术交流与资源分享，欢迎访问 云栈社区。

一、为什么是现在？——业务倒逼架构升级

网易云音乐的业务场景极其多元：日志分析、广告投放、会员运营、曲库管理、排行榜、用户圈选、CDC 监控……过去，这些场景各自为政，导致了技术栈的极度分散：

• 日志/广告：ClickHouse + Flink
• 会员报表：Hive + Spark
• 实时圈选：自研内存引擎
• 曲库聚合：MySQL 分库分表

三大痛点日益凸显：

1. 数据孤岛严重：同一份“用户播放行为”，需经 Flink -> 多套 ETL -> 多个系统，口径不一致；
2. 运维成本爆炸：维护 40+ 物理集群，扩缩容、监控、告警各自独立；
3. 资源极度浪费：中小业务独占 3FE+3BE 集群，CPU 利用率常年 <20%。

目标明确：一套引擎，支撑全场景分析——这就是网易启动 “Doris 统一计划” 的初心。

二、Doris 如何扛住亿级实时场景？

网易的选择并非偶然。Apache Doris 凭借 三大核心能力，完美匹配其复杂需求：

能力	应用场景	效果
多模型支持	- 明细模型（日志）<br>- 聚合模型（大盘）<br>- 主键模型 MOW（会员状态更新）	一张 Doris 表，替代 ClickHouse + MySQL + 自研引擎
湖仓一体	直接查询 Iceberg/HDFS 原始日志，避免冗余 ETL	减少 70% Flink 任务
高并发点查	用户圈选、实时维表关联	QPS 600+，P99 < 50ms

当前 Doris 集群规模已从 100 台优化至 70 台物理机，支撑 日均查询 5000 万次+，覆盖 80% 以上业务场景。

三、四步落地：从试点到全面收敛

阶段 1：离线场景试点（2024.05）

• 首个场景：会员日报表（原 Hive T+1）
• 方案：Doris 聚合模型，每日批量导入
• 效果：
  • 机器数：35 -> 5 台
  • 查询：4 分钟 -> 20 秒（Max）
  • 写入：6 小时 -> 10 分钟（Max）

阶段 2：实时场景扩展（2025.02）

• 核心场景：广告曝光/点击实时看板
• 链路：Kafka -> Flink 轻度聚合（20s 窗口） -> Doris 主键模型
• 挑战：端到端延迟要求 < 1 分钟，稳定性要求极高
• 解法：蓝绿发布 + 异常节点自动剔除

阶段 3：平台化 & 观测（2025.06）

• 自研运营管理平台：可视化建表、自动化写入、Quota 管理
• 构建可观测体系：
  • 服务监控（Prometheus）
  • 读写大盘（Flink + Doris）
  • 日志告警（异常日志量、Compaction Score、8040 端口异常）

阶段 4：存算分离演进（当前）

• 引入 Doris 3.x 存算分离架构
• 热数据：本地 SSD（近 7 天）
• 冷数据：自动冷却至对象存储
• 交付效率：集群创建从 7 天 -> 5 分钟（K8s + Doris Operator）

四、关键优化：性能与稳定性的双提升

1. 写入稳定性优化（广告场景核心）

• 问题：Flink 任务偶发写入卡死，导致告警误判
• 解法：
  • BE 探测 + 黑名单机制：自动剔除异常 BE
  • Resource Group 隔离：高低配机器写入隔离
  • StreamLoad 参数调优：doris_max_remote_scanner_thread_pool_thread_num=2048

2. 查询性能优化

• 高并发点查（如用户 ID 精确查询）：
  • 模型：UniqKey + MOW + 行存 + Light Schema Change
  • 参数：enable_parallel_scan=false, parallel_pipeline_task_num=1
  • 效果：在简单点查场景下，仅用 10% 集群资源即可稳定支撑 600+ QPS，P99 < 50ms
• 复杂聚合（如曲库大盘）：
  • 启用 Colocate Join + Bitmap 精确去重
  • 物化视图预计算高频维度组合

3. 时序告警准确性优化

• 旧逻辑：固定 5 分钟窗口触发，易受数据延迟影响
• 新逻辑：

• 效果：大幅降低误告警率，提升运维效率

五、避坑指南（来自真实生产经验）

团队在实践中积累了大量经验，也踩过不少典型坑：

坑点	后果	解决方案
StreamLoad 写入 BE 死锁	任务卡死，BE OOM	升级线程池参数，修复同步等待逻辑
Tablet 迁移内存失效	BE Core Dump	修复迁移过程中的内存释放 Bug
Cache 盘损坏	BE 无法启动	增强磁盘健康检查，自动隔离坏盘
物化视图未分区	刷新 OOM	强制要求 PARTITION BY 时间字段
忽略外表元数据变更	查询返回空	手动执行 REFRESH CATALOG 同步

核心理念：“能用 -> 易用 -> 放心用 -> 智能用”，这是对 Doris 平台化的四阶段定义。

六、未来展望：智能化与 AI 融合（探索阶段）

团队透露了 2026 年的技术方向，部分能力仍处于内部 PoC 或规划阶段：

1. MCP + Agent 智能运维
   • MCP（Management Control Plane）统一管控多集群
   • Agent 自动诊断慢查询、推荐索引、预测容量
2. 向量检索能力探索（实验性）
   • 正在内部 PoC 用户 Embedding 向量存储
   • 探索基于 ANN（近似最近邻）的实时相似推荐
   • 注：该能力尚未开源或 GA，属于前瞻性研究
3. 数据湖能力补全
   • 深化 Paimon Changelog 支持
   • 探索 Iceberg Row-Level Delete 与物化视图联动

结语：统一不是消灭多样性，而是建立可控秩序

网易云音乐的实践证明：统一 OLAP 的本质，不是用一个引擎取代所有，而是在复杂中建立可控、高效、低成本的秩序。

通过 多模型支持 + 湖仓一体 + 存算分离 + 平台化治理，他们不仅实现了性能与成本的双赢，更让数据真正成为业务的“实时脉搏”。正如其团队所言：“我们追求的不是技术的极致，而是业务价值的最大化。”

没有银弹，只有适配。Doris 不是万能的，但在 “统一查询 + 实时分析 + 湖仓融合” 这条赛道上，它已是网易不可或缺的基石。

附：本文内容基于网易云音乐在近期 Doris 技术峰会上的公开分享整理，核心架构与数据均已脱敏。