当前位置：首页 > news >正文

广告系统中后链路数据为什么要使用流批一体技术？流批一体技术是什么？

news 来源：原创 2025/6/13 0:14:33

在大规模广告系统的后链路（离线和实时特征计算、模型训练与上线、效果监控等）中，往往既有对海量历史数据的批量计算需求（离线特征、离线模型训练、报表汇总），又有对在线请求的低延迟实时计算需求（实时特征、在线打分、实时监控／告警）。传统将二者割裂、用 Lambda 架构（Batch + Speed 层）分别实现，带来了：

• 代码与业务逻辑重复
• 数据语义／计算结果不一致
• 运维成本、调度复杂度翻倍
• 开发调试效率低

流批一体技术（Streaming + Batch Unified）正是在这个场景下应运而生，用以打通“离线 ↔ 实时”两条腿，统一底层引擎、统一 API、统一数据语义、统一运维调度，从而大幅降低系统复杂度并提升实时性与一致性。

以下从“概念”、“核心能力”、“关键技术点”以及“在广告后链路的价值”四个角度做详细介绍。

一、流批一体技术概念

统一计算引擎
– 同一套计算框架即可处理有界（Batch）与无界（Stream）数据
– 统一抽象：数据流（DataStream）、表／SQL（Table & SQL）等
统一编程模型
– 同一份代码／同一套 API（如 Flink 的 DataStream & Table API、Spark Structured Streaming & Spark SQL、Beam）
– 业务逻辑“一次编写、实时／离线皆可跑”
统一时间语义
– 事件时间（Event Time）驱动，Watermark + Window 机制同时支持离线全局聚合和实时滑动／滚动窗口
统一容错与状态管理
– Checkpoint & Savepoint（或 Write-Ahead Log）保证 Exactly-once
– 支持大规模状态（State Backend，RocksDB、FsStateBackend 等）

二、核心能力与关键技术点

统一数据接入与存储
– 实时：Kafka、RocketMQ、Pulsar 等消息队列
– 离线：HDFS、Object Store（S3、OSS）、Iceberg/Hudi/Delta-Lake 等
– 上层统一视图、catalog 管理
事件时间＋Watermark
– 精确处理乱序数据、支持窗口聚合、状态清理
– 同一套 Window 既可做一次性全量聚合（离线），也可做增量／滑动窗口（实时）
状态管理与容错
– StateBackend（内存 / RocksDB）管理算子状态
– Checkpoint / Savepoint / 难停机升级
– 一次写入多端（消息队列、数据库、紧急告警）
高吞吐与低延迟调优
– 算子并发度、资源隔离、背压（Backpressure）控制
– 存储层冷热分离：Redis/HBase（在线）＋Parquet/Hudi（离线）
统一 SQL 层与批处理接口
– SQL on Stream + SQL on Batch：同一份视图／同一张表写离线任务即刻可查询
– 支持流式 joins（特征合并）、维表关联
Dev & Ops 一体化
– CI/CD：Job 参数化、统一打包、灰度发布
– 统一监控 & 告警：Checkpoint 时长、延迟、后端存储 IO、状态大小

三、在广告后链路的应用价值

实时特征计算与在线特征仓库
– 实时统计用户点击、曝光、转化等指标补全最新特征
– 离线批量计算多天滚动特征、标签，实时合并，保证预测时特征齐全且最新
在线实时实时打分／竞价
– 单条请求的 Feature Preparation、Model Inference 达到 ms 级
– 在同一个 Job 中既可离线更新模型版本，也可实时切流打分
离线模型训练与实时模型更新（Data Drift）
– 批量训练：历史 N 天数据训练新模型
– 实时微调：增量数据触发在线模型更新或校准
实时监控与异常检测
– 实时流水指标监控（CTR、eCPM、ROI 等）与阈值或 ML 模型告警
– 离线汇总报表与实时对齐，保证数据口径一致
降低运维与迭代成本
– “一次开发、既能部署离线 Batch 集群，也能跑在实时 Stream 集群”
– 统一 Job 管理、统一调度与监控，减少运维人员负担

四、典型架构示例

