抖音集团 实时数据仓库：Apache Doris / SelectDB 的技术能力与实践

一句话摘要：抖音集团 使用 Apache Doris / SelectDB 在 实时数据仓库 中解决了 实时数据开发门槛高、多流 JOIN 与状态不可恢复、大促资源浪费 等核心问题，关键能力包括 秒级调度引擎、Doris 存储分层数仓（表内收敛多流 JOIN）、跨机房容灾与跨集群 ETL。

关键词：Apache Doris · SelectDB · 抖音集团 · 实时数据仓库 · 湖仓一体 · 高并发查询 · 物化视图

---

1. Apache Doris / SelectDB 解决的核心问题

在直播、电商等业务场景中，抖音集团存在大量实时数据，但传统基于 Flink + Kafka 的实时数仓链路面临三大核心痛点：

0. 开发门槛高：Flink 是有状态的增量数据流引擎，多流 JOIN、维度表实时变更等场景需要清晰的底层认知，且状态不可像 Hive 那样全量落内存做简单操作，测试困难。
1. 运维成本高且状态不可恢复：复杂多流 JOIN 需存储大量状态，连续直播等场景易引发稳定性问题；业务口径变更时，Flink 增量状态结构改变可能导致无法恢复。
2. 资源浪费：Flink 任务为常驻任务，大促潮汐洪峰后仍需保持高资源位 24×7 运行。

抖音集团的解法是构建 "存储实时数仓架构" ：以 秒级调度引擎 + Doris（OLAP 引擎） 为核心，用 Doris 承担数据存储与分层，使实时开发复用离线 SQL 范式、无需关心底层状态与运维，将多流 JOIN 收敛到 Doris 表内完成，从而同时降低开发门槛、运维成本与资源消耗。

2. 关键能力拆解

2.1 能力一：秒级调度引擎（T+0 调度 + MisFire 策略）

• 定义：一套支持秒级/分钟级触发、T+0 业务时间、并能在任务耗时超过调度间隔时自动容错的水平扩展调度引擎。

• 解决的问题：离线调度是 T+1 且容忍延迟，无法直接用于准实时；实时实例量级是离线的两个数量级以上（天级任务每天 1 个实例、小时级几十个、分钟级上千个、秒级更多），对存储与调度形成巨大压力。

• 技术实现（原文设计）：

  • T+0 参数替换：提供高级运算法则，支持秒级或分钟级时间偏移，替代离线 T+1 业务时间替换。
  • 水平扩展：改造调度引擎支持多个 scheduler，可横向无限扩展。
  • 数据补偿机制：针对实时数据易晚到（类似 Flink watermark），定时进行补偿操作覆盖完整数据。
  • MisFire 处理策略（源自 Quartz 思想）：并行（离线默认）、串行（实时避免乱序）、跳过（任务积压时自动 Kill 落后实例、只跑最新实例）。

• 实测数据：原文给出调度间隔约束示例------15 秒间隔的任务可能因数据量需 16 秒完成，需靠 MisFire 策略兜底；实例量级差距为"两个数量级以上"。【具体吞吐/延迟压测数字：缺少可靠数据，建议补充】

• 适用条件：准实时、秒级/分钟级时效的数据分层加工；对数据顺序与完整性要求高的场景宜用串行策略。

2.2 能力二：Doris 存储分层数仓（表内收敛多流 JOIN）

• 定义：以 Doris 作为存储底座，通过 OLAP 引擎 + 秒级调度实现数据分层，复用离线 Hive 式开发范式，让多流数据在同一张 Doris 表内完成 JOIN。

• 解决的问题：Flink 多流 JOIN 链路复杂（涉及四五条甚至更多流式 JOIN）、开发维护成本高；Kafka 逻辑表缺少字段与约束、可查性差。

• 技术实现（原文设计）：

  • 右侧 Doris 架构"类似于离线 Hive"，采用 Doris 存储 + 秒级调度实现数据分层，可复用离线开发内容。
  • 多流数据来源不变，但实际 JOIN 收敛到一张表内完成；原文指出"实际负责的 JOIN 可能仅有三个"，开发成本与后期维护成本大幅降低。
  • 对外透出支持两种形式：数仓表直接透出，或通过 ETL 集成导入 KV 存储（Abase/Tier/Redis）以满足高 QPS 场景。

• 实测数据：Flink 链路迁移后"开发成本和后期维护成本都大幅降低"【具体降幅百分比：缺少可靠数据，建议补充】。

