農業銀行湖倉一體實時數倉建設探索實踐

一、引言

在數字化轉型驅動下，實時化需求日益成為金融業資料應用新常態。傳統離線數倉“T+N”資料供給模式，難於滿足“T+0”等高時效場景需求;依託Storm、Spark Streaming、Flink等實時計算框架提供“端到端”的實時加工模式，無法沉澱實時資料資產，存在實時資料複用性低、煙囪式垂直建設等不足。

為此，可透過建設實時數倉解決上述問題，實時數倉在離線數倉基礎上進一步滿足時效性的要求，依託流批一體、湖倉一體、雲端計算等技術，兼具時效性和靈活性優勢，可作為金融業實時資料的生產、儲存和使用平臺。

為解決傳統數倉資料時效性低等問題，實時數倉在技術路線上有多種路徑：

一種是基於Lambda架構的實時數倉，作為當前主流實時數倉架構，其在現有成熟離線加工鏈路上，增加實時計算鏈路，參照ODS、DWD、DWS等模型分層組織理念，實現與離線數倉的協同，通常採用Kafka訊息佇列、Flink計算引擎等組合實現，建設成本較低，但架構複雜，運維成本較高;

一種是基於Kappa架構的實時數倉，與Lambda架構相比，其移除了離線生產鏈路，完全依賴實時加工鏈路，其優點是資料來源統一，架構相對簡化，節約開發及日常運維成本，但不易進行資料回溯計算，比較消耗記憶體計算資源;

此外，還有一類採用實時OLAP技術，將聚合分析計算由OLAP引擎承擔，減輕實時計算部分的聚合處理壓力，分析自由度高，減輕了計算引擎的處理壓力，但對引擎的吞吐、儲存和實時攝入、分析效能要求較高，此類實時數倉通常基於商業資料庫產品，如Hologres、GaussDB等。

同時，隨著Hudi、Iceberg、Delta Lake等資料湖技術發展，依託資料湖底座的湖倉一體實時數倉建設正在興起，對推進企業數字化轉型具有重要價值：

一是彌補現有架構的不足，湖倉一體實時數倉彌補了傳統數倉對於資料實時處理能力的不足，具備多引擎、多型別資料處理能力，流批一體加工型別豐富，避免了傳統數倉無法分析非結構化資料等問題。

二是降低企業成本，湖倉一體實時數倉提供統一流批資料底座，避免不同平臺間資料移動，降低資料流動帶來的開發成本及計算儲存開銷，提升企業效率。

三是提升企業級資料分析整合能力，湖倉一體實時數倉打破了資料湖與資料倉儲割裂的體系，將資料湖的靈活性、資料多樣性以及豐富的生態與資料倉儲的企業級資料分析能力進行了融合。

二、實時數倉建設思路

自農業銀行大資料平臺建設以來，經過多年的不斷髮展，沉澱了豐富的離線數倉模型資產，具備PB級資料儲存和處理能力，支撐數百個應用場景。但總體來看，當前資料服務供給時效仍以T+N天為主，雖然依託實時流計算平臺支撐了實時存款大屏等高時效應用，但“端到端”的流加工模式難於實現實時資料資產沉澱和複用。

實時數倉基於資料湖技術能力，支援構建穩定、全面、高擴充套件性的實時資料基礎層，建設和沉澱農行共性實時資料資產，滿足不同實時分析應用用數要求，提升資料模型加工時效性(見下圖)，結合Flink、Hudi等資料湖儲存計算引擎，支援流資料、檔案等資料入湖，利用Flink流批一體計算引擎層次化組織企業級實時資產，促進全行實時分析應用的統一。

相比前期的實時流計算平臺，它具有面向主題、有整合性、相對穩定等的資料倉儲本身的特性，提供穩定、持續的實時資料統一整合能力，支援共性、個性層次化實時資料模型的構建，滿足不同型別應用對流批資料加工模式的痛點需求。

