Hologres+Hologres+Flink流批一體首次落地4982億背后的營銷分析大屏Flink流批一體首次落地4982億背后的營銷分析大屏


簡介: 本篇將重點介紹Hologres在阿里巴巴淘寶營銷活動分析場景的最佳實踐,揭秘Flink+Hologres流批一體首次落地阿里雙11營銷分析大屏背后的技術考驗。

概要:剛剛結束的2020天貓雙11中,MaxCompute交互式分析(下稱Hologres)+實時計算Flink搭建的雲原生實時數倉首次在核心數據場景落地,為大數據平台創下一項新紀錄。借此之際,我們將陸續推出雲原生實時數倉雙11實戰系列內容,本篇將重點介紹Hologres在阿里巴巴淘寶營銷活動分析場景的最佳實踐,揭秘Flink+Hologres流批一體首次落地阿里雙11營銷分析大屏背后的技術考驗。

一、背景介紹

在淘系業務運營中,大促是業務運營和用戶增長中非常重要的場景,而營銷活動分析產品作為大促期間用來服務決策、指導運營的核心數據產品,覆蓋活動前、中、后全鏈路的分析,其中需要滿足不同角色小二在不同階段下,對數據時效性和數據靈活性的不同要求,整體產品大圖如下:

老版營銷活動分析是基於常規的實時離線數據體系&FW的產品架構,在之前的各類大大小小的活動中,也暴露了比較多的問題,其中核心的問題可以歸納為三類:

  • 實時和離線數據不一致:相同口徑的數據實時和離線不一致,包括數據邏輯口徑不統一、數據接口不統一,由於實時和離線數據開發割裂(開發人員和接口),不僅僅增加了整體數據的運維成本,同時產品搭建層面的負擔也大幅度提升。
  • 維護成本高:隨着業務量的增加,原有數據庫不能快速、靈活的支持復雜且多變的應用場景。常規的Hbase、Mysql、ADB數據庫,都只能單點滿足海量數據、高並發存儲點查、OLAP查詢,因此面對極其復雜的業務,需要依賴多個數據庫,整體維護成本和依賴成本會非常高。
  • 擴展性差:在FW框架下的產品搭建邏輯復雜度高、可擴展性都比較差,在活動期間維護的成本非常大

因此,如何能夠快速應對頻繁變動的業務訴求,以及更高效的處理活動期間的數據問題變得越來越重要,升級的新一代營銷活動分析架構因而需要滿足以下幾個優點:
1. 實時數倉與離線數倉能夠模型統一(實時離線邏輯統一)、接口統一(數據存儲、取數統一),真正做到流批一體
2. 需要有更強大的數倉,既能夠滿足海量數據的並發寫入查詢,還能夠滿足業務的及時查詢功能
3. 簡化現有的產品搭建邏輯、降低產品實現復雜度

基於上訴背景,我們需要重構當前架構並尋找另外的替代產品來解決業務痛點。經過長時間的調用和嘗試,最終我們選擇了基於實時計算Flink+Hologres+FBI(阿里內部的一款可視化分析工具)的技術方案來實現天貓營銷活動分析的架構重構。

二、 流批一體技術方案

通過深度剖析業務對數據的要求,以及多方位數據模型探索和數倉的調研,最終確定了營銷活動分析產品重構的整體技術框架,如下圖所示,其中的核心要點有:

  • 通過流批一體架構升級,實現了流批SQL邏輯&計算引擎層面統一
  • 通過Hologres實現了數據存儲和查詢的統一
  • 利用FBI產品能力,在降低搭建成本的同時滿足業務的高靈活性,同時滿足不同角色對於報表的需求


**
下面,我們將詳細介紹整個技術方案中核心的幾大技術方案:流批一體、Hologres、FBI

1. 流批一體技術框架

傳統數倉架構圖如下圖所示,傳統數倉架構核心問題:

  • 流批間的存儲層割裂,集群、表、字段都是分開的,導致應用層對接時需要寫不同的取數邏輯。
  • 流批間的處理邏輯不能復用,SQL標准不一樣,計算引擎不一樣,導致實時和離線需要分別開發,其實很多情況下,邏輯大同小異,但系統之前不能靈活轉換,導致工作量重復
  • 計算層集群分開,實時和離線對資源的使用時間段高峰不一樣,導致資源利用率不夠高,波峰波谷非常明顯

image.png
流批一體數倉架構圖如下圖所示,升級后的架構主要有以下核心點需要關注:

  • 首先,數倉DWD層雖然在存儲介質上不同,但需要保證數據模型的等價,然后進行邏輯表封裝(一個邏輯表映射兩個物理表,即實時DWD和離線DWD),數據計算代碼的撰寫都是基於該邏輯表開發
  • 其次,基於邏輯表的代碼開發、流、批計算模式的個性化配置、以及不同的調度策略等,需要有開發平台(Dataphin流批統一開發平台)作為支撐,形成便捷的開發、運維一體化
  • 最后,基於OneData規范的存儲層統一,不僅是模型規范統一,還是存儲介質的統一,做到了無縫的銜接

