Categories
程式開發

阿里淘外商業化廣告工程架構實踐


導讀:大型廣告系統工程方面的主要挑戰就是海量數據,快速響應,數據實時和高可用度的要求。本次分享介紹了阿里創新事業群智能營銷平台在如何構建高性能、高可用、高效率,低成本的廣告系統架構方面所做的諸多工作及實踐經驗。主要包括:

❶ 智能營銷平台的業務

❷ 投放引擎的概念以及在廣告平台所處的位置

❸ 重點介紹我們在廣告工程架構中遇到的技術挑戰和解決思路,以及我們的一些經驗

智能營銷平台簡介

阿里淘外商業化廣告工程架構實踐 1

智能營銷平台依託於阿里創新事業群和阿里大文娛的媒體矩陣( 包括神馬搜索、UC 頭條、優酷、阿里文學、PP 助手、豌豆莢等),可以覆蓋1億+的日活用戶,在廣告主側,有10W+ 的活躍廣告主,年收入超過百億,成為阿里淘外變現的主力軍

阿里淘外商業化廣告工程架構實踐 2

我們的智能營銷平台有三大廣告系統:

臥龍:搜索廣告平台,主要承載神馬搜索的搜索廣告業務。

匯川:信息流推薦廣告平台,屬於展示類廣告,主要承載 UC 頭條、UC 瀏覽器以及優酷信息流。

應用分發:應用分發廣告平台。

阿里淘外商業化廣告工程架構實踐 3

這是我們的廣告在媒體上的展現情況:

依託於三大廣告平台,覆蓋了搜索,信息流,網盟,應用分發等多樣的媒體場景,提供了包括CPT,CPC,CPM,oCPC,oCPM,CPA 等多種多樣豐富的玩法,構建了豐富的商業產品矩陣。

投放引擎簡介

阿里淘外商業化廣告工程架構實踐 4

上圖明確了投放引擎在整個廣告平台中所處的位置。可以看到投放引擎屬於偏前端 ( 面向受眾 ) 的位置,直接向廣告受眾 ( 網民 ) 投放廣告,進而產生收益。可以說投放引擎的效果直接影響廣告平台的收益。

❶ 搜索廣告引擎

阿里淘外商業化廣告工程架構實踐 5

搜索廣告架構的典型特點就是系統本身複雜度比較高,簡單介紹搜索廣告的業務流程

用戶在媒體上發起廣告請求( 輸入query ) -> 在UI 接入層完成請求解析-> 獲得用戶畫像-> 對用戶的query 進行query 分析-> 獲取拍賣詞服務,召回相應的拍賣詞-> 在ad 邊做相應的召回和檢索-> 模型算分完成粗排-> 動態創意及商品創意構造-> 模型算分完成精排及定價-> 廣告創意構建及渲染-> 返回給用戶。

與競品相比,我們的特點主要體現在精算能力比較強:通過廣告正排信息下沉到倒排模塊,使得我們的模型精算能力很強,可以計算比較大的廣告候選集( 超過1W ) ,遠超競品,達到了更好的業務效果。

關於我們面臨的挑戰,稍後會詳細介紹。

❷ 展示廣告引擎

阿里淘外商業化廣告工程架構實踐 6

這是我們從0到1實現的一套通用的展示類廣告系統。和其他典型的展示類廣告系統架構類似,分為上層的 SSP,中間層的 ADX,最底層的 DSP。

與競品相比較:

① 我們的架構通用性很好。通過復用該廣告架構,成功支撐了應用分發的變現業務。

② 其次是數據反饋實時性。我們在媒體渠道廣告位、廣告主四層賬戶結構、實驗分桶、展點消等多個叉乘維度上的數據統計實時性,可以做到秒級別,對控制超投和勻速消費等功能,提供了很好的保證。

主要挑戰及解決思路

❶ 主要挑戰

阿里淘外商業化廣告工程架構實踐 7

海量數據規模:百億級的廣告物料數據,1億+的日活用戶產生的用戶行為+基礎特徵+標籤興趣數據,還包括了海量的廣告圖片,創意素材等數據。

高性能:高算力和低延時,通俗的講就是要在盡可能短的時間裡計算盡可能多的候選廣告。盡可能短的時間就是低延時的要求,這裡一般業界都是 200ms 的最大延時;計算盡可能多的候選廣告就是高算力。

高可用:廣告系統的正常運行分分鐘都是錢,需要保證7*24小時的不間斷服務。

迭代效率:是工程架構的水平。籠統的講,就是如何通過組件化,服務化,平台化的思想,提高廣告業務開發和策略迭代的效率。主要包括三方面:

① 業務上:發現業務開發上的痛點、共性點、或未來的瓶頸點,進行抽象

② 代碼上:拆解交織繁雜的代碼邏輯,抽像出基礎公共模塊組件

