此文是根據(jù)付海軍在【QCON高可用架構(gòu)群】中的分享內(nèi)容整理而成，轉(zhuǎn)發(fā)請(qǐng)注明出處。

付海軍，現(xiàn)就職于時(shí)趣互動(dòng)，任技術(shù)總監(jiān)，負(fù)責(zé)移動(dòng)原生廣告平臺(tái)引擎開發(fā)和數(shù)據(jù)挖掘工作，06年畢業(yè)于蘭州大學(xué)，曾就職于阿里巴巴集團(tuán)萬網(wǎng)從事主機(jī)面板和云計(jì)算底層開發(fā)；之后加入億瑪在線從事互聯(lián)網(wǎng)廣告程序化購買相關(guān)的工作，負(fù)責(zé)RTB競價(jià)投放系統(tǒng)和大數(shù)據(jù)平臺(tái)。對(duì)于系統(tǒng)架構(gòu)設(shè)計(jì)和技術(shù)團(tuán)隊(duì)建設(shè)感興趣，關(guān)注高并發(fā)實(shí)時(shí)系統(tǒng)，海量數(shù)據(jù)處理。

前言

大家好，感謝主持人，今天我講的內(nèi)容是DSP廣告系統(tǒng)架構(gòu)及關(guān)鍵技術(shù)，分享一下我過去幾年在做DSP廣告系統(tǒng)過程中的一些體會(huì)和經(jīng)歷，涉及到的內(nèi)容如果后續(xù)想做廣告系統(tǒng)的人員應(yīng)該是可以做一些參考的，后續(xù)如果有疑問在分享結(jié)束后也可以跟大家私下交流，下面我就開始今天的分享了。

廣告和網(wǎng)絡(luò)游戲是互聯(lián)網(wǎng)企業(yè)主要的盈利模式

廣告是廣告主通過媒體以盡可能低成本的方式與用戶達(dá)成接觸的商業(yè)行為。也就是說按照某種市場意圖接觸相應(yīng)人群，影響其中潛在用戶，使其選擇廣告主產(chǎn)品的幾率增加，或?qū)V告主品牌產(chǎn)生認(rèn)同，通過長期的影響逐步形成用戶對(duì)品牌的轉(zhuǎn)化。

一個(gè)好的DSP系統(tǒng)需要滿足：

1. 擁有強(qiáng)大的RTB(Real-Time Bidding)的基礎(chǔ)設(shè)施和能力。

2. 擁有先進(jìn)的用戶定向(Audience Targeting)技術(shù)。

首先，DSP對(duì)其數(shù)據(jù)運(yùn)算技術(shù)和速度要求非常之高。從普通用戶在瀏覽器中地址欄輸入網(wǎng)站的網(wǎng)址，到用戶看到頁面上的內(nèi)容和廣告這短短幾百毫秒之內(nèi)，就需要發(fā)生了好幾個(gè)網(wǎng)絡(luò)往返(Round Trip)的信息交換。

Ad Exchange首先要向DSP發(fā)競價(jià)(bidding)請(qǐng)求，告知DSP這次曝光的屬性，如物料的尺寸、廣告位出現(xiàn)的URL和類別、以及用戶的Cookie ID等；DSP接到競價(jià)請(qǐng)求后，也必須在幾十毫秒之內(nèi)決定是否競價(jià)這次曝光, 如果決定競價(jià)，出什么樣的價(jià)格，然后把競價(jià)的響應(yīng)發(fā)回到Ad Exchange。

如果Ad Exchange判定該DSP贏得了該次競價(jià)，要在極短時(shí)間內(nèi)把DSP所代表的廣告主的廣告迅速送到用戶的瀏覽器上。整個(gè)過程如果速度稍慢，Ad Exchange就會(huì)認(rèn)為DSP超時(shí)而不接受DSP的競價(jià)響應(yīng)，廣告主的廣告投放就無法實(shí)現(xiàn)。

其次，基于數(shù)據(jù)的用戶定向(Audience Targeting)技術(shù)，則是DSP另一個(gè)重要的核心特征。從網(wǎng)絡(luò)廣告的實(shí)質(zhì)上來說，廣告主最終不是為了購買媒體，而是希望通過媒體與他們的潛在客戶即目標(biāo)人群進(jìn)行廣告溝通和投放。

服務(wù)于廣告主或者廣告主代理的DSP，則需要對(duì)Ad Exchange每一次傳過來的曝光機(jī)會(huì)，根據(jù)關(guān)于這次曝光的相關(guān)數(shù)據(jù)來決定競價(jià)策略。這些數(shù)據(jù)包括本次曝光所在網(wǎng)站、頁面的信息，以及更為關(guān)鍵本次曝光的受眾人群屬性，人群定向的分析直接決定DSP的競價(jià)策略。DSP在整個(gè)過程中，通過運(yùn)用自己人群定向技術(shù)來分析，所得出的分析結(jié)果將直接影響廣告主的廣告投放效果。

此次分享主要針對(duì)以下幾個(gè)方面，描述DSP廣告系統(tǒng)架構(gòu)及關(guān)鍵技術(shù)：

