互联网DSP广告系统架构及关键技术解析 |

付海军，现就职于时趣互动，任技术总监，负责移动原生广告平台引擎开发和数据挖掘工作，06年毕业于兰州大学，曾就职于阿里巴巴集团万网从事主机面板和云计算底层开发；之后加入亿玛在线从事互联网广告程序化购买相关的工作，负责RTB竞价投放系统和大数据平台。对于系统架构设计和技术团队建设感兴趣，关注高并发实时系统，海量数据处理。

前言

大家好，感谢主持人，今天我讲的内容是DSP广告系统架构及关键技术，分享一下我过去几年在做DSP广告系统过程中的一些体会和经历，涉及到的内容如果后续想做广告系统的人员应该是可以做一些参考的，后续如果有疑问在分享结束后也可以跟大家私下交流，下面我就开始今天的分享了。

广告和网络游戏是互联网企业主要的盈利模式

广告是广告主通过媒体以尽可能低成本的方式与用户达成接触的商业行为。也就是说按照某种市场意图接触相应人群，影响其中潜在用户，使其选择广告主产品的几率增加，或对广告主品牌产生认同，通过长期的影响逐步形成用户对品牌的转化。

一个好的DSP系统需要满足：

拥有强大的RTB(Real-Time Bidding)的基础设施和能力。

拥有先进的用户定向(Audience Targeting)技术。

首先，DSP对其数据运算技术和速度要求非常之高。从普通用户在浏览器中地址栏输入网站的网址，到用户看到页面上的内容和广告这短短几百毫秒之内，就需要发生了好几个网络往返(Round Trip)的信息交换。

Ad Exchange首先要向DSP发竞价(bidding)请求，告知DSP这次曝光的属性，如物料的尺寸、广告位出现的URL和类别、以及用户的Cookie ID等；DSP接到竞价请求后，也必须在几十毫秒之内决定是否竞价这次曝光, 如果决定竞价，出什么样的价格，然后把竞价的响应发回到Ad Exchange。

如果Ad Exchange判定该DSP赢得了该次竞价，要在极短时间内把DSP所代表的广告主的广告迅速送到用户的浏览器上。整个过程如果速度稍慢，Ad Exchange就会认为DSP超时而不接受DSP的竞价响应，广告主的广告投放就无法实现。

其次，基于数据的用户定向(Audience Targeting)技术，则是DSP另一个重要的核心特征。从网络广告的实质上来说，广告主最终不是为了购买媒体，而是希望通过媒体与他们的潜在客户即目标人群进行广告沟通和投放。

服务于广告主或者广告主代理的DSP，则需要对Ad Exchange每一次传过来的曝光机会，根据关于这次曝光的相关数据来决定竞价策略。这些数据包括本次曝光所在网站、页面的信息，以及更为关键本次曝光的受众人群属性，人群定向的分析直接决定DSP的竞价策略。DSP在整个过程中，通过运用自己人群定向技术来分析，所得出的分析结果将直接影响广告主的广告投放效果。

此次分享主要针对以下几个方面，描述DSP广告系统架构及关键技术：

广告系统概念介绍

广告系统业务流程

DSP系统架构

RTB竞价引擎结构

点击率预测

DMP数据处理架构

受众定向划分

用户画像与广告系统反作弊

程序化购买的特点

下图是在DSP产生之前和产生之后广告行业的两种最常见产业链

传统的广告投放模式的产业链是广告主通过广告代理，以广告网络/联盟为渠道在媒体网站展示广告，达到接触受众的目的的过程。

这种模式的好处是媒体网站可以通过通过包段或CPS的模式可以售出自己的广告位，但是这类售出是偏粗放型的，长期同类型的广告投放，受众会视觉疲劳，点击率会下降，转化也会随之下降。为了能够获得更多的收益，媒体必须通过差异化销售细分自己的广告位和受众。而事实上显示广告领域最初的定向投放的最初动机是供给方拆分流量以获得更高的营收。好的位置，通过包段通常会供不应求，但是对于长尾流量通常是会无人问津，即便是对于广告主来说同一个潜在客户在大媒体出现会有广告主包段进行购买，但是在小网站出现就会没人买。事实上潜在客户在哪里出现对于广告主都是同一个人，如果能显示与客户需求相吻合或接近的广告就有可能产生转化。在将优质广告位包段售出后，如果对用户有足够的认识，有足够多不同类型的广告主，在流量可以拆分到单次展现的购买粒度，就有可能依据不同的受众定向为每个广告主找到合适的人群和流量。

