作者：赵阳，钛动科技 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 < 5ms
  BT 链路是整个改造中最关键、也最复杂的一条链路。它的数据规模虽然小于 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 汇聚场景提供异步加速，最终在服务层形成统一的数据入口。

在整个方案中，阿里云大数据产品栈的四个核心产品协同支撑了端到端链路：

阿里云大数据产品栈在 DSP 准实时数仓中的角色分工

这套架构的价值在于，它没有用一套技术方案强行覆盖所有场景，而是按照 SLA、数据规模、回刷压力和消费方特征进行分层设计。阿里云 EMR Serverless StarRocks 在其中承担了实时服务层的关键角色：主键表负责低延迟点查和高频更新，物化视图负责复杂汇聚和报表加速，资源隔离则保证在线投放、计费和 BI 分析互不干扰。阿里云实时计算 Flink 版与 DLF Paimon、EMR Serverless Spark 共同构成了接入层和湖仓层的完整能力。

对于广告这类同时具备大规模数据、强实时诉求和成本压力的业务来说，这是一种更可持续的准实时数仓架构路径。

本文整理自 Flink Forward Asia 2026 · 深圳 主题演讲。