1. 廣告系統(tǒng)概念介紹

2. 廣告系統(tǒng)業(yè)務(wù)流程

3. DSP系統(tǒng)架構(gòu)

4. RTB競價(jià)引擎結(jié)構(gòu)

5. 點(diǎn)擊率預(yù)測

6. DMP數(shù)據(jù)處理架構(gòu)

7. 受眾定向劃分

8. 用戶畫像與廣告系統(tǒng)反作弊

程序化購買的特點(diǎn)

下圖是在DSP產(chǎn)生之前和產(chǎn)生之后廣告行業(yè)的兩種最常見產(chǎn)業(yè)鏈

傳統(tǒng)的廣告投放模式的產(chǎn)業(yè)鏈?zhǔn)菑V告主通過廣告代理，以廣告網(wǎng)絡(luò)/聯(lián)盟為渠道在媒體網(wǎng)站展示廣告，達(dá)到接觸受眾的目的的過程。

這種模式的好處是媒體網(wǎng)站可以通過通過包段或CPS的模式可以售出自己的廣告位，但是這類售出是偏粗放型的，長期同類型的廣告投放，受眾會(huì)視覺疲勞，點(diǎn)擊率會(huì)下降，轉(zhuǎn)化也會(huì)隨之下降。為了能夠獲得更多的收益，媒體必須通過差異化銷售細(xì)分自己的廣告位和受眾。而事實(shí)上顯示廣告領(lǐng)域最初的定向投放的最初動(dòng)機(jī)是供給方拆分流量以獲得更高的營收。好的位置，通過包段通常會(huì)供不應(yīng)求，但是對(duì)于長尾流量通常是會(huì)無人問津，即便是對(duì)于廣告主來說同一個(gè)潛在客戶在大媒體出現(xiàn)會(huì)有廣告主包段進(jìn)行購買，但是在小網(wǎng)站出現(xiàn)就會(huì)沒人買。事實(shí)上潛在客戶在哪里出現(xiàn)對(duì)于廣告主都是同一個(gè)人，如果能顯示與客戶需求相吻合或接近的廣告就有可能產(chǎn)生轉(zhuǎn)化。在將優(yōu)質(zhì)廣告位包段售出后，如果對(duì)用戶有足夠的認(rèn)識(shí)，有足夠多不同類型的廣告主，在流量可以拆分到單次展現(xiàn)的購買粒度，就有可能依據(jù)不同的受眾定向?yàn)槊總€(gè)廣告主找到合適的人群和流量。

程序化購買顛覆了原有廣告產(chǎn)業(yè)鏈，形成了全新的產(chǎn)業(yè)鏈。

鑒于群里有很多人不是做廣告系統(tǒng)的，為了能夠在后續(xù)的介紹過程中更容易理解介紹的內(nèi)容，這里先介紹一些廣告行業(yè)中常見的一些概念。

DSP（Demand Side Platform），是廣告需求方平臺(tái)，DSP為廣告主提供跨媒介、跨平臺(tái)、跨終端的的廣告投放平臺(tái)，通過數(shù)據(jù)整合、分析實(shí)現(xiàn)基于受眾的精準(zhǔn)投放，并且實(shí)時(shí)監(jiān)控不斷優(yōu)化。

RTB（Real Time Bidding）實(shí)時(shí)競價(jià)是DSP、廣告交易平臺(tái)等在網(wǎng)絡(luò)廣告投放中采用的主要售賣形式，會(huì)在極端的時(shí)間內(nèi)（通常是50~100毫秒以內(nèi)）通過對(duì)目標(biāo)受眾競價(jià)的方式獲得該次廣告的展現(xiàn)，RTB的購買方式無論在PC端或是移動(dòng)端均可以實(shí)現(xiàn)。

程序化購買（Programmatic Buying）根據(jù)廣告主定義的期望受眾，系統(tǒng)幫助其找出優(yōu)選的媒體來購買受眾，為廣告主提出最優(yōu)媒介采買計(jì)劃，通過程序化購買的方式執(zhí)行，并按照期望的周期反饋監(jiān)測結(jié)果，并對(duì)后續(xù)投放進(jìn)行優(yōu)化。包括但不僅限于RTB購買。

最常見的DSP行業(yè)中的供需業(yè)務(wù)流，廣告主作為需求方，潛在客戶是最終的受眾，中間穿插著代理機(jī)構(gòu)，DSP，AdNetwork，AdExchange,SSP和供應(yīng)方也就是媒體。

下圖是DSP平臺(tái)的廣告投放流程，投放過程中涉及到廣告受眾，媒體網(wǎng)站，adx和dsp，分別標(biāo)注了廣告投放各階段伴隨發(fā)生的事件。從1~7步之間只允許100ms之內(nèi)的延時(shí)，否則廣告受眾就會(huì)覺得網(wǎng)頁加載速度太慢而選擇離開。

在線廣告的核心問題

需要在特定用戶，在指定上下文的環(huán)境下，找到最合適的廣告，進(jìn)行投放，并盡可能產(chǎn)生轉(zhuǎn)化。

在線廣告的挑戰(zhàn)

大規(guī)模

