【分享】干货 | 广告系统架构解密

广告、增值服务、佣金，是互联网企业最常见的三种盈利手段。在这3大经典中，又以广告所占的市场份额最大，几乎是绝大部分互联网平台最主要的营收途径，业务的重要性不言而喻。

从技术角度来说，广告业务涉及到 AI算法、大数据处理、检索引擎、高性能和高可用的工程架构等多个方向，同样有着不错的技术吸引力。

我从去年开始接触广告业务，到现在差不多一年时间了。这篇文章将结合我的个人经验，同时参考业界的优秀案例，阐述下广告系统的架构实践方案，希望让大家有所收获。内容包括以下3部分：

广告业务简介
面临的技术挑战
广告系统架构详解

01 广告业务简介

广告，可以说无处不在。微信、抖音、B站、百度、淘宝等等，这些占据用户时间最长的 APP，到处都能看到广告的影子。

我们每天随处可见的广告，它背后的业务逻辑到底是什么样的呢？在分享广告系统的架构之前，先给大家快速普及下业务知识。

1. 广告业务的核心点是平衡

为什么说广告业务的核心点是「平衡」？可以从广告的标准定义来理解。

广告被定义为：广告主以付费方式通过互联网平台向用户传播商品或者服务信息的手段。这个定义中涉及到 广告主、平台、用户 3个主体，但是这3个主体的利益关注点各不相同。

广告主：关注ROI，花了钱是否能带来预期收益
平台：拥有流量，关注收益能否最大化
用户：关注体验，广告是否足够精准？是否影响到了正常功能的使用？

有时候这三者的利益是冲突的，比如平台增加了广告位数量，收益肯定增加，但用户体验可能变差，因此广告业务最终要寻找的是三方的平衡。

站在平台的角度来看广告业务，它在保证用户体验的同时，要兼顾绝大部分广告主的ROI（确保他们是可以赚到钱的），在此基础上再考虑将平台的收入最大化，这样才是一个健康的广告生态。

2. 从收入的分解公式认清广告的本质

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

CPT：按时间计费，独占性包时段包位置
CPM：按照每千次曝光计费
CPC：按照点击计费
CPA：按照行为计费（比如下载、注册等）

之所以有不同的结算方式，其实也是随着广告市场的发展逐渐衍生出来的，最开始流量稀缺，平台占优势，再到今天逐渐成了买方市场，广告主作为需求方的谈判权变大。

上面这个图可以看出，由于CPA代表了广告主最终想要的转化效果，因此按CPA结算时对广告主最有利，但是对平台最不利。结算方式演进到今天，其实也是一种平衡，所以处于平衡点附近的CPM和CPC是最常见的结算方式。

以CPC为例，收入可分解成下面这个公式：

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

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

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

3. 广告的核心业务流程

广告业务发展到今天，随着广告主对投放效果的诉求不断加强，精准定向以及实时竞价是目前最主流的业务形态。

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

广告主先通过投放平台发布广告，可设置一系列的定向条件，比如投放城市、投放时间段、人群标签、出价等。
投放动作完成后，广告会被存放到广告库、同时进入索引库，以便能被广告检索引擎召回。
C端请求过来后，广告引擎会完成召回、算法策略、竞价排序等一系列的逻辑，最终筛选出Top N个广告，实现广告的千人千面。
用户点击广告后，会触发广告扣费流程，这时候平台才算真正获得收益。

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

02 面临的技术挑战

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

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

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

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

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

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

03 广告系统架构详解

了解了广告业务的目标和技术挑战后，接下来详细介绍下广告系统的整体架构和技术方案。

上面是我们公司目前的广告系统架构图，这个架构适用于广告业务初期，针对的是「自营型的竞价网络和站内流量」，不涉及联盟广告。

下面针对各个子系统做下说明：

广告投放系统：供广告主使用，核心功能包括会员续费、广告库管理、设定推广条件、设置广告出价、查看投放效果等。
广告运营后台：供平台的产品运营使用，核心功能包括广告位管理、广告策略管理、以及各种运营工具。
广告检索平台：承接C端的高并发请求，负责从海量广告库中筛选出几个或者几十个广告，实时性要求高，这个平台通常由多个微服务组成。
AB实验平台：广告业务的稳定器，任何广告策略上的调整均可以通过此平台进行灰度实验，观察收入指标的变化。
广告计费平台：面向C端，负责实时扣费，和收入直接挂钩，可用性要求高。
账务管理中心：广告业务中的财务系统，统管金额相关的业务，包括充值、冻结、扣费等。
大数据平台：整个广告系统的底盘，需要聚合各种异构数据源，完成离线和实时数据分析和统计，产出业务报表，生产模型特征等。

下面再针对架构中的技术难点展开做下介绍。

1. 广告数据的存储

广告系统要存储的数据多种多样，特点各不相同，采用的是多模的数据存储方式。

OLTP场景，包括广告库、创意库、会员库、广告产品库、广告策略库等，这些都存储在MySQL中，数据规模较大的广告库和创意库，按照广告主ID Hash做分库分表。
OLAP场景，涉及到非常多的报表，聚合维度多，单表的记录数可能达到百亿级别，底层采用HDFS和HBase存储。
面向广告检索场景的索引数据，包括正排索引和倒排索引，采用Redis和ES来存储。

存储上还需要解决的一个问题是：广告的同步问题。广告投放完成后，首先会存储在MySQL数据库中，接下来需要把广告实时传输到检索系统中，完成正排索引以及倒排索引的更新。