数据接入：Kafka ← 广告曝光／点击／转化事件
流批一体计算：Apache Flink
– 实时计算：Window 聚合、在线特征、实时打分
– 离线计算：有界批读历史 parquet / Iceberg 做全量统计、模型训练数据准备
– 同一套 Flink Job、Table & SQL 逻辑
实时存储：Redis/ HBase 作 Online Feature Store / 实时 CTR 缓存
离线存储：HDFS / Iceberg Otso / Parquet 作 OLAP / 离线报表
下游：模型训练平台、BI Dashboard、在线竞价系统

总结：
流批一体技术通过“底层统一”、“语义统一”、“运维统一”三大维度，消除了传统 Lambda 架构的技术债和一致性隐患，既能满足广告后链路对海量离线计算的吞吐要求，又能支撑对毫秒级在线特征与打分的时效需求，是现代大规模广告系统不可或缺的核心技术方案。

举个行业内落地的例子

这里以阿里巴巴展示广告实时计算平台为例，说明流批一体技术在广告后链路的落地实践。

背景与痛点

业务场景：展示广告投放中，需要对用户的历史行为（曝光、点击、转化、搜索等）做离线多天滚动特征计算，用于定期模型训练；同时又要在每次 RTB 请求到来时，做毫秒级的实时特征补全和在线打分。
原有架构：
• 离线：MaxCompute + MapReduce／Spark，每天跑批计算历史特征和训练样本；
• 实时：Flink（早期 1.x）或者 Storm + 纯消息队列＋Kafka Streams 做在线特征累加；
• 两套逻辑、两套存储、两套监控，开发迭代慢，一致性难保证。

流批一体引擎选型

核心引擎：Apache Flink（含 Blink 优化）
特征仓库：
• 实时写入：Kafka → Flink State（RocksDB） → HBase/Redis Online-Feature Store
• 离线增量：Iceberg + Flink SQL 作全量和增量批次写入

统一 Pipeline 实现
a) DataStream & Table API 统一编程
- 同一份 Flink Job，注册 Kafka（用户行为流）、Iceberg（历史轨迹表）两个源；
- 通过 Flink SQL 定义“滚动天窗特征”＋“当天滑动窗口特征”＋“实时点击率 UV 计数”
- 代码既可按“有界表”模式跑一次全量（离线训练数据），也可按“无界流”模式持续在线更新。
  b) 统一时间语义、容错与状态管理
- 事件时间＋Watermark 保证窗口计算一致；
- Checkpoint & Savepoint 支撑流批任务平滑升级；
- RocksDB StateBackend 存储大规模在线状态，可以同时支撑天级累积和秒级更新。
  c) 存储与下游交付
- 实时特征推送至 Redis/HBase ，在线打分系统秒级读取；
- 离线全量特征写入 Iceberg 表，供 MaxCompute／Model Training 集群批量拉取。
架构流程示例

行为数据接入：
• Kafka 收集曝光、点击、转化、搜索等事件；
• 离线历史轨迹落到 Iceberg 表（天级 Parquet）。
Flink Job （流批一体）：
• 在 DataStream 上注册 Table：
CREATE TABLE user_log_stream (…) WITH (‘connector’=‘kafka’, …);
CREATE TABLE user_log_iceberg (…) WITH (‘connector’=‘iceberg’, …);
• 使用 Table API/SQL 实时+批特征提取：
INSERT OVERWRITE iceberg.daily_feature
SELECT
user_id,
TUMBLE_START(event_time, INTERVAL ‘1’ DAY) AS dt,
COUNT() AS ctr_1d,
SUM(IF(action=‘click’,1,0))/COUNT() AS click_rate
FROM user_log_stream
GROUP BY user_id, TUMBLE(event_time, INTERVAL ‘1’ DAY)
;
• 同一 Job 部署两种模式：
– 有界模式（exec.env.execution-mode=BATCH）跑历史全量；
– 无界模式（执行时去掉该参数）持续消费 Kafka 做增量更新，同时实时输出至 Redis。
下游模型与竞价：
• 离线训练平台直接读取 iceberg.daily_feature 构建训练集；
• 在线竞价系统从 Redis 中秒级读到最新 ctr_1d、click_rate 等实时特征；
• 模型预测后输出 cpm 值，驱动实时竞价。