百萬量級(jí)頁面，十億量級(jí)用戶，需要被分析處理

高并發(fā)在線投放（每天處理百億次廣告交易請(qǐng)求）

時(shí)延要求嚴(yán)格（adx通常要求競價(jià)響應(yīng)時(shí)間在100ms完成）

用戶定向動(dòng)態(tài)變化

用戶的關(guān)注點(diǎn)和購物興趣變化會(huì)比較頻繁，需要能夠及時(shí)更新用戶畫像

上下文條件變化頻繁

用戶和上下文多樣化的環(huán)境一起用于廣告候選檢索

DSP系統(tǒng)架構(gòu)

上圖是主要模塊的流程圖涉及到的角色包括廣告主網(wǎng)站，媒體網(wǎng)站，廣告網(wǎng)絡(luò)和DSP，以及DSP內(nèi)部的相關(guān)模塊，如：RTB引擎，業(yè)務(wù)平臺(tái)，日志收集系統(tǒng)，DMP，CM和反作弊系統(tǒng)。

1. 投放前DSP會(huì)要求在廣告主網(wǎng)站布碼，同時(shí)在DSP的業(yè)務(wù)平臺(tái)中錄入廣告投放的需求，如投放金額，投放排期，投放定向（如地域，興趣，年齡等），最高限價(jià)。

2. 當(dāng)訪客（即潛在的消費(fèi)者）從左上角訪問廣告主網(wǎng)站開始，訪客在廣告主網(wǎng)站上的行為會(huì)被收集，同時(shí)DSP會(huì)與ADX和SSP進(jìn)行Cookie Mapping，形成日志進(jìn)行處理，形成回頭客相關(guān)的行為數(shù)據(jù)標(biāo)簽。

3. 當(dāng)訪客完成對(duì)廣告主網(wǎng)站的訪問，去其他媒體網(wǎng)站進(jìn)行訪問時(shí)，相應(yīng)的媒體廣告位根據(jù)事先嵌入的廣告代碼向廣告網(wǎng)絡(luò)發(fā)起廣告請(qǐng)求，廣告網(wǎng)絡(luò)會(huì)將廣告請(qǐng)求封裝成http頭 pb體的格式向多個(gè)DSP發(fā)起競價(jià)請(qǐng)求。

4. 當(dāng)DSP接到競價(jià)請(qǐng)求時(shí)會(huì)根據(jù)與廣告網(wǎng)絡(luò)約定的pb格式進(jìn)行解包，拆解出相關(guān)的字段進(jìn)行匹配，根據(jù)之前相關(guān)媒體積累的點(diǎn)擊率結(jié)合點(diǎn)擊率預(yù)測模型對(duì)出價(jià)進(jìn)行預(yù)測，找出平臺(tái)內(nèi)在此次競價(jià)請(qǐng)求能讓平臺(tái)利益最大化的廣告主的創(chuàng)意進(jìn)行投放，返回給廣告網(wǎng)絡(luò)出價(jià)與廣告代碼

5. 廣告網(wǎng)絡(luò)會(huì)在特定時(shí)間內(nèi)（通常是50~100毫秒）根據(jù)多個(gè)DSP的出價(jià)高低，以第二名價(jià)格多一分的價(jià)格讓出價(jià)最高的dsp勝出，并將廣告代碼中的展現(xiàn)宏和點(diǎn)擊宏進(jìn)行替換（替換過程中會(huì)根據(jù)事先與dsp約定好的公鑰對(duì)價(jià)格進(jìn)行加密，以防止第三方篡改和竊聽）

6. 廣告網(wǎng)絡(luò)將廣告代碼返回給媒體，媒體會(huì)將廣告代碼放置在js對(duì)應(yīng)的位置進(jìn)行展現(xiàn)，展現(xiàn)和點(diǎn)擊的過程中會(huì)先后觸發(fā)廣告網(wǎng)絡(luò)和勝出DSP的展現(xiàn)代碼，廣告網(wǎng)絡(luò)和DSP分別接收到展現(xiàn)請(qǐng)求會(huì)對(duì)相應(yīng)的展現(xiàn)進(jìn)行計(jì)費(fèi)操作（月底會(huì)相互進(jìn)行對(duì)賬）

7. DSP內(nèi)部會(huì)根據(jù)收集到的展現(xiàn)和點(diǎn)擊進(jìn)行計(jì)費(fèi)操作，形成相應(yīng)的報(bào)表；而瀏覽、展現(xiàn)、點(diǎn)擊的記錄會(huì)分別進(jìn)行收集形成日志，經(jīng)過ETL由DMP進(jìn)行抽取和分析，形成媒體數(shù)據(jù)，用戶標(biāo)簽，CookieMatch數(shù)據(jù)以及回頭客用戶標(biāo)簽數(shù)據(jù)，這些數(shù)據(jù)會(huì)在投放過程中作為RTB競價(jià)的參考依據(jù)。

整個(gè)投放過程中其實(shí)還有一些其他的模塊出現(xiàn)如CookieMapping、反作弊，動(dòng)態(tài)創(chuàng)意、網(wǎng)站分析系統(tǒng)。只不過這些系統(tǒng)不是在主干流程上，后續(xù)單獨(dú)進(jìn)行描述和分析。

