作者 | 駱俊武
來源 | IT人的職場進階（ID:BestITer）
廣告、增值服務、佣金，是網際網路企業最常見的三種盈利手段。在這3大經典中，又以廣告所占的市場份額最大，幾乎是絕大部分網際網路平台最主要的營收途徑，業務的重要性不言而喻。
從技術角度來說，廣告業務涉及到 AI算法、大數據處理、檢索引擎、高性能和高可用的工程架構 等多個方向，同樣有著不錯的技術吸引力。
我從去年開始接觸廣告業務，到現在差不多一年時間了。這篇文章將結合我的個人經驗，同時參考業界的優秀案例，闡述下廣告系統的架構實踐方案，希望讓大家有所收穫。內容包括以下3部分：
-
廣告業務簡介
-
面臨的技術挑戰
-
廣告系統架構詳解
廣告業務簡介
廣告，可以說無處不在。微信、抖音、B站、百度、淘寶等等，這些占據用戶時間最長的 APP， 到處都能看到廣告的影子。
我們每天隨處可見的廣告，它背後的業務邏輯到底是什麼樣的呢？在分享廣告系統的架構之前，先給大家快速普及下業務知識。
1. 廣告業務的核心點是平衡
為什麼說廣告業務的核心點是「平衡」？可以從廣告的標準定義來理解。
廣告被定義為：廣告主以付費方式通過網際網路平台向用戶傳播商品或者服務信息的手段。這個定義中涉及到 廣告主、平台、用戶3個主體，但是這3個主體的利益關注點各不相同。
圖1：廣告業務的三角平衡
-
廣告主：關注ROI，花了錢是否能帶來預期收益
-
平台：擁有流量，關注收益能否最大化
-
用戶：關注體驗，廣告是否足夠精準？是否影響到了正常功能的使用？
有時候這三者的利益是衝突的，比如平台增加了廣告位數量，收益肯定增加，但用戶體驗可能變差，因此廣告業務最終要尋找的是三方的平衡。
站在平台的角度來看廣告業務，它在保證用戶體驗的同時，要兼顧絕大部分廣告主的ROI（確保他們是可以賺到錢的），在此基礎上再考慮將平台的收入最大化，這樣才是一個健康的廣告生態。
2. 從收入的分解公式認清廣告的本質
廣告業務發展了幾十年，廣告費用的結算方式也誕生了很多種，我們最常見的有以下幾種：
-
CPT：按時間計費，獨占性包時段包位置
-
CPM：按照每千次曝光計費
-
CPC：按照點擊計費
-
CPA：按照行為計費（比如下載、註冊等）
圖2：廣告費用的結算方式演進
之所以有不同的結算方式，其實也是隨著廣告市場的發展逐漸衍生出來的，最開始流量稀缺，平台占優勢，再到今天逐漸成了買方市場，廣告主作為需求方的談判權變大。
上面這個圖可以看出，由於CPA代表了廣告主最終想要的轉化效果，因此按CPA結算時對廣告主最有利，但是對平台最不利。結算方式演進到今天，其實也是一種平衡，所以處於平衡點附近的CPM和CPC是最常見的結算方式。
以CPC為例，收入可分解成下面這個公式：
其中，PV表示系統的訪問量，PVR和ASN表示廣告的填充率，CTR表示廣告的點擊率，ACP表示廣告的平均點擊價格。
上述各個指標都可以通過一系列的廣告策略來提升。比如填充率可通過開發更多的廣告主來實現，CTR可通過AI算法做到精準投放來提升，ACP可通過精準流量溢價或者提升廣告主ROI來完成。
掌握上面這個收入分解公式，對於理解廣告業務至關重要，任何業務上的動作幾乎都能關聯到這個公式的某個指標上。
3. 廣告的核心業務流程
廣告業務發展到今天，隨著廣告主對投放效果的訴求不斷加強，精準定向以及實時競價是目前最主流的業務形態。
對網際網路平台來說，初期一般都是採用「自營的競價廣告網絡」來實現商業變現，簡單理解：就是利用平台自有的流量以及自主開發的廣告主來實現業務閉環。本文所分享的廣告架構主要針對這種業務形態，它的核心業務流程如下圖所示。
圖3：廣告的核心業務流程
-
廣告主先通過投放平台發布廣告，可設置一系列的定向條件，比如投放城市、投放時間段、人群標籤、出價等。
-
投放動作完成後，廣告會被存放到廣告庫、同時進入索引庫，以便能被廣告檢索引擎召回。
-
C端請求過來後，廣告引擎會完成召回、算法策略、競價排序等一系列的邏輯，最終篩選出Top N個廣告，實現廣告的千人千面。
-
用戶點擊廣告後，會觸發廣告扣費流程，這時候平台才算真正獲得收益。
上面是廣告業務的核心流程，隨著平台流量以及廣告主規模進一步增大，往往會從「自營型競價網絡」逐漸向「聯盟廣告以及RTB實時競價」方向發展，類似於阿里媽媽、騰訊廣點通、頭條巨量引擎，此時業務複雜度和技術架構會再上一個台階，本文不作展開，後續再跟大家詳細分享。
面臨的技術挑戰
對廣告業務有了初步了解後，再來看下廣告系統面臨的技術挑戰：
1、高並發：廣告引擎和C端流量對接，請求量大（平峰往往有上萬QPS），要求實時響應，必須在幾十毫秒內返回結果。
2、業務邏輯複雜：一次廣告請求，涉及到多路召回、算法模型打分、競價排序等複雜的業務流程，策略多，執行鏈路長。
3、穩定性要求高：廣告系統直接跟收入掛鈎，廣告引擎以及計費平台等核心系統的穩定性要求很高，可用性至少要做到3個9。
4、大數據存儲和計算：隨業務發展，推廣數量以及扣費訂單數量很容易達到千萬甚至上億規模，另外收入報表的聚合維度多，單報表可能達到百億級別的記錄數。
5、帳務的準確性：廣告扣費屬於金融性質的操作，需要做到不丟失、不重複，否則會損害某一方的利益。另外，如果收入數據不準確，還可能影響到業務決策。
廣告系統架構詳解
了解了廣告業務的目標和技術挑戰後，接下來詳細介紹下廣告系統的整體架構和技術方案。
圖4：廣告系統的整體架構
上面是我們公司目前的廣告系統架構圖，這個架構適用於廣告業務初期，針對的是「自營型的競價網絡和站內流量」，不涉及聯盟廣告。
下面針對各個子系統做下說明：
-
廣告投放系統：供廣告主使用，核心功能包括會員續費、廣告庫管理、設定推廣條件、設置廣告出價、查看投放效果等。
-
廣告運營後台：供平台的產品運營使用，核心功能包括廣告位管理、廣告策略管理、以及各種運營工具。
-
廣告檢索平台：承接C端的高並發請求，負責從海量廣告庫中篩選出幾個或者幾十個廣告，實時性要求高，這個平台通常由多個微服務組成。
-
AB實驗平台：廣告業務的穩定器，任何廣告策略上的調整均可以通過此平台進行灰度實驗，觀察收入指標的變化。
-
廣告計費平台：面向C端，負責實時扣費，和收入直接掛鈎，可用性要求高。
-
帳務管理中心：廣告業務中的財務系統，統管金額相關的業務，包括充值、凍結、扣費等。
-
大數據平台：整個廣告系統的底盤，需要聚合各種異構數據源，完成離線和實時數據分析和統計，產出業務報表，生產模型特徵等。
下面再針對架構中的技術難點展開做下介紹。
1. 廣告數據的存儲
廣告系統要存儲的數據多種多樣，特點各不相同，採用的是多模的數據存儲方式。
圖5：廣告數據的多模存儲
-
OLTP場景，包括廣告庫、創意庫、會員庫、廣告產品庫、廣告策略庫等，這些都存儲在MySQL中，數據規模較大的廣告庫和創意庫，按照廣告主ID Hash做分庫分表。
-
OLAP場景，涉及到非常多的報表，聚合維度多，單表的記錄數可能達到百億級別，底層採用HDFS和HBase存儲。
-
面向廣告檢索場景的索引數據，包括正排索引和倒排索引，採用Redis和ES來存儲。
存儲上還需要解決的一個問題是：廣告的同步問題。廣告投放完成後，首先會存儲在MySQL資料庫中，接下來需要把廣告實時傳輸到檢索系統中，完成正排索引以及倒排索引的更新。
圖6：廣告索引的更新流程
索引更新服務，有幾個要點說明下：
-
各個業務系統在推廣、餘額等信息變更時，發MQ消息，索引更新服務訂閱MQ來感知變化，完成增量同步。
-
變更的消息體中，不傳遞實際變更的欄位，僅通知有變化的廣告ID，索引更新服務實時讀取最新數據完成更新，這樣可以有效的解決消息亂序引起的數據不一致問題。
-
當更新索引的並發達到一定量級後，可通過合併相同廣告的變更、或者將倒排和正排更新分離的方式來提升整體的更新速度。
2. 廣告檢索平台的整體流程
廣告檢索平台負責承接C端的流量請求，從海量廣告庫中篩選出最合適的前N個廣告，並在幾十毫秒內返回結果，它是一個多級篩選和排序的過程。
圖7：廣告檢索平台的整體流程
Recall層側重算法模型，Search層側重業務。從下到上，計算複雜度逐層增加，候選集逐層減少。（說明：搜索廣告場景和推薦廣告場景在某些子模塊上存在差異，但整體流程基本一致，這裡不作展開）
性能設計是檢索平台的重點，通常有以下手段：
-
做好服務分層，各層均可水平擴展。
-
採用Redis緩存，避免高並發請求直接打到資料庫，緩存可按業務規劃多套，進行分流。
-
採用多線程並行化某些子流程，比如多路召回邏輯、多模型打分邏輯。
-
熱點數據進行本地緩存，比如廣告位的配置信息以及策略配置信息，在服務啟動時就可以預加載到本地，然後定時進行同步。
-
非核心流程設置超時熔斷走降級邏輯，比如溢價策略（不溢價只是少賺了，不影響廣告召回）。
-
和主流程無關的邏輯異步執行，比如扣費信息緩存、召回結果緩存等。
-
精簡RPC返回結果或者Redis緩存對象的結構，去掉不必要的欄位，減少IO數據包大小。
-
GC優化，包括JVM堆內存的設置、垃圾收集器的選擇、GC頻次優化和GC耗時優化。
3. 計費平台的技術方案
計費平台也是一個核心系統，主要完成實時扣費功能。比如CPC結算方式下，廣告主設置的預算是50元，每次點擊扣1元，當扣費金額達到預算時，需要將廣告及時下線。
除此之外，計費平台還需要支持CPM、CPT等多種結算方式，以及支持反作弊、餘額撞線處理、扣費訂單的攤銷和對帳等功能。
計費平台的特點是：並發高、數據量大、同時可用性要求高，需要做到不少扣，不重複扣。下面以CPC實時點擊扣費為例，詳細說下技術方案。
圖8：CPC實時扣費流程
首先，整個扣費流程做了異步化處理，當收到實時扣費請求後，系統先將扣費時用到的信息緩存到Redis，然後發送MQ消息，這兩步完成後扣費動作就算結束了。
這樣做的好處是：能確保扣費接口的性能，同時利用MQ的可靠性投遞和重試機制確保整個扣費流程的最終一致性。
為了提高可用性，針對Redis和MQ不可用的情況均採用了降級方案。Redis不可用時，切換到TiKV進行持久化；MQ投遞失敗時，改成線程池異步處理。
另外，每次有效點擊都需要生成1條扣費訂單，面臨大數據量的存儲問題。目前我們採用的是MySQL分庫分表，後期會考慮使用HBase等分布式存儲。另外，訂單和帳務系統之間的數據一致性，採用大數據平台做天級別的增量抽取，通過Hive任務完成對帳和監控。
4. OLAP海量數據報表的技術方案
數據報表是也是廣告平台的核心業務，它是廣告主、平台運營人員進行投放優化、業務決策的依據。先來看下廣告數據倉庫的分層結構：
圖9：廣告數據倉庫的分層結構
-
源數據層：對應各種源數據，包括HDFS中實時採集的前後端日誌，增量或者全量同步的MySQL業務數據表。
-
數據倉庫層：包含維度表和事實表，通常是對源數據進行清洗後的數據寬表，比如行為日誌表、推廣寬表、用戶寬表等。
-
數據集市層：對數據進行輕粒度的匯總表，比如廣告效果表、用戶行為的全鏈路表、用戶群分析表等。
-
數據應用層：上層應用場景直接使用的數據表，包括多維分析生成的各種收入報表、Spark任務產出的算法模型特徵和畫像數據等。
採用這樣的分層結構，和軟體分層思想類似，提高了數據的維護性和復用性。
再來看應用層報表部分面臨的挑戰：聚合維度多，需要分時、分廣告位、分推廣等幾十個維度；單表最大達到百億級別；支持時間範圍的實時查詢。
這部分由公司的大數據部門維護，採用了開源的技術方案，離線部分使用Kylin，數據存儲在HBase中；實時部分使用Flink和Spark Streaming，數據存儲在Druid中。
寫在最後
本文詳細介紹了廣告系統的初期架構和核心技術方案。隨著業務演進，架構也會隨之變得更加複雜，但是大數據存儲、高並發、高可用，始終是廣告業務的技術難點。
關於廣告系統的穩定性保障、廣告策略的可擴展性設計、RTB實時競價的系統架構等有價值的內容，後續再分享給大家，歡迎關注我的公號。針對本篇文章，如果有任何疑問或者建議，可以留言討論。