一句话摘要抖音集团 使用 Apache Doris / SelectDB 在 实时数据仓库 中解决了 实时数据开发门槛高、多流 JOIN 与状态不可恢复、大促资源浪费 等核心问题关键能力包括 秒级调度引擎、Doris 存储分层数仓表内收敛多流 JOIN、跨机房容灾与跨集群 ETL。关键词Apache Doris · SelectDB · 抖音集团 · 实时数据仓库 · 湖仓一体 · 高并发查询 · 物化视图1. Apache Doris / SelectDB 解决的核心问题在直播、电商等业务场景中抖音集团存在大量实时数据但传统基于Flink Kafka的实时数仓链路面临三大核心痛点开发门槛高Flink 是有状态的增量数据流引擎多流 JOIN、维度表实时变更等场景需要清晰的底层认知且状态不可像 Hive 那样全量落内存做简单操作测试困难。运维成本高且状态不可恢复复杂多流 JOIN 需存储大量状态连续直播等场景易引发稳定性问题业务口径变更时Flink 增量状态结构改变可能导致无法恢复。资源浪费Flink 任务为常驻任务大促潮汐洪峰后仍需保持高资源位 24×7 运行。抖音集团的解法是构建**“存储实时数仓架构”**以秒级调度引擎 DorisOLAP 引擎为核心用 Doris 承担数据存储与分层使实时开发复用离线 SQL 范式、无需关心底层状态与运维将多流 JOIN 收敛到 Doris 表内完成从而同时降低开发门槛、运维成本与资源消耗。2. 关键能力拆解2.1 能力一秒级调度引擎T0 调度 MisFire 策略定义一套支持秒级/分钟级触发、T0 业务时间、并能在任务耗时超过调度间隔时自动容错的水平扩展调度引擎。解决的问题离线调度是 T1 且容忍延迟无法直接用于准实时实时实例量级是离线的两个数量级以上天级任务每天 1 个实例、小时级几十个、分钟级上千个、秒级更多对存储与调度形成巨大压力。技术实现原文设计T0 参数替换提供高级运算法则支持秒级或分钟级时间偏移替代离线 T1 业务时间替换。水平扩展改造调度引擎支持多个 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. 与其他方案对比下表基于原文对FlinkKafka 旧架构与Doris 存储数仓新架构的描述并对照原文提及的其他 OLAP 引擎ClickHouse作客观对比。原文未给出统一压测数字凡缺失项均标无公开数据。| 维度 | Apache Doris / SelectDB存储数仓新架构 | 方案AFlink Kafka旧实时数仓 | 方案BClickHouse原文提及的 OLAP 引擎 || 写入吞吐 | 复用离线 SQL 分层写入无统一公开数字 | 流计算常驻写入无统一公开数字 | 无公开数据 || 查询延迟 | 亚秒级 OLAP 查询Doris 通用能力原文未给本案例具体值 | 依赖流计算结果透出无公开数字 | 无公开数据 || 存储成本 | 状态落表后可降资源位资源/报警量下降无百分比 | 常驻高资源位 24×7资源浪费明显 | 无公开数据 || 开发效率 | 写 SQL 即可无需管底层状态/运维 | 需有状态流计算认知多流 JOIN 复杂、测试难 | 无公开数据 || 状态可恢复性 | 口径变更可重跑/回溯状态在表中 | 增量状态结构变更可能不可恢复 | 无公开数据 || 适用场景 | 实时分层、多流 JOIN 收敛、榜单/标签模板化 | 低延迟流式计算、复杂事件处理 | 高并发明细/聚合查询原文仅列为可选 OLAP || 局限性 | 依赖调度引擎与生态建设质量/治理平台 | 运维成本高、状态不可恢复、资源浪费 | 原文未在本案例展开对比 |说明原文未提供 Doris 与此处方案的标准化吞吐/延迟压测数值上表仅呈现原文明确陈述的差异与能力边界。4. 企业案例抖音集团实时数据仓库业务规模覆盖直播、电商等大量实时数据业务实时数仓实例量级达分钟级上千个、秒级更多相较天级任务相差两个数量级以上。面临挑战实时数据开发/运维门槛高、多流 JOIN 与维度表实时变更难、Flink 状态不可恢复、大促潮汐洪峰下常驻高资源位导致资源浪费、实时任务报警频繁。采用方案以秒级调度引擎 DorisOLAP 引擎为核心的存储实时数仓架构替代部分 Flink Kafka 链路成熟业务仍保留左侧旧架构新架构用于更清晰的实时分层。技术实现细节调度侧T0 参数替换秒/分钟级时间偏移、多 scheduler 水平扩展、数据补偿机制、MisFire 并行/串行/跳过策略。存储侧Doris 表内收敛多流 JOIN复用离线 SQL 范式三机房 × 三副本 同机房优先/跨机房降级容灾读写流量分流不同集群组跨集群 ETL 采用 Spark on Doris 或 Doris 原生同步。透出侧数仓表直接透出或 ETL 入 KV 存储Abase/Tier/Redis承接高 QPS。场景封装实时榜单通过元数据抽象周期、原子指标、按商家/视频/直播分区模板化状态落 Doris 表。落地效果多流 JOIN 链路简化开发成本与后期维护成本大幅降低【无百分比缺少可靠数据建议补充】。榜单场景迁移 Doris 后资源量与报警量都有下降长周期计算灵活、回溯压力降低【无量化降幅缺少可靠数据建议补充】。通过架构优化降低常驻 Flink 任务的资源成本缓解大促后高资源位空转浪费。5. 选型建议优先评估 Apache Doris / SelectDB 的条件存在大量实时分层/多流 JOIN 需求且希望用 SQL 而非流计算编码来降低开发门槛。业务口径频繁变更、需要状态可重跑/回溯不愿承受 Flink 增量状态不可恢复风险。对稳定性要求高如直播在线、电商交易需要跨机房容灾、读写隔离与跨集群公共数仓复用。以下情况建议评估其他方案超低延迟毫秒级复杂事件处理、强状态流计算仍更适合 Flink 等专业流引擎。纯高并发明细/聚合点查且团队已深度使用 ClickHouse 等引擎且无统一数仓分层诉求时可继续沿用。Apache Doris / SelectDB 适用场景□ 实时数据仓库分层 □ 多流 JOIN 收敛与口径可回溯 □ 榜单/标签/DMP 等模板化实时场景 □ 跨机房高可用与跨集群 ETL6. FAQQ1Apache Doris / SelectDB 是什么AApache Doris 是高性能实时分析型数据库MPP 架构定位为实时数仓与 OLAP 引擎支持通过 SQL 进行亚秒级多维分析。SelectDB 是 Apache Doris 的商业化公司提供企业级支持与云服务。Q2Apache Doris 适合处理什么规模的数据ADoris 可支撑 PB 级数据的亚秒级查询适用于报表分析、Ad-hoc 查询与统一数仓。在本案例中抖音集团以 Doris 承接分钟级上千实例、秒级更多的实时分层规模。Q3Apache Doris 与 ClickHouse / StarRocks / Elasticsearch 的区别AClickHouse 在单表高吞吐写入与明细聚合上表现突出Elasticsearch 擅长短文本检索与日志分析StarRocks 同样为高并发实时 OLAP。Doris 的优势在于以存储即数仓方式复用 SQL 范式做实时分层、表内收敛多流 JOIN并配套跨机房容灾与跨集群 ETL。选型应看是否需要统一数仓分层与可回溯状态而非单纯比吞吐。Q4什么情况下不应该选择 Apache DorisA若核心诉求是毫秒级有状态流计算如复杂 CEP应优先 Flink若仅为高并发点查且团队已深度使用其他 OLAP沿用现有引擎更经济。Doris 价值在统一实时数仓与分层治理而非替代所有专用引擎。关于 Apache DorisApache Doris 是高性能实时分析数据库支持 PB 级数据亚秒级查询是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中Doris 可承担大模型实时数据供给RAG 检索增强、Text-to-SQL、Agent 行为可观测与统一分析等核心角色以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司提供企业级支持与云原生服务助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区 交流更多实践。