乾貨 | 廣告系統架構解密

廣告、增值服務、佣金，是網際網路企業最常見的三種盈利手段。在這3大經典中，又以廣告所佔的市場份額最大，幾乎是絕大部分網際網路平臺最主要的營收途徑，業務的重要性不言而喻。

從技術角度來說，廣告業務涉及到 AI演算法、大資料處理、檢索引擎、高效能和高可用的工程架構 等多個方向，同樣有著不錯的技術吸引力。

我從去年開始接觸廣告業務，到現在差不多一年時間了。這篇文章將結合我的個人經驗，同時參考業界的優秀案例，闡述下廣告系統的架構實踐方案，希望讓大家有所收穫。內容包括以下3部分：

• 廣告業務簡介
• 面臨的技術挑戰
• 廣告系統架構詳解

01 廣告業務簡介

廣告，可以說無處不在。微信、抖音、B站、百度、淘寶等等，這些佔據使用者時間最長的 APP， 到處都能看到廣告的影子。

我們每天隨處可見的廣告，它背後的業務邏輯到底是什麼樣的呢？在分享廣告系統的架構之前，先給大家快速普及下業務知識。

1、廣告業務的核心點是平衡

為什麼說廣告業務的核心點是「平衡」？可以從廣告的標準定義來理解。

廣告被定義為：廣告主以付費方式通過網際網路平臺向使用者傳播商品或者服務資訊的手段。這個定義中涉及到 廣告主、平臺、使用者3個主體，但是這3個主體的利益關注點各不相同。

• 廣告主：關注ROI，花了錢是否能帶來預期收益
• 平臺：擁有流量，關注收益能否最大化
• 使用者：關注體驗，廣告是否足夠精準？是否影響到了正常功能的使用？

有時候這三者的利益是衝突的，比如平臺增加了廣告位數量，收益肯定增加，但使用者體驗可能變差，因此廣告業務最終要尋找的是三方的平衡。

站在平臺的角度來看廣告業務，它在保證使用者體驗的同時，要兼顧絕大部分廣告主的ROI（確保他們是可以賺到錢的），在此基礎上再考慮將平臺的收入最大化，這樣才是一個健康的廣告生態。

2、從收入的分解公式認清廣告的本質

廣告業務發展了幾十年，廣告費用的結算方式也誕生了很多種，我們最常見的有以下幾種：

• CPT：按時間計費，獨佔性包時段包位置
• CPM：按照每千次曝光計費
• CPC：按照點選計費
• CPA：按照行為計費（比如下載、註冊等）

之所以有不同的結算方式，其實也是隨著廣告市場的發展逐漸衍生出來的，最開始流量稀缺，平臺佔優勢，再到今天逐漸成了買方市場，廣告主作為需求方的談判權變大。

上面這個圖可以看出，由於CPA代表了廣告主最終想要的轉化效果，因此按CPA結算時對廣告主最有利，但是對平臺最不利。結算方式演進到今天，其實也是一種平衡，所以處於平衡點附近的CPM和CPC是最常見的結算方式。

以CPC為例，收入可分解成下面這個公式：

其中，PV表示系統的訪問量，PVR和ASN表示廣告的填充率，CTR表示廣告的點選率，ACP表示廣告的平均點選價格。

上述各個指標都可以通過一系列的廣告策略來提升。 比如填充率可通過開發更多的廣告主來實現， CTR可通過AI演算法做到精準投放來提升， ACP可通過精準流量溢價或者提升廣告主ROI來完成。

掌握上面這個收入分解公式，對於理解廣告業務至關重要，任何業務上的動作幾乎都能關聯到這個公式的某個指標上。

3、廣告的核心業務流程

廣告業務發展到今天，隨著廣告主對投放效果的訴求不斷加強，精準定向以及實時競價是目前最主流的業務形態。

對網際網路平臺來說，初期一般都是採用「 自營的競價廣告網路 」來實現商業變現，簡單理解：就是利用平臺自有的流量以及自主開發的廣告主來實現業務閉環。 本文所分享的廣告架構主要針對這種業務形態 ，它的核心業務流程如下圖所示。

• 廣告主先通過投放平臺釋出廣告，可設定一系列的定向條件，比如投放城市、投放時間段、人群標籤、出價等。

• 投放動作完成後，廣告會被存放到廣告庫、同時進入索引庫，以便能被廣告檢索引擎召回。

• C端請求過來後，廣告引擎會完成召回、演算法策略、競價排序等一系列的邏輯，最終篩選出Top N個廣告，實現廣告的千人千面。

