美團廣告平臺擁抱資料實時化趨勢

本文根據劉翀在【第十三屆中國資料庫技術大會(DTCC2022)】線上演講內容整理而成。

講師介紹：

劉翀，美團廣告平臺數倉團隊負責人，專注於資料倉儲、資料治理等領域，曾就職於騰訊、美團等廣告資料開發團隊。2020年入職美團，致力於廣告資料開發和團隊管理工作，透過資料促進廣告業務目標的達成。

內容摘要：

資料實時化是數倉建設的趨勢，相對於離線數倉，實時數倉能夠給管理者、業務分析人員提供反應業務變化的實時資料，監控收入等關鍵指標的波動，及時根據市場熱點變化調整運營策略，透過實時演算法決策，提供更加滿足使用者需要的服務。

本次分享的實時數倉建設實踐，主要包括：

1、網際網路廣告業務介紹;

2、實時數倉模型、指標的建設規範;

3、實時數倉開發技術;

4、全鏈路的質量保障方案;

5、實時資料在廣告場景下的應用。

正文：

1、什麼是廣告實時資料?

在網際網路廣告業務中，參與方主要包括三方：廣告平臺(主要是各大網際網路公司的一些廣告平臺)、C端使用者、B端廣告主。

其中，網際網路廣告業務更偏B端，而B端廣告主向廣告平臺提出自己的營銷訴求，並且設計投放，把自己的廣告展示在各種C端產品上，然後在C端使用者點選各種產品、商品、服務之後，把B端廣告主的一些服務觸達到C端客戶，進而完成一些營銷訴求。

在網際網路廣告行業中，C端目前主要包括APP端、小程式端、PC端以及其他端。目前，移動網際網路APP端佔了營銷的絕大部分比例。有資料統計：在移動網際網路APP端，廣告收入佔到89%，小程式、PC等各端基本上只佔了10%左右的收入水平。

而在早期網際網路階段，PC網際網路行業廣告收入佔比更大一些，廣告平臺主要有如下幾大系統：

1)CRM系統，主要做客戶關係管理，也就是對廣告主進行管理。

2)投放系統，把廣告主的廣告、素材、營銷訴求投放在各個C端，之後有一些計費系統，對廣告主投放的廣告進行實時計費。目前，行業內比較多的是OCPX廣告。

3)運營系統，主要是在廣告投放完之後，內部一些運營銷售人員對廣告投放效果進行運營分析、對廣告主流程運營工作。

4)財務系統，主要是透過廣告計費系統和公司財務結算考核系統進行對接。

5)營銷系統，主要是創意製作平臺以及廣告主透過這些創意來製作自己的廣告。

對於廣告主而言，主要營銷訴求，除了展示廣告，更看重營銷效果，比如：透過一些商品和服務售賣、轉化情況，來衡量自己的廣告投放效果。

具體來說，對於網際網路廣告行業而言，實時資料的應用價值包括三塊：

第一，實時資料視覺化。

和離線資料視覺化比較類似，實時資料視覺化，是指透過KPI實時看板檢視資料，視覺化核心點是視覺化KPI實時資料，演算法團隊包括CTR、CPR資料。

廣告投放看板，面向B端廣告主，廣告主也要知道自己投放廣告的效果，尤其像6.18、雙11、雙12這些網際網路電商節，他們需要評估自己投放廣告的效果，瞭解投放廣告之後客流轉化情況，以便及時調整預算，進行營銷策略最佳化。

第二，監控和診斷。

首先，實時資料KPI監控要求與離線資料不同。一些離線資料的監控基本是T+1，所有廣告投放效果都需要等到一天後才能夠獲得，但是實時資料更強調實時。

另外，異常分析能力要更強。當一般結果符合預期時，是大家比較希望看到的。當結果不太符合預期時，比如上了一個演算法，但是預期收入是上漲的，但實際收入可能持平，甚至可能下降，這種情況下，就知道存在一些異常，針對異常就需要進行一些診斷和分析。