為了保證投放，DSP系統(tǒng)實(shí)現(xiàn)了多機(jī)房部署的結(jié)構(gòu)，南北方機(jī)房分別在杭州和北京部署RTB引擎、點(diǎn)擊率預(yù)測與相關(guān)的展現(xiàn)點(diǎn)擊收集節(jié)點(diǎn)。投放活動(dòng)相關(guān)數(shù)據(jù)通過Redis進(jìn)行緩存，多機(jī)房進(jìn)行準(zhǔn)實(shí)時(shí)同步，媒體展現(xiàn)點(diǎn)擊數(shù)據(jù)通過kafka隊(duì)列進(jìn)行推送，通過Consumer進(jìn)行消費(fèi)統(tǒng)計(jì)，最后通過媒體數(shù)據(jù)分發(fā)集群分發(fā)到多個(gè)機(jī)房進(jìn)行使用。

RTB投放引擎的架構(gòu)

RTB引擎是DSP系統(tǒng)的核心，是實(shí)現(xiàn)高并發(fā)實(shí)時(shí)反饋的關(guān)鍵，RTB對(duì)外以HTTP服務(wù)形式暴露接口，當(dāng)媒體上的js被觸發(fā)，adx/ssp收到j(luò)s請(qǐng)求后會(huì)將請(qǐng)求封裝成http頭 pb體(protocol buffer,谷歌定義的序列化數(shù)據(jù)交換格式)的方式作為客戶端連接RTB，RTB對(duì)http消息按照事先約定解包在內(nèi)部依靠相關(guān)數(shù)據(jù)進(jìn)行計(jì)算，最終返回pb或json格式的出價(jià)和廣告代碼給廣告交易平臺(tái)。RTB 需要支持高并發(fā)（每天百億級(jí)別請(qǐng)求）和低延時(shí)（50ms之內(nèi)需要反饋）。

當(dāng)時(shí)我們的RTB采用Linux C 開發(fā)，通過Adapter適配器層解耦適應(yīng)不同的SSP/adx，算法池內(nèi)部拆分成五層，五層之間相互正交，算法模塊允許熱插拔，編譯完成的動(dòng)態(tài)鏈接庫可根據(jù)配置文件的變化實(shí)時(shí)進(jìn)行加載和卸載，允許多算法鏈并行拆分流量進(jìn)行A/B測試，流量處理過程中會(huì)對(duì)流經(jīng)不同算法鏈的流量打上不同的算法標(biāo)簽，并在后續(xù)展現(xiàn)，點(diǎn)擊過程中持續(xù)帶上此標(biāo)簽用于后續(xù)效果的跟蹤和分析。

下面說一下在針對(duì)RTB進(jìn)行架構(gòu)設(shè)計(jì)過程中涉及到的一些技巧：

由于一個(gè)dsp要接觸到盡可能多的流量和用戶才有可能找到符合廣告主定向的目標(biāo)受眾，那dsp一定要對(duì)接很多的adx和ssp，來接受盡可能多的流量。設(shè)計(jì)適配器層的目的就是將不同adx之間的流量格式差異消滅在適配器這一層，對(duì)于進(jìn)入系統(tǒng)內(nèi)部的流量都一視同仁，簡化了rtb系統(tǒng)的復(fù)雜性。RTB系統(tǒng)在設(shè)計(jì)之初就考慮了AB測試的環(huán)節(jié)，讓算法的效果能夠進(jìn)行橫向比較，方便算法進(jìn)行優(yōu)化。RTB本身是不帶狀態(tài)的，也就是說，它只能依靠外部的輔助系統(tǒng)提供的信息，如點(diǎn)擊率預(yù)測，人群定向和反作弊這類模塊提供的數(shù)據(jù)才能實(shí)現(xiàn)快速反饋的同事能正確反饋。

DMP

對(duì)于RTB的設(shè)計(jì)在后續(xù)提問和討論的環(huán)節(jié)我們?cè)僮鲞M(jìn)一步分析，下面講一下DSP系統(tǒng)中除了RTB之外的另外一個(gè)核心：DMP

首先需要定義一下廣告投放過程中關(guān)鍵的一些數(shù)據(jù)：

廣告系統(tǒng)DMP數(shù)據(jù)處理的架構(gòu)

跟大多數(shù)的大數(shù)據(jù)相關(guān)的系統(tǒng)很相似，基本上逃不開那幾樣?xùn)|西Hadoop，storm，redis等等:

數(shù)據(jù)處理部分結(jié)合了Hadoop的離線計(jì)算、Spark的批處理和Storm的流式計(jì)算。

HBase和MySQL用于最終結(jié)果落地用于前端查詢。

ElasticSearch 有準(zhǔn)實(shí)時(shí)索引，用于明細(xì)數(shù)據(jù)實(shí)時(shí)查詢和時(shí)間序列歷史回溯統(tǒng)計(jì)。

Spark內(nèi)置的機(jī)器學(xué)習(xí)算法庫MLLib主要使用分類，聚類KMeans，協(xié)同過濾，決策樹，邏輯回歸。