• 使用者點選廣告後，會觸發廣告扣費流程，這時候平臺才算真正獲得收益。

上面是廣告業務的核心流程，隨著平臺流量以及廣告主規模進一步增大，往往會從「自營型競價網路」逐漸向「聯盟廣告以及RTB實時競價」方向發展，類似於阿里媽媽、 騰訊廣點通、頭條巨量引擎，此時業務複雜度和技術架構會再上一個臺階，本文不作展開，後續再跟大家詳細分享。

02 面臨的技術挑戰

對廣告業務有了初步瞭解後，再來看下廣告系統面臨的技術挑戰：

1、高併發：廣告引擎和C端流量對接，請求量大（平峰往往有上萬QPS），要求實時響應，必須在幾十毫秒內返回結果。

2、業務邏輯複雜：一次廣告請求，涉及到多路召回、演算法模型打分、競價排序等複雜的業務流程，策略多，執行鏈路長。

3、穩定性要求高：廣告系統直接跟收入掛鉤，廣告引擎以及計費平臺等核心系統的穩定性要求很高，可用性至少要做到3個9。

4、大資料儲存和計算：隨業務發展，推廣數量以及扣費訂單數量很容易達到千萬甚至上億規模，另外收入報表的聚合維度多，單報表可能達到百億級別的記錄數。

5、賬務的準確性：廣告扣費屬於金融性質的操作，需要做到不丟失、不重複，否則會損害某一方的利益。另外，如果收入資料不準確，還可能影響到業務決策。

03 廣告系統架構詳解

瞭解了廣告業務的目標和技術挑戰後，接下來詳細介紹下廣告系統的整體架構和技術方案。

上面是我們公司目前的廣告系統架構圖，這個架構適用於廣告業務初期，針對的是「自營型的競價網路和站內流量」，不涉及聯盟廣告。

下面針對各個子系統做下說明：

• 廣告投放系統：供廣告主使用，核心功能包括會員續費、廣告庫管理、設定推廣條件、設定廣告出價、檢視投放效果等。

• 廣告運營後臺：供平臺的產品運營使用，核心功能包括廣告位管理、廣告策略管理、以及各種運營工具。

• 廣告檢索平臺：承接C端的高併發請求，負責從海量廣告庫中篩選出幾個或者幾十個廣告，實時性要求高，這個平臺通常由多個微服務組成。

• AB實驗平臺：廣告業務的穩定器，任何廣告策略上的調整均可以通過此平臺進行灰度實驗，觀察收入指標的變化。

• 廣告計費平臺：面向C端，負責實時扣費，和收入直接掛鉤，可用性要求高。

• 賬務管理中心：廣告業務中的財務系統，統管金額相關的業務，包括充值、凍結、扣費等。

• 大資料平臺：整個廣告系統的底盤，需要聚合各種異構資料來源，完成離線和實時資料分析和統計，產出業務報表，生產模型特徵等。

1、廣告資料的儲存

廣告系統要儲存的資料多種多樣，特點各不相同，採用的是多模的資料儲存方式。

• OLTP場景，包括廣告庫、創意庫、會員庫、廣告產品庫、廣告策略庫等，這些都儲存在MySQL中，資料規模較大的廣告庫和創意庫，按照廣告主ID Hash做分庫分表。

• OLAP場景，涉及到非常多的報表，聚合維度多，單表的記錄數可能達到百億級別，底層採用HDFS和HBase儲存。

• 面向廣告檢索場景的索引資料，包括正排索引和倒排索引，採用Redis和ES來儲存。

儲存上還需要解決的一個問題是：廣告的同步問題。廣告投放完成後，首先會儲存在MySQL資料庫中，接下來需要把廣告實時傳輸到檢索系統中，完成正排索引以及倒排索引的更新。

索引更新服務，有幾個要點說明下：

• 各個業務系統在推廣、餘額等資訊變更時，發MQ訊息，索引更新服務訂閱MQ來感知變化，完成增量同步。

• 變更的訊息體中，不傳遞實際變更的欄位，僅通知有變化的廣告ID，索引更新服務實時讀取最新資料完成更新，這樣可以有效的解決訊息亂序引起的資料不一致問題。

• 當更新索引的併發達到一定量級後，可通過合併相同廣告的變更、或者將倒排和正排更新分離的方式來提升整體的更新速度。

2、廣告檢索平臺的整體流程

廣告檢索平臺負責承接C端的流量請求，從海量廣告庫中篩選出最合適的前N個廣告，並在幾十毫秒內返回結果，它是一個多級篩選和排序的過程。

