當前位置: 妍妍網 > 資訊

金融級即時數倉建設實踐

2024-04-10資訊

導讀 本文將分享螞蟻集團近兩三年在即時數倉領域的探索和實踐。

本次分享將圍繞以下四個方面展開:

1. 螞蟻即時數倉架構

2. 即時數據品質保障

3. 流批一體套用

4. 數據湖落地展望

分享嘉賓| 馬年聖 螞蟻集團 即時數倉架構師,數據技術專家

編輯整理|梁維

內容校對|李瑤

出品社群| DataFun

01

螞蟻即時數倉架構

1. 即時數倉架構設計

螞蟻即時數倉的架構主要包括計算引擎、研發平台、計算資源、即時資產、研發工具和數據品質六大模組,這六個模組覆蓋了即時數據研發的全流程,但也面臨著許多問題,包括如何管理即時數據資產和口徑、如何管控即時資源、平台能力是否健全等。

在即時數據的套用場景中,數據的準確性和穩定性尤為重要。因此,如何持續監控和發現數據品質問題是即時數據研發過程中面臨的一大挑戰。同時,隨著即時數據套用場景的增加和需求吞吐量 的上升,還需關註即時研發流程效率如何提升和計算能力如何建設的問題,這就需要我們深入到即時研發鏈路中分別攻克相應的痛點。

相較於離線完善的即時計算引擎和生態,即時數據研發生態和資產相較而言還有較大的提升空間。和業界開源使用的 Hive/Spark 離線計算生態類似,阿裏的 ODPS 也有一套完善的計算體系,從上到下包括客戶端模組、接入層、邏輯層和儲存計算層,同時還有相對應的帳號和元資訊服務。如果只是離線數據計算和分析的話,當數據入倉後即可在此生態內一站式地進行研發和運維。

即時計算對使用者而言復雜很多,其中最突出的是即時數據資產以及對應的儲存。根據計算特性和方案的不同,即時計算可以對接相當多的儲存引擎,每個引擎又都有相對應的計算和儲存特點,如何管理好這些連線資訊和其底層對應的數據語意,是即時資產模組需要建設的能力。

和離線計算類似,即時資產也應該具備數據內容定義(對標 ODPS 表 Schema 定義)、生產體系(對標 ODPS 計算能力)、消費體系(套用數據的對外使用)和資產管理(即時數據的管理)等能力。綜合以上的考慮,螞蟻透過即時元表來進行即時資產的定義和管理。即時元表之上建設了元表定義、元表消費、元表管理和元表品質四塊的能力,讓使用者基於元表便能進行即時數據的研發和運維操作。

螞蟻即時數倉架構主要包括資料來源接入、即時數據儲存、即時計算引擎、即時數據研發能力、即時數據服務和即時數據品質幾大模組,細節如下:

(1)螞蟻的即時計算資料來源主要來源於線上日誌、資料庫日誌和即時訊息,計算引擎選用 Flink 和 ODPS(主要用於維表加工),儲存引擎和業界對齊,包括訊息中間層 Sls、OLAP 引擎 Explorer、OLTP 儲存引擎 Hbase。

(2)相較於離線計算中的統一物理檔和 Meta 資訊,即時計算的儲存選型是多樣的,不同的即時儲存引擎都有自己的檔儲存模式和底層資訊格式,這裏使用元表維護不同的資料來源、物理表、欄位的定義,並做到定義可復用的能力。

(3)在計算研發平台中,除了基礎的即時計算能力以外,我們著重構建了低程式碼研發和流批一體的能力,其中低程式碼研發是希望使用者直接進行配置即可完成即時任務的研發和上線。而流批一體主要解決即時離線數據口徑、消費鏈路不統一的問題,期望透過一套程式碼和一套引擎來提升研發和運維的效率。

(4)對於即時數據的消費模組,主要分為即時數據分析和即時數據服務兩大場景,其中 OLAP 場景主要解決即時數據多維分析的問題,而 OLTP 場景則會和工程演算法層進行聯通,提供線上的即時數據服務。

(5)對於即時數據品質模組,基於即時元表構建了較多的事實數據保障能力,如 DQC 監控、主備對比、異源核對等。

2. 即時數據解決方案

