互联网DSP广告系统架构及关键技术解析 广告行业资深架构师亲述，耀世平台怎么样！付海军，现就职于时趣互动，任技术总监，负责移动原生广告平台引擎开发和数据挖掘工作，06年毕业于兰州大学，曾就职于阿里巴巴集团万网从事主机面板和云计算底层开发；之后加入亿玛在线从事互联网广告程序化购买相关的工作，负责RTB竞价投放系统和大数据平台。对于系统架构设计和技术团队建设感兴趣，关注高并发实时系统，海量数据处理。
Ad Exchange首先要向DSP发竞价(bidding)请求，告知DSP这次曝光的属性，如物料的尺寸、广告位出现的URL和类别、以及用户的Cookie ID等；DSP接到竞价请求后，也必须在几十毫秒之内决定是否竞价这次曝光, 如果决定竞价，出什么样的价格，然后把竞价的响应发回到Ad Exchange。
服务于广告主或者广告主代理的DSP，则需要对Ad Exchange每一次传过来的曝光机会，根据关于这次曝光的相关数据来决定竞价策略。这些数据包括本次曝光所在网站、页面的信息，以及更为关键本次曝光的受众人群属性，人群定向的分析直接决定DSP的竞价策略。DSP在整个过程中，通过运用自己人群定向技术来分析，所得出的分析结果将直接影响广告主的广告投放效果。
这种模式的好处是媒体网站可以通过通过包段或CPS的模式可以售出自己的广告位，但是这类售出是偏粗放型的，长期同类型的广告投放，受众会视觉疲劳，点击率会下降，转化也会随之下降。为了能够获得更多的收益，媒体必须通过差异化销售细分自己的广告位和受众。而事实上显示广告领域最初的定向投放的最初动机是供给方拆分流量以获得更高的营收。好的位置，通过包段通常会供不应求，但是对于长尾流量通常是会无人问津，即便是对于广告主来说同一个潜在客户在大媒体出现会有广告主包段进行购买，但是在小网站出现就会没人买。事实上潜在客户在哪里出现对于广告主都是同一个人，如果能显示与客户需求相吻合或接近的广告就有可能产生转化。在将优质广告位包段售出后，如果对用户有足够的认识，有足够多不同类型的广告主，在流量可以拆分到单次展现的购买粒度，就有可能依据不同的受众定向为每个广告主找到合适的人群和流量。
鉴于群里有很多人不是做广告系统的，为了能够在后续的介绍过程中更容易理解介绍的内容，这里先介绍一些广告行业中常见的一些概念。
最常见的DSP行业中的供需业务流，广告主作为需求方，潜在客户是最终的受众，中间穿插着代理机构，DSP，AdNetwork，AdExchange,SSP和供应方也就是媒体。
上图是主要模块的流程图涉及到的角色包括广告主网站，媒体网站，广告网络和DSP，以及DSP内部的相关模块，如：RTB引擎，业务平台，日志收集系统，DMP，CM和反作弊系统。
当访客（即潜在的消费者）从左上角访问广告主网站开始，访客在广告主网站上的行为会被收集，同时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引擎是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测试，流量处理过程中会对流经不同算法链的流量打上不同的算法标签，并在后续展现，点击过程中持续带上此标签用于后续效果的跟踪和分析。
由于一个dsp要接触到尽可能多的流量和用户才有可能找到符合广告主定向的目标受众，那dsp一定要对接很多的adx和ssp，来接受尽可能多的流量。设计适配器层的目的就是将不同adx之间的流量格式差异消灭在适配器这一层，对于进入系统内部的流量都一视同仁，简化了rtb系统的复杂性。RTB系统在设计之初就考虑了AB测试的环节，让算法的效果能够进行横向比较，方便算法进行优化。RTB本身是不带状态的，也就是说，它只能依靠外部的辅助系统提供的信息，如点击率预测，人群定向和反作弊这类模块提供的数据才能实现快速反馈的同事能正确反馈。
对于RTB的设计在后续提问和讨论的环节我们再做进一步分析，下面讲一下DSP系统中除了RTB之外的另外一个核心：DMP
上下文标签t(c)，即当前用户联系上下文在当前的访问行为达到的即时标签。
广告主定制化标签t(a,u)，是根据特定广告主提供的特定用户群在其网站上的访问行为数据加工所得。
人口属性主要包括年龄，性别，收入，学历等；频道定向主要是针对媒体侧特点，对相应受众进行划分；上下文定向主要是根据当前网页的内容上下文推送相关广告；行为定向是根据用户历史访问行为，了解用户喜好，进而推送相关广告；精确位置定向是在移动设备上根据精确的地理位置投放广告，更聚向与地域性非常强的的本地生活类广告主；
我们能够看到用户画像其实也就是对于用户特征的提取，涉及到人口，设备，运营商，位置以及用户的浏览，点击购买等行为数据。用户画像是通过对用户特征的提取对用户行为进行定性和定量的描述，形成：【用户ID:用户标签：标签权重】形式的用户画像标签，在广告投放过程中，根据提取流量对应用户权重较高的若干个标签反向对广告主进行筛选，找出适合流量特点的广告素材。 用户标签用于广告主对于受众的选择，而权重用于在海量用户标签里选取重点的标签进行投放。
事实上在广告平台中收集到的最多的数据是用户的浏览数据，在拿到这么多的浏览数据的情况下，想要分析出用户的爱好和兴趣以及需求，那就需要对网页的内容进行分析和抽取，下面介绍一下用户画像中非常重要的行为标注部分的架构：
用户在浏览一系列网站的过程中是多少会带着一些目的性进行浏览的，即便是没有明确目的，也会带有一些个人喜好，有了这些目的和喜好，就会进一步缩短我们在推送广告过程中对于用户定向的选择难度。上图就是在上下文定向中对网页关键字提取的子系统的架构。【上下文定向】可以通过网页关键字提取，建立一个cache，根据URL建立对应标签，当广告请求到来时，命中相应URL则返回cache的命中内容，如果URL未缓存则返回空集合，同时将URL添加到后台抓取队列，在URL被抓取，并打上标签存入cache，为cache设置TTL，当长期不访问则将该URL的记录清楚，而热点内容URL的关键词是始终被缓存的，运行较长的时间则大多数热点URL大多会被缓存。在抓取到内容之后，需要对网页内容进行内容挖掘，在挖掘的过程中有以下几个方案可以被选取：
预估的目标是为特定的受众用户再给定的媒体环境下找到最合适的广告，对媒体来说实现收入最大化，即按照eCPM排序的基本原则来排序。
三个维度的CTR对照关系，预测过程中，当一个user访问特定url时，查询词典如果存在
存在问题：基于统计数据，对旧广告效果还可以，但对冷启动的广告没有预测能力。事实上，我们在线上做点击率预测模型，使用的算法是逻辑回归，后续可能考虑会用到的广告点击率预测方法有：
对排序（pair-wise approach）：比较两个广告谁的优先级高，不分类
列排序（list-wise approach）：对整个广告候选集学习排序模型
均通过客户端软件向服务器提交互刷任务请求，客户端收到服务器分发的互刷任务后执行隐藏的浏览任务，每天可达到数千个IP的访问量，IP布局分散，UA随机生成，很难通过浏览记录寻找作弊痕迹。现在唯一有效的反作弊方法需要通过蜜罐主机进行跟踪和分析。下面介绍一下我们对于p2p刷量所采用的蜜罐主机的结构：
如果是对信息安全有一定了解的人对于蜜罐系统一定不陌生，也就是系统设计上有意抛一些破绽出来，让攻击者自己跳出来，通过对攻击者行为的观摩来寻找破解攻击的思路。
由于流量宝、流量精灵一类的刷量工具多集中于windows平台下，安装windows vm并将系统代理指向nginx反向代理，通过刷量工具提交刷量任务。提交刷量任务的站点没有任何真实流量，只要是访问这个站点的IP基本上都是通过刷量工具来的流量，IP可以在RTB引擎对相关IP端进行封杀，不再进行投放；
Nginx反向代理落详细日志通过Logstash收集、解析发送给ElasticSearch建立索引，通过kibana做可视化，统计出刷量最多的IP，域名和URL地址出来，可以作为后续模式识别的模型输入。搜集相关证据，域名可以向adx反馈对媒体进行封杀，同时可以根据筛选出的刷量作弊域名在DSP投放过程中减少投放以避免自身损失。
引流作弊可以帮助引流网站“提高”CPC，“提高”CPS。但对广告主不产生实际有效的流量。
也就是说在DSP投放了广告的网站里被插入了跳转到CPS计费链接的302跳转的图片，虽然DSP花钱从adx买了流量投放了广告，但是这个页面里还有大量的CPS结算的链接跳转，如果广告主既在网盟，又在DSP投放广告的话，任何看过这类页面的人在广告主网站下的单，就有可能被劫持走。整个过程中，用户都不知道有广告主的存在。但是对应的广告主会认为是特定CPS链接带来了一个点击，后续的cps应该是记在相应的CPS合作方名下。
数据分不同的形式存在不同的地方，原始日志存放在硬盘上，经过ETL后写入HDFS，结构化存放在Hive表中进行查询，cookiemapping数据经过hadoop计算过后导出成文件，存放在Tair里让RTB查询，用户行为数据存放在hdfs里，画像之后数据存放在redis供rtb查询，跑出来的统计报表存放在mysql供报表系统调用。CM的cookie对应数据有一部分也是存放在hbase的，hbase和hadoop共用hdfs，所以查询速度也会受到hadoop集群资源多少的影响。
上面我曾经提到过RTB系统是用Linux C 开发的，如果对于Linux C 比较熟悉的人应该知道Linux下是可以动态加载动态链接库的使用的主要是：
inotify是一种文件系统的变化通知机制，如文件增加、删除等事件，可以立刻让用户态得知。我们在RTB程序启动过程中向系统注册了inotify事件来监控配置文件，当配置文件被修改的时候立即通知程序重新加载配置文件
cookieMapping分在线和离线两种，通常情况下广告投放过程中会有几个场景会发起cm
除此之外对于运营商数据的使用过程中通常就是离线匹配的了，方法通常是运营商的浏览数据来自于路由设备的DPI信息，里面有用户的adsl账号信息，运营商会找出一定时间内访问过dsp指定的几个域名的人，通常会在这个域名下面的所有页面都布上cm代码，通过http头就能找出dsp的cookieID，找出的这些人都会有adsl账号标识，通过账号就能建立与dsp的cookieID的关系，这类cm就是离线：请问怎么识别是同一个用户？通过cookie，还是有其他先进的办法？
在PC端还会用flash cookie的方法来打通不同的浏览器，因为flash storage是同一块存储不同的浏览器可以跨浏览器打通。当然还有一种叫evercookie的手段集合了包括flash cookie 之内的多种标识方式，感兴趣的可以了解一下这个网址
移动端的身份标识，安卓的包括android id，mac地址IMSI和IMEI，而iOS是IDFA。由于移动设备上安装的app里可以嵌入SDK，而app有可能在移动端的权限也不同获取到的标识也会有差异，所以最终也会涉及到用户标识统一识别的问题，当然移动端的用户标识会远比PC端要强很多，移动广告化之后用户画像将会更加的准确。
本文策划 秋翾@百姓网, 内容由国忠，陈刚编辑与发布，其他多位志愿者对本文亦有贡献。读者可以通过搜索“ArchNotes”或长按下面图片，关注“高可用架构”公众号，查看更多架构方面内容，获取通往架构师之路的宝贵经验。转载请注明来自“高可用架构（ArchNotes）”公众号。
本站是提供个人知识管理的网络存储空间，所有内容均由用户发布，不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息，谨防。如发现有害或侵权内容，请点击