程序化购买颠覆了原有广告产业链，形成了全新的产业链。

鉴于群里有很多人不是做广告系统的，为了能够在后续的介绍过程中更容易理解介绍的内容，这里先介绍一些广告行业中常见的一些概念。

DSP（Demand Side Platform），是广告需求方平台，DSP为广告主提供跨媒介、跨平台、跨终端的的广告投放平台，通过数据整合、分析实现基于受众的精准投放，并且实时监控不断优化。

RTB（Real Time Bidding）实时竞价是DSP、广告交易平台等在网络广告投放中采用的主要售卖形式，会在极端的时间内（通常是50~100毫秒以内）通过对目标受众竞价的方式获得该次广告的展现，RTB的购买方式无论在PC端或是移动端均可以实现。

程序化购买（Programmatic Buying）根据广告主定义的期望受众，系统帮助其找出优选的媒体来购买受众，为广告主提出最优媒介采买计划，通过程序化购买的方式执行，并按照期望的周期反馈监测结果，并对后续投放进行优化。包括但不仅限于RTB购买。

最常见的DSP行业中的供需业务流，广告主作为需求方，潜在客户是最终的受众，中间穿插着代理机构，DSP，AdNetwork，AdExchange,SSP和供应方也就是媒体。

下图是DSP平台的广告投放流程，投放过程中涉及到广告受众，媒体网站，adx和dsp，分别标注了广告投放各阶段伴随发生的事件。从1~7步之间只允许100ms之内的延时，否则广告受众就会觉得网页加载速度太慢而选择离开。

在线广告的核心问题

需要在特定用户，在指定上下文的环境下，找到最合适的广告，进行投放，并尽可能产生转化。

在线广告的挑战

大规模

百万量级页面，十亿量级用户，需要被分析处理

高并发在线投放（每天处理百亿次广告交易请求）

时延要求严格（adx通常要求竞价响应时间在100ms完成）

用户定向动态变化

用户的关注点和购物兴趣变化会比较频繁，需要能够及时更新用户画像

上下文条件变化频繁

用户和上下文多样化的环境一起用于广告候选检索

DSP系统架构

上图是主要模块的流程图涉及到的角色包括广告主网站，媒体网站，广告网络和DSP，以及DSP内部的相关模块，如：RTB引擎，业务平台，日志收集系统，DMP，CM和反作弊系统。

投放前DSP会要求在广告主网站布码，同时在DSP的业务平台中录入广告投放的需求，如投放金额，投放排期，投放定向（如地域，兴趣，年龄等），最高限价。

当访客（即潜在的消费者）从左上角访问广告主网站开始，访客在广告主网站上的行为会被收集，同时DSP会与ADX和SSP进行Cookie Mapping，形成日志进行处理，形成回头客相关的行为数据标签。

当访客完成对广告主网站的访问，去其他媒体网站进行访问时，相应的媒体广告位根据事先嵌入的广告代码向广告网络发起广告请求，广告网络会将广告请求封装成http头+pb体的格式向多个DSP发起竞价请求。

当DSP接到竞价请求时会根据与广告网络约定的pb格式进行解包，拆解出相关的字段进行匹配，根据之前相关媒体积累的点击率结合点击率预测模型对出价进行预测，找出平台内在此次竞价请求能让平台利益最大化的广告主的创意进行投放，返回给广告网络出价与广告代码

广告网络会在特定时间内（通常是50~100毫秒）根据多个DSP的出价高低，以第二名价格多一分的价格让出价最高的dsp胜出，并将广告代码中的展现宏和点击宏进行替换（替换过程中会根据事先与dsp约定好的公钥对价格进行加密，以防止第三方篡改和窃听）