流量場景中轉化歸因是流量效能的一大重點,離線中透過流量日誌和轉化日誌關聯,並使用自訂排序演算法,剔除返回的路徑,最後生成使用者轉化的路徑圖。

在即時計算中,雙流 join 可解決此類問題,但流量過大會導致 Flink 後端狀態過大,且如果多個轉化事件接入後,計算成本成倍增長。亦或者將流量數據寫入到諸如 Hbase 的維表中,轉化事件到來時進行維表關聯,但此方案需要嚴格的流量在前、轉化在後的上報邏輯,如果流量日誌延遲上報,轉化數據就會失真。最終我們使用即時流圖來解決此類問題:

(1)首先在圖資料庫中,構建使用者和流量日誌、轉化事件的關聯關系,當一個轉化事件觸發後,會篩選使用者完成轉化事件之前的流量路徑。

(2)根據流量日誌的時間生成路徑的拓撲,剔除掉鏈路中的環,最後生成使用者的存取路徑圖。

(3)將以上生成的拓撲圖打平拆成多條記錄,形成即時轉化歸因表,進行實分時析和二次消費。

當前方案主要依賴圖進行歸因的計算,Flink 只是做了數據入圖和消費圖中結果數據的工作。除此之外,還有一些後續會實踐的解決方案:一是端上流量日誌串聯,透過在端上定義重要轉化事件,實作邊緣計算效果;二是數據湖準即時構建,以解決狀態問題。

去重類指標主要套用於兩個場景:一是繪制天級按分鐘累計的趨勢圖;二是在活動期間,檢視整個活動期間的使用者。即時計算在活動期間可能面臨狀態較大的問題,一旦發生問題,回補計算將變得困難。針對這些場景,我們有以下幾種解決方案:

(1)對於天級按分鐘累計,對使用者進行去重,將去重後的分鐘級新增數據分發並聚合,從而得到累計數據。但這種方法存在數據量大、難以回補的問題。

(2)可以使用 Flink Cumulate Window 來計算累計 UV,這是一種漸進式視窗,能夠直接計算累計數據。

(3)維表 Join 也是一種常用方法,透過將使用者明細流寫入維表並關聯,可以判斷使用者是否之前來過,從而計算新增數據。

(4)還可以使用估算能力,如 Hyperloglog 或 Thetasketch,生成 UDF 進行聚合,得到最細粒度的累積數據,在下遊使用 merge 能力達到高精度的累積 UV。

如果希望得到準確的累計 UV 的即時數據,並且也希望保證查詢端具有一定的靈活性,可以使用 BitMap 來實作,如計算每小時的 Bitmap Bytes,在查詢時進行Merge Agg,但對於活動期較少的場景,分小時的 Bitmap 數據會有較多的小檔,影響查詢的效能,是否可以將累計的 Bitmap 進行合並,這樣就能保證查詢是 Bitmap 檔在較小的數據量,具體細節在後續流批套用場景介紹。

02

即時數據品質保障

