Question

根据广告的核心优化问题和上面个性化系统的一般框架，我们抽象出一个完整的广告系统可能具备的各个模块以及这些模块之间的协作关系，用图9-2中的架构框架来描述。这一架构图将是后面讨论各种广告产品系统结构的统一基础。我们在下面分几个部分介绍该架构中的功能模块。

需要说明，并不是每一个广告系统都需要以上所有的功能模块。这样的架构图和模块划分是为了方便本书后面在各种广告系统之间进行架构上的对比。另外，这样的架构主要是根据竞价广告系统的骨架来进行的，对于其他类型的广告系统，虽然概念上也可以套用，但是术语和习惯表达上会有一些不同。大家要注意的最关键之处是，在一个完整的广告系统架构中，数据的记录、交易、流转、建模和使用，因为这些是广告系统最核心的驱动力，也从本质上决定了广告产品的变现能力和利润空间。因此，我们将广告系统归于大数据产品之列。

在实践中，广告系统的建立应该是循序渐进的。一般来说，对一个刚起步的广告产品，有广告投放机和相应的日志系统，实现简单的定向投放逻辑，就可以开始使用。随着对广告效果深入优化的需求，需要建立起完整的广告排序和用户行为反馈模型；而当中小广告主大量增加时，就需要实现广告的倒排索引和相应的检索功能。因此，在一个新的广告产品开始运营和逐步完善的过程中，要特别注意根据当前阶段的实际需求决定哪些模块是必要的，哪些可以暂时省略，以避免过度设计和不必要的投入。

9.3.1 广告投放引擎

广告系统中必不可少的部分是一个实时响应广告请求，并决策广告的投放引擎，这与我们在个性化系统框架中介绍的个性化投放引擎一致。一般来说，广告系统的投放引擎采用类搜索的架构，即检索加排序的两阶段决策过程。另外，广告投放引擎还有一个独特模块，就是要从全局优化的角度对整体收益进行管理。广告投放引擎主要有以下几个模块。

图9-2 在线广告系统一般性架构示意

（1）广告投放机（ad server）。这是接受广告前端Web服务器发来的请求，完成广告投放决策并返回最后页面片段的主逻辑。广告投放机的主要任务是与其他各个功能模块打交道，并将它们串联起来完成在线广告投放决策。一般来说，为了扩展性的考虑，我们都采用类搜索的投放机架构，即先通过倒排索引从大量的广告候选中得到少量符合条件的或相关的候选，再在这个小的候选集上应用复杂而精确的排序方法找到综合收益最高的若干个广告。对广告投放机来说，最重要的指标是每秒查询数（Query per Second，QPS）以及广告决策的延迟（latency）。

（2）广告检索（ad retrieval）。这部分的主要功能在线时根据用户标签（user attributes）与页面标签（page attributes）从广告索引（ad index）中查找符合条件的广告候选。实际上，倒排索引技术的重要性体现在所有Web规模的技术挑战上，也同样是大规模计算广告系统的基础。广告检索得到的候选将被送入广告排序模块。

（3）广告排序（ad ranking）。这部分是在线高效地计算广告的 eCPM，并进行排序的模块。eCPM 的计算主要依赖于点击率估计，这需要用到离线计算得到的 CTR模型和特征（CTR Model&Features），有时还会用到流计算得到的实时点击率特征（real-time features）。在需要估计点击价值的广告产品（如按效果结算的DSP）中，还需要一个点击价值估计的模型。

（4）收益管理（yield management）。我们用这部分来统一代表在各种广告系统中将局部广告排序的结果进一步调整，以全局收益最优为目的做调整的功能，如GD系统中的在线分配、DSP 中的出价策略等。这部分一般都需要用到离线计算好的某种分配计划来完成在线时的决策。

（5）广告请求接口。实际系统中，根据前端接口形式的不同，广告请求可能来自于基于HTTP的 Web服务器，也可能来自于移动 App内的 SDK，或者其他类型的 API接口。不论哪种接口，只要能够提供用户唯一的身份标识ID以及其他一些上下文信息，从逻辑上讲与标准的HTTP请求就没有本质区别，因此我们都用Web服务器来表示。

程序化交易市场中的广告请求接口与上面有所不同，它包括作为需求方时使用的RTBS以及作为供给方时使用的 RTBD。这一接口可以采用 IAB建议的 OpenRTB协议或者其他主要ADX规定的接口形式。

（6）定制化用户划分（customized audience segmentation）。由于广告是媒体替广告主完成用户接触，那么有时需要根据广告主的逻辑来划分用户群，这部分也是具有鲜明广告特色的模块。这个部分指的是从广告主处收集用户信息的产品接口，而收集到的数据如果需要较复杂的加工，也将经过数据高速公路导入受众定向模块来完成。

