美团数十 PB 规模 Apache Doris 实践：从统一 OLAP 到 AI-Native 数据基座

本文整理自美团技术专家在 Apache Doris 线上活动中的分享。

随着美团业务规模持续增长，数据分析系统所面对的问题已经不再只是查询更快，而是如何在多业务、多场景、多负载并存的情况下，构建一套长期可演进的统一 OLAP 架构。

基于此，美团 OLAP 平台完成了从多引擎并存，到基于 Apache Doris 构建统一分析引擎，再到大规模集群治理、无感升级和 AI 场景演进的建设过程。本文将围绕整体架构、核心能力建设与无感升级，介绍美团在 Doris 体系下的 OLAP 实践。分享基于 CCR 支撑 300+ 集群、10w 核计算资源 、数十 PB 数据规模的平滑升级，并带来整体查询与导入性能约 20%–40% 的提升，部分极端场景可达 50%。

01

美团 OLAP 场景特点与挑战

美团业务高度依赖数据分析，战略决策、产品迭代、经营分析及营销活动都需要实时、准确的数据支撑。随着业务持续增长，美团 OLAP 平台主要面临四大挑战：

• 低延迟要求高：绝大多数分析报表需要秒级响应，部分 ToB 场景要求亚秒级返回。
• 数据规模持续增长：核心业务数据已达千亿级以上，传统数仓难以兼顾海量数据与低延迟查询。
• 分析场景复杂多样：交易、经营、用户、流量、商户等业务并存，对查询模式、并发能力、数据新鲜度和稳定性提出不同要求。
• 从 BI 向 AI 演进：随着各业务线 BI 系统逐步整合，底层平台不仅要支撑统一分析，还需要满足 AI 应用带来的复杂查询和弹性计算需求。

典型业务包括：

• 外卖经营分析：按蜂窝组织统计交易额、用户数等指标。由于组织结构动态变化、业务逻辑复杂，难以依赖预计算宽表，需要 MPP、Colocate Join 和列式存储支撑海量多表关联分析。
• 到店餐饮 BD 人效分析：涉及上百个维度、数十项聚合指标，以及绩效考核所需的精确去重，对 Bitmap 去重、预计算和查询性能要求较高。
• 商户经营报表：面向 B 端商户提供实时查询，主要基于商家 ID 等高选择性字段进行高并发点查，对低延迟、高并发和高可用性要求极高。

这些场景决定了，美团需要一套统一的 OLAP 数据平台，能够同时支持复杂分析、精确去重、高并发点查、实时导入、离线加工及多业务统一治理，并为 AI-Native 数据应用提供底层支撑。

02

从多引擎并存到 Apache Doris 统一 OLAP 架构

美团早期 OLAP 架构依赖 Hadoop、Kylin、Druid 等多个引擎，多引擎并存带来了维护、存储和使用成本上升的问题。因此，美团开始建设统一 OLAP 引擎，并选择通用性和性能较好的 Apache Doris。到 2020 年，美团已将全部存量及新增 OLAP 需求整合到统一 Doris 体系中。

从整体数据平台视角看，用户行为数据、DB 数据、日志数据统一采集到 Kafka 后，分别进入实时和离线链路：

• 实时链路：数据由 Flink 消费，经过实时处理后写入 Doris，支撑实时看板、经营监控和在线分析；
• 离线链路：数据进入 Hive/HDFS 离线数仓，通过 Spark、Hive 完成清洗、汇总和建模后，再同步到 Doris，对外提供高性能查询服务。

在美团内部，大数据处理主要分为三类场景：

• 数仓加工。主要负责用户行为、DB、日志数据的清洗、转换和汇总。该场景数据规模极大，每天处理量达到百 PB 级别，单个作业可能超过 100TB，对吞吐和稳定性要求很高。
• 即席查询。面向更加灵活的数据探索，通常在 Presto 和 Spark 上完成，需要在数据规模和查询性能之间取得平衡。
• OLAP 分析。面向相对确定但性能要求极高的查询模式，包括固定报表、经营分析、商户分析、流量分析等。当前 100% OLAP 查询请求由 Doris 承载。

在这一架构中，Apache Doris 位于数据服务层，向上承接业务报表、经营分析、商户服务和流量分析等应用，向下承接实时链路和离线数仓加工后的数据结果。它不仅承担低延迟查询职责，也负责支撑高并发访问、复杂多表分析、精确去重、实时写入和离线加工结果的统一服务，是美团统一 OLAP 架构中的核心分析引擎。

03

美团对 Apache Doris 社区的贡献

3.1 Colocate Join：支撑复杂经营分析

在外卖经营分析等场景中，经常需要进行多表关联查询。传统 Shuffle Join 在分布式系统中会产生大量跨节点网络传输，容易导致查询超时。

为解决这一问题，美团提出了 Colocate Join 的想法：提前对数据进行分布和组织，使 Join 相关的数据尽可能分布在同一节点上，从而减少跨网络数据传输。

在内部验证中，Colocate Join 使关联查询性能平均提升约 3 倍，有效解决了外卖经营分析中大规模关联查询超时的问题。相关能力也回馈给 Apache Doris 社区，帮助更多用户解决类似场景下的 Join 性能问题。

3.2 Bitmap 精确去重：支撑流量与用户分析

在流量分析场景中，DAU 计算、用户留存分析、用户行为分析等高度依赖精确去重能力。

美团围绕 Doris Bitmap 能力进行了大量优化，尤其是在数据分布方面，通过控制数据分布基数，提高单用户基数下的整体精确去重性能。

经过优化后，系统能够支持百亿级数据量的单 SQL 查询，在亿级和数亿基数下，指标计算性能平均提升 4～5 倍，单表查询可在 10 秒内返回结果。

