[[338994]]

廣告、增值服務(wù)、傭金，是互聯(lián)網(wǎng)企業(yè)最常見的三種盈利手段。在這3大經(jīng)典中，又以廣告所占的市場(chǎng)份額最大，幾乎是絕大部分互聯(lián)網(wǎng)平臺(tái)最主要的營(yíng)收途徑，業(yè)務(wù)的重要性不言而喻。

從技術(shù)角度來(lái)說(shuō)，廣告業(yè)務(wù)涉及到 AI算法、大數(shù)據(jù)處理、檢索引擎、高性能和高可用的工程架構(gòu) 等多個(gè)方向，同樣有著不錯(cuò)的技術(shù)吸引力。

我從去年開始接觸廣告業(yè)務(wù)，到現(xiàn)在差不多一年時(shí)間了。這篇文章將結(jié)合我的個(gè)人經(jīng)驗(yàn)，同時(shí)參考業(yè)界的優(yōu)秀案例，闡述下廣告系統(tǒng)的架構(gòu)實(shí)踐方案，希望讓大家有所收獲。內(nèi)容包括以下3部分：

• 廣告業(yè)務(wù)簡(jiǎn)介
• 面臨的技術(shù)挑戰(zhàn)
• 廣告系統(tǒng)架構(gòu)詳解

01 廣告業(yè)務(wù)簡(jiǎn)介

廣告，可以說(shuō)無(wú)處不在。微信、抖音、B站、百度、淘寶等等，這些占據(jù)用戶時(shí)間最長(zhǎng)的 APP， 到處都能看到廣告的影子。

我們每天隨處可見的廣告，它背后的業(yè)務(wù)邏輯到底是什么樣的呢?在分享廣告系統(tǒng)的架構(gòu)之前，先給大家快速普及下業(yè)務(wù)知識(shí)。

1. 廣告業(yè)務(wù)的核心點(diǎn)是平衡

為什么說(shuō)廣告業(yè)務(wù)的核心點(diǎn)是「平衡」?可以從廣告的標(biāo)準(zhǔn)定義來(lái)理解。

廣告被定義為：廣告主以付費(fèi)方式通過(guò)互聯(lián)網(wǎng)平臺(tái)向用戶傳播商品或者服務(wù)信息的手段。這個(gè)定義中涉及到 廣告主、平臺(tái)、用戶 3個(gè)主體，但是這3個(gè)主體的利益關(guān)注點(diǎn)各不相同。

圖1：廣告業(yè)務(wù)的三角平衡

• 廣告主：關(guān)注ROI，花了錢是否能帶來(lái)預(yù)期收益
• 平臺(tái)：擁有流量，關(guān)注收益能否最大化
• 用戶：關(guān)注體驗(yàn)，廣告是否足夠精準(zhǔn)?是否影響到了正常功能的使用?

有時(shí)候這三者的利益是沖突的，比如平臺(tái)增加了廣告位數(shù)量，收益肯定增加，但用戶體驗(yàn)可能變差，因此廣告業(yè)務(wù)最終要尋找的是三方的平衡。

站在平臺(tái)的角度來(lái)看廣告業(yè)務(wù)，它在保證用戶體驗(yàn)的同時(shí)，要兼顧絕大部分廣告主的ROI(確保他們是可以賺到錢的)，在此基礎(chǔ)上再考慮將平臺(tái)的收入最大化，這樣才是一個(gè)健康的廣告生態(tài)。

2. 從收入的分解公式認(rèn)清廣告的本質(zhì)

廣告業(yè)務(wù)發(fā)展了幾十年，廣告費(fèi)用的結(jié)算方式也誕生了很多種，我們最常見的有以下幾種：

• CPT：按時(shí)間計(jì)費(fèi)，獨(dú)占性包時(shí)段包位置
• CPM：按照每千次曝光計(jì)費(fèi)
• CPC：按照點(diǎn)擊計(jì)費(fèi)
• CPA：按照行為計(jì)費(fèi)(比如下載、注冊(cè)等)