由于之前在群里的分享中,王新春@大眾點(diǎn)評(píng) ，王勁@酷狗音樂 講了很多storm實(shí)時(shí)處理和大數(shù)據(jù)架構(gòu)的內(nèi)容，他們二位都是大數(shù)據(jù)領(lǐng)域的大佬了，我在這里就不班門弄斧了，簡單提一下廣告行業(yè)里是怎么做的，基本上大同小異，大家用的東西都差不多。

對(duì)于廣告投放要投放的目標(biāo)，落實(shí)在dmp中就是需要找出相應(yīng)的受眾定向，下面簡單分析一下幾類受眾定向：

上圖是廣告有效性模型根據(jù)受眾定向的定性評(píng)估表，水平方向是定向技術(shù)在廣告信息接受過程中所起作用的階段，垂直方向是大致的效果評(píng)價(jià)（從下往上效果依次升高）。

按照計(jì)算框架不同這些受眾定向可以分為三類：

1. 用戶標(biāo)簽t(u)，即在時(shí)間序列上用戶歷史行為為依據(jù)，為用戶打上的標(biāo)簽。

2. 上下文標(biāo)簽t(c)，即當(dāng)前用戶聯(lián)系上下文在當(dāng)前的訪問行為達(dá)到的即時(shí)標(biāo)簽。

3. 廣告主定制化標(biāo)簽t(a,u)，是根據(jù)特定廣告主提供的特定用戶群在其網(wǎng)站上的訪問行為數(shù)據(jù)加工所得。

其中：地域定向、頻道定向和上下文定向?qū)儆趖(c)的定向方式；人口屬性定向、行為定向?qū)儆趖(u)的定向方式；
而重定向和Look-alike則是t(a, u)的定向方式。
地域定向主要用于商家銷售目標(biāo)局限于特定區(qū)域的情況下；

人口屬性主要包括年齡，性別，收入，學(xué)歷等；頻道定向主要是針對(duì)媒體側(cè)特點(diǎn)，對(duì)相應(yīng)受眾進(jìn)行劃分；上下文定向主要是根據(jù)當(dāng)前網(wǎng)頁的內(nèi)容上下文推送相關(guān)廣告；行為定向是根據(jù)用戶歷史訪問行為，了解用戶喜好，進(jìn)而推送相關(guān)廣告；精確位置定向是在移動(dòng)設(shè)備上根據(jù)精確的地理位置投放廣告，更聚向與地域性非常強(qiáng)的的本地生活類廣告主；

重定向是對(duì)特定廣告主一定時(shí)間段內(nèi)訪客投放廣告以提升效果的廣告投放方式，人群規(guī)模由廣告主固有用戶量和媒體重合量共同決定；新客推薦是在重定向規(guī)模太小，無法滿足廣告主接觸用戶需求的情況下，以重定向用戶為種子，根據(jù)廣告平臺(tái)數(shù)據(jù)積累，為廣告主找出行為相似用戶的定向條件。

用戶畫像的方法

接下來基于上面提到的積累受眾定向介紹一下用戶畫像的方法

我們能夠看到用戶畫像其實(shí)也就是對(duì)于用戶特征的提取，涉及到人口，設(shè)備，運(yùn)營商，位置以及用戶的瀏覽，點(diǎn)擊購買等行為數(shù)據(jù)。用戶畫像是通過對(duì)用戶特征的提取對(duì)用戶行為進(jìn)行定性和定量的描述，形成：【用戶ID:用戶標(biāo)簽：標(biāo)簽權(quán)重】形式的用戶畫像標(biāo)簽，在廣告投放過程中，根據(jù)提取流量對(duì)應(yīng)用戶權(quán)重較高的若干個(gè)標(biāo)簽反向?qū)V告主進(jìn)行篩選，找出適合流量特點(diǎn)的廣告素材。 用戶標(biāo)簽用于廣告主對(duì)于受眾的選擇，而權(quán)重用于在海量用戶標(biāo)簽里選取重點(diǎn)的標(biāo)簽進(jìn)行投放。

同時(shí)要注意用戶的畫像隨時(shí)間的推移會(huì)有衰減，需要在用戶畫像的過程中考慮時(shí)間衰減的因素，因?yàn)橛脩舻膼酆煤土?xí)慣會(huì)隨著時(shí)間變長而有變化，同時(shí)數(shù)據(jù)的時(shí)效性也決定了用戶畫像的準(zhǔn)確程度，進(jìn)而影響廣告的投放。

事實(shí)上在廣告平臺(tái)中收集到的最多的數(shù)據(jù)是用戶的瀏覽數(shù)據(jù)，在拿到這么多的瀏覽數(shù)據(jù)的情況下，想要分析出用戶的愛好和興趣以及需求，那就需要對(duì)網(wǎng)頁的內(nèi)容進(jìn)行分析和抽取，下面介紹一下用戶畫像中非常重要的行為標(biāo)注部分的架構(gòu)：