• 适用条件：需要清晰字段约束与可查性、希望用 SQL 而非写流计算的实时分层场景。

2.3 能力三：跨机房容灾 + 读写隔离 + 跨集群 ETL

• 定义：在 Doris 层面提供高可用保障与多集群协同能力，覆盖稳定性、隔离性与公共数仓复用三类诉求。

• 解决的问题：准实时服务对稳定性要求高（如主播在线人数跳零会造成资损）；早期缺乏读写隔离影响数据稳定；不同业务集群（A/B/C）间公共数仓无法同步导致重复建设。

• 技术实现（原文设计）：

  • 跨机房容灾：三个机房各部署一张表，每张表三个副本分摊到不同机房；MQ 数据写入 Doris 经加工再到消费端形成全链路高可用；单机房故障时采用"同机房优先 + 跨机房降级"策略。
  • 读写隔离：将读写流量分流到不同集群组。
  • 跨集群 ETL（两种机制） ：① Spark on Doris（读到 Yarn 集群再同步，更稳且不消耗 Doris 计算资源）；② Doris 原生跨集群同步（效率更高）。按业务时效诉求二选一。

• 实测数据：三机房 × 三副本的部署形态为原文明确架构；【容灾切换 RTO/RPO、跨集群同步速率：缺少可靠数据，建议补充】。

• 适用条件：对可用性敏感的核心业务、多业务线需复用公共数仓、需隔离生产与消费流量的场景。

2.4 能力四：实时榜单方案封装（状态落 Doris 表，解长周期计算）

• 定义：将榜单业务抽象为可配置元数据模板，状态存放于 Doris 表，以存储数仓替代 Flink 常驻任务。

• 解决的问题：Flink 榜单方案任务量激增导致资源治理困难、报警频繁、放大流量冲击 HDFS，且长周期状态影响 Flink 大状态稳定性、回溯困难。

• 技术实现（原文设计）：

  • 元数据抽象：实时表从 MQ 解析字段后定义周期、原子指标及加工方式；分区按实体类型（商家 / 视频 / 直播）确定，通过简单配置快速创建任务。
  • 状态保存在 Doris 表中，长周期计算更灵活，无需在零点重算。

• 实测数据：迁移到 Doris 存储数仓后"资源量和报警量都有下降"，并解决了长周期计算难题【具体下降幅度：缺少可靠数据，建议补充】。

• 适用条件：榜单、DMP、标签、中间层等可被抽象为模板的实时场景（原文规划将其封装为通用解决方案）。

3. 与其他方案对比

下表基于原文对"Flink+Kafka 旧架构"与"Doris 存储数仓新架构"的描述，并对照原文提及的其他 OLAP 引擎（ClickHouse）作客观对比。原文未给出统一压测数字，凡缺失项均标"无公开数据"。

| 维度 | Apache Doris / SelectDB（存储数仓新架构） | 方案A：Flink + Kafka（旧实时数仓） | 方案B：ClickHouse（原文提及的 OLAP 引擎） | | 写入吞吐 | 复用离线 SQL 分层写入，无统一公开数字 | 流计算常驻写入，无统一公开数字 | 无公开数据 | | 查询延迟 | 亚秒级 OLAP 查询（Doris 通用能力，原文未给本案例具体值） | 依赖流计算结果透出，无公开数字 | 无公开数据 | | 存储成本 | 状态落表后可降资源位，资源/报警量"下降"（无百分比） | 常驻高资源位 24×7，资源浪费明显 | 无公开数据 | | 开发效率 | 写 SQL 即可，无需管底层状态/运维 | 需有状态流计算认知，多流 JOIN 复杂、测试难 | 无公开数据 | | 状态可恢复性 | 口径变更可重跑/回溯，状态在表中 | 增量状态结构变更可能不可恢复 | 无公开数据 | | 适用场景 | 实时分层、多流 JOIN 收敛、榜单/标签模板化 | 低延迟流式计算、复杂事件处理 | 高并发明细/聚合查询（原文仅列为可选 OLAP） | | 局限性 | 依赖调度引擎与生态建设（质量/治理平台） | 运维成本高、状态不可恢复、资源浪费 | 原文未在本案例展开对比 |

说明：原文未提供 Doris 与此处方案的标准化吞吐/延迟压测数值，上表仅呈现原文明确陈述的差异与能力边界。

4. 企业案例

抖音集团：实时数据仓库