圖2：廣告費(fèi)用的結(jié)算方式演進(jìn)

之所以有不同的結(jié)算方式，其實(shí)也是隨著廣告市場(chǎng)的發(fā)展逐漸衍生出來(lái)的，最開始流量稀缺，平臺(tái)占優(yōu)勢(shì)，再到今天逐漸成了買方市場(chǎng)，廣告主作為需求方的談判權(quán)變大。

上面這個(gè)圖可以看出，由于CPA代表了廣告主最終想要的轉(zhuǎn)化效果，因此按CPA結(jié)算時(shí)對(duì)廣告主最有利，但是對(duì)平臺(tái)最不利。結(jié)算方式演進(jìn)到今天，其實(shí)也是一種平衡，所以處于平衡點(diǎn)附近的CPM和CPC是最常見的結(jié)算方式。

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

其中，PV表示系統(tǒng)的訪問(wèn)量，PVR和ASN表示廣告的填充率，CTR表示廣告的點(diǎn)擊率，ACP表示廣告的平均點(diǎn)擊價(jià)格。上述各個(gè)指標(biāo)都可以通過(guò)一系列的廣告策略來(lái)提升。比如填充率可通過(guò)開發(fā)更多的廣告主來(lái)實(shí)現(xiàn)，CTR可通過(guò)AI算法做到精準(zhǔn)投放來(lái)提升，ACP可通過(guò)精準(zhǔn)流量溢價(jià)或者提升廣告主ROI來(lái)完成。掌握上面這個(gè)收入分解公式，對(duì)于理解廣告業(yè)務(wù)至關(guān)重要，任何業(yè)務(wù)上的動(dòng)作幾乎都能關(guān)聯(lián)到這個(gè)公式的某個(gè)指標(biāo)上。

3. 廣告的核心業(yè)務(wù)流程

廣告業(yè)務(wù)發(fā)展到今天，隨著廣告主對(duì)投放效果的訴求不斷加強(qiáng)，精準(zhǔn)定向以及實(shí)時(shí)競(jìng)價(jià)是目前最主流的業(yè)務(wù)形態(tài)。對(duì)互聯(lián)網(wǎng)平臺(tái)來(lái)說(shuō)，初期一般都是采用「自營(yíng)的競(jìng)價(jià)廣告網(wǎng)絡(luò)」來(lái)實(shí)現(xiàn)商業(yè)變現(xiàn)，簡(jiǎn)單理解：就是利用平臺(tái)自有的流量以及自主開發(fā)的廣告主來(lái)實(shí)現(xiàn)業(yè)務(wù)閉環(huán)。本文所分享的廣告架構(gòu)主要針對(duì)這種業(yè)務(wù)形態(tài)，它的核心業(yè)務(wù)流程如下圖所示。

圖3：廣告的核心業(yè)務(wù)流程

• 廣告主先通過(guò)投放平臺(tái)發(fā)布廣告，可設(shè)置一系列的定向條件，比如投放城市、投放時(shí)間段、人群標(biāo)簽、出價(jià)等。
• 投放動(dòng)作完成后，廣告會(huì)被存放到廣告庫(kù)、同時(shí)進(jìn)入索引庫(kù)，以便能被廣告檢索引擎召回。
• C端請(qǐng)求過(guò)來(lái)后，廣告引擎會(huì)完成召回、算法策略、競(jìng)價(jià)排序等一系列的邏輯，最終篩選出Top N個(gè)廣告，實(shí)現(xiàn)廣告的千人千面。
• 用戶點(diǎn)擊廣告后，會(huì)觸發(fā)廣告扣費(fèi)流程，這時(shí)候平臺(tái)才算真正獲得收益。上面是廣告業(yè)務(wù)的核心流程，隨著平臺(tái)流量以及廣告主規(guī)模進(jìn)一步增大，往往會(huì)從「自營(yíng)型競(jìng)價(jià)網(wǎng)絡(luò)」逐漸向「聯(lián)盟廣告以及RTB實(shí)時(shí)競(jìng)價(jià)」方向發(fā)展，類似于阿里媽媽、騰訊廣點(diǎn)通、頭條巨量引擎，此時(shí)業(yè)務(wù)復(fù)雜度和技術(shù)架構(gòu)會(huì)再上一個(gè)臺(tái)階，本文不作展開，后續(xù)再跟大家詳細(xì)分享。