Recall層側重演算法模型，Search層側重業務。從下到上，計算複雜度逐層增加，候選集逐層減少。（說明：搜尋廣告場景和推薦廣告場景在某些子模組上存在差異，但整體流程基本一致，這裡不作展開）

效能設計是檢索平臺的重點，通常有以下手段：

• 做好服務分層，各層均可水平擴充套件。

• 採用Redis快取，避免高併發請求直接打到資料庫，快取可按業務規劃多套，進行分流。

• 採用多執行緒並行化某些子流程，比如多路召回邏輯、多模型打分邏輯。

• 熱點資料進行本地快取，比如廣告位的配置資訊以及策略配置資訊，在服務啟動時就可以預載入到本地，然後定時進行同步。

• 非核心流程設定超時熔斷走降級邏輯，比如溢價策略（不溢價只是少賺了，不影響廣告召回）。

• 和主流程無關的邏輯非同步執行，比如扣費資訊快取、召回結果快取等。

• 精簡RPC返回結果或者Redis快取物件的結構，去掉不必要的欄位，減少IO資料包大小。

• GC優化，包括JVM堆記憶體的設定、垃圾收集器的選擇、GC頻次優化和GC耗時優化。

3、計費平臺的技術方案

計費平臺也是一個核心繫統，主要完成實時扣費功能。比如CPC結算方式下，廣告主設定的預算是50元，每次點選扣1元，當扣費金額達到預算時，需要將廣告及時下線。

除此之外，計費平臺還需要支援CPM、CPT等多種結算方式，以及支援反作弊、餘額撞線處理、扣費訂單的攤銷和對賬等功能。

計費平臺的特點是：併發高、資料量大、同時可用性要求高，需要做到不少扣，不重複扣。下面以CPC實時點選扣費為例，詳細說下技術方案。

首先，整個扣費流程做了非同步化處理，當收到實時扣費請求後，系統先將扣費時用到的資訊快取到Redis，然後傳送MQ訊息，這兩步完成後扣費動作就算結束了。

這樣做的好處是：能確保扣費介面的效能，同時利用MQ的可靠性投遞和重試機制確保整個扣費流程的最終一致性。

為了提高可用性，針對Redis和MQ不可用的情況均採用了降級方案。Redis不可用時，切換到TiKV進行持久化；MQ投遞失敗時，改成執行緒池非同步處理。

另外，每次有效點選都需要生成1條扣費訂單，面臨大資料量的儲存問題。目前我們採用的是MySQL分庫分表，後期會考慮使用HBase等分散式儲存。另外，訂單和賬務系統之間的資料一致性，採用大資料平臺做天級別的增量抽取，通過Hive任務完成對賬和監控。

4、OLAP海量資料包表的技術方案

資料包表是也是廣告平臺的核心業務，它是廣告主、平臺運營人員進行投放優化、業務決策的依據。 先來看下廣告資料倉儲的分層結構：

• 源資料層：對應各種源資料，包括HDFS中實時採集的前後端日誌，增量或者全量同步的MySQL業務資料表。

• 資料倉儲層：包含維度表和事實表，通常是對源資料進行清洗後的資料寬表，比如行為日誌表、推廣寬表、使用者寬表等。

• 資料集市層：對資料進行輕粒度的彙總表，比如廣告效果表、使用者行為的全鏈路表、使用者群分析表等。

• 資料應用層：上層應用場景直接使用的資料表，包括多維分析生成的各種收入報表、Spark任務產出的演算法模型特徵和畫像資料等。

採用這樣的分層結構，和軟體分層思想類似，提高了資料的維護性和複用性。

再來看應用層報表部分面臨的挑戰： 聚合維度多， 需要分時、分廣告位、分推廣等幾十個維度； 單表最大達到百億級別；支援時間範圍的實時查詢。

這部分由公司的大資料部門維護，採用了開源的技術方案，離線部分使用Kylin，資料儲存在HBase中；實時部分使用Flink和Spark Streaming，資料儲存在Druid中。

寫在最後

本文詳細介紹了廣告系統的初期架構和核心技術方案。隨著業務演進，架構也會隨之變得更加複雜，但是 大資料儲存、高併發、高可用，始終是廣告業務的技術難點 。

關於廣告系統的穩定性保障、廣告策略的可擴充套件性設計、RTB實時競價的系統架構等有價值的內容，後續再分享給大家，歡迎關注我的公號。 針對本篇文章，如果有任何疑問或者建議，可以留言討論 。

- End -

作者簡介：985碩士，前亞馬遜工程師，現58轉轉技術總監

歡迎掃描下方的二維碼，關注我的個人公眾號：IT人的職場進階，精彩原創不斷！