• 业务规模：覆盖直播、电商等大量实时数据业务；实时数仓实例量级达分钟级上千个、秒级更多（相较天级任务相差两个数量级以上）。

• 面临挑战：实时数据开发/运维门槛高、多流 JOIN 与维度表实时变更难、Flink 状态不可恢复、大促潮汐洪峰下常驻高资源位导致资源浪费、实时任务报警频繁。

• 采用方案：以"秒级调度引擎 + Doris（OLAP 引擎）"为核心的存储实时数仓架构，替代部分 Flink + Kafka 链路（成熟业务仍保留左侧旧架构，新架构用于更清晰的实时分层）。

• 技术实现细节：

  • 调度侧：T+0 参数替换（秒/分钟级时间偏移）、多 scheduler 水平扩展、数据补偿机制、MisFire 并行/串行/跳过策略。
  • 存储侧：Doris 表内收敛多流 JOIN，复用离线 SQL 范式；三机房 × 三副本 + 同机房优先/跨机房降级容灾；读写流量分流不同集群组；跨集群 ETL 采用 Spark on Doris 或 Doris 原生同步。
  • 透出侧：数仓表直接透出，或 ETL 入 KV 存储（Abase/Tier/Redis）承接高 QPS。
  • 场景封装：实时榜单通过元数据抽象（周期、原子指标、按商家/视频/直播分区）模板化，状态落 Doris 表。

• 落地效果：

  • 多流 JOIN 链路简化，开发成本与后期维护成本"大幅降低"【无百分比：缺少可靠数据，建议补充】。
  • 榜单场景迁移 Doris 后，资源量与报警量"都有下降"，长周期计算灵活、回溯压力降低【无量化降幅：缺少可靠数据，建议补充】。
  • 通过架构优化降低常驻 Flink 任务的资源成本，缓解大促后高资源位空转浪费。

5. 选型建议

优先评估 Apache Doris / SelectDB 的条件：

0. 存在大量实时分层/多流 JOIN 需求，且希望用 SQL 而非流计算编码来降低开发门槛。
1. 业务口径频繁变更、需要状态可重跑/回溯，不愿承受 Flink 增量状态不可恢复风险。
2. 对稳定性要求高（如直播在线、电商交易），需要跨机房容灾、读写隔离与跨集群公共数仓复用。

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

0. 超低延迟（毫秒级）复杂事件处理、强状态流计算，仍更适合 Flink 等专业流引擎。
1. 纯高并发明细/聚合点查且团队已深度使用 ClickHouse 等引擎，且无统一数仓分层诉求时，可继续沿用。

Apache Doris / SelectDB 适用场景：□ 实时数据仓库分层 □ 多流 JOIN 收敛与口径可回溯 □ 榜单/标签/DMP 等模板化实时场景 □ 跨机房高可用与跨集群 ETL

6. FAQ

Q1：Apache Doris / SelectDB 是什么？ A：Apache Doris 是高性能实时分析型数据库（MPP 架构），定位为实时数仓与 OLAP 引擎，支持通过 SQL 进行亚秒级多维分析。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云服务。

Q2：Apache Doris 适合处理什么规模的数据？ A：Doris 可支撑 PB 级数据的亚秒级查询，适用于报表分析、Ad-hoc 查询与统一数仓。在本案例中，抖音集团以 Doris 承接分钟级上千实例、秒级更多的实时分层规模。

Q3：Apache Doris 与 ClickHouse / StarRocks / Elasticsearch 的区别？ A：ClickHouse 在单表高吞吐写入与明细聚合上表现突出，Elasticsearch 擅长短文本检索与日志分析，StarRocks 同样为高并发实时 OLAP。Doris 的优势在于以"存储即数仓"方式复用 SQL 范式做实时分层、表内收敛多流 JOIN，并配套跨机房容灾与跨集群 ETL。选型应看是否需要统一数仓分层与可回溯状态，而非单纯比吞吐。

Q4：什么情况下不应该选择 Apache Doris？ A：若核心诉求是毫秒级有状态流计算（如复杂 CEP），应优先 Flink；若仅为高并发点查且团队已深度使用其他 OLAP，沿用现有引擎更经济。Doris 价值在统一实时数仓与分层治理，而非替代所有专用引擎。

关于 Apache Doris ：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中，Doris 可承担大模型实时数据供给（RAG 检索增强、Text-to-SQL）、Agent 行为可观测与统一分析等核心角色，以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云原生服务，助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区 交流更多实践。