前亚马逊工程师：广告系统架构解密

一、无处不在的广告

广告的形式分为线上和线下模式。

线上广告以互联网的高速发展作为媒介，在 pc 端和移动端有着多种多样的发展模式：

线下广告以传统方式，以公交站牌、门头、交通等媒介的发展模式。

在当今社会的发展趋势下，线上广告占的比重越来越大。

二、什么是广告

广告的基本组成单位：广告主、媒介、受众。

广告的基础概念：流量。对于互联网来讲，如何更好地引流、吸引更多的群体，和如何精准地向特定人群推送广告主的广告，是互联网广告的关键。

三、互联网广告的发展趋势

• 互联网广告的行业规模越来越大；

• 移动端的快速发展，给人们带来了更多的方便，广告产业比重越来越多；

• 广告模式越来越多；

• 互联网广告依托互联网媒介的发展，在各类平台广告的比重，有着正相关的影响。

好的互联网产品更够带来更多的广告推广和盈利模式。

四、互联网广告的本质

以 CPC（按照点击计费）为例，收入可分解成下面这个公式：

其中，PV 表示系统的访问量，PVR 和 ASN 表示广告的填充率，CTR 表示广告的点击率，ACP 表示广告的平均点击价格。

上述各个指标都可以通过一系列的广告策略来提升。比如填充率可通过开发更多的广告主来实现，CTR 可通过 AI 算法做到精准投放来提升，ACP 可通过精准流量溢价或者提升广告主 ROI 来完成。

掌握上面这个收入分解公式，对于理解广告业务至关重要，任何业务上的动作几乎都能关联到这个公式的某个指标上。

五、互联网的结算方式

广告业务发展了几十年，广告费用的结算方式也诞生了很多种，我们最常见的有以下几种：

• CPT： 按时间计费，独占性包时段包位置

• CPM： 按照每千次曝光计费

• CPC： 按照点击计费

• CPA： 按照行为计费（比如下载、注册等）

不同的广告平台适合自己的结算方式：

如以信息流为主的 cpm，搜索软件为主的 cpc 等，根据广告推广的直接效果，而进行的结算模式变革。

六、互联网广告的初始形态

自己引流，开发广告主，具有一定的局限性，只依靠自己的流量，不具有受众的广泛性和多样性，开发广告主的过程中具有一定的限制。

七、后期广告的发展

广告的核心就是流量，联盟广告的出现，确保在受众的多样性和广告平台的多样性，具有更高的曝光率和广告模式的收益。为此此项广告模式，也就要求平台具有多样的资源整合能力，对平台技术的稳定性要求也越来越高。

八、电商广告

对互联网平台来说，初期一般都是采用「 自营的竞价广告网络 」来实现商业变现，简单理解：就是利用平台自有的流量以及自主开发的广告主来实现业务闭环。本文所分享的广告架构主要针对这种业务形态，它的核心业务流程如上图所示。

• 广告主先通过投放平台发布广告，可设置一系列的定向条件，比如投放城市、投放时间段、人群标签、出价等。

• 投放动作完成后，广告会被存放到广告库、同时进入索引库，以便能被广告检索引擎召回。

• C 端请求过来后，广告引擎会完成召回、算法策略、竞价排序等一系列的逻辑，最终筛选出 Top N 个广告，实现广告的千人千面。

• 用户点击广告后，会触发广告扣费流程，这时候平台才算真正获得收益。

上面是广告业务的核心流程，随着平台流量以及广告主规模进一步增大，往往会从「自营型竞价网络」逐渐向「联盟广告以及 RTB 实时竞价」方向发展，类似于阿里妈妈、腾讯广点通、头条巨量引擎，此时业务复杂度和技术架构会再上一个台阶，本文不作展开，后续再跟大家详细分享。

随着电商模式的发展，B2C、C2C 等模式的开展，卖家和买家都在疯狂的增长，电商平台也为此带来的更多的便利性。对于电商，由于买家和买家的准确性，电商广告具有一定的精准性，广告收益比相对较高，效果更好。好的广告排名往往带来更多的效益，对于电商平台而言，也带来的更多的挑战，平台的维护成本和大数据的处理优化。

九、电商广告面临的技术挑战

由于广告主->平台->受众，平台在为广告主和受众提供更好的服务和用户体验性，同时在追求更好的广告效果，需要各个系统之间的系统运转，保证整个平台的流畅性。

广告平台技术挑战

对广告业务有了初步了解后，再来看下广告系统面临的技术挑战：

