Categories
程式開發

解密商業化廣告投放平台技術架構


導讀:互聯網廣告是流量商業變現的重要途徑之一,涉及服務平台、檢索引擎、算法策略、數據工程等多個方向。本次分享的主題為商業化廣告投放平台技術架構,分享的內容集中在工程領域,結合業界廣告投放平台的通用技術範式,分享智能營銷平台是如何打造高性能、高可用、可擴展平台架構的,從服務化、數據傳輸分發、廣告投放引擎、計費、海量數據實時報表等方向切入,深入淺出的闡述一套最佳實踐。

——業務介紹——

1. 廣告業務簡介

解密商業化廣告投放平台技術架構 1

商業化是互聯網公司營收的重要來源,業界比較大的商業化產品有Google AdWords、Facebook Ad、百度鳳巢、頭條巨量引擎、騰訊廣點通等產品,阿里電商場景的變現平台是阿里媽媽。目前國內互聯網廣告的營收年規模達數千億元。

廣告平台一般由三方組成:網站主、廣告主、用戶。

  • 網站主:有流量資源的變現需求。
  • 廣告主:有投放預算,希望在流量資源上找到合適的人進行推廣。
  • 用戶:得到更好的廣告推薦結果。

2. 智能營銷平台簡介 & 通用的廣告系統組成

解密商業化廣告投放平台技術架構 2

阿里創新事業群智能營銷平台的主要流量構成包括:神馬搜索、UC 瀏覽器、UC 頭條、優酷、阿里雲 OS 以及手機廠商、網盟第三方流量等。

通用的廣告系統組成如右圖,主要包括4部分:投放平台、廣告引擎、算法策略、數據平台。

運轉的流程如下:

首先,廣告主有一定的預算,選擇在什麼樣的流量上投廣告,這樣就有了輸入;然後存廣告,通過投放平台來完成,把投放所需的設置、預算、創意等數據實時傳輸到檢索系統;每當用戶發起一次檢索請求時,簡單來說後台相當於做召回+優選,把最合適的TOP 候選廣告返回給用戶;還有一部分是計廣告,通過數據平台來完成;最終廣告主來查廣告績效展點消數據。

本次分享主要聚焦在如下5個環節:

解密商業化廣告投放平台技術架構 3

——投廣告——

業務微服務化構建

第一,來看如何投廣告,包括無狀態的服務層,來滿足廣告主進行預算設置、存廣告、建創意等操作訴求。

1. 單體模式到微服務化 ( MSOA ) 的過渡

解密商業化廣告投放平台技術架構 4

任何一個大的產品,都會遇到從單體過渡到微服務的過程,其架構的實施方法論落在三個字:分、合、細:

  • :分化、隔離、獲得技術、業務上的縱深和彈性。
  • :隨著業務的增長,要加大復用度,歸併同類項。
  • :細化分工、架構,深入優化技術&業務。

當業務發展到足夠大的時候,最終會採用 MSOA 架構。

分合細的基礎在於:如何把這些服務給拆開,對於投放平台來說,需要對投放需求進行規範化的表達和產品功能的標準化設計。把這些領域模型建起來之後,服務自然就有了劃分的依據。

2. 微服務化分層體系建設

解密商業化廣告投放平台技術架構 5

上圖為拆分之後的投放服務架構圖,水平拆分成簇,縱向拆分成層。外層是API 和WEB 端,進行相應的權限驗證、流控等;中間為計算層,細分出來各個服務,包括面向業務流程處理、業務邏輯組件以及公共服務組件三層;最底層是基礎設施和數據資源。把所有的服務串聯起來的就是分佈式服務化框架。

3. 微服務化與服務治理

解密商業化廣告投放平台技術架構 6

做平台方向的團隊可能需要幾十人上百人,而服務則可能有幾十上百個,它們所組成的網絡會非常混亂,最終難以治理。我們需要具備服務治理能力的微服務化框架來解問題,包括 ( RPC 框架 )( 服務治理能力 )

4. 分佈式服務化框架一覽

解密商業化廣告投放平台技術架構 7

業界的分佈式服務化框架一覽,如上圖所示。這裡有的是 RPC 框架,有的才是真正合格的服務化框架,對於投放平台,需要的是一個服務化的框架。我們拆分來看,先認識下 RPC 框架:

① 體系化認知 RPC

解密商業化廣告投放平台技術架構 8

