广告竞价为什么要拼毫秒级速度？揭秘 RTB 实时广告系统背后的数据流水线设计

作者：Echo_Wish
方向：大数据架构 / 实时计算 / AI系统设计

你有没有想过：

打开一个网页，短短几百毫秒后，一张广告图片已经精准出现在你面前。

你看到的是一张广告。

但在广告平台眼里，这背后可能刚刚经历了一场“百亿级别的小型战争”。

用户点击页面 → 浏览器发起广告请求 → 多家广告主参与竞价 → 系统预测点击概率 → 计算广告价值 → 完成竞价 → 返回广告素材。

整个过程通常要求：

100毫秒以内完成决策。

这就是 RTB（Real-Time Bidding，实时竞价）系统。

很多人认为广告系统就是“存数据 + 展示广告”，其实真正的大厂广告平台，本质上是一个：

实时数据流处理系统 + 机器学习预测系统 + 高性能交易系统。

今天我们聊聊，一个广告 RTB 平台背后的数据流水线应该怎么设计，以及为什么很多系统一上量就崩。

---

一、RTB到底是什么？一次广告展示就是一次实时交易

先简单理解一下。

比如你打开一个新闻网站：

页面有一个广告位。

网站：

“我这里有一个用户流量，现在出售。”

广告平台：

“这个用户价值多少钱？”

多个广告主：

“我要出价！”

最终：

最高价值广告获得展示机会。

整个过程类似股票交易。

区别是：

股票交易可能几秒。

广告交易：

几十毫秒。

因为用户不会等你。

所以 RTB 系统必须解决三个问题：

1. 数据实时进入
2. 数据实时计算
3. 数据实时决策

---

二、RTB数据流水线整体架构

一个典型广告实时竞价系统，大概长这样：

用户请求
   |
   v
广告网关
   |
   v
实时竞价服务
   |
   +------------+
   |            |
   v            v
用户画像      广告库
   |            |
   +------------+
          |
          v
     竞价模型计算
          |
          v
      返回广告


同时：

点击日志
曝光日志
交易日志

        |
        v

Kafka

        |
        v

实时计算 Flink

        |
        v

用户画像更新
模型训练
数据分析

这里最核心的是：

实时数据流。

---

三、第一道难题：广告数据为什么不能直接写数据库？

很多初学者设计系统：

用户点击广告：

↓

insert mysql

↓

分析数据

看起来没问题。

但是实际广告系统：

每天可能产生：

• 100亿曝光日志
• 10亿点击日志
• 千万级广告请求 QPS

如果全部写 MySQL：

数据库直接“冒烟”。

例如：

INSERT INTO ad_click_log
(
 user_id,
 ad_id,
 click_time
)
VALUES
(
 '10001',
 'A001',
 NOW()
);

一天几十亿次：

MySQL：

CPU 100%

IO等待

连接池耗尽

系统雪崩

所以广告系统第一原则：

日志不要直接进入业务数据库。

而是进入消息队列。

---

四、Kafka为什么成为广告系统标配？

广告系统通常第一站：

Kafka。

例如：

用户点击：

{
 "userId":"U10001",
 "adId":"AD9001",
 "event":"click",
 "timestamp":1720000000
}

发送：

from kafka import KafkaProducer
import json


producer = KafkaProducer(
    bootstrap_servers=[
        "localhost:9092"
    ],
    value_serializer=lambda x:
        json.dumps(x).encode()
)


event={
    "userId":"U10001",
    "adId":"AD9001",
    "event":"click"
}


producer.send(
    "ad_click_topic",
    event
)


producer.flush()

Kafka负责：

• 削峰
• 解耦
• 缓冲

比如：

广告活动突然爆发：

平时：

10万QPS

突然：

100万QPS

Kafka：

生产速度：
100万/s


消费速度：
20万/s


剩余80万：

先进入队列

慢慢处理

不会直接击穿后端。

---

五、实时计算：为什么广告需要Flink？

广告系统最关心：

不是昨天的数据。

而是：

刚刚发生的数据。

例如：

一个用户：

过去5分钟：

搜索：

“新能源汽车”

浏览：

“特斯拉”

点击：

“电动车报价”

那么下一秒广告：

应该推荐：

新能源相关广告。

这个过程需要实时计算。

Flink代码示例：

DataStream<Event> stream =
env
.fromSource(
 kafkaSource,
 WatermarkStrategy.noWatermarks(),
 "click"
);