1、高并发 ：广告引擎和 C 端流量对接，请求量大（平峰往往有上万 QPS），要求实时响应，必须在几十毫秒内返回结果。

2、业务逻辑复杂 ：一次广告请求，涉及到多路召回、算法模型打分、竞价排序等复杂的业务流程，策略多，执行链路长。

3、稳定性要求高 ：广告系统直接跟收入挂钩，广告引擎以及计费平台等核心系统的稳定性要求很高，可用性至少要做到 3 个 9。

4、大数据存储和计算 ：随业务发展，推广数量以及扣费订单数量很容易达到千万甚至上亿规模，另外收入报表的聚合维度多，单报表可能达到百亿级别的记录数。

5、账务的准确性 ：广告扣费属于金融性质的操作，需要做到不丢失、不重复，否则会损害某一方的利益。另外，如果收入数据不准确，还可能影响到业务决策。

下面着重介绍平台设计的几个关键点：

广告检索平台的性能设计

计费平台的方案

计费平台也是一个核心系统，主要完成实时扣费功能。比如 CPC 结算方式下，广告主设置的预算是 50 元，每次点击扣 1 元，当扣费金额达到预算时，需要将广告及时下线。

除此之外，计费平台还需要支持 CPM、CPT 等多种结算方式，以及支持反作弊、余额撞线处理、扣费订单的摊销和对账等功能。

计费平台的特点是： 并发高、数据量大、同时可用性要求高，需要做到不少扣，不重复扣。 下面以 CPC 实时点击扣费为例，详细说下技术方案。

CPC 实时扣费流程

首先，整个扣费流程做了异步化处理，当收到实时扣费请求后，系统先将扣费时用到的信息缓存到 Redis，然后发送 MQ 消息，这两步完成后扣费动作就算结束了。

这样做的好处是：能确保扣费接口的性能，同时利用 MQ 的可靠性投递和重试机制确保整个扣费流程的最终一致性。

为了提高可用性，针对 Redis 和 MQ 不可用的情况均采用了降级方案。Redis 不可用时，切换到 TiKV 进行持久化；MQ 投递失败时，改成线程池异步处理。

另外，每次有效点击都需要生成 1 条扣费订单，面临大数据量的存储问题。目前我们采用的是 MySQL 分库分表，后期会考虑使用 HBase 等分布式存储。另外，订单和账务系统之间的数据一致性，采用大数据平台做天级别的增量抽取，通过 Hive 任务完成对账和监控。

OLAP 海量数据报表方案

数据报表是也是广告平台的核心业务，它是广告主、平台运营人员进行投放优化、业务决策的依据。先来看下广告数据仓库的分层结构：

• 源数据层 ：对应各种源数据，包括 HDFS 中实时采集的前后端日志，增量或者全量同步的 MySQL 业务数据表。

• 数据仓库层 ：包含维度表和事实表，通常是对源数据进行清洗后的数据宽表，比如行为日志表、推广宽表、用户宽表等。

• 数据集市层 ：对数据进行轻粒度的汇总表，比如广告效果表、用户行为的全链路表、用户群分析表等。

• 数据应用层 ：上层应用场景直接使用的数据表，包括多维分析生成的各种收入报表、Spark 任务产出的算法模型特征和画像数据等。

采用这样的分层结构，和软件分层思想类似，提高了数据的维护性和复用性。

再来看应用层报表部分面临的挑战：聚合维度多，需要分时、分广告位、分推广等几十个维度；单表最大达到百亿级别；支持时间范围的实时查询。

这部分由公司的大数据部门维护，采用了开源的技术方案，离线部分使用 Kylin，数据存储在 HBase 中；实时部分使用 Flink 和 Spark Streaming，数据存储在 Druid 中。

• 对于平台而讲，在确定需求后，首先需要明确自己的发展模式，更具模式，确定系统，从而明确各个系统的功能、协同性、以及各个系统的压力点。进行倒推，确定平台系统的架构和技术方案。

• 好的系统架构，需要以系统的可用性为基础，进行系统升级和拓展。

• 对于互联网广告业务来讲：好的产品往往带来革命性的变革，这个社会缺乏沉淀和创意。优秀的产品思路决定着广告行业的风向。

• 小问题：百度为何衰落的呢？是电商的冲击还是微信的崛起呢？

作者介绍：

骆俊武，前亚马逊工程师，现 58 转转技术总监

本文转载自公众号技术琐话（ID：TheoryPractice）。

原文链接：

前亚马逊工程师：广告系统架构解密