RPC 體系的腦圖如上所示,作為 PRC 框架應具備如下功能:

  1. 傳輸方式:我們要看是採用的傳統 TCP 或者 HTTP 技術,還是運用的最新技術,如阿里很多基礎產品是用 RDMA 網絡的,或者採用一些用戶態的協議,不走 TCP 協議,來做 kernel bypass。
  2. I/O 模型:是採用同步還是異步的,可以選用Blocking IO 或者Non-blocking IO,I/O 多路復用最有名的是基於epoll 的,大部分走TCP 協議的都採用的是epoll;異步的AIO 網絡通信在Windows 下用的比較多,在Linux 上AIO 主要應用在磁盤IO 相關。
  3. I/O 線程處理模型:可以分為單線程、多線程,以及各種 pattern,大多數情況下都會選擇 Reactor pattern,基於 I/O 多路復用 epoll 這種形式。
  4. 協議棧:數據可以點對點傳輸之後,如何識別這些數據,主要就是協議棧的工作。大多數框架都採用基於 header+payload 的方式。
  5. 序列化:當點對點的實時的識別出一個具體的包之後,需要序列化的解析包裡的數據。
  6. 連接可靠性和易用性:可以快速的傳輸和識別包之後,還要面臨可靠性的保證,以及暴露給上層的調用方式,如何更好的調用服務,是用同步、異步,還是泛化調用類似的問題是需要考慮的。

這些範疇,共同組成了 RPC 體系,但是光有這些是不足的,最終還要落在服務治理上:

② 服務治理能力

解密商業化廣告投放平台技術架構 9

服務治理能力包括

  • 通信傳輸:這是最基本的。
  • 服務發現:包括服務註冊,自動的下發和發現;客戶端路由的規則,是同機房路由還是打標分組路由;以及負載均衡的策略,是RR 還是Random 等;有了這些之後,可以做服務的拓撲和強弱依賴分析。
  • 監控度量:從 logging、tracing、metric 三個維度進行監控。
  • 健壯容錯:如何 design for failure 做處理異常,做服務的降級和限流。
  • 契約管理:管理服務的 IDL 以及進行兼容性分析。
  • 持續交付:開發測試,整個應用的生命週期管理,更多的是與 PaaS 平台相結合。
  • 安全保證:應用鑑權、服務鑑權、用戶鑑權、傳輸加密等。

通過這些模塊,共同構成了服務的治理。

現階段我們的服務治理方案如下

  • 服務化框架:HSF
  • 容器隔離:Pandora-boot
  • 配置管理:基於 Diamond
  • 監控度量:Metrics+Tracing+Logging ( ARMS+SLS+鷹眼 )
  • 健壯容錯:Sentinel
  • 基礎設施:基於 K8S 的雲平台
  • 持續交付:基於 Aone 的 Paas+CD 平台

發展未來上來看,雲原生是一個方向,代表了先進的生產力,這當中服務的架構設計、開發交付都會被重塑,一些變化主要在於

  • 資源效率:重點在於容器化、調度、混部。
  • 開發效率:注重編排、敏捷 CI/CD;Service Mesh、Serverless 等基礎設施的下層和 business logic focus 的專注。
  • 標準與開放:開源、社區和生態的建設。

個人理解:萬變不離其宗,雲原生解決的問題覆蓋了服務治理,天然的利用 “雲” 去解決,而非某個框架或者 vendor lockin 的能力

——存廣告——

OLTP 海量數據存儲

1. 廣告數據存儲

解密商業化廣告投放平台技術架構 10

數據存儲可以看做有狀態的存儲層,要把這些生產資料,存在廣告系統中。我們採用的是多模數據存儲的方式,OLTP 大部分都是 MySQL 分庫分錶,OLAP 有相應的報表平台,非關係型的有 OSS、KV 存儲以及基於 ES 的全文檢索。

2. 體系化認識數據庫

解密商業化廣告投放平台技術架構 11

如果數據庫從0到1開始做,最簡單通過一個文件把相應的字段存起來,可以用到的數據結構有:Hash,Binary Tree,B+Tree。但是採用這些方式,會面臨著不同的時延問題,如圖所示:訪問內存大概是 100ns,訪問 SDD 大概是 16μs,但是一次 Disk seek 需要 3-10ms。所以,為了減少隨機 IO,Hash 和 Binary Tree 都是不合適的。因此,有了 B+Tree 這種 MySQL 使用的索引數據結構。

