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