透過診斷和分析能夠儘快止損，避免有問題的策略和營銷方式、手段線上上存在。不僅對廣告平臺如此，對廣告主而言也依然如此。透過實時監控和診斷，廣告主可以更快速地瞭解自己投放策略的效果，尤其相對大的品牌廣告主而言，實時化需求更強烈。比如：聯合利華、寶潔這些公司營銷團隊，都會有專門的廣告投放部門，都會分析自己的實時投放效果，來進行實時策略的最佳化，避免自己營銷預算浪費。

第三，演算法智慧決策。

問題是，沒有專業營銷團隊的廣告主，應該怎麼辦呢?

目前，網際網路廣告行業除了大的頭部廣告主，比如寶潔、聯合利華、可口可樂這些公司，有專業的廣告投放營銷策略團隊，有廣告投放製作和最佳化能力，大量中小行業的廣告主沒有自己的營銷團隊，比如：一些街邊攤或路邊餐飲店，在投放策略最佳化和創意製作能力方面比較弱，需要依賴廣告平臺提供的實時服務為業務賦能，比如：透過實時的智慧的出價最佳化、創意製作、創意最佳化能力，提升廣告主在廣告平臺操作體驗，獲得更好的效果。

實時資料相對離線資料而言，時效性肯定更強，能夠幫助平臺和廣告主更快地感知到實時資料的效果和策略的效果，來進行快速止損以及獲得更大的業務機會。

2、實時數倉開發規範有哪些?

1)實時數倉分層規範

離線數倉一般會分DWS、DWD、DIM層，實時數倉依然需要分這幾層，是和離線數倉原因一樣，透過分層來實現指標口徑的統一、計算效率提升。

實時數倉分層相對離線數倉而言，主要是業務系統的原始資料，ODS層包括埋點日誌，包括業務系統記錄日誌，包括訂單記錄，透過MySQL binlog產生。

DWD實施明細層，主要對原始資料進行資料清洗和過濾，還有關聯和維度擴充套件，包括資料驅重處理等。

DWS層，主要進行輕度彙總寬表，這一塊分層核心價值體現是，主要提高資料易用性和指標一致性。

DIM實時維表，離線資料維表基本上都是取的一天全量的狀態，甚至很多時候取的是當天最後一次狀態，比如：投放過程中間，投放有暫停、開啟、每天投放還可能會設定不同的出價，對於離線維表時，每一個投放只有一個唯一的出價、創意和狀態;對實時維表，能反映當天投放實時出價情況、創意情況以及狀態情況，有暫停狀態還是開啟狀態。經常在發現實時資料和離線資料不一致的地方，很多情況下都是因為維度狀態變化導致的，比如：一個投放，當天看來是在離線時最後一次是暫停的，但是在實時時，可能今天開啟了3次，暫停了4次，最後變成了暫停。如果計算過程中取投放的線上狀態，可能在離線時這個投放就不是一個線上狀態，導致消耗等核心指標計算的缺失，但在實時時，因為是實時的狀態，投放一些消耗資料就不會出現丟失的情況。

而在APP上層一些產品應用端，就需要根據各個資料產品的需要來加工出各種應用的資料。

2)實時數倉開發技術

在ODS層，主要包括Kafka和Binlog。Kafka主要存放使用者行為日誌實時流;Binlog儲存業務系統資料庫記錄實時流，包括投放狀態，投放計費資訊。

DW數倉模型層，核心技術主要包括Flink，支援狀態和SQL方式開發的高效能實時計算引擎，早期實時資料計算方式主要採用Stom(音)，原生版本不太支援SQL計算，開發效率和開發複雜度相對比較高，但是FLink除了底層支援一些API方式開發，還能在高層能夠支援SQL的開發方式。換言之，實時數倉開發方式和離線開發方式比較接近，能支援更高效的開發，而且對於資料邏輯的開發和維護相對來說比以前Java、API開發方式更為高效，任務管理方式也變得更加高效。Tair，是美團內部用來儲存海量資料的KV引擎，在實時數倉開發過程中，利用Tair，建設一些實時維表，實時維表和離線維表具有比較大的差異性。

