基于Apache Doris：网易云音乐如何统一千表孤岛构建实时数据底座

在近期的 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的核心能力匹配

网易云音乐的数据平台架构庞大而复杂。其数据源包括结构化数据（如OLTP数据库）、半结构化数据（日志、埋点）和非结构化数据（图像、音频、视频）。平台的核心处理模块涵盖了从数据接入（ETL/ELT、Connector、CDC）、数据存储（HDFS, Kafka, Hive, Iceberg, Paimon）、数据处理（Spark/Flink, Doris, Graph计算, ML/DL）到数据服务（统一API, AdHoc查询, 低代码平台）的全链路。平台最终服务于报表BI、PUSH推送、机器学习/深度学习以及数据科学平台和AIGC应用。整个体系支撑着2000+流任务、10万+批任务和数百PB的存储量，并集成了元数据管理、智能化运维、安全体系、数据质量、流批一体、DataOps、云原生容器化等全方位的能力。

在这样的背景下，Apache Doris 凭借其三大核心能力，完美匹配了网易云音乐的复杂需求：

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

目前，Doris集群规模已从早期的100台物理机收敛至70台，日均查询量超过5000万次，覆盖了80%以上的核心业务场景。

三、四步落地：从谨慎试点到全面推广

团队的落地过程并非一蹴而就，而是遵循了一条清晰的演进路径，可以概括为从“能用”到“易用”，再到“放心用”，并最终走向“智能用”。其落地简史主要分为五个关键阶段：

第一阶段：调研与离线场景试点 (2024年02月 - 05月)

• 首个场景：会员日报表（原为Hive T+1产出）。
• 技术方案：采用Doris聚合模型，每日进行批量数据导入。
• 核心效果：
  • 机器数量从35台减少至5台。
  • 最大查询耗时从4分钟降至20秒。
  • 最大数据写入耗时从6小时压缩到10分钟。
    此阶段的成功验证了Doris在离线场景的可行性，为后续推广树立了信心。

第二阶段：实时与混合场景扩展 (2025年02月)

• 核心场景：广告曝光与点击实时数据看板。
• 数据链路：Kafka -> Flink进行轻度聚合（20秒窗口）-> Doris主键模型。
• 核心挑战：端到端数据延迟要求小于1分钟，且稳定性要求极高。
• 关键解法：采用蓝绿发布策略与异常节点自动剔除机制来保障服务稳定。

第三阶段：平台化与可观测性建设 (2025年06月)

• 自研运营管理平台：实现了可视化建表、自动化数据写入流程和Quota资源管理。
• 构建可观测体系：
  • 服务监控：集成Prometheus。
  • 读写大盘：基于Flink与Doris数据构建。
  • 智能告警：对异常日志量、Compaction Score、8040端口状态等进行监控告警。

第四阶段：数据湖与存算分离演进 (当前进行中)

• 引入Doris 3.x的存算分离架构。
• 数据分层：热数据（近7天）存储于本地SSD；冷数据自动沉降至对象存储。
• 提升交付效率：借助K8s与Doris Operator，新集群的创建时间从7天缩短至5分钟，充分体现了云原生的敏捷性。

四、关键优化：保障性能与稳定性的实战经验

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分钟时间窗口触发告警，极易因数据本身延迟而产生误报。
• 新逻辑设计：引入更智能的判断条件，区分“数据延迟”与真正的“业务异常”。其核心判断逻辑如下：

  IF (当前时间 - P99(storage_time)) > 2min 
  AND (log_time ∈ [19:10, 19:15]) 
  AND (该区间数据量极少) 
  THEN 
  触发“数据延迟”告警，而非“业务异常”

• 优化效果：大幅降低了误告警率，提升了运维效率与告警的可信度。

五、避坑指南：来自真实生产环境的经验

团队在实践中积累了宝贵经验，也踩过一些典型的技术“坑”，具体如下：

坑点	可能后果	解决方案
StreamLoad写入导致BE死锁	任务卡死，BE节点内存溢出(OOM)	升级线程池相关参数，修复同步等待逻辑
Tablet迁移过程中内存未正确释放	BE进程Core Dump	修复迁移流程中的内存释放Bug
Cache缓存盘损坏	BE节点无法正常启动	增强磁盘健康检查，实现坏盘自动隔离
物化视图未进行分区	刷新物化视图时导致OOM	强制要求物化视图必须按时间字段进行PARTITION BY
忽略外表元数据变更	查询外部表时返回空结果	在源表结构变更后，手动执行 REFRESH CATALOG 命令同步元数据

六、未来展望：走向智能化与更深度集成

团队也展望了未来的技术方向，部分能力目前仍处于内部概念验证或规划阶段：

1. MCP + Agent智能运维：通过统一的管理控制平面（MCP）管控多集群，并借助Agent实现慢查询自动诊断、索引推荐与容量预测。
2. 向量检索能力探索（实验性）：正在内部PoC用户Embedding向量的存储与检索，探索基于近似最近邻（ANN）算法的实时相似推荐。需注意，该能力尚未正式开源或发布。
3. 数据湖能力补全：深化对Paimon Changelog的支持，并探索Iceberg行级删除（Row-Level Delete）与物化视图的联动机制。

结语

网易云音乐的实践表明，统一OLAP的本质，并非用一个引擎粗暴地取代所有，而是在复杂的业务与技术生态中，建立可控、高效、低成本的秩序。通过 多模型支持、湖仓一体、存算分离与平台化治理 的组合拳，他们不仅实现了性能与成本的双重优化，更让数据真正成为了驱动业务的“实时脉搏”。

参考资料

[1] 网易云音乐实时场景 Doris 实践：从千表孤岛到统一实时底座, 微信公众号：mp.weixin.qq.com/s/we2rLkBLaZo1u-OQkI0Ewg

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。