分享嘉宾：曲瑶 58同城 架构师导读：随着大数据的快速生长，大数据应用已经融入各行各业。在许多场景中获得了商业化实践。今天和大家分享下58同城同盟广告平台架构及实践。主要包罗：58同盟广告SSP媒体平台、投放平台、法式化创意等焦点模块的设计和实现，以及对同盟业务的思考与展望。

01同盟广告平台简介1. 业务概述58同盟广告平台主要是以58站内的广告主为基础并联合站外流量，资助58站内广告主获取站外潜在用户，从而实现流量变现。流量获取主要通过SSP和DSP这两种方式。同盟SSP平台可直接与媒体对接，直接在媒体上展示投放的广告。

DSP是通过投放平台（例如百度SEM、广点通等）投放到媒体上展示广告。2. 业务架构主要先容以下四个模块：① 同城宝SSP同城宝SSP主要是服务于媒体方（例如民众号，blog站点），媒体方可以在此注册广告位，资助媒体方实现流量变现。

焦点模块主要包罗媒体治理、广告位治理、广告治理、媒体报表、广告位报表、财政结算、流水记载等。② 直投平台直投平台是基于一些媒体平台（百度SEM、广点通等）的 Marketing API开发的一个平台，主要是更高效的举行广告投放，资助我们更好的运营。焦点模块主要包罗统一投放网关、法式化创意生成、OCPX、账号治理、物料治理、报表服务、优化工具（批量操作、法式化调价等）等。

③ 同盟DSP主要与一些主流的ADX对接，服务于58运营，将运营建立的广告投放到媒体上。详细先容见下文。④ 创意平台其实广告很重要的一部门就是创意，广告位的规格种种各样，比力碎片化。

创意平台提供通历程序化工具生成创意图片、标题、形貌等，来提高创意制作效率和效果。02媒体平台1. 业务先容媒体平台主要服务于媒体方的，媒体方可以在此平台注册公司、注册媒体和注册广告位，获得投放链接、js或api，然后部署到自己的媒体上，从而通过提供广告位举行变现。2. 对接模式对接模式现在主要支持牢固链、标签云、快捷图标和 API。

3. 架构① 媒体方先在SSP平台上注册好广告位(包罗公司、媒体和广告位设置信息)，然后获取广告投放链接、js或api接口等相关信息。② 媒体方将获得的链接、js或api接口等信息，部署到媒体方App或站点上。③ 媒体方App或站点请求同盟广告API，会转向到同盟ADX，从而对接58站内广告库（包罗房产、招聘、二手车、黄页等），对广告库内广告举行召回并在媒体方上投放广告。

④ 媒体方App或站点上的广告被展示或点击，会向同盟监测上报请求，最后数据落入同盟数据平台。⑤ 凭据最终广告效果，基于分成或服务费的模式，媒体方获取提供广告位的收入。4. 效果评估关于如何评估每个媒体的广告效果，主要有以下三种方式，现在58同盟主要使用Cookie方式。

① url通过URL透传的方式，一直向下游通报广告泉源参数，但维护成本高，中途容易丢失。② 日志追溯通过记载用户行为日志的方式举行离线归因的方式。

处置惩罚用户行为日志是通过用户SessionId 串联用户的所有行为，并根据时间戳举行排序，获取该用户第一次进入系统URL，只需用户一跳带上泉源标识即可获取用户的泉源信息。缺点是工程层面无法实时归因。③ Cookie基于Cookie传输，维护成本低，各个系统可以从Cookie中实时获取用户信息，支持实时归因。5. 挟制防范流量挟制通常通过DNS挟制或路由器挟制的方式，将正常会见58的用户会见链接重定向为302，然后在会见链接后面加上一些参数。

