作者赵阳钛动科技 DSP 大数据架构团队在 DSP 广告业务中数据链路需要同时支撑在线投放、计费、Ad-hoc 分析和 BI 报表等多类场景。不同场景对数据新鲜度、查询延迟、回刷能力和存储成本的要求差异很大。如果继续用一套统一链路承载所有数据系统很容易在成本、性能和稳定性之间相互牵制。钛动科技 DSP 广告链路的核心数据流可以概括为Request、Response、Impression、Click 和 Postback。随着业务规模增长原有架构逐渐暴露出三个问题数据规模持续扩大数据复用和跨链路分析成本较高链路维护复杂难以针对不同 SLA 单独优化同时StarRocks All-in-One 架构下任何变更都可能影响全链路故障隔离能力不足。一、背景与挑战业务现状与核心挑战 —— 9.6 PB 在库规模、日均 26 TB 增量从规模上看整体在库数据量达到 9.6 PB日均增量约 26 TB。与此同时核心链路希望将数据新鲜度压缩到 2 分钟以内并将在线点查查询延迟稳定在毫秒级。也就是说这不是单纯的把数据算出来的问题而是要在大规模数据、长周期回刷、低延迟查询和成本约束之间取得平衡。因此架构调整的核心思路不是继续强化一套统一链路而是按照不同数据链路的业务特征进行差异化设计高频但低时效要求的数据下沉到 DLF Paimon 湖仓高价值、强实时、强点查的数据保留在阿里云 EMR Serverless StarRocks需要归并和补充的数据通过主键表进入统一服务层。其中阿里云 EMR Serverless StarRocks 的角色也从单一存储查询系统进一步演进为承接在线点查、准实时明细分析和异步物化视图加速的核心服务层。二、从 All-in-One 到分链路差异化设计方案演进 —— 从 StarRocks All-in-One 到分链路差异化在原有架构中多类数据混合在一套 StarRocks All-in-One 链路中处理。这样做的好处是入口统一但问题也很明显低频冷数据长期占用本地存储高频写入会影响查询稳定性长窗口回刷也可能冲击在线 SLA。随着链路规模扩大这种一套方案服务所有场景的架构开始难以持续。新的方案将核心数据拆分为三条链路NRR 链路、BT 链路和 CT 链路。数据流全景 —— 三条核心链路统一接入、差异化落地NRR 链路日增量约 25 TB占整体数据量的大部分但时效性要求相对较低小时级即可满足业务需求。BT 链路日增量约 1 TB但对实时性、回刷能力和在线点查能力要求最高需要支持 30 天窗口回刷并服务在线投放和计费。CT 链路数据量较小主要承担归并和补充作用通过主键表进入主链路。三条链路在入口上保持统一都从 Kafka 多 Topic 接入但在落地路径上采用不同技术选型。NRR 通过阿里云 EMR Serverless Spark 批处理或阿里云实时计算 Flink 版微批写入 DLF Paimon 湖再由阿里云 EMR Serverless StarRocks External Catalog 进行联邦查询BT 通过 Flink 写入 EMR Serverless StarRocks 聚合表或主键表支撑在线点查和准实时分析CT 则通过 Flink 写入 EMR Serverless StarRocks 主键表并与主链路归并。这种设计的关键在于数据入口统一但存储、计算和查询路径不再强行统一。每条链路根据自身 SLA 独立演进从而降低架构耦合和故障影响面。子链路画像对比 —— 96% 数据是 NRR但真正的难点在 BT三、NRR 链路用 DLF Paimon 承接大规模低频数据NRR 链路设计 —— 对象存储省成本综合存储成本节省约 60%NRR 是整体数据量最大的链路但它的业务特点是时效性要求不高。对于这类数据如果继续长期放在 EMR Serverless StarRocks 本地盘中会带来较高存储成本也会挤占更高价值链路的计算和存储资源。因此NRR 链路采用 DLF Paimon on 对象存储的方式承接大规模数据沉淀。写入侧可以通过阿里云 EMR Serverless Spark 批处理或阿里云实时计算 Flink 版微批完成存储侧利用对象存储降低成本查询侧通过 EMR Serverless StarRocks External Catalog 直接访问 Paimon 表。这一设计带来两个收益第一低频数据不再占用昂贵的 StarRocks 本地存储综合存储成本可节省约 60%。第二EMR Serverless StarRocks 仍然可以通过 External Catalog 查询 DLF Paimon 表避免数据重复迁移同时保留秒级可接受的 Ad-hoc 查询能力。对于 NRR 这类规模大、价值密度相对低、时效要求弱的链路DLF Paimon 湖仓存储更适合作为主承载层。它让系统把高性能资源留给真正需要低延迟和高并发的业务链路。四、BT 链路用 EMR Serverless StarRocks 支撑稳定低延迟BT 链路设计 —— 60s Checkpoint、2min 新鲜度、30 天回刷、P99 5msBT 链路是整个改造中最关键、也最复杂的一条链路。它的数据规模虽然小于 NRR但对业务价值和实时性要求最高在线投放和计费需要毫秒级点查Ad-hoc 分析需要尽可能接近实时BI 报表又需要稳定的汇聚结果。同时BT 还要支持最长 30 天的回刷窗口。因此BT 链路没有选择 DLF Paimon 作为查询层而是通过 Flink 实时写入 EMR Serverless StarRocks 主键表。Flink 侧以 60 秒 Checkpoint 周期控制写入节奏StarRocks 主键表负责承接最新状态并通过 PK 点查支撑在线投放和计费场景。这里的关键不是简单把数据写入 StarRocks而是充分利用 EMR Serverless StarRocks 主键模型面向高频更新和低延迟点查的能力。BT 数据存在持续增量、状态更新和长窗口回刷如果全部转化为批式重算会对成本和在线稳定性造成压力通过主键表承接最新状态并结合部分列更新能力可以让多路增量数据在同一张业务宽表中持续归并减少上游复杂合并逻辑也避免回刷任务直接冲击在线查询。在服务层BT 链路按消费方进一步拆分在线投放和计费直接通过 EMR Serverless StarRocks 主键表进行 PK 点查P99 延迟可稳定在 5ms 以下。Ad-hoc 分析直接查询同源明细表获得 2 分钟级数据新鲜度。BI 报表通过异步物化视图进行汇聚刷新周期可以放宽到 10 分钟左右。这样做的核心是把在线实时点查和BI 汇聚分析解耦。在线链路直接读主键表不依赖物化视图物化视图只服务 BI 汇聚场景即使发生回刷或刷新压力也不会影响在线投放和计费的 SLA。五、2 分钟新鲜度让 MV 退居二线2 分钟新鲜度实现路径 —— PK 索引点查天然实时无需 MV 介入在传统理解中要实现准实时查询往往会优先考虑物化视图或预聚合。但在 BT 链路中真正需要 2 分钟新鲜度的是在线点查和明细分析而不是所有消费方都需要同样的刷新频率。因此新的设计把 2 分钟新鲜度建立在实时写入和主键索引能力之上。Flink 将增量数据写入 EMR Serverless StarRocks 主键表后在线投放和 Ad-hoc 分析可以直接访问同一份实时数据。对于这两类场景不需要等待物化视图刷新。物化视图的角色则被重新定位它不再承担所有实时消费压力而是专注服务 BI 报表等汇聚场景。由于 BI 对新鲜度要求相对宽松物化视图可以采用 10 分钟左右的异步刷新周期从而显著降低 StarRocks 写入和刷新压力。从能力应用上看EMR Serverless StarRocks 物化视图在这里承担的是有边界的加速层而不是所有实时链路的必经路径。它可以围绕 BI 报表和汇聚分析做异步刷新把高频在线点查留给主键索引把复杂聚合留给 MV 预计算。这样既保留了 StarRocks 在实时写入和点查上的优势也发挥了物化视图在自动维护、查询加速和资源错峰上的价值。这也是本次架构调整中非常重要的原则不是所有场景都需要同样的新鲜度也不是所有查询都应该走同一条加速路径。根据消费方特征拆分链路才能同时兼顾实时性、成本和稳定性。六、架构收益与后续演进落地收益 —— 2min 新鲜度、5ms PK 点查、存储降 60%、故障隔离经过分链路差异化改造后DSP 准实时数仓在查询新鲜度、在线点查、存储成本和故障隔离方面都获得了明显收益查询新鲜度 10min → 2min核心链路数据新鲜度从原来的 10 分钟级压缩到 2 分钟级能够更好支撑准实时投放和分析需求。在线点查 P99 5ms在线投放和计费通过 EMR Serverless StarRocks 主键表完成毫秒级 PK 点查P99 延迟可稳定在 5ms 以下。存储成本降低约 60%大规模低频数据下沉到 DLF Paimon 湖仓后综合存储成本显著降低。故障隔离三条链路独立演进、独立优化故障影响面从全链路收敛到单条链路内部。七、总结阿里云大数据产品栈的协同总体来看这次改造的核心不是简单替换某个组件而是重新定义不同数据链路的职责边界NRR 用 DLF Paimon 承接低频大规模数据BT 用 EMR Serverless StarRocks 主键表支撑高价值低延迟查询CT 通过主键表完成归并补充并借助 StarRocks 物化视图为 BI 汇聚场景提供异步加速最终在服务层形成统一的数据入口。在整个方案中阿里云大数据产品栈的四个核心产品协同支撑了端到端链路产品在本方案中的角色阿里云实时计算 Flink 版统一的数据接入与实时写入层。以 60s Checkpoint 周期将 Kafka 数据实时写入 StarRocks 主键表BT/CT 链路或以微批模式写入 Paimon 湖NRR 链路保证端到端 2 分钟数据新鲜度。DLF Paimon大规模低频数据的湖仓存储层。基于对象存储承载 NRR 链路日增 25 TB 数据综合存储成本相比本地盘降低约 60%同时提供 Lakehouse 语义供 StarRocks 联邦查询。阿里云 EMR Serverless StarRocks核心服务层。主键表承接实时写入与毫秒级 PK 点查P99 5ms异步物化视图加速 BI 汇聚分析External Catalog 联邦查询 Paimon 湖表实现一个入口服务在线投放、Ad-hoc 和 BI 三类消费方。阿里云 EMR Serverless Spark大规模批处理与历史回刷引擎。负责 NRR 链路的批量 ETL 写入 Paimon 以及长周期历史数据回刷与 Flink 微批互为补充。阿里云大数据产品栈在 DSP 准实时数仓中的角色分工这套架构的价值在于它没有用一套技术方案强行覆盖所有场景而是按照 SLA、数据规模、回刷压力和消费方特征进行分层设计。阿里云 EMR Serverless StarRocks 在其中承担了实时服务层的关键角色主键表负责低延迟点查和高频更新物化视图负责复杂汇聚和报表加速资源隔离则保证在线投放、计费和 BI 分析互不干扰。阿里云实时计算 Flink 版与 DLF Paimon、EMR Serverless Spark 共同构成了接入层和湖仓层的完整能力。对于广告这类同时具备大规模数据、强实时诉求和成本压力的业务来说这是一种更可持续的准实时数仓架构路径。本文整理自 Flink Forward Asia 2026 · 深圳 主题演讲。