乾貨 | 廣告系統架構解密

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

從技術角度來講，廣告業務涉及到 AI算法、大數據處理、檢索引擎、高性能和高可用的工程架構 等多個方向，一樣有着不錯的技術吸引力。

我從去年開始接觸廣告業務，到如今差很少一年時間了。這篇文章將結合個人我的經驗，同時參考業界的優秀案例，闡述下廣告系統的架構實踐方案，但願讓你們有所收穫。內容包括如下3部分：

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

01 廣告業務簡介

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

咱們天天隨處可見的廣告，它背後的業務邏輯究竟是什麼樣的呢？在分享廣告系統的架構以前，先給你們快速普及下業務知識。

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

爲何說廣告業務的核心點是「平衡」？能夠從廣告的標準定義來理解。

廣告被定義爲：廣告主以付費方式經過互聯網平臺向用戶傳播商品或者服務信息的手段。這個定義中涉及到 廣告主、平臺、用戶3個主體，可是這3個主體的利益關注點各不相同。

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

有時候這三者的利益是衝突的，好比平臺增長了廣告位數量，收益確定增長，但用戶體驗可能變差，所以廣告業務最終要尋找的是三方的平衡。

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

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

廣告業務發展了幾十年，廣告費用的結算方式也誕生了不少種，咱們最多見的有如下幾種：

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

之因此有不一樣的結算方式，其實也是隨着廣告市場的發展逐漸衍生出來的，最開始流量稀缺，平臺佔優點，再到今天逐漸成了買方市場，廣告主做爲需求方的談判權變大。

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

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

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

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

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

三、廣告的核心業務流程

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

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

• 廣告主先經過投放平臺發佈廣告，可設置一系列的定向條件，好比投放城市、投放時間段、人羣標籤、出價等。

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

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

• 用戶點擊廣告後，會觸發廣告扣費流程，這時候平臺纔算真正得到收益。

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

02 面臨的技術挑戰

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

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

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

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

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

五、帳務的準確性：廣告扣費屬於金融性質的操做，須要作到不丟失、不重複，不然會損害某一方的利益。另外，若是收入數據不許確，還可能影響到業務決策。

03 廣告系統架構詳解

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

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

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

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

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

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

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

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

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

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

一、廣告數據的存儲

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

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

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

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

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

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

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

• 變動的消息體中，不傳遞實際變動的字段，僅通知有變化的廣告ID，索引更新服務實時讀取最新數據完成更新，這樣能夠有效的解決消息亂序引發的數據不一致問題。

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

二、廣告檢索平臺的總體流程

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

Recall層側重算法模型，Search層側重業務。從下到上，計算複雜度逐層增長，候選集逐層減小。（說明：搜索廣告場景和推薦廣告場景在某些子模塊上存在差別，但總體流程基本一致，這裏不做展開）

性能設計是檢索平臺的重點，一般有如下手段：

• 作好服務分層，各層都可水平擴展。

• 採用Redis緩存，避免高併發請求直接打到數據庫，緩存可按業務規劃多套，進行分流。

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

• 熱點數據進行本地緩存，好比廣告位的配置信息以及策略配置信息，在服務啓動時就能夠預加載到本地，而後定時進行同步。

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

• 和主流程無關的邏輯異步執行，好比扣費信息緩存、召回結果緩存等。

• 精簡RPC返回結果或者Redis緩存對象的結構，去掉沒必要要的字段，減小IO數據包大小。

• GC優化，包括JVM堆內存的設置、垃圾收集器的選擇、GC頻次優化和GC耗時優化。

三、計費平臺的技術方案

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

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

計費平臺的特色是：併發高、數據量大、同時可用性要求高，須要作到很多扣，不重複扣。下面以CPC實時點擊扣費爲例，詳細說下技術方案。

首先，整個扣費流程作了異步化處理，當收到實時扣費請求後，系統先將扣費時用到的信息緩存到Redis，而後發送MQ消息，這兩步完成後扣費動做就算結束了。

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

爲了提升可用性，針對Redis和MQ不可用的狀況均採用了降級方案。Redis不可用時，切換到TiKV進行持久化；MQ投遞失敗時，改爲線程池異步處理。

另外，每次有效點擊都須要生成1條扣費訂單，面臨大數據量的存儲問題。目前咱們採用的是MySQL分庫分表，後期會考慮使用HBase等分佈式存儲。另外，訂單和帳務系統之間的數據一致性，採用大數據平臺作天級別的增量抽取，經過Hive任務完成對帳和監控。

四、OLAP海量數據報表的技術方案

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

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

• 數據倉庫層：包含維度表和事實表，一般是對源數據進行清洗後的數據寬表，好比行爲日誌表、推廣寬表、用戶寬表等。

• 數據集市層：對數據進行輕粒度的彙總表，好比廣告效果表、用戶行爲的全鏈路表、用戶羣分析表等。

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

採用這樣的分層結構，和軟件分層思想相似，提升了數據的維護性和複用性。

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

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

寫在最後

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

關於廣告系統的穩定性保障、廣告策略的可擴展性設計、RTB實時競價的系統架構等有價值的內容，後續再分享給你們，歡迎關注個人公號。 針對本篇文章，若是有任何疑問或者建議，能夠留言討論 。

- End -

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

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