02 面臨的技術(shù)挑戰(zhàn)

對(duì)廣告業(yè)務(wù)有了初步了解后，再來(lái)看下廣告系統(tǒng)面臨的技術(shù)挑戰(zhàn)：

1、高并發(fā)：廣告引擎和C端流量對(duì)接，請(qǐng)求量大(平峰往往有上萬(wàn)QPS)，要求實(shí)時(shí)響應(yīng)，必須在幾十毫秒內(nèi)返回結(jié)果。

2、業(yè)務(wù)邏輯復(fù)雜：一次廣告請(qǐng)求，涉及到多路召回、算法模型打分、競(jìng)價(jià)排序等復(fù)雜的業(yè)務(wù)流程，策略多，執(zhí)行鏈路長(zhǎng)。

3、穩(wěn)定性要求高：廣告系統(tǒng)直接跟收入掛鉤，廣告引擎以及計(jì)費(fèi)平臺(tái)等核心系統(tǒng)的穩(wěn)定性要求很高，可用性至少要做到3個(gè)9。

4、大數(shù)據(jù)存儲(chǔ)和計(jì)算：隨業(yè)務(wù)發(fā)展，推廣數(shù)量以及扣費(fèi)訂單數(shù)量很容易達(dá)到千萬(wàn)甚至上億規(guī)模，另外收入報(bào)表的聚合維度多，單報(bào)表可能達(dá)到百億級(jí)別的記錄數(shù)。

5、賬務(wù)的準(zhǔn)確性：廣告扣費(fèi)屬于金融性質(zhì)的操作，需要做到不丟失、不重復(fù)，否則會(huì)損害某一方的利益。另外，如果收入數(shù)據(jù)不準(zhǔn)確，還可能影響到業(yè)務(wù)決策。

03 廣告系統(tǒng)架構(gòu)詳解

了解了廣告業(yè)務(wù)的目標(biāo)和技術(shù)挑戰(zhàn)后，接下來(lái)詳細(xì)介紹下廣告系統(tǒng)的整體架構(gòu)和技術(shù)方案。

圖4：廣告系統(tǒng)的整體架構(gòu)

上面是我們公司目前的廣告系統(tǒng)架構(gòu)圖，這個(gè)架構(gòu)適用于廣告業(yè)務(wù)初期，針對(duì)的是「自營(yíng)型的競(jìng)價(jià)網(wǎng)絡(luò)和站內(nèi)流量」，不涉及聯(lián)盟廣告。

下面針對(duì)各個(gè)子系統(tǒng)做下說(shuō)明：