① MySQL InnoDB 引擎

解密商業化廣告投放平台技術架構 12

我們大部分數據都是 MySQL 存儲的,且採用的是 InnoDB 引擎,主要面向的是 OLTP 場景。 InnoDB 引擎是行存,多行組成一個 Page,多個 Page 組成一個 Extent,而每個索引的葉子節點和非葉子節點又由 Segment 這個概念維護,最終形成了一張表 ( tablespace )。每次檢索實際就是按照剛剛提到的 B+ Tree 做點查或者範圍查詢,可以走 clustered index 或者 secondary index 或者 full scan。

我們不止要把數據存起來,還需要有SQL 和ACID 功能,Durability 是靠Redo Log 來做的,保證數據不丟失;還要滿足Isolation,也就是事務之間是有並發的,並且要進行隔離,不能互相影響,採用Undo Log+MVCC 機制來實現。 InnoDB 還有很多好處,比如它是基於行鎖的,有索引的支持等。右圖為 MySQL 官方的架構圖,大家可以官方查詢下資料。所以,通過 MySQL 可以把廣告數據高並發、可靠的持久化存起來。

② 阿里云自研 X-Engine 引擎

解密商業化廣告投放平台技術架構 13

在海量數據高 TPS 場景下,阿里也在做一些優化。這裡介紹下X-Engine 引擎,阿里在SIGMOD 2019 發表的一篇論文:《X-Engine:An Optimized Storage Engine for Large-scale E-Commerce Transaction Processing》,X-Engine 可以實現超高並發事務的讀寫,可以達到65w/Write Per Second,讀的話和InnoDB 差不多,主要是優化寫的方向;可單獨作為單機MySQL 或者分佈式數據庫PolarDB X 存儲引擎。馬上在阿里雲上就可以看到雲上產品。 X-Engine 的創新點,如圖所示,這裡不再細說。

3. 數據庫存儲架構

① 可擴展

解密商業化廣告投放平台技術架構 14

剛剛介紹了存廣告的基礎,由於廣告產品產生的數據量非常大,尤其是搜索廣告的關鍵詞維度,基本都是百億的量級,如何做擴展,是一個很重要的問題。常用的解法是分而治之,做垂直拆分和水平拆分。

我們是基於 TDDL ( 雲上產品 DRDS ) 的解決方案,來做分庫分錶,讀寫分離,主備切換以及鏈接管理的。

② 高可用

解密商業化廣告投放平台技術架構 15

對於數據庫高可用的保證,常常採用:

  • 異地高可用:兩地三中心( 如左圖,主庫和備庫都在同一個Region B 中,但是它們分了兩個機房來做相應的同步,同時通過DRC 把數據異步的傳到另外一個Region 中,這兩個Region 可能距離非常遠有上千公里,所以是兩地三中心的架構),可以擴展成三地五中心。
  • 異地多活:基於 Paxos 狀態機複製,可做跨地域一致性保證。
  • 單元化部署:將 “分庫” 邏輯上移到無狀態服務層的一種方案,某一批用戶被固定路由到某個地域,一套產品形成若干個封閉單元。

③ 一致性

解密商業化廣告投放平台技術架構 16

基於傳統的 MySQL 主從復制機制,使用 “雙1”+semi-sync 的保守配置,還是不能保證主從一致性,如圖所示這裡不再贅述。為了解決這個問題,我們有很多的 workaround,如開 MP 最大保護模式,強制主從必須同步,或者阿里內部有很多工具,例如 ADHA 來做主從切換的保證,以及數據的校驗訂正等。現在流行的優雅解決方案還是要依賴於 Paxos 協議保證多副本強一致,例如阿里雲金融級 RDS。

4. 分佈式數據庫發展趨勢

解密商業化廣告投放平台技術架構 17

追求強一致,可擴展,高可用的分佈式數據庫的發展趨勢主要分為5個階段:

(a) Standalone -> (b) share disk fallover -> © share nothing -> (d) share everything -> (e) share nothing

目前我們處於基於share nothing 架構的DRDS 來實現,業務體量到達一定規模的時候,未來一定是朝著高擴展性、高可靠、成本優先的方向發展的,我們也會持續跟進數據庫行業的發展,做更好的技術演進和選型。

——傳廣告——

廣告傳輸流建設