螞蟻的即時數據品質在事前和事中兩個階段進行針對性保障,其中:

  • 事前首先在研發過程中進行程式碼的偵錯和診斷,重要的即時場景還會對即時任務進行壓測,在觀察任務的消費能力達到目標值,且上下遊中介軟體保持穩定的前提下,設定即時任務對應的限流值。

  • 事中則圍繞任務異常監控和數據異常監控兩塊進行構建,其中任務異常監控主要對即時任務本身的穩定性進行監控和預警 ( 如任務延遲、 failover 次數、 checkpoint 失敗率等 ) ,而數據異常監控則對數據本身進行規則校驗 ( 如跌 0 、同環比波動、閾值分布等 )

  • 相比離線可能動不動就是幾十層的鏈路相比,即時端到端的全鏈路任務數是相對較少的,但因為即時資產本身的復用性和邏輯抽象,也會出現 5+ 層的情況。對於此,透過全鏈路基線進行端到端的即時數據時效性監控。

    最後則是服務異常監控,主要面向即時數據服務的可用性進行監控。透過以上研發流程的各節點的即時數據品質監控能力,來保障即時數據端到端的數據時效性和準確性。

    除了圍繞研發流程進行保障以外,從數據流通的全生命周期和全鏈路,也能夠進行相對應的監控和保障,主要包括生產和消費兩大環節,其中:

  • 生產環節包括資料來源監控、計算層監控和儲存層監控,這三者對應即時計算任務的 Source Runtime Sink ,這個數據穩定性對三者缺一不可。 資料來源監控包括數據上報的時效 ( 同業務端共同監控 ) 、采集延遲、采集服務本身的穩定性監控等 ; 計算層則是即時計算任務以及對應的底層元件的穩定性監控 ; 儲存層則是對中間 / 結果數據的儲存引擎進行保障。

  • 消費端從查詢層和套用層兩塊進行保障,其中查詢層對查詢引擎的穩定性進行監控,如查詢服務水位監控、查詢報錯告警、查詢耗時告警等 ; 而套用層則需要和數據使用平台進行聯合保障,對數據產品 / 平台進行套用角度的保障。

  • 在對以上每一層的穩定性監控之後,可將所有的相關 Metric 資訊統一收集,並配置相應的即時數據監控大盤,全方位了解即時數據品質的健康度,當前這塊能力還在設計並逐步構建中。

    任務粒度品質監控主要具備三個能力:任務 DQC 覆蓋單任務的品質波動監控,異源核對覆蓋即時和離線數據的比對,主備監控則覆蓋主備鏈路的數據比對,以上能力基於即時的 Metric 指標采集和結果數據構建。

    透過 UDF 的方式,在即時任務中加入Metric 采集模組,數據異步傳輸到後端資料庫中,監控系統根據使用者配置的規則,觸發 Metric 采集和校驗。

    即時全鏈路保障依賴即時任務和元表血緣,構建即時場景和即時基線能力,其中:

  • 即時場景對即時資產使用範圍進行分類,作為資產重要性評估的重要依據,同時也作為即時計算的輸入項。

  • 即時基線則對上掛的事實元表進行血緣追溯,監控全鏈路中即時任務的數據時效,當前有三大類即時基線: 大促臨時基線、以場景為依據的基線和中間層重要基線,根據基線的優先級進行不同措施的即時數據保障。

  • 03

    流批一體套用

    在構建流批能力之前,先來看下當前即時數倉中的數據鏈路情況。在 Lambda 架構中,三個消費場景的即時離線數據融合方案還不統一,從數據側到套用側都有觸發流批數據融合的邏輯,但本質上還是流批模型欄位對齊的語意表達,下遊便可實作欄位對齊邏輯。

    其次在即時數倉中,大部份都是 ODS/DWD 層直接計算累計結果,而離線數倉中,套用層數據大部份都是從輕度匯總層計算得到。因此在構建流批數據時需要考慮這樣的差異,可能流和批表的對齊方式就是明細和匯總。

    流引擎和批引擎在落地的過程中有很多的工作量,這裏主要介紹 Flink 批計算引擎的架構:

  • 排程層: 螞蟻 Flink 的排程使用原生的 K8S 排程,同時嘗試集群排程模式,在 K8S 之上直接獲取機器資源,減少任務釋出上線的時間,同時保障任務的穩定性。

  • 引擎層: Flink 研發運維同學做了很多的工作,從上往下看,首先對齊 BlinkSQL 完成計算函式的新增,並最佳化了部份執行計劃推斷的邏輯,如單表抽取了 ab 欄位,同樣的表抽取了 bc 欄位,則會對 source 表進行合並讀取。

    引擎執行最佳化方面,對批計算中的並行度、 CPU 和記憶體進行配置, Connector 的並行度根據數據量進行推斷,而執行中搭配 AdaptiveBatchScheduler 進行動態調整。 對於 CPU 和記憶體,則根據不同的算子類別型進行設定,並透過線上任務的執行驗證,保證批任務的執行效能和穩定性。

    Connector 方面則主要對齊 Blink 進行適配,考慮到批任務在計算完成之後一次性同步會產生輸出洪峰,為了保護線上庫,設定限流是相當必要的,引擎側在 Connector 外掛程式中實作了限流的能力。

    DataStream 引擎和算子主要使用開源能力。 最後在可插拔元件中,我們主要對 Shuffle 元件、排程元件和後端狀態進行了適配最佳化。 批任務預設使用基於 TaskManager 本地磁盤的 Shuffle 方式,這種方式對本地磁盤的要求比較高,在上下遊互動的時候存在依賴關系,我們引入了開源的 flink remote shuffle 元件,獨立部份 Shuffle 元件,實作計存分離的架構。

  • 平台層: 對批任務的預編譯、偵錯、送出、釋出進行了支持,對於離線程式碼中的時間變量、任務參數進行解析轉譯。 其中最重要的是將 Flink 批計算型別加入到離線排程引擎中,依賴 Odps 等其它任務產出的數據,在排程執行時生成任務例項,並查詢具體的執行日誌。

  • 對於流批表對齊的問題,我們來看以上兩個 Case,在流和批都是明細的情況下,流和批的欄位含義不一致和不對齊是常見的,比如離線是否打標是 Y/N,即時打標 1/0。而對於流明細批匯總的場景,比如離線時算到使用者粒度的輕度匯總數據,對於 PV 這樣的欄位,即時肯定是沒有的。

    對於以上這類問題,一個方案是某一方進行數據的改造,保證兩側的數據欄位對齊,但是成本相當高。因此,我們設計了虛擬列欄位,對於某一方不存在的情況下,使用虛擬列標識,同時對流表和批表進行參數定義,這樣就能在程式碼中顯式的判斷和處理,以此來解決流批欄位不對齊的問題,在這樣的能力支撐下,即使是流和批表欄位完全不一致的極端情況,也能進行特判和處理。

    過去如果需要計算即時長周期累計指標(如活動期累計 PV/UV、視訊累計觀看次數),一般會使用離線 Odps 任務計算好 T-1 的累計值,並回流到 Lindorm 中,即時任務計算當天的數值,關聯 Lindorm 中的 T-1 累計值進行相加,得到截至當前的即時累計匯總值。對於此套方案,即時和離線任務需要分別開發,並且根據計算引擎的特性會有不一樣的計算邏輯。在套用流批一體能力後,其計算方案如下:

    首先透過混合元表將即時和離線資料來源進行繫結,流批任務基於混合元表進行分天匯總指標的研發,同時在批代分碼支上增加離線累計指標的計算(簡單的 T-2 累計 + T-1 分天的計算),並將計算好的指標直接寫入到 Odps(用於下一次計算)/Lindorm(用於即時關聯),最終實分時支將即時天級匯總關聯 T-1 累計匯總,求解得到即時累計匯總值。

    此套方案在保障數據口徑一致性的前提下,只需要一個任務即可完成即時累計指標的計算,得益於 Flink 強調的即時研發生態,可以直接將結果數據回流到所有需要用到的儲存中,便於多場景的數據使用。

    04

    數據湖落地展望

    以上的流批一體方案還只是計算層的流批,在程式碼中需要明確區分流任務和批任務的處理方式。流數據一般儲存在訊息中介軟體中,而批數據則儲存在 ODPS 中。研發時需要感知流和批任務的不同特性,並進行針對性的處理。

    在計算流批之上可以透過儲存的流批一體,透過將即時數據和離線歷史數據回流到數據湖中,來實作最終的流批一體計算儲存方案。螞蟻當前選用的是 Paimon 作為數據湖元件,基於 Paimon 可以實作從 ODS 到 ADM 層進行數據準即時的計算和消費。

    螞蟻當前主要有三條不同時效性的排程任務,分別是:天級排程、小時級排程和即時任務,綜合三者的數據基本可完成所有的數據需求研發,但在開發過程中需要進行數據的來回同步,計算鏈路相當復雜。在參照 Paimon 作為進行即時數據湖研發之後,可在 Paimon 這一元件中完成全鏈路的準即時數據研發,大大簡化了即時研發的鏈路和復雜度,並可實作一套計算引擎、一份儲存、一份資產。

    以上就是本次分享的內容,謝謝大家。


    分享嘉賓

    INTRODUCTION


    馬年聖

    螞蟻集團

    即時數倉架構師,數據技術專家

    馬年聖,畢業於河海大學,先後就職於網易、阿裏、螞蟻等互聯網公司,當前工作重心在即時數據研發和架構,負責螞蟻集團廣告、決策等領域即時數據

    往期推薦


    點個 在看 你最好看

    SPRING HAS ARRIVED