為了提升實時資料資產的複用性，支援不同的應用，實時數倉採用資料分層理念組織實時資料資產。同時，考慮到層次增加會提高資料處理成本和時延，為縮短加工鏈路，實時數倉資產組織為ODS、DWD、DWS，外加DIM層。

lODS層

基於Hudi儲存原始資料，Binlog日誌訊息轉換成Upsert流式入湖，資料與生產源系統資料保持一致，保持原子粒度的資料。

lDWD層

和離線數倉中DWD層主題劃分一致，主要是為了解決一些原始資料中存在的噪聲、資料不完整和資料格式不一致的問題，形成規範、統一的資料來源。DWD層包括資料解析、業務整合、髒資料的清洗和模型規範化。

lDIM層

DIM層是實時數倉中的維度資料，主要分為2類：變化頻率低的和變化頻率高的維度資料。對於變化頻率較低的維度資料，比如說機構資訊等，可以透過離線維度資料同步到快取或者透過公共維度服務進行查詢;對於變化頻率較高的維度資料，比如說匯率、價格等資訊，則需要監聽其變化情況，維護變動資訊。

lDWS層

DWS層即彙總層，主要是對共性指標的統一加工，同時根據主題進行多維度的彙總等操作。特別地，對於時間區間的彙總，可以使用Flink中豐富的時間視窗實現。

三、實時數倉建設關鍵技術

1.實時資料入湖

實時資料入湖是湖倉一體實時數倉資料模型建設的基礎，與流計算模式下“即用即棄”的資料處理策略不同，湖倉一體實時數倉藉助Hudi資料湖儲存引擎對實時流資料進行攝入儲存，以支援流讀、批讀等流批一體處理。為了支援實時資料Upsert語義，並提供ACID事務保證，實時入湖環節會帶來較高的處理開銷，因此為了保障大規模實時資料持續穩定入湖整合，該環節對Hudi表型別、壓縮機制、Flink checkpoint間隔設定等有較高要求。

實時入湖表型別選取方面，根據讀寫特性的不同，Hudi表型別區分為MOR(Merge On Read)、COW(Copy On Write)模式。MOR方式透過不斷追加日誌，在讀取時進行合併，適用於高吞吐寫入場景;COW方式是在寫入就進行合併操作，適合快速讀取場景。為保障農行高吞吐實時交易等資料入湖，對於個人活期交易明細等大表優先選擇MOR方式。

入湖過程中持續的併發寫入，容易導致資料規模的膨脹和放大，需要週期性進行壓縮。同時，Hudi資料的可見性依賴於Flink計算引擎的CheckPoint間隔設定，在寫入操作和壓縮操作的雙重壓力下，為了避免壓縮操作與checkpoint的相互阻礙，可以採用離線壓縮模式，提升作業的穩定性。

此外，針對各表不同的資料量，實時數倉會針對實時處理作業的執行CPU、記憶體進行調整，以滿足接入作業執行需求;為了保障後續的資料血緣追蹤，採用Hive MetaStore作為技術後設資料的儲存。

2.流批資料模型加工

實時資料透過實時入湖集中接入資料湖後，將轉換成流批一體的資料格式，支援流批方式的讀取和加工，針對實時資料模型構建過程中的資料依賴特點，實時數倉在資料資產模型的加工能力支援上有不同的側重點。

情形一：資料模型完全依賴於增量資料：增量資料均可以實時入倉，並完成後續鏈路的實時流轉，得到分鐘級結果;

情形二：資料模型部分依賴於存量(無變化)資料：對於全量資料無變化的依賴資料，可以將存量資料進行加速(快取至Redis/Hbase等)，實現分鐘級模型生成，但對存量資料的管理要求很高。

情形三：資料模型部分依賴於全量(存量+增量)資料：對於全量資料緩慢變化的依賴資料，可以將存量資料進行加速(快取至Redis/Hbase等)，並實時維護資料變化，實現分鐘級模型生成，但對全量資料的管理要求很高。

