導讀：互聯網廣告是流量商業變現的重要途徑之一，涉及服務平臺、檢索引擎、算法策略、數據工程等多個方向。本次分享的主題爲商業化廣告投放平臺技術架構，分享的內容集中在工程領域，結合業界廣告投放平臺的通用技術範式，分享智能營銷平臺是如何打造高性能、高可用、可擴展平臺架構的，從服務化、數據傳輸分發、廣告投放引擎、計費、海量數據實時報表等方向切入，深入淺出的闡述一套最佳實踐。
——業務介紹——
1. 廣告業務簡介
商業化是互聯網公司營收的重要來源，業界比較大的商業化產品有 Google AdWords、Facebook Ad、百度鳳巢、頭條巨量引擎、騰訊廣點通等產品，阿里電商場景的變現平臺是阿里媽媽。目前國內互聯網廣告的營收年規模達數千億元。
廣告平臺一般由三方組成：網站主、廣告主、用戶。
- 網站主：有流量資源的變現需求。
- 廣告主：有投放預算，希望在流量資源上找到合適的人進行推廣。
- 用戶：得到更好的廣告推薦結果。
2. 智能營銷平臺簡介 & 通用的廣告系統組成
阿里創新事業羣智能營銷平臺的主要流量構成包括：神馬搜索、UC 瀏覽器、UC 頭條、優酷、阿里雲 OS 以及手機廠商、網盟第三方流量等。
通用的廣告系統組成如右圖，主要包括4部分：投放平臺、廣告引擎、算法策略、數據平臺。
運轉的流程如下：
首先，廣告主有一定的預算，選擇在什麼樣的流量上投廣告，這樣就有了輸入；然後存廣告，通過投放平臺來完成，把投放所需的設置、預算、創意等數據實時傳輸到檢索系統；每當用戶發起一次檢索請求時，簡單來說後臺相當於做召回+優選，把最合適的 TOP 候選廣告返回給用戶；還有一部分是計廣告，通過數據平臺來完成；最終廣告主來查廣告績效展點消數據。
本次分享主要聚焦在如下5個環節：
——投廣告——
業務微服務化構建
第一，來看如何投廣告，包括無狀態的服務層，來滿足廣告主進行預算設置、存廣告、建創意等操作訴求。
1. 單體模式到微服務化 ( MSOA ) 的過渡
任何一個大的產品，都會遇到從單體過渡到微服務的過程，其架構的實施方法論落在三個字：分、合、細：
- 分：分化、隔離、獲得技術、業務上的縱深和彈性。
- 合：隨着業務的增長，要加大複用度，歸併同類項。
- 細：細化分工、架構，深入優化技術&業務。
當業務發展到足夠大的時候，最終會採用 MSOA 架構。
分合細的基礎在於：如何把這些服務給拆開，對於投放平臺來說，需要對投放需求進行規範化的表達和產品功能的標準化設計。把這些領域模型建起來之後，服務自然就有了劃分的依據。
2. 微服務化分層體系建設
上圖爲拆分之後的投放服務架構圖，水平拆分成簇，縱向拆分成層。外層是 API 和 WEB 端，進行相應的權限驗證、流控等；中間爲計算層，細分出來各個服務，包括面向業務流程處理、業務邏輯組件以及公共服務組件三層；最底層是基礎設施和數據資源。把所有的服務串聯起來的就是分佈式服務化框架。
3. 微服務化與服務治理
做平臺方向的團隊可能需要幾十人上百人，而服務則可能有幾十上百個，它們所組成的網絡會非常混亂，最終難以治理。我們需要具備服務治理能力的微服務化框架來解問題，包括 [ RPC 框架 ] 和 [ 服務治理能力 ]。
4. 分佈式服務化框架一覽
業界的分佈式服務化框架一覽，如上圖所示。這裏有的是 RPC 框架，有的纔是真正合格的服務化框架，對於投放平臺，需要的是一個服務化的框架。我們拆分來看，先認識下 RPC 框架：
① 體系化認知 RPC
RPC 體系的腦圖如上所示，作爲 PRC 框架應具備如下功能：
- 傳輸方式：我們要看是採用的傳統 TCP 或者 HTTP 技術，還是運用的最新技術，如阿里很多基礎產品是用 RDMA 網絡的，或者採用一些用戶態的協議，不走 TCP 協議，來做 kernel bypass。
- I/O 模型：是採用同步還是異步的，可以選用 Blocking IO 或者 Non-blocking IO，I/O 多路複用最有名的是基於 epoll 的，大部分走 TCP 協議的都採用的是 epoll；異步的 AIO 網絡通信在 Windows 下用的比較多，在 Linux 上 AIO 主要應用在磁盤 IO 相關。
- I/O 線程處理模型：可以分爲單線程、多線程，以及各種 pattern，大多數情況下都會選擇 Reactor pattern，基於 I/O 多路複用 epoll 這種形式。
- 協議棧：數據可以點對點傳輸之後，如何識別這些數據，主要就是協議棧的工作。大多數框架都採用基於 header+payload 的方式。
- 序列化：當點對點的實時的識別出一個具體的包之後，需要序列化的解析包裏的數據。
- 連接可靠性和易用性：可以快速的傳輸和識別包之後，還要面臨可靠性的保證，以及暴露給上層的調用方式，如何更好的調用服務，是用同步、異步，還是泛化調用類似的問題是需要考慮的。
這些範疇，共同組成了 RPC 體系，但是光有這些是不足的，最終還要落在服務治理上：
② 服務治理能力
服務治理能力包括：
- 通信傳輸：這是最基本的。
- 服務發現：包括服務註冊，自動的下發和發現；客戶端路由的規則，是同機房路由還是打標分組路由；以及負載均衡的策略，是 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. 廣告數據存儲
數據存儲可以看做有狀態的存儲層，要把這些生產資料，存在廣告系統中。我們採用的是多模數據存儲的方式，OLTP 大部分都是 MySQL 分庫分表，OLAP 有相應的報表平臺，非關係型的有 OSS、KV 存儲以及基於 ES 的全文檢索。
2. 體系化認識數據庫
如果數據庫從0到1開始做，最簡單通過一個文件把相應的字段存起來，可以用到的數據結構有：Hash，Binary Tree，B+Tree。但是採用這些方式，會面臨着不同的時延問題，如圖所示：訪問內存大概是 100ns，訪問 SDD 大概是 16μs，但是一次 Disk seek 需要 3-10ms。所以，爲了減少隨機 IO，Hash 和 Binary Tree 都是不合適的。因此，有了 B+Tree 這種 MySQL 使用的索引數據結構。
① MySQL InnoDB 引擎
我們大部分數據都是 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 引擎
在海量數據高 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. 數據庫存儲架構
① 可擴展
剛剛介紹了存廣告的基礎，由於廣告產品產生的數據量非常大，尤其是搜索廣告的關鍵詞維度，基本都是百億的量級，如何做擴展，是一個很重要的問題。常用的解法是分而治之，做垂直拆分和水平拆分。
我們是基於 TDDL ( 雲上產品 DRDS ) 的解決方案，來做分庫分表，讀寫分離，主備切換以及鏈接管理的。
② 高可用
對於數據庫高可用的保證，常常採用：
- 異地高可用：兩地三中心 ( 如左圖，主庫和備庫都在同一個 Region B 中，但是它們分了兩個機房來做相應的同步，同時通過 DRC 把數據異步的傳到另外一個 Region 中，這兩個 Region 可能距離非常遠有上千公里，所以是兩地三中心的架構 )，可以擴展成三地五中心。
- 異地多活：基於 Paxos 狀態機複製，可做跨地域一致性保證。
- 單元化部署：將 “分庫” 邏輯上移到無狀態服務層的一種方案，某一批用戶被固定路由到某個地域，一套產品形成若干個封閉單元。
③ 一致性
基於傳統的 MySQL 主從複製機制，使用 “雙1”+semi-sync 的保守配置，還是不能保證主從一致性，如圖所示這裏不再贅述。爲了解決這個問題，我們有很多的 workaround，如開 MP 最大保護模式，強制主從必須同步，或者阿里內部有很多工具，例如 ADHA 來做主從切換的保證，以及數據的校驗訂正等。現在流行的優雅解決方案還是要依賴於 Paxos 協議保證多副本強一致，例如阿里雲金融級 RDS。
4. 分佈式數據庫發展趨勢
追求強一致，可擴展，高可用的分佈式數據庫的發展趨勢主要分爲5個階段：
(a) Standalone -> (b) share disk fallover -> © share nothing -> (d) share everything<storage> -> (e) share nothing
目前我們處於基於 share nothing 架構的 DRDS 來實現，業務體量到達一定規模的時候，未來一定是朝着高擴展性、高可靠、成本優先的方向發展的，我們也會持續跟進數據庫行業的發展，做更好的技術演進和選型。
——傳廣告——
廣告傳輸流建設
現在廣告已經投完了，並且存在了數據庫中，接下來就要把廣告實時傳輸到檢索系統。如上圖，大致介紹了傳輸流。剛剛提到的服務層，可以有服務治理，廣告庫存在 MySQL 中，我們通過傳輸流實時把數據傳輸到檢索端，做建庫到廣告索引中，以搜索場景爲例，用戶發起一個 query，需要匹配與 query 相關所有的廣告，生成候選集，再進行相應的 Auction 和 Ranking 工作，最終返回給用戶1條或幾條廣告。所以廣告傳輸流非常重要，傳輸的是召回候選集的生成資料，是連接業務系統和檢索系統的關鍵鏈路。
這條鏈路上，我們面臨的挑戰有：
- 海量數據，天級別幾十億增量。
- 高吞吐，Peak 20W+ QPS。
- 高可用，大於5個9的 SLA，跨機房容災，計劃下線等敏感數據不能延遲否則會造成收入損失。
- 低延遲，同機房數據庫 binlog 訂閱到檢索 SLA TP95＜200ms。
- 變化快，業務變更頻繁。
我們的方案是分庫分表之後，通過 binlog/DRC 組件來接廣告傳輸流做實時增量鏈路，檢索端訂閱 message queue 來感知變化；全量數據 Dump 會存在分佈式存儲上，檢索端可以天級別的 base+delta 的方式重建索引。
數據變化驅動的擴展，剛剛說的傳輸流只是其中的一個場景，可以擴展到很多場景中。都可以採用這種方式，做一個虛擬存庫，開源的可以用 Fountain、Hiriver、Canal，以及阿里雲的 DTS 等，可以做事務打包、規則過濾、數據轉換等，最終到增量消費端，傳輸流只是其中的某一個場景來做平臺端到檢索端的同步，另外我們可以做歷史操作記錄，緩存更新失效，NoSQL 物化試圖構建，異構存儲同步等，想象空間會非常大，我們內部做了很多物化視圖類的緩存和索引，輔助業務系統加速查詢使用。
——計廣告——
實時計費系統
1. 實時計費平臺
現在業界幾乎都會實現一個實時計費平臺，需具備基本的實時扣費和充值功能。計費廣告最簡單的模型是，廣告主有錢，比如預算設置1000元，每次點擊都要扣1~2元，最終扣完時，需要把這個廣告下線，這是典型的 CPC 計費模式，還有 CPM，CPT，GD 等計費方式。計費平臺還需要處理超投控制，避免平臺利益受損。
實時計費系統特點是：高併發、訪問量大、數據準確不丟不重、高可用性。
右圖爲實時計費平臺的關係圖：
用戶中心來充值，業務平臺同步一些計劃的預算數據，引擎根據點擊進行實時的扣費，計費系統要把計劃上下線的信息，通過傳輸流實時傳輸給廣告檢索引擎。
2. 實時計費系統簡介
我們過去的計費系統是基於單機或者分佈式的系統來開發的，現在的計費系統跑在 Flink上，我們接收媒體的請求，展現/點擊事件、預算事件、充值事件這三類事件之後，基於 YARN、Flink 之上，通過 Stream API 來做相應的邏輯。每個計費事件來之後，會先做去重，然後再做計費，把明細數據存在數據庫中，撞線/下線數據可以實時的通過隊列傳輸給檢索系統。採用流式計算引擎做計費的好處在於：
- 可以做到實時處理，敏感信息高優低延遲的冪等下發；
- 對於明細數據可以通過兩階段提交 sink 的方式，保證端到端 exactly once 語義，然後做聚批高吞吐的寫入數據庫；
- 有狀態的存儲賬戶狀態，在面對 failover，修歷史數據場景下可以做自動和靈活的處理。
總結下流計算引擎計費系統特點：
- 多事件源接入，高吞吐處理
- 計費關係樹有狀態的維護
- 端到端 exactly once 保證明細
- 不丟、冪等下發撞線/下線事件
——查廣告——
OLAP 海量數據報表
1. 數據報表
計費、展現的數據，都要給用戶查看或進行分析。上圖爲某數據報表截圖，某賬戶、單元、關鍵詞維度下的展現、點擊、消費數據。
報表是廣告平臺的核心業務，報表數據的披露與分析是投放優化的起源。面臨的問題：
- 數據量大：總數據千億級，單表最大百億級；大賬戶單表數據近2億。
- 快速響應：支持任意時間段查詢實時返回；併發高&平均響應百毫秒級
- 查詢複雜：① 時間聚合：分月，分周，分日，分時等。② 維度聚合：物料層級，分地域，搜索詞等30+。③ 功能多樣：分頁，排序，彙總，導出，對比。
2. 技術選型思考
技術選型上的思考：
友商方案和開源方案如上圖所示。根據我們廣告業務特點：
- 近實時 mini-batch 導入，分鐘級報表需求
- 查詢複雜，但維度基本確定
- 不需要明細數據
我們的選型方案：
- 實時構建增量數據，金字塔模型，支撐有限吞吐下的高併發查詢
- 維度+指標列，使用 cube 數據立方體模型
- 預計算 rollup 的物化視圖，不用生成複雜的查詢 DAG
3. 實時報表平臺
最終我們的實時報表平臺，包括4層：
- 應用層：關注總吞吐量、總計算量，以及和業務的 join。
- 查詢計算：關注高併發，百毫秒級查詢延遲。
- 數據存儲：有可擴展能力，並且有高效的 scan 能力。
- 數據構建：要保證增量構建和原子更新。
技術選型：
- 採用定製的 Kylin，是 MOLAP 多維的 OLAP 分析；複用數據構建與部分查詢組件。
- 實時性保證，基於 Blink 計算分鐘級數據，阿里雲 ADB 實時導入事實表，Kylin 接入 ADS 來進行分鐘級增量構建。
4. 報表平臺關鍵技術點
報表數據分爲指標列和維度列，支持業務維度 ( 聚合邏輯固定，能預聚合 ) 和時間維度 ( 任意時間段聚合，無法預先計算 )。基於 Kylin 來做歷史和小時級數據的查詢，基於 ADB 來做實時分鐘級數據的查詢。這裏的創新點採用金字塔模型做基於貪心算法的 query path 優化，在掃描數據量、IO 上做最優的查詢計劃。
5. CBO 優化之 TOP N 深分頁優化
這裏舉例說明一個比較細的優化點，假設有1000萬結果集，廣告主需求按照點擊率 CTR 倒排，取50分位結果，每頁20行。往往很多系統都是禁止這些查詢的，因爲，一旦在大數據集上做深分頁 order by 操作，返回的數據量可能非常大，在最終彙總節點是無法完成這項工作的。所以我們做了一些分析：
- 業務要 skip 前500萬，不需要全排序；
- CTR 的顯示值最多1萬種；
- 指標列分佈都有業務特徵。
解法核心思想：
- 分桶統計：跳過無用數據
- 謂詞下推：優化計算吞吐
- 並行查詢：加速結果彙總
最終在我們的平臺上是可以做海量數據深分頁查詢的，秒級響應返回。
總結：
上圖爲阿里巴巴技術體系大圖：
- 基礎設施：硬件網絡相關的。
- 重點軟件：分操作系統、數據庫、存儲、中間件等方向。
- 平臺相關：計算平臺、數據平臺、算法平臺等。
- 業務平臺：業務上會走相應的業務平臺和中臺的方向。
- 應用層：最終服務於阿里內部衆多的產品。
廣告投放平臺技術側重點：
包括：數據庫、中間件、計算平臺、廣告引擎、業務平臺、廣告業務。
本次的分享就到這裏，謝謝大家。
作者介紹：
辰序
阿里巴巴 | 高級技術專家
本文來自 DataFun 社區
原文鏈接：