Question

广告网络是除了搜索广告以外最重要的非实时竞价类广告产品。由于没有了明确的用户意图以及展示位置的固定性，像查询扩展、广告放置等问题在广告网络中并不存在。下面看一下广告网络的优化目标、系统架构以及短时行为反馈等问题。

广告网络的优化目标在公式2.2的基础上有所调整，可以用下式来表达：

由于广告网络的成本是分成或包断媒体资源，因此公式2.2中的成本项被去掉了；而收入部分是比较典型的根据“a given user in a given context”，求“suitable ad”的过程，即根据给定的用户和上下文求合适的广告的过程，这也反映了计算广告决策的核心逻辑。

广告网络的典型系统架构如图13-2所示，其中广告投放的决策流程为：服务器接收前端用户访问触发的广告请求，首先根据上下文信息和用户身份标识从页面标签和用户标签中查出相应的上下文标签和用户标签；然后用这些标签以及其他一些广告请求条件从广告索引中找到符合要求的广告候选集合；最后，利用CTR预估模型计算所有的广告候选的eCPM，再根据eCPM排序选出赢得竞价的广告，并返回给前端完成投放。

从离线计算的流程来看，广告网络需要根据广告投放的历史展示和点击数据对点击率预测进行建模。当然，实际的广告网络也往往需要同时提供受众定向的功能，因此这部分离线计算也需要进行。不过由于我们只给出最核心的功能块，因此没有强调这一部分。

由于广告网络广泛采用 CPC 计费，准实时的计费和点击反作弊功能是必不可少的；另外，将用户行为尽快反馈到广告决策中对于点击率预估和受众定向的效果提升也非常关键。这些需求共同催生了流计算技术，这一技术被广泛应用于短时受众定向和短时用户行为反馈。

短时行为反馈与流计算

虽然用户行为定向不适用于搜索广告，但是用户在一个会话内的一系列查询如果能够快速处理，还是会对准确理解用户意图有帮助。除了这样的短时用户行为反馈，在广告业务中还有以下一些需要快速对在线日志进行处理的场景。

图13-2 广告网络系统架构示意

（1）实时反作弊。反作弊是所有广告系统都需要的模块，关于反作弊具体的技术将在第15章中介绍。在ADN、DSP这类依赖于站外流量的广告产品中，爬虫流量、突发的作弊流量都会对广告主预算产生巨大的影响。因此，在所有需要实时数据处理的模块之前，需要一个实时反作弊的模块，对系统产生的日志进行过滤。

（2）实时计费。广告产品需要一个实时计费的模块，以便将那些预算消耗完的广告及时下线，避免系统损失。

（3）短时用户标签。Hadoop 上计算用户标签 t（u） 往往需要比较长的更新周期，如每天。而及时利用用户分钟级别的行为数据加工用户短时兴趣的标签，被证明对广告效果帮助很大^[13]。这种短时用户标签也需要一种数据准实时处理的工具。

（4）短时动态特征。CTR预测中的动态特征（见 13.5.4节）也可以根据分钟级的数据补充调整。

这些场景对数据处理系统提出了新的挑战：简单的基于Hadoop的离线挖掘模式不再适用了，需要一个灵活的计算框架，能够实时流式地接受线上日志，并用预先组织好的一组处理过程来加工这些数据，得到随时可以被使用的结果。这样的需求催生了流计算平台。以上面的几个广告系统中实时处理的任务为例，它们组成的处理流程可以用图13-3来示意。

图13-3 广告系统中的流计算任务流程示意

图13-3的流程非常类似于一组有依赖关系的MapReduce任务，但是由于数据实时处理的需求，它需要的计算架构与MapReduce是不同的。一个流计算的基础平台应该能够自动完成数据在不同任务间的调度以及任务内部的分布计算。流计算平台有若干开源工具可供选择，其中 Storm的编程接口与 Hadoop很相似，使用起来相当方便，可以参考 9.5.8节中的介绍。

虽然计算逻辑上接近，流计算与MapReduce有着本质的不同：MapReduce是通过分布式文件系统尽可能对计算进行调度，而流计算则是在各台服务器之间调度数据来完成计算。这使得它们的适用场景也有着很大的区别：流计算适用于准实时、快速的数据统计和反馈，但是由于是在调度数据，所以并不适合于海量数据的批量计算；而MapReduce更适用于数据量非常大，但是计算实时性要求并不太高的情形。实践中，往往需要两者结合来达到数据量和实时性两方面的要求。