stream
.keyBy(
 Event::getUserId
)
.window(
 SlidingEventTimeWindows
 .of(
   Time.minutes(5),
   Time.minutes(1)
 )
)
.aggregate(
 new UserInterestAggregator()
)
.print();

含义：

按照用户ID分组。

统计最近5分钟行为。

实时更新用户兴趣。

例如：

用户画像：

之前：

{
"user":"U1001",
"interest":[
 "手机"
]
}

实时变化：

{
"user":"U1001",
"interest":[
 "手机",
 "新能源汽车",
 "智能家居"
]
}

---

六、RTB真正难点：毫秒级竞价计算

广告竞价不是简单：

谁价格高谁赢。

现在广告系统一般计算：

广告价值 =
出价
×
点击概率
×
转化概率
×
用户价值

例如：

广告A：

出价：

2元

点击概率：

5%

转化概率：

10%

价值：

2 × 0.05 × 0.1

=0.01

广告B：

出价：

1元

点击概率：

20%

转化概率：

30%

价值：

0.06

虽然B出价低。

但是系统选择B。

这就是：

智能广告。

---

七、机器学习模型如何进入RTB？

广告平台通常会训练：

CTR模型：

Click Through Rate

预测点击率。

例如：

输入：

用户年龄
地域
兴趣
历史行为
广告类型
时间
设备

输出：

点击概率

简单模型：

from sklearn.linear_model import LogisticRegression


model=LogisticRegression()


X=[
 [25,1,3],
 [40,0,2],
 [30,1,5]
]


y=[
1,
0,
1
]


model.fit(
 X,
 y
)


prob=model.predict_proba(
[
 [28,1,4]
]
)


print(prob)

输出：

点击概率：

0.73

广告系统根据：

预测概率 × 出价

决定排序。

---

八、性能优化：为什么广告系统喜欢内存计算？

RTB最大的敌人：

慢。

如果每次查询：

MySQL：

用户画像
广告信息
模型参数

查询：

10ms
20ms
30ms

加起来：

几十毫秒没了。

所以：

大量数据放：

Redis。

例如：

用户画像：

key:

user:10001


value:

{
age:30,
interest:[
AI,
汽车
]
}

查询：

import redis


r=redis.Redis(
host="localhost",
port=6379
)


profile=r.get(
"user:10001"
)


print(profile)

Redis：

微秒级响应。

---

九、数据冷热分离，是广告系统的生存技巧

广告数据非常特殊。

比如：

最近一分钟点击：

非常重要。

三年前点击：

基本没人看。

所以：

冷热分离。

热数据

存：

Redis

Flink State

特点：

高速访问。

---

温数据

存：

HBase

ClickHouse

例如：

最近30天广告效果。

---

冷数据

存：

HDFS

对象存储

用于：

模型训练。

架构：

实时数据

 Kafka

   |

 Flink

   |

 Redis
   |
实时决策


历史数据

 HDFS

   |

 Spark

   |

模型训练

---

十、真正的大规模RTB系统，优化重点在哪里？

我认为有三个关键。

第一：不要让数据库承担实时计算

数据库负责：

存储。

计算交给：

Flink/Spark。

---

第二：减少网络调用

RTB一次请求：

可能调用：

用户画像

广告库

模型服务

风控服务

如果：

10个服务 × 5ms

直接超时。

所以：

需要：

• 服务合并
• 本地缓存
• 模型预加载

---

第三：数据链路必须可观测

广告系统最怕：

“不知道哪里慢。”

所以需要：

监控：

Kafka lag

Flink checkpoint

接口耗时

模型响应时间

QPS

错误率

例如：

Prometheus：

- job_name:
    rtb-service

  metrics_path:
    /metrics

Grafana展示：

RTB响应时间

P99:

85ms


Kafka延迟:

2000


模型耗时:

15ms

---

十一、写在最后：RTB其实就是大数据时代的“高速交易系统”

很多人学习大数据，只关注：

Hadoop

Spark

Hive

但真正工业级应用：

不是离线分析。

而是：

实时决策。

广告RTB只是其中一个代表。

类似架构还应用于：

• 推荐系统
• 风控系统
• 智能客服
• 自动驾驶
• 金融交易

它们都有共同特点：

数据不断产生。

系统不断计算。

决策必须实时。

未来的大数据竞争，不是谁存的数据多。

而是谁：

能够最快把数据变成行动。

这也是为什么：

实时计算、流式架构、AI模型服务，会成为未来数据工程师必须掌握的核心能力。

—— Echo_Wish

数据不会自动产生价值，真正产生价值的是：让数据在正确的时间，做出正确的决策。