今年雙11,實時計算Flink處理的流量洪峰創紀錄地達到了每秒40億條的記錄,數據體量也達到了驚人的每秒7TB,基於Flink的流批一體數據應用在營銷活動分析場景中嶄露頭角,並在穩定性、性能和效率方面都經受住了嚴苛的生產考驗
整體Flink流和Flink batch任務在活動期間都表現了極強的穩定性,全程0鏈路容量、機器單點、網絡帶寬等問題的發生

2. Hologres流批一體落地

流批一體數據架構實現了整體的數據層面的統一,還需要選用一款產品讓整體的存儲統一,這款產品需要即支持高並發寫入,又能夠滿足及時查詢,同時還能夠支持OLAP分析。

在老版本的架構中每個頁面模塊會涉及到一個或多個數據庫的數據查詢,如Mysql、Hbase、ADB3.0「老版本HybridDB」等。由於Hbase的高並發寫入、高性能點查等特性,所以大多數實時數據就會放在Hbase中;而由於Mysql表管理便捷、查詢簡易等好處,維表數據、離線數據通常會選擇存放在其中;另外,產品的一些模塊涉及到的數據,具有數據量小、維度多等特征「如營銷玩法數據」,則會選擇ADB作為OLAP多維分析的數據庫。如此,就會存在兩個痛點:實時數據與離線數據的割裂、多數據庫多實例的雜亂管理。
新版營銷活動分析產品的建設,一個目標是要做到存儲統一,降低運維成本和提高研發效能;另外一個目標是高性能、高穩定、低成本。

我們通過與多方位的產品對標之后,選用了Hologres作為整個營銷活動分析的統一產品。Hologres作為一款兼容PostgreSQL 11協議的一站式實時數倉,與大數據生態無縫打通,支持PB級數據高並發、低延時的分析處理,可以輕松而經濟地使用現有BI工具對數據進行多維分析透視和業務探索,在這樣復雜的業務場景中Hologres的優勢就表現得極為突出了。

通過對整體營銷活動分析個模塊的深度分析,以及結合業務側對數據時效性的要求,整體將營銷活動分析的幾大模塊的數據制定了具體的實時鏈路方案:

  • 活動直播、預售、加購、流量監控等核心模塊,我們選用了Hologres的實時點查能力,
  • 面對復雜多變的營銷玩法場景,我們選用了Hologres的OLAP即時查詢能力

針對營銷活動分析需要的點查能力和OLAP分析能力,天貓營銷活動分析分別建了dt-camp和dt-camp-olap庫,其中dt_camp點查庫由於需要將活動期間的一些歷史數據長期存放用來做活動的對比,整體數據量級在近40TB;營銷玩法的OLAP庫中,存放的是玩法的一些明細數據,整體數據量級在近百TB,由於營銷玩法對整體數據的准確度要求非常高,因此沒有采用有損精度的查詢方式,對整體數倉的查詢性能提出了更高的要求。

為了提升Hologres的整體性能,針對營銷活動分析數倉主要做了一下幾類優化策略:

  1. 設置distribution key:對於count(distinct user_id)的情況將user_id設置為distribution key在hologres中每一個shard做count distinct,避免大量的數據shuffle,大大提升查詢性能。
  2. 盡量減少count distinct 次數:通過多層group by 操作轉換SQL減少count distinct成本
  3. shard prunning:在一些場景中,查詢會指定某個表的pk中的一些key進行查詢,如果將這些場景的key組合設置為distribution key,可以在處理查詢的時候就確定本次查詢會命中那幾個shard,減少RPC請求數,對於高QPS場景至關重要
  4. 生成最優的plan:營銷活動分析有基於匯總數據的點查或者范圍查詢,有基於原始數據的OLAP查詢,還有單表的聚合之后取topn的查詢,對於不同的查詢類型,Hologres能夠根據收集的統計信息,生成最優的執行計划,保證查詢的QPS和Latency
  5. 寫入優化:營銷活動分析的寫入都是基於列存表UPDATE操作,該操作在hologres中會首先根據指定的pk找到對應的uniqueid,然后根據uniqueid找到對應的記錄標記刪除,然后再查詢一條新紀錄,這種情況如果能夠設置一個遞增的segment key,查詢的時候就可以根據segment key快速定位到文件,提升根據pk定位到記錄的速度,提升寫入性能,營銷活動分析系統壓測時寫入峰值可以達到800W/s的更新
  6. 小文件合並:某些寫入不是很頻繁的表因為一段時間更新的key比較固定,這導致memory table flush的時候是一個比較小的文件,而Hologres默認的compaction策略並沒有對這些文件做compaction,導致存在比較多的小文件,通過深入優化compaction參數,增加compaction的頻率,減少小文件,對於查詢性能有較明顯的提升

