@騰訊廣告大數據平台 從廣告數據接入、處理、應用三個層面剖析廣告大數據平台的核心架構設計，重點包括百億級廣告日誌數據的接入架構設計（雲落地系統）、廣告數據 session 化實現（ logjoin 系統)、PB 級數據的 OLAP 查詢 Lambda 架構設計。

數據接入

大數據平台接入的數據主要包括3個大類：業務維度數據、媒體流量數據、廣告流量數據。

  • 業務維度數據

業務維度數據主要包括廣告客戶數據、廣告下單數據、廣告排期數據、廣告位數據，這些數據原生位於廣告投放體系中的其他業務系統如CRM系統、Order系統、Planning系統。大數據平台使用3種方式獲取這種維度數據：

1. 業務提供數據介面，平台主動拉取

2. 業務提供表schema/IP/埠，平台編寫業務邏輯SQL，主動拉取

3. 平台提供介面，業務主動調用介面上傳

  • 媒體流量數據

媒體流量數據來源於媒體，主要包括騰訊視頻播放數據、騰訊新聞瀏覽數據，這些媒體數據通過騰訊公司級數據倉庫TDW出庫到大數據平台側的Hadoop集群。媒體流量數據主要有兩大類用途：

1. 結合媒體數據分析廣告的投放效果和售賣效果

2. ETL清洗後為演算法服務提供原始特徵數據

  • 廣告流量數據

廣告流量數據包括廣告的檢索、曝光、點擊數據，是整個大數據平台自有的核心數據。實際商用的媒體往往有著巨大流量（日均百億級廣告PV、峰值QPS40萬），採集和傳輸這海量廣告日誌數據成為大數據平台首先需要面對的挑戰，這個挑戰主要體現在以下3個方面：

  1. 數據總量大、峰值壓力高
  2. 數據的可靠性、實時性要求極高
  3. 業務數據種類繁多且業務變化快

因此，一個良好的數據採集傳輸系統需要具備下述特性：

  1. 高可靠性和高可擴展性，完善的容錯和負載均衡機制，可水平擴展的處理能力
  2. 支持離線分析系統和實時計算系統
  3. 能夠靈活快速響應業務需求，實現數據欄位新增、修改

雲落地系統的設計目標是建成廣告效果數據匯流排以實現數據集中接入、秒級實時處理、下游業務各取所需、業務變更不停數據流。雲落地系統主要由Storm、TDBank(騰訊自研的分散式消息隊列)、Hadoop等分散式系統組件構建，總體架構採用分層結構。

業務伺服器包含雲落地系統所對接的各種業務日誌伺服器。發送Agent包含收集業務日誌數據並進行轉發的Sender。傳輸層使用TDBank，接收Agent發送的日誌數據。核心分揀層包含2個分揀引擎：實時分揀引擎以及作為容錯機制的離線分揀引擎。實時分揀在Storm Topology中實現。離線分揀使用Hadoop MapReduce實現。當實時分揀數據流出現問題時，可用離線分揀進行數據分揀，依然能保證數據完整性。存儲層是HDFS分散式文件系統以及TDBank，其中HDFS存儲支持下遊離線數據應用，TDBank存儲支持下游實時計算系統。

雲落地目前接入了騰訊網，騰訊視頻，騰訊新聞客戶端，微信/手Q新聞插件等業務，已覆蓋所有廣平數據業務。日均接收原始請求數百億級，峰值QPS 40W/S。平均處理延遲7.5s。雲落地系統將服務和數據解耦，提高了業務響應能力；配置中心化，一個業務，只需要維護一個配置，數據一致性得到保障；Hadoop和Storm結合保證了數據接入和傳輸的高可靠性和高可擴展性；雲落地系統強化數據匯流排概念，所有的數據都從雲分揀「入」，所有的數據需求都從雲分揀「出」。

數據處理

  • 業務維度表構建

針對業務維度數據，數據處理流程做的主要工作是生成一系列的維度表，這一系列的維度表將被用於數據建模時維度的擴展。例如對於廣告下單數據，數據平台會生成以訂單號oid為key的維度表，該維度表中還包括如客戶ID，廣告排期等其他訂單號相關的屬性。一個維度表最終的物理存儲形式為HDFS上的一個文件，大數據平台目前維護著數百份維度表，這些維度表的更新周期包括按天、按小時等等。

  • 媒體流量數據ETL

媒體流量數據由媒體側出庫到大數據平台側的Hadoop集群，之後數據平台將進行必要的數據清洗和轉換以構建數據模型。

  • 廣告流量數據ETL