可以接纳使用全局HTTPS、手动指定DNS和HTTPS-DNS解决流量挟制。03投放平台1. 投放平台(MKT API)由于线上主流的投放平台众多，如百度搜索、百度信息流、神马搜索、360搜索、头条搜索、广点通、头条信息流等，每个投放平台都拥有自己的私有流量，如果想要全网投放广告，需要对接平台很是之多，运营营销人员维护起来很是繁琐。MKT API投放平台主要是整合各投放平台，降低维护难度，淘汰运营成本。

2. 投放平台 ( MKT API ) 架构Marketing API模式存在的问题：Marketing API投放平台的模型依赖媒体侧用户画像，更适合拉新场景，但在RT场景无法充实使用广告主侧画像和模型；无法按一次曝光精致化购置流量（频控、跨屏联动）；计谋模型、投放数据、投放规则散落在各个外部DSP，难以沉淀3. 投放平台 ( DSP )广告竞价流程：通过ADX（包罗外部广告媒体（如广点通、今日头条ADX） 和同盟SSP平台的ADX）与我们同盟DSP平台对接，媒体方提倡广告请求时，ADX会将广告请求发送到DSP，DSP收到请求后会做简朴的参数映射处置惩罚后，然后将请求转发给DSP广告检索服务，检索服务会从同盟DMP平台获取用户的画像，然后凭据用户的偏好从广告库中检索广告，通过预算控制或CPM报价服务预估广告的出价返回给ADX，ADX竞价乐成、广告展示或点击都市上报到监测接口。广告所发生的数据（包罗出价、获胜、展示、点击等）最终均落在数仓中。实时数据会基于Flink框架举行数据处置惩罚加工，最终存储在Druid或ES中。

离线主要基于Kylin预盘算举行OLAP多维分析4. 投放平台 ( DSP ) 性能优化RTB实时竞价历程对性能要求很是高，对接外部ADX要求在70ms内返回竞价效果，我们58同盟内部的性能要求是在50ms之内返回竞价效果。由于我们DSP对接多方ADX，QPS到达了10万左右。

如何提高我们系统性能呢？我们现在接纳异步和延时这两种方式优化系统性能。异步异步一般适用IO比力麋集、请求处置惩罚时间过长、线程数较多、高负载等场景。

起初我们使用的是阻塞线程模型，遇到一些IO操作（如查询Redis，挪用其他服务等），线程处于阻塞状态，导致一个线程只能处置惩罚一个请求，想要提高系统处置惩罚的请求数，只能通过增加线程数类解决。线程数过大会导致线程切换开销过大，内存占用较大。

我们接纳EventLoop-Thread线程处置惩罚多个请求，淘汰锁的开销，制止线程爆炸问题。在代码层面接纳Future/Promise解决异步回调开发繁琐，代码结构庞大，嵌套较多的问题。异步与同步压测效果对比：延时我们的DSP平台主要是基于Java生态的，GC问题会导致性能下降，对广告系统影响较大。

这里先容下我们关于GC遇到的一个问题及解决方案。配景：在DSP竞价时，需要获取当前用户所在的都会信息，之前我们是通过IP来查询用户所在都会，并将IP和CityId（都会信息）的对应关系使用LRU缓存起来。问题：上线以后，发现每2小时出发一次FullGC（Old区内存为2G），造成600ms STW。分析：发现我们线上服务TP99在80ms左右，理论上应该不会有存活工具进入暮年代，可是发现每次YoungGC有2M左右，发现主要是LRU缓存中工具进入Old区。

解决方案：我们之前LRUCache的工具数量快要1600w多个，举行GC时JVM会扫描存活的工具，这将发生1000多万次工具扫描的开销。为了制止这个问题，我们接纳Free GC设计，通过声明一个long类型的三维数组(前32位代表时间戳，后32位地域id),使用一块牢固内存，这样在GC时只扫描一个工具。

另外在破晓4:00手动触发System.gc()，制止对系统白昼运行的影响。效果：FullGC距离从之前的2h酿成30h；TP99 从80ms降低到50ms；MEAN从13ms 降低到 11ms。5. 投放平台 ( DSP ) 索引设计现在DSP平台主要是对58内部运营开放，推广数并不是很大。