APP應用層，主要是Doris和Blade。Doris是一些海量資料中低效能查詢的OLAP引擎，在實際測試過程中，當資料量比較大，比如：每天資料量在千萬級甚至超過億級時，OLAP產品效能只能達到QPS在100以內，與Doris查詢引擎的查詢計算方式有關，裡面存在非常多的執行緒搶佔，任務計算時會有非常多計算資源搶佔行為。Blade是海量資料高效能查詢的HTAP引擎，是美團內部進行自研並且非常多改造的產品引擎，這個產品引擎因為是分散式的，而且資料量非常大，對於我們目前資料服務而言，我們在廣告資料服務基於Blade資料儲存規模超過百T，基本是資料量非常大的情況，很多資料都是超過百億級。

實時數倉開發技術相對離線數倉而言，資料用的技術相對比較多一些，對於離線數倉開發時，技術早期主要是Hive儲存引擎、計算引擎，後來因為計算效能提升的動作，大家可能會引用一些Spark產品引擎。但是在實時數倉過程中，儲存可能用了Kafka，甚至Tair這樣一些儲存引擎，但是在計算層面，除了用Flink，很多公司依然會存在一些別的計算引擎，比如：Storm支援SQL的版本。在應用端，應用層資料很多時依然會選用Doris、Blade等。

我們把實時數倉規範的設計和概念，與實時數倉的一些實現進行分離，我們不認為所有的實時數倉都基於Kafka，實時數倉有一些儲存和計算可以用不同的技術和方案實現。

3)實時資料開發的質量保障

如何保證實時資料開發質量?主要包括事前預防、事中測試、事後監控!

如何理解事前預防?

在開發規範設計時，首先要進行技術選型，包括實時數倉分層、命名規範。

同時，還涉及運維規範，主要包括任務分級，以及不同分級情況下的故障處理方式、流程、報點機制等。

另外，還有模型對齊，指在開發實時資料過程中，實時資料和離線資料的對齊。實時數倉和離線數倉建設過程中間，受制於計算方式不同，以及資料的實時性不同，經常出現適時資料和離線資料不一致的問題。從兩組模型差距來看，各自資料都是準確的，只是因為資料實時行不通，導致有一點差異。所以在事前做技術方案時就要確定在事實時據和離線資料的對齊方式和差異的合理性。

什麼是事中測試?

開發測試，需要實時數倉建設非常多的測試運力，來覆蓋各種可能出錯的場景，在上線前把一些未知問題儘量避免。尤其像廣告資料，因為面向廣告主，有很多實時資料需要提供給廣告主，廣告主投放廣告之後需要知道效果，這個資料要準確，否則影響到廣告主廣告投放資料的最佳化，我們需要透過測試保證資料異常能夠儘量在上線之前避免。

主備鏈路，主備鏈路最好能進行物理隔離，當遇到機房故障、裝置物理故障時，直接能夠把資料切到備份鏈路，包括線上實時資料的穩定性。

峰值壓測，隨著業務量，比如雙11秒殺等活動，會遇到流量突增情況，對於這種場景，需要保證業務穩定性時，還需要對鏈路峰值處理能力進行壓測，保證6.18、雙11時能夠平穩渡過一些高峰時間，保證資料穩定性。

為什麼要做事後監控?

分級運維，對於P0級任務就需要測定一些故障響應時間，如報警機制、值班機制，包括資料延遲監控，不同優先順序任務延遲可接受範圍不一樣，面向廣告主資料或KPI看板資料，會有一些延遲，比如5分鐘以內。

資料監控，是指是否存在資料異常下跌或掉零、突增等情況，這種資料本身可能不是因為實時資料開發過程引入的，是業務過程引入的，比如C端一些入口倍增或突發事件、業務變動導致異常上升下降，或發板導致資料出不來等問題，透過實時資料能艦空導這些異常資料指標的波動，及時感知到業務的問題，也是實時資料在止損方面一些突出的價值。

4)實時資料指標的開發流程

一般在實時資料開發過程中，會先確定一些實時資料的口徑、定義，經過技術方案評審、程式碼開發、資料邏輯測試、效能壓測，質量保障監控等方案，最終上線。覆蓋了剛剛提到的事前、事中和事後的過程。其中，資料技術方案是比較核心的部分。

資料技術方案主要包括：

模型規範，比如模型分層方式是什麼樣的;

指標規範，比如指標怎麼樣和離線進行對齊、指標命名方式、指標定義方式;

儲存和計算引擎的選擇，比如儲存，在應用層是選擇Blade還是Doris、ES、Flink等，目前主流應該都是用Flink。Flink+Kafka計算方式依然會出現一些問題，比如Kafka資料其實不太好查，資料開發過程中間，對於測試環節相對複雜，因為Kafka資料不查，要把Kafka資料匯出到Hive等可查的一些查詢介質上才能進行開發測試;

質量保障，包括核心指標異常波動範圍，比如收入可能波動10%~20%就是比較異常，對應異常需要識別出來，並且監控出來，讓問題能夠及時感知到，進行止損。

3、在廣告實時資料開發實踐過程中有哪些關鍵點?

1)實時任務

在美團內部自建了一個實時數倉開發平臺，能進行實時數倉任務開發，能夠進行程式碼的編輯、作業的管理、模型的管理，以及實時數倉函式的管理。

除了程式碼和任務管理之外，這個平臺也能夠進行實時數倉任務的除錯、校驗，還能進行一些作業運維能力，包括任務重啟、下線，以及任務引數，比如併發度、記憶體等引數的調整，這個平臺也能進行作業版本的管理等。

2)資料血緣

任務血緣管理，除了任務本身作業程式碼以及運維能力之外，還能夠在平臺上看到任務血緣，包括這個任務上游接的是哪些維表，接了哪些計算任務和計算模型，以及它的下游匯出到哪些儲存引擎上，並且這個模型涉及一層血緣、二層血緣和三層血緣等，以及資料儲存格式，到底是Json格式還是其他格式。

3)資料視覺化

絕大部分資料開發工作都是直接面向資料視覺化的，在離線要建設各種各樣的一些資料看板，以及自助分析工具、自助看板工具等，在實時數倉開發過程中也一樣，也需要進行一些資料視覺化，相對於離線數倉而言，實時數倉可能有一個顯著特點，資料維度比離線更細，實時資料維度或資料時間序列維度基本上都是到分鐘級，對離線數倉而言資料維度很可能是天級，最多可能就是小時級。

比如：在CPM熱實時場景，包括一些資料級命名規範，有熱實時、熱離線、冷實時、冷離線等，熱實時上可以看到實時資料CPM的曝光消耗基本會存在早上11點是高峰，以及下午5~6點左右是高峰的場景，可能早上高峰更多一些。

4)流量異動監控

對比有效曝光，今天資料、昨天資料和歷史資料，從昨天和歷史資料來看，在11~12點之間相對比較平穩的波動，但是今天資料會存在異常的上升，這個地方肯定就會存在一些問題。問題可能原因是，異常活動輸入，某一個活動導致流量突然上升，還有可能是平臺工具穩定性導致的，比如資料重複發生，或者重發，所以在DWD層需要進行一些實時資料的去重，因為離線去重相對比較簡單，實時資料的去重就需要我們進行前期的去重，避免平臺穩定性導致資料重發，導致資料計算指標的異常。

如果這個資料因為平臺穩定性導致資料重發，不在計算過程中間處理這個問題，這個資料就會暴露給KPI的核心監控看板以及廣告主實時資料感知，他們感覺到自己曝光突然莫名其妙上升，會導致CPM異常下降，如果這個資料不加判斷就使用的話，當前拿到廣告價格好像下降了，是否可以加大投入。事實上，是因為我們資料錯誤，如果因為這種原因導致決策成本和沉默成本等投入，就會出現廣告主和平臺扯皮，甚至會引起後續大量的客訴風險。所以，核心資料的監控是非常有必要的，因為很多問題可能在制度設計方案層面不一定能完全考慮到。

5)消耗異動診斷

可以讓異常資料診斷變得更加實時，能夠及時止損，帶來一些成本和消耗的減少，讓整個業務變得更加平穩。

例如，美團內部有一個系統能夠檢測到消耗資料的異常下降，並且能夠基於消耗資料的下降來進行實時診斷。

廣告決策和效果都非常依賴於資料，而且這些資料能夠進行非常好的指標拆分，比如廣告這邊有一塊計算廣告學，主要是解釋一些廣告指標的拆分方式和實現原理。如消耗指標=點選×acp，點選=曝光×ctr×acp，看每一個指標對於異常下降貢獻率。如圖，曝光的下降，點選也會下降，點選下降，平臺召回的pv也會下降，一般越是靠近整個廣告鏈路上游，指標的波動對整個影響貢獻是越大的。對於這種情況來說，整個消耗下降主要來自於召回pv的下降，就需要排查召回的系統，為什麼召回的廣告變少了。這是一個視覺化的展示異常診斷的過程，實際系統中間，會建設一些指標貢獻度的情況，會透過系統，根據一些指標的拆解以及指標貢獻度，能夠自動去提示和診斷出一些消耗等核心指標波動的原因，加快異常診斷的速度。

6)智慧調價

實時資料核心價值和能力還包括智慧調價，如網際網路廣告行業，很多廣告主其實不能像可口可樂或寶潔、聯合利華等廣告主一樣有自己的營銷團隊和廣告投放團隊，而且這個團隊非常專業，基本上會從各個廣告平臺去拿到自己的資料來進行自己策略的分析和投放的最佳化。

現在頭部廣告平臺基本上廣告主規模都是在幾十萬的水平。問題是，這些廣告主有多少是寶潔和可口可樂這種大的廣告主?事實上，絕大部分都是一些中小廣告主，可能大家對中小廣告主的定義不同，有些公司中小廣告主規模是每天消耗在幾千元左右，有些公司可能在幾百元左右，這些小廣告主沒有自己專業的營銷團隊。

對廣告平臺而言，不能只是說收廣告主的一些錢，依然要代表廣告主的利益，幫廣告主去實時最佳化自己投放的效果，但是因為廣告平臺面對的是幾十萬相對來說海量的廣告主，不可能為每一個廣告主進行實時策略的最佳化，不可能靠人工方式去做，所以需要在綜合評估整個平臺的生態以及廣告主利益情況下，動態調整廣告投放策略。一個廣告平臺廣告主量非常大，大家透過計價方式，對於平臺而言，大家出的價格肯定越高越好，但是對於整個生態而言並不是如此，我們需要代表廣告主的利益，要讓廣告主出相對合理的價格拿到更有價值的量，核心部分就是出價。

曾經，某公司的一些競價排名策略在整個行業裡深入人心，現在很多廣告主非常能夠接受這種競價排名方式，但是有很多中小廣告主其實沒辦法全天候盯著廣告的出價，所以平臺就能夠利用一些實的資料，比如今天流量的消耗情況，以及大家出價情況、競爭激烈程度等，來進行一些智慧調價。智慧調價的核心包括出了什麼價，預估能拿到多少量，多少轉化效果，這是比較核心的能力。所以對於廣告平臺而言，實時資料非常有應用價值的場景就是能夠幫廣告主進行智慧調價，節省廣告預算成本，提升效果，讓整個生態和廣告主體驗變得更好。

4、未來何去何從?

如前文所述，在廣告實時數倉開發技術規範和方案時提到，一些當前實時數倉建設方案的問題，目前各公司在實時數倉建設方式主要採用的是Lambda架構，其顯著問題是實時資料和離線資料是分開建設的。面臨非常大的問題就是實時資料和離線資料不統一，計算邏輯兩套程式碼邏輯維護，包括Kafka裡資料不可查，以及開發測試運維成本投入較大的情況。當然，也有提出Kappa架構，所有資料都實時化，開發運維成本也相對比較高。

基於這些運維成本的問題，目前各大網際網路公司基本探索的方式，主要是透過流批一體方式，可採用的架構主要是Lambda+Hudi等計算方式。實時數倉流批一體架構目前並沒有得到廣泛應用，有些公司有一些嘗試，大家希望能透過流批一體解決的問題包括能夠統一計算、統一儲存，這樣的方式可以讓整個開發和測試能夠進行提效，尤其是Kafka的資料不可實時可查，測試過程相對比較麻煩。最大一個好處和應用價值是指標的一致性，避免維護、實時離線兩套邏輯，開發過程和運維成本能夠相對降低。