解密商業化廣告投放平台技術架構 18

現在廣告已經投完了,並且存在了數據庫中,接下來就要把廣告實時傳輸到檢索系統。如上圖,大致介紹了傳輸流。剛剛提到的服務層,可以有服務治理,廣告庫存在MySQL 中,我們通過傳輸流實時把數據傳輸到檢索端,做建庫到廣告索引中,以搜索場景為例,用戶發起一個query,需要匹配與query 相關所有的廣告,生成候選集,再進行相應的Auction 和Ranking 工作,最終返回給用戶1條或幾條廣告。所以廣告傳輸流非常重要,傳輸的是召回候選集的生成資料,是連接業務系統和檢索系統的關鍵鏈路。

解密商業化廣告投放平台技術架構 19

這條鏈路上,我們面臨的挑戰有:

  • 海量數據,天級別幾十億增量。
  • 高吞吐,Peak 20W+ QPS。
  • 高可用,大於5個9的 SLA,跨機房容災,計劃下線等敏感數據不能延遲否則會造成收入損失。
  • 低延遲,同機房數據庫 binlog 訂閱到檢索 SLA TP95<200ms。
  • 變化快,業務變更頻繁。

我們的方案是分庫分錶之後,通過binlog/DRC 組件來接廣告傳輸流做實時增量鏈路,檢索端訂閱message queue 來感知變化;全量數據Dump 會存在分佈式存儲上,檢索端可以天級別的base+delta 的方式重建索引。

解密商業化廣告投放平台技術架構 20

數據變化驅動的擴展,剛剛說的傳輸流只是其中的一個場景,可以擴展到很多場景中。都可以採用這種方式,做一個虛擬存庫,開源的可以用Fountain、Hiriver、Canal,以及阿里雲的DTS 等,可以做事務打包、規則過濾、數據轉換等,最終到增量消費端,傳輸流只是其中的某一個場景來做平台端到檢索端的同步,另外我們可以做歷史操作記錄,緩存更新失效,NoSQL 物化試圖構建,異構存儲同步等,想像空間會非常大,我們內部做了很多物化視圖類的緩存和索引,輔助業務系統加速查詢使用。

——計廣告——

實時計費系統

1. 實時計費平台

解密商業化廣告投放平台技術架構 21

現在業界幾乎都會實現一個實時計費平台,需具備基本的實時扣費和充值功能。計費廣告最簡單的模型是,廣告主有錢,比如預算設置1000元,每次點擊都要扣1~2元,最終扣完時,需要把這個廣告下線,這是典型的CPC 計費模式,還有CPM,CPT,GD 等計費方式。計費平台還需要處理超投控制,避免平台利益受損。

實時計費系統特點是:高並發、訪問量大、數據準確不丟不重、高可用性。

右圖為實時計費平台的關係圖:

用戶中心來充值,業務平台同步一些計劃的預算數據,引擎根據點擊進行實時的扣費,計費系統要把計劃上下線的信息,通過傳輸流實時傳輸給廣告檢索引擎。

2. 實時計費系統簡介

解密商業化廣告投放平台技術架構 22

我們過去的計費系統是基於單機或者分佈式的系統來開發的,現在的計費系統跑在Flink上,我們接收媒體的請求,展現/點擊事件、預算事件、充值事件這三類事件之後,基於YARN、Flink 之上,通過Stream API 來做相應的邏輯。每個計費事件來之後,會先做去重,然後再做計費,把明細數據存在數據庫中,撞線/下線數據可以實時的通過隊列傳輸給檢索系統。採用流式計算引擎做計費的好處在於:

  • 可以做到實時處理,敏感信息高優低延遲的冪等下發;
  • 對於明細數據可以通過兩階段提交 sink 的方式,保證端到端 exactly once 語義,然後做聚批高吞吐的寫入數據庫;
  • 有狀態的存儲賬戶狀態,在面對 failover,修歷史數據場景下可以做自動和靈活的處理。

總結下流計算引擎計費系統特點:

  • 多事件源接入,高吞吐處理
  • 計費關係樹有狀態的維護
  • 端到端 exactly once 保證明細
  • 不丟、冪等下發撞線/下線事件

——查廣告——

OLAP 海量數據報表

1. 數據報表

解密商業化廣告投放平台技術架構 23

