干貨 | 廣告系統(tǒng)架構(gòu)解密
從技術(shù)角度來(lái)說(shuō)，廣告業(yè)務(wù)涉及到?AI算法、大數(shù)據(jù)處理、檢索引擎、高性能和高可用的工程架構(gòu)?等多個(gè)方向，同樣有著不錯(cuò)的技術(shù)吸引力。
我從去年開始接觸廣告業(yè)務(wù)，到現(xiàn)在差不多一年時(shí)間了。這篇文章將結(jié)合我的個(gè)人經(jīng)驗(yàn)，同時(shí)參考業(yè)界的優(yōu)秀案例，闡述下廣告系統(tǒng)的架構(gòu)實(shí)踐方案，希望讓大家有所收獲。內(nèi)容包括以下3部分：
廣告業(yè)務(wù)簡(jiǎn)介 面臨的技術(shù)挑戰(zhàn) 廣告系統(tǒng)架構(gòu)詳解
01 廣告業(yè)務(wù)簡(jiǎn)介
廣告，可以說(shuō)無(wú)處不在。微信、抖音、B站、百度、淘寶等等，這些占據(jù)用戶時(shí)間最長(zhǎng)的 APP， 到處都能看到廣告的影子。
我們每天隨處可見的廣告，它背后的業(yè)務(wù)邏輯到底是什么樣的呢？在分享廣告系統(tǒng)的架構(gòu)之前，先給大家快速普及下業(yè)務(wù)知識(shí)。
1. 廣告業(yè)務(wù)的核心點(diǎn)是平衡
為什么說(shuō)廣告業(yè)務(wù)的核心點(diǎn)是「平衡」？可以從廣告的標(biāo)準(zhǔn)定義來(lái)理解。
廣告被定義為：廣告主以付費(fèi)方式通過(guò)互聯(lián)網(wǎng)平臺(tái)向用戶傳播商品或者服務(wù)信息的手段。這個(gè)定義中涉及到?廣告主、平臺(tái)、用戶?3個(gè)主體，但是這3個(gè)主體的利益關(guān)注點(diǎn)各不相同。
圖1：廣告業(yè)務(wù)的三角平衡
廣告主：關(guān)注ROI，花了錢是否能帶來(lái)預(yù)期收益
平臺(tái)：擁有流量，關(guān)注收益能否最大化
用戶：關(guān)注體驗(yàn)，廣告是否足夠精準(zhǔn)？是否影響到了正常功能的使用？
有時(shí)候這三者的利益是沖突的，比如平臺(tái)增加了廣告位數(shù)量，收益肯定增加，但用戶體驗(yàn)可能變差，因此廣告業(yè)務(wù)最終要尋找的是三方的平衡。
站在平臺(tái)的角度來(lái)看廣告業(yè)務(wù)，它在保證用戶體驗(yàn)的同時(shí)，要兼顧絕大部分廣告主的ROI（確保他們是可以賺到錢的），在此基礎(chǔ)上再考慮將平臺(tái)的收入最大化，這樣才是一個(gè)健康的廣告生態(tài)。
廣告業(yè)務(wù)發(fā)展了幾十年，廣告費(fèi)用的結(jié)算方式也誕生了很多種，我們最常見的有以下幾種：
CPT：按時(shí)間計(jì)費(fèi)，獨(dú)占性包時(shí)段包位置 CPM：按照每千次曝光計(jì)費(fèi) CPC：按照點(diǎn)擊計(jì)費(fèi) CPA：按照行為計(jì)費(fèi)（比如下載、注冊(cè)等）
圖2：廣告費(fèi)用的結(jié)算方式演進(jìn)
之所以有不同的結(jié)算方式，其實(shí)也是隨著廣告市場(chǎng)的發(fā)展逐漸衍生出來(lái)的，最開始流量稀缺，平臺(tái)占優(yōu)勢(shì)，再到今天逐漸成了買方市場(chǎng)，廣告主作為需求方的談判權(quán)變大。
3. 廣告的核心業(yè)務(wù)流程
圖3：廣告的核心業(yè)務(wù)流程
廣告主先通過(guò)投放平臺(tái)發(fā)布廣告，可設(shè)置一系列的定向條件，比如投放城市、投放時(shí)間段、人群標(biāo)簽、出價(jià)等。
投放動(dòng)作完成后，廣告會(huì)被存放到廣告庫(kù)、同時(shí)進(jìn)入索引庫(kù)，以便能被廣告檢索引擎召回。
C端請(qǐng)求過(guò)來(lái)后，廣告引擎會(huì)完成召回、算法策略、競(jìng)價(jià)排序等一系列的邏輯，最終篩選出Top N個(gè)廣告，實(shí)現(xiàn)廣告的千人千面。
用戶點(diǎn)擊廣告后，會(huì)觸發(fā)廣告扣費(fèi)流程，這時(shí)候平臺(tái)才算真正獲得收益。
1、高并發(fā)：廣告引擎和C端流量對(duì)接，請(qǐng)求量大（平峰往往有上萬(wàn)QPS），要求實(shí)時(shí)響應(yīng)，必須在幾十毫秒內(nèi)返回結(jié)果。
2、業(yè)務(wù)邏輯復(fù)雜：一次廣告請(qǐng)求，涉及到多路召回、算法模型打分、競(jìng)價(jià)排序等復(fù)雜的業(yè)務(wù)流程，策略多，執(zhí)行鏈路長(zhǎng)。
3、穩(wěn)定性要求高：廣告系統(tǒng)直接跟收入掛鉤，廣告引擎以及計(jì)費(fèi)平臺(tái)等核心系統(tǒng)的穩(wěn)定性要求很高，可用性至少要做到3個(gè)9。
4、大數(shù)據(jù)存儲(chǔ)和計(jì)算：隨業(yè)務(wù)發(fā)展，推廣數(shù)量以及扣費(fèi)訂單數(shù)量很容易達(dá)到千萬(wàn)甚至上億規(guī)模，另外收入報(bào)表的聚合維度多，單報(bào)表可能達(dá)到百億級(jí)別的記錄數(shù)。
5、賬務(wù)的準(zhǔn)確性：廣告扣費(fèi)屬于金融性質(zhì)的操作，需要做到不丟失、不重復(fù)，否則會(huì)損害某一方的利益。另外，如果收入數(shù)據(jù)不準(zhǔn)確，還可能影響到業(yè)務(wù)決策。
了解了廣告業(yè)務(wù)的目標(biāo)和技術(shù)挑戰(zhàn)后，接下來(lái)詳細(xì)介紹下廣告系統(tǒng)的整體架構(gòu)和技術(shù)方案。
圖4：廣告系統(tǒng)的整體架構(gòu)
上面是我們公司目前的廣告系統(tǒng)架構(gòu)圖，這個(gè)架構(gòu)適用于廣告業(yè)務(wù)初期，針對(duì)的是「自營(yíng)型的競(jìng)價(jià)網(wǎng)絡(luò)和站內(nèi)流量」，不涉及聯(lián)盟廣告。
廣告投放系統(tǒng)：供廣告主使用，核心功能包括會(huì)員續(xù)費(fèi)、廣告庫(kù)管理、設(shè)定推廣條件、設(shè)置廣告出價(jià)、查看投放效果等。
廣告運(yùn)營(yíng)后臺(tái)：供平臺(tái)的產(chǎn)品運(yùn)營(yíng)使用，核心功能包括廣告位管理、廣告策略管理、以及各種運(yùn)營(yíng)工具。
廣告檢索平臺(tái)：承接C端的高并發(fā)請(qǐng)求，負(fù)責(zé)從海量廣告庫(kù)中篩選出幾個(gè)或者幾十個(gè)廣告，實(shí)時(shí)性要求高，這個(gè)平臺(tái)通常由多個(gè)微服務(wù)組成。
AB實(shí)驗(yàn)平臺(tái)：廣告業(yè)務(wù)的穩(wěn)定器，任何廣告策略上的調(diào)整均可以通過(guò)此平臺(tái)進(jìn)行灰度實(shí)驗(yàn)，觀察收入指標(biāo)的變化。
廣告計(jì)費(fèi)平臺(tái)：面向C端，負(fù)責(zé)實(shí)時(shí)扣費(fèi)，和收入直接掛鉤，可用性要求高。
賬務(wù)管理中心：廣告業(yè)務(wù)中的財(cái)務(wù)系統(tǒng)，統(tǒng)管金額相關(guān)的業(yè)務(wù)，包括充值、凍結(jié)、扣費(fèi)等。
大數(shù)據(jù)平臺(tái)：整個(gè)廣告系統(tǒng)的底盤，需要聚合各種異構(gòu)數(shù)據(jù)源，完成離線和實(shí)時(shí)數(shù)據(jù)分析和統(tǒng)計(jì)，產(chǎn)出業(yè)務(wù)報(bào)表，生產(chǎn)模型特征等。
1. 廣告數(shù)據(jù)的存儲(chǔ)
廣告系統(tǒng)要存儲(chǔ)的數(shù)據(jù)多種多樣，特點(diǎn)各不相同，采用的是多模的數(shù)據(jù)存儲(chǔ)方式。
圖5：廣告數(shù)據(jù)的多模存儲(chǔ)
OLTP場(chǎng)景，包括廣告庫(kù)、創(chuàng)意庫(kù)、會(huì)員庫(kù)、廣告產(chǎn)品庫(kù)、廣告策略庫(kù)等，這些都存儲(chǔ)在MySQL中，數(shù)據(jù)規(guī)模較大的廣告庫(kù)和創(chuàng)意庫(kù)，按照廣告主ID Hash做分庫(kù)分表。 OLAP場(chǎng)景，涉及到非常多的報(bào)表，聚合維度多，單表的記錄數(shù)可能達(dá)到百億級(jí)別，底層采用HDFS和HBase存儲(chǔ)。
面向廣告檢索場(chǎng)景的索引數(shù)據(jù)，包括正排索引和倒排索引，采用Redis和ES來(lái)存儲(chǔ)。
圖6：廣告索引的更新流程
索引更新服務(wù)，有幾個(gè)要點(diǎn)說(shuō)明下：
各個(gè)業(yè)務(wù)系統(tǒng)在推廣、余額等信息變更時(shí)，發(fā)MQ消息，索引更新服務(wù)訂閱MQ來(lái)感知變化，完成增量同步。
變更的消息體中，不傳遞實(shí)際變更的字段，僅通知有變化的廣告ID，索引更新服務(wù)實(shí)時(shí)讀取最新數(shù)據(jù)完成更新，這樣可以有效的解決消息亂序引起的數(shù)據(jù)不一致問(wèn)題。
當(dāng)更新索引的并發(fā)達(dá)到一定量級(jí)后，可通過(guò)合并相同廣告的變更、或者將倒排和正排更新分離的方式來(lái)提升整體的更新速度。
2. 廣告檢索平臺(tái)的整體流程
廣告檢索平臺(tái)負(fù)責(zé)承接C端的流量請(qǐng)求，從海量廣告庫(kù)中篩選出最合適的前N個(gè)廣告，并在幾十毫秒內(nèi)返回結(jié)果，它是一個(gè)多級(jí)篩選和排序的過(guò)程。
Recall層側(cè)重算法模型，Search層側(cè)重業(yè)務(wù)。從下到上，計(jì)算復(fù)雜度逐層增加，候選集逐層減少。（說(shuō)明：搜索廣告場(chǎng)景和推薦廣告場(chǎng)景在某些子模塊上存在差異，但整體流程基本一致，這里不作展開）
性能設(shè)計(jì)是檢索平臺(tái)的重點(diǎn)，通常有以下手段：
做好服務(wù)分層，各層均可水平擴(kuò)展。
采用Redis緩存，避免高并發(fā)請(qǐng)求直接打到數(shù)據(jù)庫(kù)，緩存可按業(yè)務(wù)規(guī)劃多套，進(jìn)行分流。
采用多線程并行化某些子流程，比如多路召回邏輯、多模型打分邏輯。
熱點(diǎn)數(shù)據(jù)進(jìn)行本地緩存，比如廣告位的配置信息以及策略配置信息，在服務(wù)啟動(dòng)時(shí)就可以預(yù)加載到本地，然后定時(shí)進(jìn)行同步。
非核心流程設(shè)置超時(shí)熔斷走降級(jí)邏輯，比如溢價(jià)策略（不溢價(jià)只是少賺了，不影響廣告召回）。
和主流程無(wú)關(guān)的邏輯異步執(zhí)行，比如扣費(fèi)信息緩存、召回結(jié)果緩存等。
精簡(jiǎn)RPC返回結(jié)果或者Redis緩存對(duì)象的結(jié)構(gòu)，去掉不必要的字段，減少IO數(shù)據(jù)包大小。
GC優(yōu)化，包括JVM堆內(nèi)存的設(shè)置、垃圾收集器的選擇、GC頻次優(yōu)化和GC耗時(shí)優(yōu)化。
3. 計(jì)費(fèi)平臺(tái)的技術(shù)方案
首先，整個(gè)扣費(fèi)流程做了異步化處理，當(dāng)收到實(shí)時(shí)扣費(fèi)請(qǐng)求后，系統(tǒng)先將扣費(fèi)時(shí)用到的信息緩存到Redis，然后發(fā)送MQ消息，這兩步完成后扣費(fèi)動(dòng)作就算結(jié)束了。
這樣做的好處是：能確保扣費(fèi)接口的性能，同時(shí)利用MQ的可靠性投遞和重試機(jī)制確保整個(gè)扣費(fèi)流程的最終一致性。
為了提高可用性，針對(duì)Redis和MQ不可用的情況均采用了降級(jí)方案。Redis不可用時(shí)，切換到TiKV進(jìn)行持久化；MQ投遞失敗時(shí)，改成線程池異步處理。
另外，每次有效點(diǎn)擊都需要生成1條扣費(fèi)訂單，面臨大數(shù)據(jù)量的存儲(chǔ)問(wèn)題。目前我們采用的是MySQL分庫(kù)分表，后期會(huì)考慮使用HBase等分布式存儲(chǔ)。另外，訂單和賬務(wù)系統(tǒng)之間的數(shù)據(jù)一致性，采用大數(shù)據(jù)平臺(tái)做天級(jí)別的增量抽取，通過(guò)Hive任務(wù)完成對(duì)賬和監(jiān)控。
圖9：廣告數(shù)據(jù)倉(cāng)庫(kù)的分層結(jié)構(gòu)
源數(shù)據(jù)層：對(duì)應(yīng)各種源數(shù)據(jù)，包括HDFS中實(shí)時(shí)采集的前后端日志，增量或者全量同步的MySQL業(yè)務(wù)數(shù)據(jù)表。
數(shù)據(jù)倉(cāng)庫(kù)層：包含維度表和事實(shí)表，通常是對(duì)源數(shù)據(jù)進(jìn)行清洗后的數(shù)據(jù)寬表，比如行為日志表、推廣寬表、用戶寬表等。
數(shù)據(jù)集市層：對(duì)數(shù)據(jù)進(jìn)行輕粒度的匯總表，比如廣告效果表、用戶行為的全鏈路表、用戶群分析表等。
數(shù)據(jù)應(yīng)用層：上層應(yīng)用場(chǎng)景直接使用的數(shù)據(jù)表，包括多維分析生成的各種收入報(bào)表、Spark任務(wù)產(chǎn)出的算法模型特征和畫像數(shù)據(jù)等。
寫在最后