• 廣告投放系統(tǒng)：供廣告主使用，核心功能包括會(huì)員續(xù)費(fèi)、廣告庫(kù)管理、設(shè)定推廣條件、設(shè)置廣告出價(jià)、查看投放效果等。
• 廣告運(yùn)營(yíng)后臺(tái)：供平臺(tái)的產(chǎn)品運(yùn)營(yíng)使用，核心功能包括廣告位管理、廣告策略管理、以及各種運(yùn)營(yíng)工具。
• 廣告檢索平臺(tái)：承接C端的高并發(fā)請(qǐng)求，負(fù)責(zé)從海量廣告庫(kù)中篩選出幾個(gè)或者幾十個(gè)廣告，實(shí)時(shí)性要求高，這個(gè)平臺(tái)通常由多個(gè)微服務(wù)組成。
• AB實(shí)驗(yàn)平臺(tái)：廣告業(yè)務(wù)的穩(wěn)定器，任何廣告策略上的調(diào)整均可以通過(guò)此平臺(tái)進(jìn)行灰度實(shí)驗(yàn)，觀察收入指標(biāo)的變化。
• 廣告計(jì)費(fèi)平臺(tái)：面向C端，負(fù)責(zé)實(shí)時(shí)扣費(fèi)，和收入直接掛鉤，可用性要求高。
• 賬務(wù)管理中心：廣告業(yè)務(wù)中的財(cái)務(wù)系統(tǒng)，統(tǒng)管金額相關(guān)的業(yè)務(wù)，包括充值、凍結(jié)、扣費(fèi)等。
• 大數(shù)據(jù)平臺(tái)：整個(gè)廣告系統(tǒng)的底盤，需要聚合各種異構(gòu)數(shù)據(jù)源，完成離線和實(shí)時(shí)數(shù)據(jù)分析和統(tǒng)計(jì)，產(chǎn)出業(yè)務(wù)報(bào)表，生產(chǎn)模型特征等。下面再針對(duì)架構(gòu)中的技術(shù)難點(diǎn)展開做下介紹。

1. 廣告數(shù)據(jù)的存儲(chǔ)

廣告系統(tǒng)要存儲(chǔ)的數(shù)據(jù)多種多樣，特點(diǎn)各不相同，采用的是多模的數(shù)據(jù)存儲(chǔ)方式。

圖5：廣告數(shù)據(jù)的多模存儲(chǔ)

• OLTP場(chǎng)景，包括廣告庫(kù)、創(chuàng)意庫(kù)、會(huì)員庫(kù)、廣告產(chǎn)品庫(kù)、廣告策略庫(kù)等，這些都存儲(chǔ)在MySQL中，數(shù)據(jù)規(guī)模較大的廣告庫(kù)和創(chuàng)意庫(kù)，按照廣告主ID Hash做分庫(kù)分表。
• OLAP場(chǎng)景，涉及到非常多的報(bào)表，聚合維度多，單表的記錄數(shù)可能達(dá)到百億級(jí)別，底層采用HDFS和HBase存儲(chǔ)。
• 面向廣告檢索場(chǎng)景的索引數(shù)據(jù)，包括正排索引和倒排索引，采用Redis和ES來(lái)存儲(chǔ)。存儲(chǔ)上還需要解決的一個(gè)問(wèn)題是：廣告的同步問(wèn)題。廣告投放完成后，首先會(huì)存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)中，接下來(lái)需要把廣告實(shí)時(shí)傳輸?shù)綑z索系統(tǒng)中，完成正排索引以及倒排索引的更新。

圖6：廣告索引的更新流程

索引更新服務(wù)，有幾個(gè)要點(diǎn)說(shuō)明下：

• 各個(gè)業(yè)務(wù)系統(tǒng)在推廣、余額等信息變更時(shí)，發(fā)MQ消息，索引更新服務(wù)訂閱MQ來(lái)感知變化，完成增量同步。
• 變更的消息體中，不傳遞實(shí)際變更的字段，僅通知有變化的廣告ID，索引更新服務(wù)實(shí)時(shí)讀取最新數(shù)據(jù)完成更新，這樣可以有效的解決消息亂序引起的數(shù)據(jù)不一致問(wèn)題。
• 當(dāng)更新索引的并發(fā)達(dá)到一定量級(jí)后，可通過(guò)合并相同廣告的變更、或者將倒排和正排更新分離的方式來(lái)提升整體的更新速度。

2. 廣告檢索平臺(tái)的整體流程

廣告檢索平臺(tái)負(fù)責(zé)承接C端的流量請(qǐng)求，從海量廣告庫(kù)中篩選出最合適的前N個(gè)廣告，并在幾十毫秒內(nèi)返回結(jié)果，它是一個(gè)多級(jí)篩選和排序的過(guò)程。

圖7：廣告檢索平臺(tái)的整體流程