計費、展現的數據,都要給用戶查看或進行分析。上圖為某數據報表截圖,某賬戶、單元、關鍵詞維度下的展現、點擊、消費數據。

解密商業化廣告投放平台技術架構 24

報表是廣告平台的核心業務,報表數據的披露與分析是投放優化的起源。面臨的問題:

  • 數據量大:總數據千億級,單表最大百億級;大賬戶單表數據近2億。
  • 快速響應:支持任意時間段查詢實時返回;並發高&平均響應百毫秒級
  • 查詢複雜:① 時間聚合:分月,分週,分日,分時等。 ② 維度聚合:物料層級,分地域,搜索詞等30+。 ③ 功能多樣:分頁,排序,匯總,導出,對比。

2. 技術選型思考

解密商業化廣告投放平台技術架構 25

技術選型上的思考:

友商方案和開源方案如上圖所示。根據我們廣告業務特點:

  • 近實時 mini-batch 導入,分鐘級報表需求
  • 查詢複雜,但維度基本確定
  • 不需要明細數據

我們的選型方案:

  • 實時構建增量數據,金字塔模型,支撐有限吞吐下的高並發查詢
  • 維度+指標列,使用 cube 數據立方體模型
  • 預計算 rollup 的物化視圖,不用生成複雜的查詢 DAG

3. 實時報表平台

解密商業化廣告投放平台技術架構 26

最終我們的實時報表平台,包括4層:

  • 應用層:關注總吞吐量、總計算量,以及和業務的 join。
  • 查詢計算:關注高並發,百毫秒級查詢延遲。
  • 數據存儲:有可擴展能力,並且有高效的 scan 能力。
  • 數據構建:要保證增量構建和原子更新。

技術選型

  • 採用定制的 Kylin,是 MOLAP 多維的 OLAP 分析;復用數據構建與部分查詢組件。
  • 實時性保證,基於 Blink 計算分鐘級數據,阿里雲 ADB 實時導入事實表,Kylin 接入 ADS 來進行分鐘級增量構建。

4. 報表平台關鍵技術點

解密商業化廣告投放平台技術架構 27

報表數據分為指標列和維度列,支持業務維度 ( 聚合邏輯固定,能預聚合 ) 和時間維度 ( 任意時間段聚合,無法預先計算 )。基於 Kylin 來做歷史和小時級數據的查詢,基於 ADB 來做實時分鐘級數據的查詢。這裡的創新點採用金字塔模型做基於貪心算法的 query path 優化,在掃描數據量、IO 上做最優的查詢計劃。

5. CBO 優化之 TOP N 深分頁優化

解密商業化廣告投放平台技術架構 28

這裡舉例說明一個比較細的優化點,假設有1000萬結果集,廣告主需求按照點擊率 CTR 倒排,取50分位結果,每頁20行。往往很多系統都是禁止這些查詢的,因為,一旦在大數據集上做深分頁 order by 操作,返回的數據量可能非常大,在最終匯總節點是無法完成這項工作的。所以我們做了一些分析:

  1. 業務要 skip 前500萬,不需要全排序;
  2. CTR 的顯示值最多1萬種;
  3. 指標列分佈都有業務特徵。

解密商業化廣告投放平台技術架構 29

解法核心思想

  1. 分桶統計:跳過無用數據
  2. 謂詞下推:優化計算吞吐
  3. 並行查詢:加速結果匯總

最終在我們的平台上是可以做海量數據深分頁查詢的,秒級響應返回。

總結

解密商業化廣告投放平台技術架構 30

上圖為阿里巴巴技術體系大圖

  • 基礎設施:硬件網絡相關的。
  • 重點軟件:分操作系統、數據庫、存儲、中間件等方向。
  • 平台相關:計算平台、數據平台、算法平台等。
  • 業務平台:業務上會走相應的業務平台和中台的方向。
  • 應用層:最終服務於阿里內部眾多的產品。

廣告投放平台技術側重​​點

包括:數據庫、中間件、計算平台、廣告引擎、業務平台、廣告業務。

本次的分享就到這裡,謝謝大家。

作者介紹

辰序

阿里巴巴 | 高級技術專家

本文來自 DataFun 社區

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247495504&idx=1&sn=35ebf88055839e0775a082dece99a99c&chksm=fbd75d3ccca0d42a09249dc266b4c55acb9fd232ac0caf9e8dd04e5007b80860fbb3737f4c05&scene=27#wechat_redirect