9.3.2 数据高速公路

数据高速公路完成的功能是将在线投放的数据准实时传输到离线分布式计算平台与流计算平台上，供后续处理和建模使用，它非常类似于人体的循环系统。由于在进行受众定向建模时需要用到广告系统以外的其他用户产品日志或者第三方提供的数据，因此，数据高速公路也担负着收集这些数据源的任务。

9.3.3 离线数据处理

计算广告最具挑战的算法问题大多都集中在离线数据处理的部分。离线数据处理有两个输出目标：一是统计日志得到报表、dashboard 等，供决策人进行决策时作为参考；二是利用数据挖掘、机器学习技术进行受众定向、点击率预估、分配策略规划等，为在线的机器决策提供支持。为了对大规模数据进行分布式的处理加工，我们一般会选用Hadoop这样的分布式存储和MapReduce计算框架。离线数据处理有下面几个主要模块。

（1）用户会话日志生成。从各个渠道收集的日志需要先整理成以用户ID为键的统一存储格式，这样的日志称为用户会话日志（session log）。这样整理的目的是为了让后续的受众定向过程更加简单高效^[1]。

（2）行为定向（behaviorial targeting）。这部分功能完成挖掘用户日志，根据日志中的行为给用户打上结构化标签库（structural label base）中的某些标签，并将结果存储在用户标签的在线缓存中，供广告投放机使用。这部分是计算广告的原材料加工厂，也因此在整个系统中具有非常关键的地位。

（3）上下文定向（contextual targeting）。这部分包括半在线页面抓取（near-Line page Fetcher）和上下文页面标签的缓存，与行为定向互相配合，负责给上下文页面打上标签，用于在线的广告投放中。这里的抓取系统比搜索系统要简单，但也有不太一样的需求，后面会详细介绍。

（4）点击率建模（click modeling）。它的功能是在分布式计算平台上训练得到点击率的模型参数和相应特征（click model&features），加载到缓存中供线上投放系统决策时使用。

（5）分配规划（planning）。这部分为在线的收益管理模块提供服务，它根据广告系统全局优化的具体需求，利用离线日志数据进行规划，得到适合线上执行的分配方案（allocation plan）。

（6）商业智能（business intelligence，BI）系统。这部分包括 Extract-Transform-Load（ETL）过程、dashboard 和 cube，这些是所有以人为最终接口的数据处理和分析流程的总括，担负着对外信息交流的任务。由于实际的广告运营不可能完全通过机器的决策来进行，其间必然需要有经验的运营者根据数据反馈对一些系统设置及时调整。因此，实现一个功能强大、交互便利的BI系统是非常重要的。

（7）广告管理系统。这部分是广告操作者，即客户执行（Account Execute，AE）与广告系统的接口。AE通过广告管理系统定制和调整广告投放，并且与数据仓库交互，获得投放统计数据以支持决策。一般来说，广告系统中只有这部分是面向用户的产品。根据对操作对象开放程度的不同，这一系统有时又有开放自助的需求，在这种情况下，还需要包含相应的财务结算功能。对这部分，读者可以从很多自助式广告产品中看到，我们在第3章中已经进行了简单介绍。

9.3.4 在线数据处理

在线数据处理基本上可以认为是离线数据处理的镜像功能，它是为了满足广告系统对实时数据反馈的要求，解决那些离线分布式计算平台无法快速响应的计算问题。为了组织下面一些在线时前后有依赖关系的数据流加工过程，我们经常选用流式管理平台作为基础设施。在线数据处理主要包括以下模块。

（1）在线反作弊（anti-spam）。实时判断流量来源中是否有作弊流量，并且将这部分流量从后续的计价和统计中去除掉，是广告业务非常重要的部分。此模块是所有后续在线数据处理必须经过的前置模块。

（2）计费（billing）。这部分同样是计算广告关键的业务功能之一。对于那些经过扣费预算耗尽的广告，系统必须马上通知广告索引系统将其下线。当然，扣费也必须在扣除了作弊流量的基础上进行。

（3）在线行为反馈，包括实时受众定向（real-time targeting）和实时点击反馈（realtime click feedback）等部分。这部分是将短时内发生的用户行为和广告日志及时地加工成实时用户标签以及实时的点击率模型特征。对于在线广告系统，这部分对于效果提升的意义重大：在很多情形下，把系统信息反馈调整做得更快比把模型预测做得更准确效果更加显著。

（4）实时索引（real-time indexing）。这部分的主要功能是实时接受广告投放数据，建立倒排索引。广告的索引由于涉及预算调整等商业环节，因此必须在投放管理者调整以后非常快速地在线上广告索引中生效。