③ 架構上:抽象統一通用的技術,框架,服務和平台,便於別的團隊或業務使用和擴展

❷ 整體思路

阿里淘外商業化廣告工程架構實踐 8

廣告工程架構整體的思路主要從兩方面開展,分別是業務架構和中台架構。

業務架構:專注於業務賦能和解決業務特有痛點和問題。比如在搜索廣告中會做一些動態創意,商品檢索庫等事情。對於展示類廣告,比如媒體接入平台以及廣告交易平台ADX 等,都是展示類廣告所需要做的事情;另一方面通過針對性的架構優化解決業務的特有問題( 如冷熱庫,定向框架,實時反饋流等),綜合來推動業務的發展。

中台架構:專注於解決廣告業務或者廣告工程所存在的共性問題,通過組件化 -> 服務化 -> 平台化發展來解決。例如:

① 基礎組件:APP 服務框架、特徵統一抽取框架、彈性算力分配框架、Adsindex 組件、RPC 通訊組件。

② 基礎服務:滿足業務海量數據存儲需求的 OLDB 在線存儲系統,以及 MQ 消息隊列服務。

③ 基礎平台:CHAOS 服務治理平台,全鏈路 TRACE 平台,BTS 實驗平台,模型工程平台,一鍵壓測平台,磐石穩定性平台,特徵調研平台。

接下來會從海量數據規模、高性能、高可用、迭代效率四個方面分別談一下我們的解決思路和實踐經驗:

❸ 海量數據規模

阿里淘外商業化廣告工程架構實踐 9

海量數據規模,主要包括3部分:

廣告物料數據:搜索廣告所特有的,對應的解決方案是冷熱分庫。

用戶數據、素材數據:通過 OLDB 分佈式存儲來存儲這些數據。

SESSION 數據:持久化的存儲放在 Hadoop 或者集團內的 ODPS 上,但是如何從檢索系統中實時的獲取到,我們使用的是分佈式消息隊列 MQ。

❶ 冷熱分庫

阿里淘外商業化廣告工程架構實踐 10

背景:冷熱分庫的背景就是在搜索廣告系統中特有的海量廣告物料的快速增長。搜索廣告中物料主要來源於廣告主的四層賬戶物料和拍賣詞,物料的增加主要來自於廣告主的買詞和新增創意行為。可以想像,隨著廣告主規模的擴大,物料一定是海量,並且快速膨脹的。

帶來的技術問題

① 擴容成本高:大家可以看看這張表格,這是17年底的大致情況。隨著機器規模的擴大,以往依賴切庫增加分片擴容的處理方式難以為繼下去。

② 業務迭代慢:數據增長帶來建庫時間的增加,搜索廣告最長的建庫達到14小時,留給業務變更上線的時間很短,一定程度上影響了業務的迭代。

③ 檢索效率低:進一步影響了業務效果。

深入分析

① 無效物料佔比高。這裡的無效是指由於財務,賬戶,審核,投放狀態等原因無法正常投放的物料。這部分物料的佔比達到將近50%,浪費了我們系統的計算資源。

② 物料消費有極度的不均勻問題。我這邊總結就是一百定律。也就是1%的物料占我們整體的消費的將近100%。

解決方案

基於上述兩點信息,我們的整體解決思路就是在拋出無效物料的基礎上,根據價值分對物料進行冷熱物理隔離。加載少量高價值物料的熱集群使用更多的副本更長的截斷時間和截斷數,保證檢索基本不會被截斷;加載其餘低價值物料的冷集群使用更少的副本/更短的截斷時間和截斷數。旨在通過這種方式,使用更少的機器成本承接更多物料,同時提昇在線檢索的有效性與性能,進而實現提升廣告收益。其流程主要分3步:

① 無效物料識別、邏輯刪除

② 物料熱度評估、冷熱分離

③ 物理隔離部署、業務透明

❷ OLDB

阿里淘外商業化廣告工程架構實踐 11

背景:這是我們廣告系統中所面臨的不同的存儲需求,每種存儲需求都有不一樣的數據規模、讀寫要求和更新方式。

原有方案

採用混用存儲中間件的方式,如:

-tair-mdb

優點:內存存儲,同時讀寫,性能高,雙副本,單機有效存儲 0.2T

缺點:成本高

-Redis

優點:內存存儲,讀寫性能高,功能豐富 ( klist )

缺點:成本高,集群支持差

-tair-ldb

優點:SSD 存儲,成本優勢,只讀性能高

缺點:同時讀寫性能差,使用限制多

存在的問題

  • 成本高,資源消耗過大
  • 運維負擔大,頻繁擴容
  • 使用限制多,故障頻發
  • 在線性能差,業務瓶頸

問題總結:混用存儲中間件的方案,無法有效的支持業務的迭代發展。