我们现在接纳一个主分片和多个从分片（主要是分摊查询流量），为保证索引可用性，我们接纳了双索引设计。6. 投放平台 ( DSP ) TB级竞价缓存由于一般URL的长度有限制，携带的信息有限，我们接纳两级Cache，将竞价信息，如召回计谋、排序计谋、预估CTR等中间环节数据写到到缓存中，在获胜、展示和点击时从缓存中获取数据。7. 投放平台 ( DSP ) 竞价引擎竞价引擎包罗流量优选、召回、智能预算、过滤、CPM报价计谋和创意展示模块。

流量优选：基于反作弊手段和投放效果过滤掉一部门流量，从而减轻后链路数据盘算处置惩罚的压力。召回：基于广告排期人群定向媒体定向等规则从索引中召回广告。智能预算：基于预算计谋(快速消耗宁静滑消耗)，快速消耗则正常出价，平滑消耗使用pCTR出价计谋。

过滤：基于频控计谋，包罗DSP内部频控计谋和ADX团结频控计谋。报价计谋：支持CPM和CPC两种报价模式，均提供牢固模式和基于ROI调控模式报价。

创意展示：包罗个性化创意和创意优选功效，个性化创意凭据用户画像特征示，创意优选凭据模板基于历史效果选择最优举行展示。8. 投放平台(DSP) OLAP多维分析DSP系统现在接纳Lambda架构，以离线数据为准，保证数据的稳定性，历史数据可追溯。9. 用户画像标签体系标签体系主要是基于业务线构建的，上层支持DSP、ADX、创意、落地页动态路径等应用。

04法式化创意由于站外媒体提供的广告位规格碎片化、创意恒久投放会导致CTR下降需要定期更新和人工制作上传效率低，站内存在大量低质图片，导致用户体验不友好等问题，基于这些问题我们开发了法式化创意平台。建设法式化创意平台需要面临如何法式制作切合美学的图片和如何应对数据量和检索量过大的挑战。

1. 图片渲染2. 架构提供服务公布API，供DSP投放平台、站内广告系统等。创意图片渲染引擎（Creative-Builder），提供图片自动化生成，包罗特征抽取、设置组装、规则优选、图片渲染等模块。从广告中抽取一些焦点元素(如标题、标签等)，凭据用户的需求设置检索合适的模板然后举行组装，基于标签、配色等组合计谋优选出合适的素材，然后举行渲染，并上传到CDN，同时同步到创意索引中。

创意索引会基于CTR预估将多张创意图片针对不用用户举行优选，创意的展示点击数据会回传到我们平台，形成数据链路闭环。3. 索引设计法式化创意索引设计接纳的是58自研云搜体系，当shard数量过多时，会导致读写扩散，增加CPU和IO分外开销，发生性能瓶颈。针对上述问题，我们对路由计谋举行优化，只管将查询路由到较少的分片上。route-key设计：58大多数广告是都会加种别组成，很少有跨都会或种别的广告，基于这种业务场景，我们在路由设计时接纳一级都会加二级种别作为route-key，这样可以保证95%的请求同一个route-key，仅查询1个分片即可。

route-strategy：凭据route-key的hash值取模来指定soltId，另外还需人工设置路由表，设置中会记载每个分片和soltId的对应关系，并将设置记载在Zookeeper中。路由计谋仅由 IndexBuilder和Router(Redis) 控制，索引扩容时只需修改RoutetConfig，增量数据就会使用新的路由计谋构建索引，再针看待迁移slot触发重建即可，从而解决了索引扩容和重建的问题。4. 展望今天的分享就到这里，谢谢大家。原文：https://mp.weixin.qq.com/s/ns0GtvI0NDFAZf-Q1TlYbA。

本文来源：金沙官方登录入口-www.30law.com