Recall層側(cè)重算法模型，Search層側(cè)重業(yè)務(wù)。從下到上，計(jì)算復(fù)雜度逐層增加，候選集逐層減少。(說(shuō)明：搜索廣告場(chǎng)景和推薦廣告場(chǎng)景在某些子模塊上存在差異，但整體流程基本一致，這里不作展開)

性能設(shè)計(jì)是檢索平臺(tái)的重點(diǎn)，通常有以下手段：

• 做好服務(wù)分層，各層均可水平擴(kuò)展。
• 采用Redis緩存，避免高并發(fā)請(qǐng)求直接打到數(shù)據(jù)庫(kù)，緩存可按業(yè)務(wù)規(guī)劃多套，進(jìn)行分流。
• 采用多線程并行化某些子流程，比如多路召回邏輯、多模型打分邏輯。
• 熱點(diǎn)數(shù)據(jù)進(jìn)行本地緩存，比如廣告位的配置信息以及策略配置信息，在服務(wù)啟動(dòng)時(shí)就可以預(yù)加載到本地，然后定時(shí)進(jìn)行同步。
• 非核心流程設(shè)置超時(shí)熔斷走降級(jí)邏輯，比如溢價(jià)策略(不溢價(jià)只是少賺了，不影響廣告召回)。
• 和主流程無(wú)關(guān)的邏輯異步執(zhí)行，比如扣費(fèi)信息緩存、召回結(jié)果緩存等。
• 精簡(jiǎn)RPC返回結(jié)果或者Redis緩存對(duì)象的結(jié)構(gòu)，去掉不必要的字段，減少IO數(shù)據(jù)包大小。
• GC優(yōu)化，包括JVM堆內(nèi)存的設(shè)置、垃圾收集器的選擇、GC頻次優(yōu)化和GC耗時(shí)優(yōu)化。

3. 計(jì)費(fèi)平臺(tái)的技術(shù)方案

計(jì)費(fèi)平臺(tái)也是一個(gè)核心系統(tǒng)，主要完成實(shí)時(shí)扣費(fèi)功能。比如CPC結(jié)算方式下，廣告主設(shè)置的預(yù)算是50元，每次點(diǎn)擊扣1元，當(dāng)扣費(fèi)金額達(dá)到預(yù)算時(shí)，需要將廣告及時(shí)下線。除此之外，計(jì)費(fèi)平臺(tái)還需要支持CPM、CPT等多種結(jié)算方式，以及支持反作弊、余額撞線處理、扣費(fèi)訂單的攤銷和對(duì)賬等功能。計(jì)費(fèi)平臺(tái)的特點(diǎn)是：并發(fā)高、數(shù)據(jù)量大、同時(shí)可用性要求高，需要做到不少扣，不重復(fù)扣。下面以CPC實(shí)時(shí)點(diǎn)擊扣費(fèi)為例，詳細(xì)說(shuō)下技術(shù)方案。

圖8：CPC實(shí)時(shí)扣費(fèi)流程

首先，整個(gè)扣費(fèi)流程做了異步化處理，當(dāng)收到實(shí)時(shí)扣費(fèi)請(qǐng)求后，系統(tǒng)先將扣費(fèi)時(shí)用到的信息緩存到Redis，然后發(fā)送MQ消息，這兩步完成后扣費(fèi)動(dòng)作就算結(jié)束了。

這樣做的好處是：能確?？圪M(fèi)接口的性能，同時(shí)利用MQ的可靠性投遞和重試機(jī)制確保整個(gè)扣費(fèi)流程的最終一致性。

為了提高可用性，針對(duì)Redis和MQ不可用的情況均采用了降級(jí)方案。Redis不可用時(shí)，切換到TiKV進(jìn)行持久化;MQ投遞失敗時(shí)，改成線程池異步處理。