广告网络将广告代码返回给媒体，媒体会将广告代码放置在js对应的位置进行展现，展现和点击的过程中会先后触发广告网络和胜出DSP的展现代码，广告网络和DSP分别接收到展现请求会对相应的展现进行计费操作（月底会相互进行对账）

DSP内部会根据收集到的展现和点击进行计费操作，形成相应的报表；而浏览、展现、点击的记录会分别进行收集形成日志，经过ETL由DMP进行抽取和分析，形成媒体数据，用户标签，CookieMatch数据以及回头客用户标签数据，这些数据会在投放过程中作为RTB竞价的参考依据。

整个投放过程中其实还有一些其他的模块出现如CookieMapping、反作弊，动态创意、网站分析系统。只不过这些系统不是在主干流程上，后续单独进行描述和分析。

为了保证投放，DSP系统实现了多机房部署的结构，南北方机房分别在杭州和北京部署RTB引擎、点击率预测与相关的展现点击收集节点。投放活动相关数据通过Redis进行缓存，多机房进行准实时同步，媒体展现点击数据通过kafka队列进行推送，通过Consumer进行消费统计，最后通过媒体数据分发集群分发到多个机房进行使用。

RTB投放引擎的架构

RTB引擎是DSP系统的核心，是实现高并发实时反馈的关键，RTB对外以HTTP服务形式暴露接口，当媒体上的js被触发，adx/ssp收到js请求后会将请求封装成http头+pb体(protocol buffer,谷歌定义的序列化数据交换格式)的方式作为客户端连接RTB，RTB对http消息按照事先约定解包在内部依靠相关数据进行计算，最终返回pb或json格式的出价和广告代码给广告交易平台。RTB需要支持高并发（每天百亿级别请求）和低延时（50ms之内需要反馈）。

当时我们的RTB采用Linux C++开发，通过Adapter适配器层解耦适应不同的SSP/adx，算法池内部拆分成五层，五层之间相互正交，算法模块允许热插拔，编译完成的动态链接库可根据配置文件的变化实时进行加载和卸载，允许多算法链并行拆分流量进行A/B测试，流量处理过程中会对流经不同算法链的流量打上不同的算法标签，并在后续展现，点击过程中持续带上此标签用于后续效果的跟踪和分析。

下面说一下在针对RTB进行架构设计过程中涉及到的一些技巧：

由于一个dsp要接触到尽可能多的流量和用户才有可能找到符合广告主定向的目标受众，那dsp一定要对接很多的adx和ssp，来接受尽可能多的流量。设计适配器层的目的就是将不同adx之间的流量格式差异消灭在适配器这一层，对于进入系统内部的流量都一视同仁，简化了rtb系统的复杂性。RTB系统在设计之初就考虑了AB测试的环节，让算法的效果能够进行横向比较，方便算法进行优化。RTB本身是不带状态的，也就是说，它只能依靠外部的辅助系统提供的信息，如点击率预测，人群定向和反作弊这类模块提供的数据才能实现快速反馈的同事能正确反馈。

DMP

对于RTB的设计在后续提问和讨论的环节我们再做进一步分析，下面讲一下DSP系统中除了RTB之外的另外一个核心：DMP

首先需要定义一下广告投放过程中关键的一些数据：

广告系统DMP数据处理的架构

跟大多数的大数据相关的系统很相似，基本上逃不开那几样东西Hadoop，storm，redis等等:

数据处理部分结合了Hadoop的离线计算、Spark的批处理和Storm的流式计算。

HBase和MySQL用于最终结果落地用于前端查询。

ElasticSearch有准实时索引，用于明细数据实时查询和时间序列历史回溯统计。

Spark内置的机器学习算法库MLLib主要使用分类，聚类KMeans，协同过滤，决策树，逻辑回归。

由于之前在群里的分享中,王新春@大众点评 ，王劲@酷狗音乐 讲了很多storm实时处理和大数据架构的内容，他们二位都是大数据领域的大佬了，我在这里就不班门弄斧了，简单提一下广告行业里是怎么做的，基本上大同小异，大家用的东西都差不多。