Hologres在雙十一期間表現,點查場景的寫入峰值達幾十w/s,服務能力幾百w/s,OLAP寫入峰值400w/s,服務能力500w/s。同時單點查詢&OLAP查詢幾乎都能夠滿足單條查詢小於ms的查詢比例高達99.7%以上,因此在整個活動期間,Hologres整體表現非常平穩,能夠很好的同時支持快速點查和快速OLAP分析。

3. FBI分析大屏

FBI作為阿里生態內的首選數據可視化平台,即能快速支持搭建各類報表進行數據分析,也能支持多種數據集的快速接入與擴展,還有支持各種分析型數據產品建設的高級功能【產品搭建】。

在FBI產品搭建的核心流程中,可以通過4個核心功能大幅降低搭建成本:

1)實時離線一體的“實時小時分鍾模型”,自動實現實時數據的精確趨勢和對比
針對營銷活動定義的批流一體的底層數據,為了滿足用戶分析實時數據,實時對比,小時對比的靈活性,FBI抽象出一套實時離線一體的標准數據模型,創建該模型后就可以實現實時數據的精確對比,趨勢分析自動路由分鍾表,小時趨勢直接路由到小時表的能力。
2)FBI原創的FAX函數,極簡定義輸出各種復雜指標
針對復雜的指標:如通道占比,類目占比,同比貢獻度,活動累計成交額,上個版本中均是用sql套sql進行定義,不僅導致SQL長度保障,同時產品的穩定性和可維護性都大大降低。為了解決這類問題,FBI構建了一套易於學習和理解的分析DSL,名為 FAX函數(同比差額、貢獻率、活動累計等20+分析函數),簡單的一行語句可以定義出營銷活動分析中用到的各種復雜指標。
3)通過分析能力配置化和專有邏輯插件化,大幅節約頁面構建時間
產品頁面構建是一個非常核心的環節,如何節約用戶的配置,FBI的方法就是:
a、通用分析能力配置化:對於最常用到的交叉表、活動對比,日期變量傳參等分析場景,抽象升級為簡單的配置項,即可完成相應的同期對比和同比差額等分析。
b、專有邏輯插件化:對於活動參數,顯示隱藏,結果排序等作用於區塊的定制能力,可以通過數據插件的方式覆蓋。
4、打造沉淀FBI的高保障體系,升級了發布管控,監控預警,變更提示等,支持1-5-10

三、測試端的保駕護航

為了進一步保障營銷活動分析產品質量,測試端從明細->匯總->產品端都做了嚴格的數據比對和校驗,同時針對大促的核心數據,進行了全方位的監控

在活動期間測試巡檢功能大大提升了主動發現數據問題的能力,以及及時發現核心問題的能力,大大的提升了活動期間整個數據產品的質量和穩定性

四、業務反饋&價值

整個雙十一期間,基於實時計算Flink+Hologres流批一體的營銷活動分析產品不僅支持了天貓事業群上千+小二的人均上百PV高頻訪問,更實現了0 P1/P2故障的目標,同時整個產品在活動期間表現了相比往年更有優勢的幾大方面:

  • 豐富:實時數據在營銷活動分析產品中大規模鋪開,核心維度可以down到活動商品、商家標簽分層等多個維度,同時加購和預售都新增了商家、商品維度的實時數據,更加友好的支持了業務側進行商家的BD
  • 穩定:基於Hologres持續高穩定的輸出,整體雙十一期間不論是實時數據寫入、還是數據的讀取都表現出了極強的穩定性;同時工程端實時監控用戶訪問和數據響應效率,實時分析解決業務問題;產品巡檢涵蓋了產品的核心數據,進一步的保障了整個產品的穩定性
  • 高效:流批技術的應用,以及Hologres的統一對接,不僅大幅度的提升了活動期間的需求接入效率(今年雙十一期間整體需求承接能力是去年的3倍),同時整體的提升了問題反饋和解決的時效(相比以往活動提升了3-4倍)

五、未來展望

雖然已經經歷了一次大促大考驗,但是技術的探索永無止境,我們需要不斷的完善來應對更加復雜的業務場景:
1)Dataphin流批一體的產品進一步完善,減少人工干預成本,同時進一步保證數據質量
2)Hologres資源隔離,讀寫資源隔離,更好地保證查詢的SLA;打通Hologres與MaxCompute,支持元數據的互通,為產品元數據提供更高的保障;動態擴容,能夠靈活應對峰值及日常的業務需要。
3)FBI產品工具,能夠提升產品版本管理功能,同一頁面支持多人編輯不覆蓋,更加高效的支持產品搭建


原文鏈接
本文為阿里雲原創內容,未經允許不得轉載。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM