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