我們的經驗:有開發過基於 SATA 的圖床存儲系統 OLDB 的經驗。

目標:開發一塊基於 SSD 的在線存儲系統,完成存儲架構的統一。

要求

① 低成本。以 SSD 為存儲介質替代內存,成本縮減

② 高性能。讀寫毫秒級延時

③ 讀寫隔離,實時更新。支持實時更新,支持同時讀寫

④ 功能完善。支持複雜數據結構,如 KV,kList,kCounter 等,支持批量操作

阿里淘外商業化廣告工程架構實踐 12

這裡我們核心是採用了 nrw 機制和短時超時重試機制。使用 nrw 保證數據的一致性,使用短時超時重試來解決 SSD 所存在的抖動問題。

上圖為 OLDB 上線後 ( 和 TAIR+LDB 對比 ) 的使用情況:

容量情況

-集群,44台機器

-使用 400T/總共 700T

訪問情況

-1720億/day

-44MB/s 寫, 120MB/s 讀

業務收益

-統一了存儲架構

-節省了機器成本,1000+

❹ 高性能

阿里淘外商業化廣告工程架構實踐 13

高性能,主要指高算力和低延時,主要包括4部分:

① 基礎組件:RPC、索引、Web 組件、Jemalloc、Pb-arena

② 問題發現:GProfile -> 全鏈路 TRACE 平台

③ 檢索優化:多線程手段、並行化加速、全異步化、應用 CACHE

④ 業務優化:邏輯分庫並行檢索、冷熱分庫、彈性計算框架

❶ 全鏈路 TRACE 系統

阿里淘外商業化廣告工程架構實踐 14

全鏈路 TRACE 系統就是讓我們的系統從黑盒變成透視狀態。早先我們對系統的分析,主要通過壓測、日誌、GProfile 等方式去採集,但是我們基於Google 的論文,實現了TRACE 以後,可以細化到RPC 層或者函數級做監控,計算每個函數或者RPC單次調用的時長,以及匯總調用時長,可以非常方便的發現性能上的熱點。

主要特點

① 高性能,單次插入調用<4μs

② 低侵入,嵌入 RPC 對用戶無感,函數級調用也是通過無參數 SDK 的方式,對使用者非常友好

③ 高精度&業務化,可以重點對整個系統中TP90 或者TP99 這樣高耗時的請求做針對性的分析,發現高耗時的PV 存在熱點的消耗是如何的,而之前更多的是從整個系統角度做分析

④ 高擴展性

TRACE 的目的

① 指導性能優化

② 沉澱優化方法論

❷ 彈性計算框架

阿里淘外商業化廣告工程架構實踐 15

彈性計算框架是廣告業務所特有的一些問題。

背景就是我們如何分配計算資源:

① 流量商業價值不一

搜索廣告:分渠道,分query,價值不一

展示廣告:分渠道,分媒體,分廣告位,分用戶,價值不一

② 作弊 & 抓取等流量耗費計算資源

③ 檢索各階段有截斷需求。比如召回,我們遍歷的廣告數目,還有粗排、精排,我們模型計算的廣告數量,這些都有一些截斷需求。

目標:如何把好鋼用在刀刃上。

方案

① 離線訓練基於 query 的商業價值模型,判斷流量的商業價值

② 作弊和抓取流量識別

上面都是兄弟部門做的事情,對於廣告工程來說,主要是:

③ 確定彈性區域,明確參數設​​計

④ 區分彈性擋位,設定對應參數,對外屏蔽系統複雜度

⑤ 實現彈性計​​算框架,動態參數全鏈路傳遞

⑥ 在線設定檔位,合適分配計算資源

這樣我們用有限的資源,在不同質量的流量之間做平衡,達到 offer 高算力的目標。

❺ 高可用

阿里淘外商業化廣告工程架構實踐 16

高可用,比較清晰,就是發現問題->解決問題->故障恢復,當發現故障時,我們該如何處理,如何快速恢復。這裡說幾點:

① 全方位監控:監控包括基礎的 CPU,內存,網絡,I/O 等監控;業務層的 QPS,水位等;在廣告業務中我們還有一些收入上的指標監控。

② 全鏈路壓測平台:幫助我們找到性能瓶頸,並且探底服務容量。

③ 穩定性平台:提供自動降級功能。如:

  • 提供容災機制的標準規範接入方式
  • 故障場景的數據化表達
  • 故障場景和容災應急預案統一管理
  • 應急預案的自動執行

優化啟動時間:保證在故障出現的時候,能夠快速的恢復。

❻ 高效率

阿里淘外商業化廣告工程架構實踐 17

迭代效率是工程架構的水平。籠統的講,就是如何通過組件化,服務化,平台化的思想,提高廣告業務開發和策略迭代的效率:

① 業務上:發現業務開發上的痛點、共性點、或未來的瓶頸點,進行抽象。

② 代碼上:拆解交織繁雜的代碼邏輯,抽像出基礎公共模塊組件。

③ 架構上:抽象統一通用的技術,框架,服務和平台,便於別的團隊或業務使用和擴展。通過模型工程平台解決特徵優化,模型優化等問題

通過向量檢索平台解決向量建庫,線上檢索召回等問題

通過服務治理平台解決資源管理,應用管理,數據管理,監控報警等問題

❶ 模型工程平台

阿里淘外商業化廣告工程架構實踐 18

首先明確下特徵工程的概念和重要性,引用 Andrew Ng 的一段話 “基本上,所謂機器學習應用,就是進行特徵工程”,Andrew Ng 說的話雖然可能有些絕對,但也從一個側面說明了特徵工程的重要性。

工程架構實際上是如何讓特徵工程更加高效。

阿里淘外商業化廣告工程架構實踐 19

特徵這塊最主要的問題就是抽取邏輯分散:在線,離線,實時這三個場景下我們有三套不同的抽取邏輯,並且因為可維護性比較差,在離線抽取特徵的結構存在著8%的diff,這就導致後續幾乎所有的特徵調研都走的是在線抽取+落日誌的這種抽取方式,對業務的影響就是特徵調研需要攢數據,週期長並且效率低。

這塊我們的解決方式使用過 lib 的方式做了邏輯封裝,一套代碼,到處使用,統一了特徵計算邏輯。

阿里淘外商業化廣告工程架構實踐 20

再有就是特徵邏輯複雜,在線抽取性能差的問題,這導致了我們的很多特徵技術即使調研完成後很有效果,也因為在線性能的原因難於全量上線。

對於這塊的我們主要通過特徵計算離線化的方式進行優化,大家可以看一下我們系統中用到的主要特徵,例如用戶特徵,query 特徵,拍賣詞特徵,ad… 這些特徵都是單體特徵,對於這類特徵,我們通過離線計算,在線獲取的方式進行了優化,對於組合特徵,我們離線計算好中間結果,只對最後的combine 環節做在線計算,最大優化性能。此外,我們還通過插件配置化的定義特徵獲取的方式,提升了這塊的工作效率。

阿里淘外商業化廣告工程架構實踐 21

對於多模型的特徵使用問題。以我們的臥龍系統為例,比如我們的 root 模塊和 ad 模塊,都使用到了廣告特徵,屬於同類特徵。但 root 的 dsa 模塊中廣告特徵的抽取邏輯和 ad 模塊中的抽取邏輯由於歷史的原因可能不一致,這就是同類特徵的未對齊問題。還有就是即使特徵的抽取邏輯完全一致,但實際上也是重複抽取了兩次,存在冗餘的計算。

對這塊我們主要通過強化特徵管理,形成了統一的特徵體係來解決,相同的特徵會在模塊間傳遞,避免重複抽取。

阿里淘外商業化廣告工程架構實踐 22

還有就是我們提供了一套簡單的離線特徵評估工具,可以基於小樣本集評估特徵的質量,避免把所有特徵調研的驗證工作都帶到線上。

阿里淘外商業化廣告工程架構實踐 23

最後就是在線預估部分,我們通過lib 封裝了在線預估的邏輯,內部使用名字服務確定模型到具體機器的依賴,並且做了並行等加速優化,將在線預估以服務化的方式輸出,對應用方屏蔽了具體部署的細節。

阿里淘外商業化廣告工程架構實踐 24

模型工程平台小結,如上。

阿里淘外商業化廣告工程架構實踐 25

通過模型工程平台化的管理,在整個模型工程的離線處理從日誌處理->特徵處理->樣本處理->模型訓練->模型評估,做了集中化的管理和可視化的操作;其次,我們打通了在離線的流程,比如使用者在模型訓練出來後,可以一鍵上線;最後,模型工程平台成為我們沉澱工作方法和成果的平台。

❷ 服務治理平台

阿里淘外商業化廣告工程架構實踐 26

最後是我們的服務治理平台,在容器層主要使用的是Docker,一層調度主要使用的是K8S,二層調度使用的是ChaosEngine 和本地數據管理器,很好的支持了資源調度、彈性伸縮、服務治理、數據管理、應用管理等。通過服務治理平台,我們的上線效率,數據管理,擴容效率相比之前有了很大的提升。目前,服務治理平台不僅僅是一個提效平台,也在做一些如成本優化方面的工作。包括:在線和離線的混部;在線業務潮汐的伸縮容,彈性伸縮,將節省出來的機器應用到模型訓練所需要的 MPI 集群和 Hadoop 集群等等。

作者介紹

項錚,阿里巴巴 | 高級技術專家

本文來自 DataFunTalk

原文鏈接

https://mp.weixin.qq.com/s/V7_I2QzEDGbQ9tYIxidUbw