这一能力使 Doris 能够更好地承接原本由 Kylin 等预计算引擎承担的精确去重分析场景。

3.3 Spark on Doris：隔离生产与查询负载

部分业务场景要求在 10 分钟内完成数据生产、加工和落地。如果将复杂加工逻辑直接压在 Doris 中执行，容易与在线查询产生资源竞争，影响查询稳定性。

为此，美团基于 Doris Spark Connector 构建了 Spark on Doris 架构。该架构利用 Spark 的稳定计算能力完成复杂数据加工，再将结果写入 Doris 提供查询服务。

这一模式带来了几个收益：

• 支持跨集群读写能力，避免重复计算逻辑。
• 将复杂数据加工放在 Spark 执行，降低 Doris 计算压力。
• 通过 SQL 接口衔接 Doris 到 Doris 的数据加工任务。
• 实现数据生产和在线查询的资源隔离，提升整体稳定性。

04

大规模集群升级：架构持续演进中的关键实践

随着 Doris 使用规模持续扩大，美团 OLAP 平台进入了新的阶段。平台中 Doris 集群数量超过 300 个，计算资源达到数 10w 核，数据规模达到数十 PB。

在这一阶段，系统面临的核心问题不是单点性能优化，而是多版本、多集群、多业务并存带来的系统性治理压力。

由于历史原因，不同业务线在不同阶段引入了不同版本的 Doris，系统长期处于 0.1 到 2.x 多版本并存状态。不同版本之间存在功能差异、语义差异和运维方式差异，使得问题排查、能力迭代和统一治理变得越来越困难。

4.1 为什么不能直接原地升级

原地升级在工程上风险很高。由于版本跨度较大，中间涉及多轮升级路径和元数据结构变化，一旦升级失败，可能出现无法回滚的问题。

传统全量重导或 backup restore 方案也难以满足要求。单集群数据规模可达 PB 甚至 10PB 级别，完整迁移耗时长、风险高，并且难以避免停机窗口。

双写方案虽然在部分场景可行，但业务改造成本高，链路复杂，难以在数百个集群中统一推广。

因此，这一问题最终收敛为一个核心约束：在尽量不影响业务连续性的前提下，实现 PB 级数据系统的平滑升级。

4.2 CCR 解决方案

在多种方案评估之后，美团选择基于 Doris CCR 能力构建升级体系。

CCR 的核心机制是基于 binlog 的变更捕获与重放。源集群将数据和元数据变更记录为 binlog，目标集群持续消费并重放这些变更，从而实现跨集群增量同步。

这一机制将传统“离线数据搬迁”转变为“持续增量追平”。新集群可以在后台持续同步旧集群数据。当两侧数据延迟收敛到可接受范围后，再通过域名切换完成流量迁移，实现对业务几乎无感的升级。

4.3 工程化落地与回滚保障

在实际落地中，美团构建了新旧集群并行体系。

新版本集群通过 CCR sink 持续接收 binlog，在完成存量回放后进入增量同步阶段。

切换时，团队采用双域名与双跑机制保证安全性。Kafka 与 Hive 等导入任务在新旧集群同时运行，确保数据链路一致，并在观察期内保留快速回滚能力。

数据验证是整个升级链路中的关键环节。早期仅依赖 SQL 回放无法覆盖真实业务场景，因此团队引入业务侧端到端验证机制，从业务语义层面验证新旧集群一致性，降低迁移风险。

4.4 升级与治理同步推进

在升级过程中，团队同步开展了大规模数据治理。例如治理元数据膨胀、控制副本规模、清理异常元数据结构、统一集群健康状态等。

这些治理工作并不是附加优化，而是升级成功的前置条件。部分历史集群存在严重元数据膨胀问题，副本数量甚至达到千万级规模，在极端情况下会影响 FE 节点恢复。如果不先完成治理，迁移和升级本身也会面临较大风险。

围绕 CCR 体系，团队还进行了多项工程增强，包括将 CCR 能力 backport 到低版本集群，将 DB 级串行同步优化为表级并行执行，并修复跨版本精度差异、优化器行为差异和性能回退问题。

通过这些工作，美团将“以停机换升级”的传统模式，转变为“以数据持续追平驱动系统演进”的模式，提升了 OLAP 架构的长期演进能力。

4.5 升级治理效果

团队基于 CCR 构建了 PB 级数据规模下的无感升级体系，支撑 300+ 集群平滑升级。升级与治理完成后，整体查询与导入性能提升约 20%–40%，部分极端场景提升可达 50%，系统稳定性也得到明显改善。

05

未来规划：面向 AI 的数据基础设施演进

AI Agent 正在改变数据系统的使用方式。未来 OLAP 系统不再只服务于传统 BI 查询，还需要支撑 AI Agent、自动化分析、智能运维和智能问数等新型负载。

为适应这一趋势，美团正在建设统一查询与接口层，将 SQL 查询、运维诊断和数据访问能力进行统一抽象，为上层 AI 应用提供标准化、安全可控的数据交互方式。

同时，美团也在探索智能运维 Agent，用于自动分析大查询、数据倾斜、节点异常等问题，并逐步形成自动诊断能力。如何构建面向 Agent 的观测、评测和治理体系，也将成为下一阶段的重要课题。

我们了解到，Apache Doris 正在围绕 Agent Native 场景增强相关能力，基于混合检索分析、VARIANT、倒排索引、排序键、分区裁剪和缓存机制，为 Agent 运行过程中的 trace、事件、查询、评测结果和多租户观测提供高性能数据底座。在此基础上，Litefuse（litefuse.ai）以 Doris 为底座，进一步构建面向 Agent 的可观测与评估平台，可实现 Agent 全链路可追踪、过程可分析、效果可量化和能力可持续改进。后续我们也将积极尝试相关方向。