對於通過雲落地系統接入的廣告流量數據，ETL流程通過清洗、關聯和轉換以實現數據的一致性、完整性、標準化。數據平台2017年前的ETL流程和業界通用的ETL流程類似，通過離線的Map/Reduce程序對廣告日誌進行清洗、關聯和轉換，清洗程序包括小時級的和天級的。

這種離線數據ETL方式主要存在以下問題：

  1. 數據時效性差：採用離線清洗,不能給下游實時統計提供實時流量，下游統計分析僅支持到T+1（1表示小時或者天，絕大部分數據為天）
  2. 離線清洗計算引擎落後：離線清洗基於Hadoop MapReduce, 一方面計算中間結果需要存放到hdfs中，效率較低，另一方面支持的運算元僅有Map和Reduce，表達能力欠缺，需要手工寫很多代碼，較難維護。

針對以上不足，大數據平台在2017年對數據ETL系統進行了重構升級，升級後的ETL系統架構如圖所示。新的ETL系統由兩大部分組成，實時ETL和離線ETL。

  1. 實時ETL: 基於實時LogJoin(下文會介紹)的輸出，構建實時清洗，為下游實時業務提供基礎數據。
  2. 離線ETL: 清洗計算引擎升級為spark，提升處理速度。

實時ETL分事實數據生成維度數據Join兩個主模塊。事實數據生成模塊主要負責數據過濾，轉換，格式化處理，生成事實表模型；維度數據Join模塊負責根據不同的實時業務需求，關聯不同的維度數據。實時ETL生成的數據將被用於實時查詢引擎實時數據的查詢以及演算法需要的實時特徵數據。

廣告數據Session化

廣告數據session化，即構建從用戶產生一個廣告請求到曝光以及最終產生點擊的session級數據模型，實時logjoin就是用來實現廣告數據session化的系統。廣告檢索日誌、曝光日誌、點擊日誌三路數據將通過實時logjoin模塊進行整合，曝光、點擊數據只需攜帶關鍵信息，其他信息由檢索數據填充。目前廣告曝光點擊等效果日誌關聯是離線任務方式執行，延遲至少2個小時，通過實時logjoin可以有效服務演算法實時CTR。

LogJoin項目主要意義：

  1. 提升數據一致性。以發布測數據為準，曝光、點擊、動作數據都向發布數據靠，保證數據一條線的一致性
  2. 提升數據完整性。減少大欄位導致的http截斷等用戶側上報場景下的問題
  3. 提升數據時效性。基於Storm做流式logjoin，秒級完成數據ETL。可供實時CTR預估，在線學習等，提升廣告收益，並為海象等下游業務提速打下基礎
  4. 精簡曝光點擊請求上報，節省用戶流量
  5. 解耦SDK和數據採集，提升新需求的響應速度
  6. 基礎數據底層schema重構優化，對各種業務不同格式數據建立統一底層數據模型，降低系統複雜度
  7. 實時補全日誌，緯度信息更加豐富，可支持實時多維分析。

核心業務邏輯

LogJoin的核心業務邏輯是將用戶產生的一個廣告從請求到曝光以及最終產生點擊的完整日誌數據Join到一起，LogJoin通過將一個廣告的請求、曝光、點擊寫到Hbase的同一行中的Column Family並通過不同的qualifier來標識請求、曝光、點擊來實現Join的功能。LogJoin中數據的實時清洗以及讀寫HBase的操作都是在JStorm中完成。

  • 數據服務

數據平台的數據服務可以分成在線數據服務和離線數據服務兩大類。在線數據服務包括為實時CTR預估提供數據的LogJoin數據流、實時播控、點擊過濾、計費。離線數據服務主要包括廣告效果分析平台(Measurement)、廣告運營分析平台(燈塔)以及自助查詢OLAP系統 (蓋亞 & Walrus)、各個業務系統所需的廣告執行數據的推送服務。

  • 數據建模

離線數據服務的核心是數據的建模以及基於建模的異構數據的OLAP查詢。數據建模的目標是基於業務視角，將原始的廣告日誌數據轉化成業務所需的數據模型以便於業務側的高效查詢，這個過程中做的主要工作是維度的聚合、指標的計算。數據平台的數據模型包括實時模型和離線模型兩個部分。實時模型通過接入實時ETL的結果數據利用Spark-streaming或Storm進行窗口聚合提供40+維度的廣告曝光點擊數據的實時查詢(數據延遲在分鐘級)。離線模型主要通過Spark或Hadoop任務基於任務DAG生成數據模型，數據平台現有模型21個，每個模型可查詢維度40~250個，時間跨度為最近2年。

  • 數據查詢