情形四：資料模型完全依賴於全量(存量+增量)資料：分鐘級就緒，需要時觸發批次排程執行，適用於批次模式;

此外，結合農行資料模型的特點，實時數倉對明細類實時資料、主檔類實時資料的處理策略有所不同。

① 明細類實時資料

對於明細類交易資料，資料前後關聯度較低，可以採用流式寫入、流式讀取的方式進行增量處理。

② 主檔類實時資料

對於主檔類資料，資料需要考慮存量和增量的關係，而存量資料往往資料量比較大，無法直接進行關聯處理，可以採用流式更新、批次讀取的模式，及時準備好全量資料，實現模型的即時加工。

3.維度資料服務

為提升資料加工時效，實時資料模型對常用的基礎維度進行提前補齊，在滿足吞吐量等情況下，實現實時資料擴維，以空間換取時間，為資料分組彙總等提供基礎資料準備。例如：主檔類等具有存量資料的模型，可維護在Hbase、Redis等KV儲存引擎中，基於Ad hoc查詢的方式實現資料的拼接處理，實現加工鏈路提速，不會由於主檔類資料的加入而導致全鏈路時效性降低。維度服務作為一種特殊的整合方式，提供全量上線、實時更新和批次增量更新模式。

維度載入

首次上線時，從大資料平臺主庫提取完備的全量資料，基於離線載入方式完成維度資料的全量鋪底，如基於Bulkload載入全量資料到Hbase。

維度更新

維度上線後，為了及時地反映維度資訊的變化，維度服務同時會接入維度變化的實時流資料進行更新。

維度修正

為了減少離線、實時通道維度資料的偏差放大，維度服務將週期性進行維度資料同步更新修正，實現最新的維度資料和離線維度資料的一致性，避免後續計算口徑出現大的偏差。

4.寬表模型加工

寬表是按照“向主流標準靠攏”的方法對資料中臺基礎資料進行標準化組織整理形成的企業級資料模型表，作為農行新一代大資料模型規範，經過不斷迭代和發展，形成了理財、貸款等多種領域寬表。離線寬表模型核心是基於T+N的離線資料處理，因此具有強一致性、高吞吐性等特點，另一方面，為了保證更強的靈活性，離線寬表模型依賴關係錯綜複雜，流轉鏈路較長。

對於實時寬表而言，直接將離線寬表模型照搬到實時寬表模型成本代價高昂，加之加工環節的相互制約，時效性提升受限，不易實現成本和可行性價值的最大化。在實際業務場景中，很多場景其實並不要求全欄位實時化，而是專注於拿到實時的事實資料，因此實時數倉在T-1離線寬表基礎上，透過擴增高時效欄位等方式進一步滿足高時效場景。

四、實時數倉建設探索實踐

1.實時理財寬表探索

為探索寬表時效性提升路徑，實時數倉以理財寬表為試點，探索實時寬表建設思路。透過梳理整體加工鏈路，發現當前離線寬表模型具有如下顯著特點：

一是增量模式少，增全量模式多，其中交易拼接通用寬表增量與增全量加工比例為(3/25)，理財產品歷史通用寬表(0/6)，理財合約拼接通用寬表(0/43)。

二是模型層次多，加工鏈路普遍較長，層次普遍在3~7層。

三是模型之間依賴複雜，存在較多關聯，模型之間存在大量Join操作，個別模型單次存在11張表關聯。

因此，為了實現上述複雜鏈路的時效性提升，對於明細資料，實時數倉基於Upsert模式實現明細資料的維護，按時間分割槽分鐘級流式寫入，提供流式讀增量資料，支援了分鐘級資料鮮度。

