爱奇艺广告平台的架构设计分析

爱奇艺广告平台的架构设计分析

近年来爱奇艺快速发展，优质内容层出不穷，爱奇艺广告也随之发展和壮大，广告在线服务同时服务于品牌、中小、DSP 等不同客户，形成了可以满足不同需求类型的较为完善的商业广告变现布局，广告库存涵盖视频、信息流、泡泡社交（爱奇艺的社交平台）和开机屏等多种场景。

爱奇艺效果广告是2015 年开始全新搭建的一个广告投放平台，随着信息流业务的增长，整个投放平台也经历了一次大的架构调整和多次重要的升级优化。

爱奇艺广告投放平台的概要架构如下图所示。本文主要介绍在线服务相关的内容，在线投放服务即图中虚线所框出的部分，主要包括在线的投放和计费服务。

架构背后的业务需求

架构肯定是为业务需求而生的，先来看看我们面对的业务需求及其特点。

爱奇艺效果广告投放平台目前采用代理商模式，平台主要满足两大类业务需求：面向代理商（广告主）的和面向产品及运营团队的需求。具体来看看。

1、面向代理商的需求：本质上是要帮助代理商降低转化成本

∙支持多种广告位：贴片、暂停、浮层、信息流、视频关联位和推荐位等

∙支持多种结算类型：支持CPC、CPM 和CPV 等广告结算类型，oCPC 结算方式在规划中∙丰富的定向功能：常用定向维度（平台、地域等）及人群精准定向（地域定向- 支持区县级别、人群属性定向和DMP 人群定向），关键词定向

∙灵活的排期及预算设置：支持分钟粒度的排期设置，支持日预算的任意增减

∙特殊的业务功能：广告去重功能、动态创意、创意优选和平滑消耗等，都是为了提升广告的转化效果

∙频次控制：避免对相同用户短时间的大量曝光

2、面向产品及运营团队：主要是提升产品控制能力，促进整体系统的良好运转

∙流量控制：通过黑白名单控制某些流量上不可以/ 可以投放哪些广告

∙AB 测试功能：影响较大的功能全量发布之前需要进行AB 测试以确认效果符合预期

∙计费相关：延迟曝光不计费，曝光、点击异常检测及过滤

∙负反馈：根据用户反馈自动调整广告投放策略优化用户体验，同时也是对广告主的一种制约从上面描述的业务需求可以看出，业务的特点有：

1.业务逻辑复杂：流程包括很多环节（场景信息获取，广告召回，预算控制，频次控制，点击率

预估，创意优选，平滑消耗，广告去重，结果排序，结果筛选，概率投放，AB 测试）；下图

中绿框的部分仅展示投放服务的主要流程：

2.业务变更非常快：平均每周5 次的系统功能变更；

3.广告主数量多，订单量大，订单平均预算较小，并且订单设置会频繁变化。

系统架构

爱奇艺效果广告于2016 年正式上线。起步伊始，业务逻辑简单，广告和订单数量较少，整体架构相对比较简单。为了快速完成系统的搭建和上线应用，复用了品牌广告投放平台的架构，并做了剪裁，系统架构图如下：

接入层包括QLB（iQiYi Load Balance）、Nginx 前端机，主要做流量的反向代理和整体的限流与降级功能。

流量分发层：包括策略服务和流量平台服务；策略服务支持公司层面的策略控制和日常的运营需求；流量平台服务主要控制流量在各投放平台上的分配和请求逻辑，投放平台包括品牌广告投放平台，效果广告投放平台和外部DSP。

投放服务：前文介绍的业务逻辑都包含在这里，由单一的模块来实现。

日志收集：接收曝光点击等日志，主要完成计费、频控和去重等业务逻辑，也是由单一的模块来实现。

计费系统：利用Redis 主从同步机制把订单的实时消耗数据同步到投放服务。

频次系统：使用Couchbase 机群来做用户数据存储。

数据同步层：这一层涉及的数据种类很多，其中相对较重要的有两种：业务数据和日志数据，业务数据主要包括广告的定向、排期和预算等内容。

我们利用业务数据做了两方面的优化工作：

1.通过业务数据分发一些对时效性要求不高的数据给到投放服务，避免了一些网络IO；

2.在业务数据中进行空间换时间的优化，包括生成索引及一些投放服务所需要的数据的预计算，

譬如提前计算计费系统中的key 值。

随着业务增长，架构也遇到了一些挑战。

1.流量增长：系统上线之后很好地满足了广告主对转化效果的要求，这个正向的效果激发了广告

主对流量的需求，为此产品和运营团队不断地开辟新的广告位，同时爱奇艺的用户数和流量也在持续增长，这些原因共同为效果广告平台带来了巨大的流量。

2.广告主数量和订单数量增长：这个增长包括两方面，一方面与流量增长相辅相成，相互促进；

爱奇艺的优质流量和良好的转化效果吸引了更多的广告主；另一方面，由于商务政策上的原因，广告主和订单量在季度末会有阶段性的增长。

3.性能问题：流量和订单量的增长使得系统的负载快速增加，因为订单是全量召回的，当订单量

增长到一定数量之后，会使得长尾请求增多，影响整体服务性能，无法通过水平扩容解决。4.超投问题：由于曝光和点击的延迟，以及投放计费环路的延迟，不可避免的存在超投问题，这

也是广告系统的固有问题；品牌广告是先签订合同，投放量达到即可按照合同收款，超出部分不会对广告主收费，品牌广告预定量都很大，超投比率较小；和品牌广告不同，效果广告实时扣费，如果沿用品牌思路的话，超投部分会造成多余的扣费，而中小广告主对此非常敏感，也会增加技术团队问题分析排查工作，同时因为效果广告的预算少，预算调整变化很快，使得超投比率要比品牌广告大；针对效果广告的超投问题，技术团队要做的事情分成两个层面，一是保证超投的部分不会计费，不给广告主带来损失，二是从根本上减少超投，即减少我们自己的收入损失；分别称为超投不计费和减少超投；

针对上面的几个情况，我们的架构做了调整，如下图：

对比上线伊始的架构，此阶段架构调整体现在以下几个方面：

1.投放服务性能优化–包括索引分片和增加粗排序模块，主要解决了上述流量增长、广告主数量

订单增长等方面带来的性能问题

2.索引分片是把原来的一份索引拆分成多份，对应的一个请求会被拆分成多个子请求并行处理，

这样每个请求的处理时间会减少，从而有效减少长尾请求数量。

3.粗排序：全量召回的好处是收益最大化，缺点是性能会随着订单量增加而线性下降；粗排序在

召回阶段过滤掉没有竞争力的低价值的（ECPM 较低的）广告，低价值广告被投放的概率和产生转化的概率很低，因此粗排序的过滤对整体收入影响很小，同时能有效减少进入后续核心计算逻辑（包括精排序及其他的业务逻辑）的订单数量，使得服务压力不随订单量而线性增长。

4.计费服务架构优化- 主要是提升系统的可扩展性和解决超投问题

可扩展性通过服务拆分来解决，把单一模块的计费服务拆分成三个模块，拆分之后日志收集模块对外提供服务，主要职责是接收日志请求并立即返回，保证极低的响应时间；然后对计费日志和非计费日志进行不同的处理；检测过滤模块主要职责是进行定向检查和异常日志识别。计费服务把有效计费数据更新到计费系统。拆分成三个模块之后，每个模块都很简单，符合微服务基本原则之一：单一职责。