“58同城”架構師分享：聯盟廣告平臺架構及實踐

分享嘉賓：曲瑤 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