對於主檔類資料，由於具有歷史資料，實時數倉採用Bulk Insert模式實現存量資料的鋪底入湖，透過Hudi全量資料接增量的方式，解決歷史資料首次載入，並平滑銜接增量資料的問題。同時，基於流式寫分鐘級更新資料狀態、批次讀取模式提供最新全量快照結果。

透過對明細、主檔類基礎資料的實時化處理，可以為寬表模型提供分鐘級資料，提升寬表產出時效，支撐重點鏈路分支分鐘級、整體T+0的資料供給時效。

2.實時標籤場景實踐

針對網金等實時標籤建設需求，實時數倉透過個人活期交易、掌銀新註冊客戶等明細模型建設，複用同一共性實時模型資料基礎上，拆分跨行交易、個人基金、代發工資3類主題資料，支援標籤中心不同型別實時標籤構建。此模式按照主題進行管理，進行統一的加工，比如清洗、過濾、擴維等，給下游提供直接可用的資料，避免了資料的重複加工，同時也實現了實時資料的儲存回溯，可滿足後續實時標籤等多場景建設。

在個人活期交易明細共性模型資產建設實踐中，為了滿足單表日均億級的高吞吐入湖整合，實時數倉從Hudi表型別、資料分割槽、Hudi壓縮等措施最佳化配置，實現高吞吐實時流資料場景下的穩定入湖：

1)Hudi表選型方面，透過長週期疲勞測試發現，此場景下基於COW型別作業會出現較大反壓、延遲逐漸放大等情形，為了避免延遲情況，實時數倉基於MOR表的模式，滿足高吞吐實時資料的快速入湖;

2)資料分割槽方面，實時數倉對明細資料模型進行日期分割槽，考慮到明細類資料插入多、更新少等特點，為了減輕Hudi的Index索引壓力，進一步降低索引存效時間;

3)壓縮方面，實時數倉考慮到線上壓縮對入湖任務造成的不穩定性，採用了離線壓縮，透過指令碼控制壓縮計劃的執行，確保不會出現積壓的問題。

基於沉澱的共性模型資產，實時數倉先後支撐大額動賬實時線索、掌銀新客實時標籤、代發工資實時標籤等多個場景建設。

五、未來展望

湖倉一體實時數倉將資料湖的靈活性、資料多樣性、豐富生態與資料倉儲的企業級資料分析能力進行了融合，對實時資料模型建設具有重要價值。未來，隨著農行資料湖建設，實時數倉將融合資料湖基礎底座建設，構建穩定、全面、高擴充套件性的實時資料基礎層，建設和沉澱農行共性實時資料資產，滿足不同實時分析應用用數要求。實時數倉基於流批一體資料整合，提升資料加工時效性，促進全行實時分析型應用架構的統一，對實時場景建設支撐等具有重要意義。

1.持續穩定的實時資料供給

實時數倉基於湖的平臺化實時整合能力，可以實現對豐富的實時流資料整合，降低各類實時應用實時資料整合建設成本;同時依託資料湖流批一體儲存特性，以實現時間旅行等一些新特性，滿足可靠性要求等場景，比如某個時間端實時資料的重放處理等等。

2.豐富的實時資料模型資產

實時數倉統籌供給共性的實時資料模型資產，避免了各實時應用端到端的重複加工。比如基於明細層模型，運營可以獲取到機構級的彙總結果，營銷可以彙總到產品級的結果等等，而各自無需對明細處理，實現實時資料的一口出。

3.開放的多租戶能力建設

資料湖倉租戶依託資料湖統一存算底座，低成本拎包入住，實現資源申配、實時資料授權、資產發現，利用實時數倉持續實時資料、共性模型供給，並結合資料湖一站式DataOps標準化工藝，無需資料出湖，提升資料加工時效，滿足實時應用場景快速落地，實現資料湖價值最大化。

下一步，實時數倉將深度融入到湖倉一體建設，藉助現代資料棧，實現統一資料血緣、安全管控、服務共享等，助力農業銀行企業級實時資料應用生態發展。