數據平台的數據查詢服務主要包括兩大類，通用型的多維聚合類查詢與廣告明細提取，人群包提取。數據查詢的挑戰在於：數據量大（PB級別）、緯度多（單表200+緯）、查詢時間跨度大、聚合緯度多、數據準確性高（不允許非精確值）及查詢性能要求高。

隨著業務的不停增長，數據平台的查詢引擎從也進行了一系列的升級。

  1. 以開源Infobright為基礎的查詢引擎

Infobright是開源的MySQL數據倉庫解決方案，它將列存儲、高強度的數據壓縮、優化的統計計算引入到了MySQL中，對於處理億級規模以下的數據具有較好的性能，但無法支持百億級、千億級數據的查詢。隨著業務的發展，數據平台需要查詢的數據規模達到了萬億級，Infobright因為其有限的吞吐量已不能滿足業務需求。

2. 以PIG為主要計算引擎的查詢引擎(查詢耗時小時級)

為了處理萬億級規模的數據，Pig被引入到了查詢引擎中。Pig本質上是Map Reduce ON HDFS，由Yahoo在2006年開始開發，在2010成為Apache頂級項目。Pig是MapReduce的一個抽象，它提供了一種稱為Pig Latin的高級語言來編寫數據處理腳本。所有這些腳本都在Pig內部的Pig Engine組件轉換為Map和Reduce任務。

Pig提供了豐富的運算符集如join，sort，filer等來操作數據;Pig內部也會對Pig腳本進行優化，開發人員只需要關注語言的語義而不需要過度關注底層Map Reduce實現;Pig提供UDF(用戶定義函數)的功能,開發人員可以通過其他編程語言（如Java、Python）創建UDF的功能，並且可以調用或嵌入到Pig腳本中。

和其他基於Map Reduce的批處理工具類似，基於Pig的數據處理也是典型的IO密集型計算，其效率相對低下。對於例行化的批處理任務，Pig由於其支持大吞吐量的特性是一個不錯的選擇，但對於面向用戶的查詢引擎，Pig效率的低下(用戶查詢耗時在小時級)，越來越不能滿足業務需求。

3. Rocket AdHoc查詢引擎(查詢耗時秒級)

為了解決基於Pig的查詢引擎查詢性能低下的缺陷，Rocket查詢引擎應運而生。Rocket查詢引擎是SparkSQL和Paruqet存儲格式的結合。數據平台查詢引擎的業務特點是計算多個維度聚合下的指標，計算引擎的查詢壓力集中在reduce端。因此Rocket採用了大寬表結構的數據模型。通過合理的數據預處理和Parquet列式存儲的選擇，Rocket查詢引擎將用戶查詢的時間開銷降低到了秒級。

Rocket查詢引擎的數據預處理包括大寬表構建（預先join所有常用維度）、String轉Int（更高的數據壓縮比、更好的查詢性能）以及行轉列（高效數據壓縮）。數據組織包括多分區方式（按全量、年、月分區，各分區獨立schema、獨立中間表）、多版本管理（讀寫分離）、視圖模型（多模型聯合查詢）和廣播模型（小表預先broadcast）。

4. 當前的lambda架構查詢引擎

數據平台當前的查詢引擎採用了lambda架構的經典設計，相比於之前3代查詢引擎只支持離線數據的查詢，當前lambda架構引入了實時數據的查詢，其設計目的在於提供一個能滿足大數據系統關鍵特性的架構，包括高容錯、低延遲、可擴展等。其整合離線計算與實時計算，融合不可變性、讀寫分離和複雜性隔離等原則，可集成Hadoop，Kafka，Spark，Storm等各類大數據組件。Lambda 架構可分解為三層Layer，即Batch Layer，Real-Time(Speed) Layer和ServingLayer。其中Batch Layer用於離線數據的處理和查詢，Speed Layer用於實時數據的處理和查詢，Serving Layer用於合併離線數據的查詢結果和實時數據的查詢結果作為最終的數據結果集。

在介面層，當前架構支持兩種類型的介面，包括HTTP介面和類SQL查詢， 五元素定義一個查詢。在視圖層，當前架構屏蔽了底層異構計算引擎；屏蔽模型中實體表與維度表的關聯關係，對外以大寬表形式，降低使用門檻。在計算層，當前架構整體構建在spark on yarn之上。

除了上文中提到的應用和服務之外，數據平台還負責著統一緩存服務(提供用戶的基礎屬性等的查詢)、TencentAdId服務、Poseidon海量標籤檢索服務等相對獨立的數據服務。

推薦閱讀：

相关文章