用戶在瀏覽一系列網(wǎng)站的過程中是多少會(huì)帶著一些目的性進(jìn)行瀏覽的，即便是沒有明確目的，也會(huì)帶有一些個(gè)人喜好，有了這些目的和喜好，就會(huì)進(jìn)一步縮短我們?cè)谕扑蛷V告過程中對(duì)于用戶定向的選擇難度。上圖就是在上下文定向中對(duì)網(wǎng)頁關(guān)鍵字提取的子系統(tǒng)的架構(gòu)?！旧舷挛亩ㄏ颉靠梢酝ㄟ^網(wǎng)頁關(guān)鍵字提取，建立一個(gè)cache，根據(jù)URL建立對(duì)應(yīng)標(biāo)簽，當(dāng)廣告請(qǐng)求到來時(shí)，命中相應(yīng)URL則返回cache的命中內(nèi)容，如果URL未緩存則返回空集合，同時(shí)將URL添加到后臺(tái)抓取隊(duì)列，在URL被抓取，并打上標(biāo)簽存入cache，為cache設(shè)置TTL，當(dāng)長期不訪問則將該URL的記錄清楚，而熱點(diǎn)內(nèi)容URL的關(guān)鍵詞是始終被緩存的，運(yùn)行較長的時(shí)間則大多數(shù)熱點(diǎn)URL大多會(huì)被緩存。在抓取到內(nèi)容之后，需要對(duì)網(wǎng)頁內(nèi)容進(jìn)行內(nèi)容挖掘，在挖掘的過程中有以下幾個(gè)方案可以被選取：

網(wǎng)頁文本內(nèi)容通過擴(kuò)展語境，引入更多文本進(jìn)行挖掘；利用語義分類樹；建立主題模型。

我們?cè)谏厦嫣岬搅嗽诰€廣告的核心問題其實(shí)是找上下文，用戶，廣告三者之間的最恰當(dāng)?shù)钠ヅ洹?/p>

在展示類廣告中比較重要的一個(gè)核心考核點(diǎn)就是點(diǎn)擊率，因此點(diǎn)擊率預(yù)測模塊在DSP中是非常重要的部分

CTR預(yù)估涉及到三種角色：受眾用戶，媒體，廣告主

預(yù)估的目標(biāo)是為特定的受眾用戶再給定的媒體環(huán)境下找到最合適的廣告，對(duì)媒體來說實(shí)現(xiàn)收入最大化，即按照eCPM排序的基本原則來排序。

最簡單的CTR預(yù)估的模型，根據(jù)歷史日志，統(tǒng)計(jì)出三個(gè)維度的CTR對(duì)照關(guān)系，預(yù)測過程中，當(dāng)一個(gè)user訪問特定url時(shí)，查詢?cè)~典如果存在的CTR，則返回CTR最高的ad，如不存在，則隨機(jī)返回ad，積累后續(xù)數(shù)據(jù)。

存在問題：基于統(tǒng)計(jì)數(shù)據(jù)，對(duì)舊廣告效果還可以，但對(duì)冷啟動(dòng)的廣告沒有預(yù)測能力。
事實(shí)上，我們?cè)诰€上做點(diǎn)擊率預(yù)測模型，使用的算法是邏輯回歸，后續(xù)可能考慮會(huì)用到的廣告點(diǎn)擊率預(yù)測方法有：

1. 機(jī)器學(xué)習(xí)方法：特征 模型 融合方案

2. 協(xié)同過濾方法：看做推薦系統(tǒng)來處理

排序模型以預(yù)測結(jié)果為基礎(chǔ)，廣告排序模型有如下幾種：

1. 點(diǎn)排序（point-wise approach）：變成分類問題或者回歸模型來處理

2. 對(duì)排序（pair-wise approach）：比較兩個(gè)廣告誰的優(yōu)先級(jí)高，不分類

3. 列排序（list-wise approach）：對(duì)整個(gè)廣告候選集學(xué)習(xí)排序模型

廣告行業(yè)的反作弊

作弊背后必然有一個(gè)或者一堆的人從眾有獲利，比如制造垃圾站掛廣告獲利的總是扎堆出現(xiàn)的。如果你抓到了一個(gè)網(wǎng)站流量異常，在用工具刷量，那肯定不會(huì)只是這一個(gè)網(wǎng)站在用這個(gè)模式在刷量；如果一個(gè)人有多個(gè)網(wǎng)站，如果有一個(gè)網(wǎng)站在刷量，那他的其他網(wǎng)站也應(yīng)該檢查一下了。

在廣告反作弊的過程中，為了找出刷量的垃圾站背后都有哪些人，這些人有哪些網(wǎng)站，針對(duì)DSP平臺(tái)流量80%的網(wǎng)站域名去重，通過whois信息查詢到域名注冊(cè)郵箱，歸類出哪些域名屬于哪個(gè)注冊(cè)郵箱，發(fā)現(xiàn)其中一個(gè)刷量，則對(duì)同一郵箱下的其他域名進(jìn)行嚴(yán)查。

上圖是主要的一些廣告反作弊的思路，廣告作弊是有成本的，有人作弊，還是背后有利益驅(qū)動(dòng)，找出利益鏈條是反作弊的關(guān)鍵
下面對(duì)之前我們做廣告反作弊工作過程中遇到的幾類例子：