另外，每次有效點(diǎn)擊都需要生成1條扣費(fèi)訂單，面臨大數(shù)據(jù)量的存儲(chǔ)問(wèn)題。目前我們采用的是MySQL分庫(kù)分表，后期會(huì)考慮使用HBase等分布式存儲(chǔ)。另外，訂單和賬務(wù)系統(tǒng)之間的數(shù)據(jù)一致性，采用大數(shù)據(jù)平臺(tái)做天級(jí)別的增量抽取，通過(guò)Hive任務(wù)完成對(duì)賬和監(jiān)控。

4. OLAP海量數(shù)據(jù)報(bào)表的技術(shù)方案

數(shù)據(jù)報(bào)表是也是廣告平臺(tái)的核心業(yè)務(wù)，它是廣告主、平臺(tái)運(yùn)營(yíng)人員進(jìn)行投放優(yōu)化、業(yè)務(wù)決策的依據(jù)。先來(lái)看下廣告數(shù)據(jù)倉(cāng)庫(kù)的分層結(jié)構(gòu)：

圖9：廣告數(shù)據(jù)倉(cāng)庫(kù)的分層結(jié)構(gòu)

• 源數(shù)據(jù)層：對(duì)應(yīng)各種源數(shù)據(jù)，包括HDFS中實(shí)時(shí)采集的前后端日志，增量或者全量同步的MySQL業(yè)務(wù)數(shù)據(jù)表。
• 數(shù)據(jù)倉(cāng)庫(kù)層：包含維度表和事實(shí)表，通常是對(duì)源數(shù)據(jù)進(jìn)行清洗后的數(shù)據(jù)寬表，比如行為日志表、推廣寬表、用戶寬表等。
• 數(shù)據(jù)集市層：對(duì)數(shù)據(jù)進(jìn)行輕粒度的匯總表，比如廣告效果表、用戶行為的全鏈路表、用戶群分析表等。
• 數(shù)據(jù)應(yīng)用層：上層應(yīng)用場(chǎng)景直接使用的數(shù)據(jù)表，包括多維分析生成的各種收入報(bào)表、Spark任務(wù)產(chǎn)出的算法模型特征和畫像數(shù)據(jù)等。采用這樣的分層結(jié)構(gòu)，和軟件分層思想類似，提高了數(shù)據(jù)的維護(hù)性和復(fù)用性。再來(lái)看應(yīng)用層報(bào)表部分面臨的挑戰(zhàn)：聚合維度多，需要分時(shí)、分廣告位、分推廣等幾十個(gè)維度;單表最大達(dá)到百億級(jí)別;支持時(shí)間范圍的實(shí)時(shí)查詢。這部分由公司的大數(shù)據(jù)部門維護(hù)，采用了開源的技術(shù)方案，離線部分使用Kylin，數(shù)據(jù)存儲(chǔ)在HBase中;實(shí)時(shí)部分使用Flink和Spark Streaming，數(shù)據(jù)存儲(chǔ)在Druid中。

寫在最后

本文詳細(xì)介紹了廣告系統(tǒng)的初期架構(gòu)和核心技術(shù)方案。隨著業(yè)務(wù)演進(jìn)，架構(gòu)也會(huì)隨之變得更加復(fù)雜，但是大數(shù)據(jù)存儲(chǔ)、高并發(fā)、高可用，始終是廣告業(yè)務(wù)的技術(shù)難點(diǎn)。關(guān)于廣告系統(tǒng)的穩(wěn)定性保障、廣告策略的可擴(kuò)展性設(shè)計(jì)、RTB實(shí)時(shí)競(jìng)價(jià)的系統(tǒng)架構(gòu)等有價(jià)值的內(nèi)容，后續(xù)再分享給大家，歡迎關(guān)注我的公號(hào)。針對(duì)本篇文章，如果有任何疑問(wèn)或者建議，可以留言討論。

本文轉(zhuǎn)載自微信公眾號(hào)「IT人的職場(chǎng)進(jìn)階」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系IT人的職場(chǎng)進(jìn)階公眾號(hào)。