P2P流量互刷

互刷作弊有代表性的軟件是：流量寶和流量精靈

均通過客戶端軟件向服務(wù)器提交互刷任務(wù)請(qǐng)求，客戶端收到服務(wù)器分發(fā)的互刷任務(wù)后執(zhí)行隱藏的瀏覽任務(wù)，每天可達(dá)到數(shù)千個(gè)IP的訪問量，IP布局分散，UA隨機(jī)生成，很難通過瀏覽記錄尋找作弊痕跡?，F(xiàn)在唯一有效的反作弊方法需要通過蜜罐主機(jī)進(jìn)行跟蹤和分析。下面介紹一下我們對(duì)于p2p刷量所采用的蜜罐主機(jī)的結(jié)構(gòu)：

其中虛線框中是我們的的蜜罐系統(tǒng)，虛線框外面的灰色部分是我們要尋找的作弊目標(biāo)
如果是對(duì)信息安全有一定了解的人對(duì)于蜜罐系統(tǒng)一定不陌生，也就是系統(tǒng)設(shè)計(jì)上有意拋一些破綻出來，讓攻擊者自己跳出來，通過對(duì)攻擊者行為的觀摩來尋找破解攻擊的思路。

由于流量寶、流量精靈一類的刷量工具多集中于windows平臺(tái)下，安裝windows vm并將系統(tǒng)代理指向nginx反向代理，通過刷量工具提交刷量任務(wù)。提交刷量任務(wù)的站點(diǎn)沒有任何真實(shí)流量，只要是訪問這個(gè)站點(diǎn)的IP基本上都是通過刷量工具來的流量，IP可以在RTB引擎對(duì)相關(guān)IP端進(jìn)行封殺，不再進(jìn)行投放；

Nginx反向代理落詳細(xì)日志通過Logstash收集、解析發(fā)送給ElasticSearch建立索引，通過kibana做可視化，統(tǒng)計(jì)出刷量最多的IP，域名和URL地址出來，可以作為后續(xù)模式識(shí)別的模型輸入。搜集相關(guān)證據(jù)，域名可以向adx反饋對(duì)媒體進(jìn)行封殺，同時(shí)可以根據(jù)篩選出的刷量作弊域名在DSP投放過程中減少投放以避免自身損失。

CPS引流作弊

我們遇到的另外一種對(duì)于DSP投放效果有非常大影響的一類作弊手段是：CPS引流作弊

引流作弊可以幫助引流網(wǎng)站“提高”CPC，“提高”CPS。但對(duì)廣告主不產(chǎn)生實(shí)際有效的流量。

目前發(fā)現(xiàn)的引流作弊行為有3種：

1. 作弊代理通過回帖作弊（對(duì)媒體網(wǎng)站無控制權(quán)）

2. 作弊代理伙同媒體網(wǎng)站作弊（對(duì)媒體網(wǎng)站有控制權(quán)）

3. 作弊代理伙同媒體網(wǎng)站通過網(wǎng)盟作弊

也就是說在DSP投放了廣告的網(wǎng)站里被插入了跳轉(zhuǎn)到CPS計(jì)費(fèi)鏈接的302跳轉(zhuǎn)的圖片，雖然DSP花錢從adx買了流量投放了廣告，但是這個(gè)頁面里還有大量的CPS結(jié)算的鏈接跳轉(zhuǎn)，如果廣告主既在網(wǎng)盟，又在DSP投放廣告的話，任何看過這類頁面的人在廣告主網(wǎng)站下的單，就有可能被劫持走。整個(gè)過程中，用戶都不知道有'廣告主'的存在。但是對(duì)應(yīng)的'廣告主'會(huì)認(rèn)為是特定CPS鏈接帶來了一個(gè)點(diǎn)擊，后續(xù)的cps應(yīng)該是記在相應(yīng)的CPS合作方名下。

Q & A

Q1：請(qǐng)問付總dmp數(shù)據(jù)存哪里？HBase？

數(shù)據(jù)分不同的形式存在不同的地方，原始日志存放在硬盤上，經(jīng)過ETL后寫入HDFS，結(jié)構(gòu)化存放在Hive表中進(jìn)行查詢，cookiemapping數(shù)據(jù)經(jīng)過hadoop計(jì)算過后導(dǎo)出成文件，存放在Tair里讓RTB查詢，用戶行為數(shù)據(jù)存放在hdfs里，畫像之后數(shù)據(jù)存放在redis供rtb查詢，跑出來的統(tǒng)計(jì)報(bào)表存放在mysql供報(bào)表系統(tǒng)調(diào)用。CM的cookie對(duì)應(yīng)數(shù)據(jù)有一部分也是存放在hbase的，hbase和hadoop共用hdfs，所以查詢速度也會(huì)受到hadoop集群資源多少的影響。

Q2：請(qǐng)問 RTB算法模塊熱插拔大概是怎么實(shí)現(xiàn)的？

上面我曾經(jīng)提到過RTB系統(tǒng)是用Linux C 開發(fā)的，如果對(duì)于Linux C 比較熟悉的人應(yīng)該知道Linux下是可以動(dòng)態(tài)加載動(dòng)態(tài)鏈接庫的使用的主要是：

dlopen：打開動(dòng)態(tài)加載庫

dlsym：獲取接口函數(shù)指針

dlcose：關(guān)閉庫

這三個(gè)函數(shù)就可以在程序運(yùn)行時(shí)加載動(dòng)態(tài)鏈接庫了。為了達(dá)到模塊準(zhǔn)實(shí)時(shí)熱插拔的目標(biāo)我們還使用了Linux下的inotify,
inotify是一種文件系統(tǒng)的變化通知機(jī)制，如文件增加、刪除等事件，可以立刻讓用戶態(tài)得知。我們?cè)赗TB程序啟動(dòng)過程中向系統(tǒng)注冊(cè)了inotify事件來監(jiān)控配置文件，當(dāng)配置文件被修改的時(shí)候立即通知程序重新加載配置文件

Q3：請(qǐng)問cookiemap是離線map還是實(shí)時(shí)map？map后數(shù)據(jù)正確率有多少？移動(dòng)端map 主要根據(jù)那些key來map？

cookieMapping分在線和離線兩種，通常情況下廣告投放過程中會(huì)有幾個(gè)場景會(huì)發(fā)起cm

第一種，廣告主網(wǎng)站上布碼之后當(dāng)訪客訪問廣告主網(wǎng)站時(shí)觸發(fā)js，dsp會(huì)主動(dòng)向各家對(duì)接過后的adx進(jìn)行cookiemapping

第二種，廣告投放過程中，當(dāng)dsp的出價(jià)的同時(shí)會(huì)帶上廣告展現(xiàn)代碼里面也包含有cm代碼，當(dāng)出價(jià)高于其他dsp的時(shí)候，廣告代碼會(huì)被吐到媒體網(wǎng)站，相應(yīng)的也會(huì)觸發(fā)cm

第三種，當(dāng)在adx消耗金額達(dá)到一定水平，像Tanx會(huì)按照消耗比例每天向dsp發(fā)起一定比例的dsp無法識(shí)別用戶的cm請(qǐng)求，這個(gè)時(shí)候dsp也會(huì)向其他adx發(fā)起cm

除此之外對(duì)于運(yùn)營商數(shù)據(jù)的使用過程中通常就是離線匹配的了，方法通常是運(yùn)營商的瀏覽數(shù)據(jù)來自于路由設(shè)備的DPI信息，里面有用戶的adsl賬號(hào)信息，運(yùn)營商會(huì)找出一定時(shí)間內(nèi)訪問過dsp指定的幾個(gè)域名的人，通常會(huì)在這個(gè)域名下面的所有頁面都布上cm代碼，通過http頭就能找出dsp的cookieID，找出的這些人都會(huì)有adsl賬號(hào)標(biāo)識(shí)，通過賬號(hào)就能建立與dsp的cookieID的關(guān)系，這類cm就是離線的了。

Q4：請(qǐng)問怎么識(shí)別是同一個(gè)用戶？通過cookie，還是有其他先進(jìn)的辦法？

PC端的用戶識(shí)別通常是依靠cookie，這類cookie好植入，但生命周期比較短，無法直接跨瀏覽器/跨設(shè)備，同時(shí)容易被各類電腦管家/助手清理，所以很容易出現(xiàn)信息苦苦畫好的用戶畫像，過兩天這個(gè)id就再也不出現(xiàn)了。

在PC端還會(huì)用flash cookie的方法來打通不同的瀏覽器，因?yàn)閒lash storage是同一塊存儲(chǔ)不同的瀏覽器可以跨瀏覽器打通。
當(dāng)然還有一種叫evercookie的手段集合了包括flash cookie 之內(nèi)的多種標(biāo)識(shí)方式，感興趣的可以了解一下這個(gè)網(wǎng)址 http:///evercookie/

移動(dòng)端的身份標(biāo)識(shí)，安卓的包括android id，mac地址IMSI和IMEI，而iOS是IDFA。由于移動(dòng)設(shè)備上安裝的app里可以嵌入SDK，而app有可能在移動(dòng)端的權(quán)限也不同獲取到的標(biāo)識(shí)也會(huì)有差異，所以最終也會(huì)涉及到用戶標(biāo)識(shí)統(tǒng)一識(shí)別的問題，當(dāng)然移動(dòng)端的用戶標(biāo)識(shí)會(huì)遠(yuǎn)比PC端要強(qiáng)很多，移動(dòng)廣告化之后用戶畫像將會(huì)更加的準(zhǔn)確。

本文策劃 秋翾@百姓網(wǎng), 內(nèi)容由國忠，陳剛編輯與發(fā)布，其他多位志愿者對(duì)本文亦有貢獻(xiàn)。讀者可以通過搜索“ArchNotes”或長按下面圖片，關(guān)注“高可用架構(gòu)”公眾號(hào)，查看更多架構(gòu)方面內(nèi)容，獲取通往架構(gòu)師之路的寶貴經(jīng)驗(yàn)。轉(zhuǎn)載請(qǐng)注明來自“高可用架構(gòu)（ArchNotes）”公眾號(hào)。