《金融信息化研究所(FITI)&華為云:金融數據倉庫發展報告(2022)(73頁).pdf》由會員分享,可在線閱讀,更多相關《金融信息化研究所(FITI)&華為云:金融數據倉庫發展報告(2022)(73頁).pdf(73頁珍藏版)》請在三個皮匠報告上搜索。
1、金融信息化研究所(FITI)2022 年 11 月(白皮書)編制委員會主 任:潘潤紅副主任:習 輝、莊文君編委會成員(排名不分先后,按姓氏拼音排序):董理斌、辜 敏、郭 煜、劉遠東、李 凡、彭貴平、饒爭光、田永江、童 蕙、王 瑜、魏文術、向 民、謝云龍、葉 濤、尤 鵬、尤 俊、周 全執 筆(排名不分先后,按姓氏拼音排序):曹嘉欣、從平平、馮明亮、高 犇、高 鵬、侯 偉、黃海燕、黃書春、李 杰、李 智、劉志浩、劉振東、彭 強、孫玖山、蘇 萌、王漢福、王健楠、王帥強、王志遠、魏 沖、徐嘉禛、楊 銳、楊大鵬、趙昆鵬、趙義斌、張 倩、周曉陽、朱并隊統稿人(排名不分先后,按姓氏拼音排序):從平平、張 倩
2、主編單位:金融信息化研究所華為云計算技術有限公司中國工商銀行股份有限公司交通銀行股份有限公司中國光大銀行股份有限公司招商銀行股份有限公司參編單位:中信銀行股份有限公司中國民生銀行股份有限公司華夏銀行股份有限公司興業銀行股份有限公司中原銀行股份有限公司威海市商業銀行股份有限公司江蘇江南農村商業銀行股份有限公司中電金信軟件有限公司深圳市長亮科技股份有限公司北京宇信科技集團股份有限公司I金融數據倉庫發展報告(白皮書)摘 要隨著數字金融快速發展,金融業數據量爆發式增長,數據挖掘、分析、應用已逐步成為金融業務發展和管理決策的重要支撐手段,數據成為金融機構的核心資產。數據倉庫可對異構源數據進行有效集成,面
3、向數據分析場景,支持全局信息共享和決策分析處理,充分釋放數據價值,助力構建數據要素市場。針對金融數據服務、存儲、處理、質量和安全等不同維度的需求,金融數據倉庫需提供適配的架構和技術,包括超大規模并行處理滿足海量數據的算力要求、高可用及容災技術實現數據永遠在線、動態負載管理滿足多樣化負載統一管理、數據安全技術保障數據合規訪問、融合分析技術打通結構化與非結構化數據分析邊界、彈性擴展技術滿足系統在線按需擴展以及管控一體的智能運維釋放運維壓力等。為順利開展金融數據倉庫建設,金融機構應進行合理規劃、精心組織、高效實施,準確把握數據倉庫的 T+0,湖倉一體、數智融合、存算分離、高維分析、HTAP、Data
4、 Mesh、Data Fabric、現代數據棧及數據共享十大發展趨勢,切實提升金融數據應用水平,助力金融科技快速發展、金融業數字化轉型深入推進。I金融數據倉庫發展報告(白皮書)目 錄1.概述.011.1.數據倉庫發展歷程.011.2.數據倉庫成為金融行業的重要應用.022.金融數據倉庫發展現狀.042.1.金融數據倉庫建設進展.042.2.金融數據倉庫數據存儲情況.072.3.金融數據倉庫投入情況.082.4.金融行業使用數據倉庫的痛點及訴求.093.金融關鍵業務對數據倉庫的要求.113.1.數據服務要求.113.2.數據存儲要求.123.3.數據處理要求.143.4.數據質量要求.153.5
5、.數據安全要求.164.金融數據倉庫總體設計與關鍵技術.184.1.金融數據倉庫模型.184.1.1.數據倉庫模型設計原則.184.1.2.數據倉庫模型層次.204.1.3.數據倉庫建模方式.204.2.金融數據倉庫架構設計.214.2.1.數據倉庫架構設計原則.214.2.2.數據倉庫典型設計架構.224.3.金融數據倉庫典型技術架構.234.4.金融數據倉庫的關鍵技術.254.4.1.超大規模并行處理滿足海量數據的算力要求.254.4.2.高可用及容災技術實現數據永遠在線.26II4.4.3.動態負載管理滿足多樣化負載統一管理.274.4.4.數據安全技術保障數據合規訪問.294.4.5.
6、融合分析技術打通結構化與非結構化數據分析邊界.304.4.6.彈性擴展技術滿足系統在線按需擴展.304.4.7.管控一體的智能運維釋放運維壓力.315.金融數據倉庫建設策略.335.1.指導原則.335.2.建設規劃策略.335.2.1.實施規劃.345.2.2.運營規劃.355.3.實施要求.385.3.1.組織架構.385.3.2.實施過程.395.3.3.規范約束.395.3.4.實施注意事項.405.3.5.主要交付件.406.金融數據倉庫十大發展趨勢.426.1.T+0 分析.436.2.湖倉一體.446.3.數智融合.446.4.數據共享.456.5.存算分離.456.6.高維分析
7、.466.7.HTAP.466.8.數據網格(Data Mesh).476.9.數據編織(Data Fabric).476.10.現代數據棧(Modern Data Stack).47附錄:金融數據倉庫行業實踐.49金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究I圖目錄圖 1 金融數據倉庫建設情況.04圖 2 不同類型金融機構使用我國主流數據倉庫產品情況.05圖 3 國有大行、股份制銀行主流金融數據倉庫產品使用情況.06圖 4 金融數據倉庫數據量分布情況.07圖 5 不同類型金融機構數據倉庫數據量情況.08圖 6 數據倉庫在所有數據庫中的投入占比情況.08圖
8、 7 金融數據倉庫應用的主要痛點分析.09圖 8 金融機構對數據倉庫的訴求分析.10圖 9 數據倉庫典型設計架構示意圖.22圖 10 典型銀行的數據倉庫平臺技術架構圖.24圖 11 數據倉庫建設規劃示意圖.33圖 12 容災規劃的三種形式.37圖 13 實施組織架構圖.38圖 14 金融行業對數據倉庫技術關注熱度分布.42金融數據倉庫發展報告(白皮書)01金融數據倉庫發展報告(白皮書)1.概述1991 年 Bill Inmon 在Building the Data Warehouse書中提出數據倉庫(Data Warehouse)是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合,用
9、于支持管理決策。1.1.數據倉庫發展歷程早在 20 世紀 70 年代就開始萌發數據倉庫的概念,卻在相當長一段時間都停留在理論層面。一直到數據倉庫基本原理、技術架構以及分析系統等主要原則確定,數據倉庫才初具雛形。但由于數據倉庫的實施難度過大,在方法和架構上很難有清晰的路徑,導致大多以失敗告終。此時,02金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究數據集市因實施難度較低,并且能夠滿足企業部分業務部門的迫切需求,得到了一定的發展。而隨著數據集市的不斷增多,獨立建設的數據集市由于遵循不同的標準和建設原則,導致多個數據集市的數據混亂、不一致,進而產生數據孤島。為了解
10、決這個問題,1998 年 Inmon 提出了新的BI 架構 CIF(Corporation Information Factory,企業信息工廠),即在不同架構層次上采用不同的構件來滿足不同的業務需求。進入21世紀,信息化轉型的大潮席卷而來,數據量呈現爆炸式增長,得力于 Oracle、IBM 及 Teradata 等產品在分析型應用上的成熟,數據倉庫產品快速發展。1.2.數據倉庫成為金融行業的重要應用數據倉庫作為金融行業數據分析平臺的核心,能對異構源數據進行有效集成,面向數據分析場景,支持全局信息共享和決策分析處理,已成為金融行業重要的基礎設施。經過幾十年的演進和創新,當前各金融機構主要使用的
11、是第二代探索型數據倉庫。未來,隨著技術的迭代,金融數據倉庫會不斷向著運營型和智慧型邁進。初代描述型數據倉庫,基于歷史數據反映發生了什么事情。金融機構通過 BI 服務和固定報表等主要應用做 T+1 批量數據分析,為外部監管機構報送、內部經營分析及運營管理提供準確的數據支撐。第二代探索型數據倉庫,增加了數據科學場景支持,業務分析師通過自助分析挖掘數據價值,研究歷史數據得知為什么會發生這些情況。由于可以很好支持半結構化和非結構化數據,支持數據科學和機器學習,金融數據倉03金融數據倉庫發展報告(白皮書)庫的應用范圍開始迅速擴展,除了傳統的監管審計類報表應用,還涵蓋了客戶服務、產品銷售、風險管理、績效管
12、理等領域的完整數據應用,數據處理成為整個應用價值鏈交付中非常重要的環節。但隨著互聯網金融、移動支付等金融服務爆炸式擴展,金融機構在風險管控和運營管理的時效性面臨越來越大的挑戰。第三代運營型數據倉庫應時而生,也稱之為實時數倉,基于 T+0 數據描述正在發生的事情。其對探索型數據倉庫的 ETL 方式、源批量文件接入方式進行了優化,以ELT 模式實時接入源數據,強調 HTAP 混合負載能力,解決時效性問題,讓金融機構能夠從實時動態的監控指標體系尋找機會、防控風險,幫助決策者實時運營。此外,目前金融機構內部數據平臺尚未完全打通,機構之間數據處于割裂狀態,資源配置效率不高。同時,國家政策提出要從“數字基
13、建”向“數智基建”轉變,數據倉庫作為數據基礎設施的基石,通過數流和智流的融合,可助力資源配置效率提升、金融風險控制、數據資產共享。因此,金融機構開始探索面向未來的預測型數倉,也稱之為智慧型數據倉庫,可以描述將來要發生什么,以及如何引導未來。智慧型數倉融合數據分析技術和人工智能技術,引入人工智能在視頻、圖像、語音等非結構化數據的高效處理的能力,替代人類重復性工作,將有效提升工作效率與用戶體驗??傮w而言,金融數據倉庫從僅支持批量報表服務,到支持數據探索、實時分析、數智融合,支撐金融業務持續創新。04金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究2.金融數據倉庫發
14、展現狀2.1.金融數據倉庫建設進展銀行、證券、保險等不同領域的金融機構普遍建設了數據倉庫,以滿足金融業務對數據的需求。銀行業建設數據倉庫占比最高,證券業和保險業相對較低,同時,銀行業不同類型機構數據倉庫建設情況也不相同。國有大行、股份制銀行、直轄市農商行及省聯社基本都建設了數據倉庫,占比達到 100%,而區域性城市商業銀行尚有部分機構未建設數據倉庫,以數據集市應用為主,如圖 1 所示。圖 1 金融數據倉庫建設情況數據來源:金融信息化研究所金融數據倉庫建設情況國有大行股份制銀行城市商業銀行直轄市農商行、省聯社證券業保險業80.00%85.00%90.00%95.00%100.00%105.00%
15、100.00%100.00%92.31%100.00%88.46%86.67%05金融數據倉庫發展報告(白皮書)不同類型金融機構使用我國主流數據倉庫產品的情況也不相同,相較于證券業和保險業,銀行業使用我國數據倉庫產品的機構數量占比較高。不同類型的銀行業金融機構使用情況也不同,其中國有大行基本都使用我國數據倉庫產品或采取自研自建數據倉庫的模式,機構數量占比達到 83.33%,其次是股份制商業銀行和直轄市農商行、省聯社,區域性城市商業銀行使用我國數據倉庫產品的機構數量占比較低,如圖 2 所示。圖 2 不同類型金融機構使用我國主流數據倉庫產品情況數據來源:金融信息化研究所不同類型金融機構使用我國主流
16、數據倉庫產品情況10.00%20.00%30.00%40.00%50.00%60.00%70.00%80.00%90.00%83.33%66.67%45.45%14.71%9.09%7.69%國有大行股份制銀行 直轄市農商行、省聯社城市商業銀行證券業保險業0.00%06金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究1由于有些機構使用了多家廠商的數據倉庫產品,因此不同產品的百分比加和大于 100%。通過調研全量的國有大行和股份制銀行關于我國主流數據倉庫產品使用情況,可以發現其使用最多的數據倉庫產品是華為云GaussDB(DWS),機構數量占比達到 38.89%
17、,其次是南大通用 GBase 8a 和阿里云 AnalyticDB,然后是阿里云 Maxcompute 和星環 ArgoDB,此外還有 2 家機構采用自研自建模式建設數據倉庫,如圖 3 所示。圖 3 國有大行、股份制銀行主流金融數據倉庫產品使用情況1數據來源:金融信息化研究所國有大行、股份制銀行使用主流數據倉庫產品情況38.89%22.22%16.67%11.11%9.09%5.56%5.56%5.56%5.56%華為云GaussDB(DWS)TeradataOracle/Exadata南大通用GBase 8a阿里云AnalyticDB阿里云Maxcompute星環ArgoDB Vertica
18、Greenplum10.00%20.00%30.00%40.00%50.00%0.00%07金融數據倉庫發展報告(白皮書)不同類型金融機構數據倉庫存儲的數據量差異較大,國有大行數據倉庫存儲的數據量平均值最大,達到 10.76PB;其次是股份制銀行,數據倉庫存儲的數據量平均為 1.49PB;區域性城市商業銀行、直轄市農商行、省聯社、證券業、保險業等金融機構數據倉庫存儲的數據量平均值基本持平,均處于 TB 級別,只有個別金融機構達到了 PB 級別,如圖 5 所示。2.2.金融數據倉庫數據存儲情況金融數據倉庫存儲的數據量基本是 TB 級別,其中,數據量在 50T以下的金融機構占比達到 45.75%,
19、接近一半。金融數據倉庫存儲的數據量達到 PB 級別的金融機構占比達到 15.96%,但基本在 10PB 以下,數據量在 10PB 以上的金融機構占比僅有 2.13%,如圖 4 所示。圖 4 金融數據倉庫數據量分布情況數據來源:金融信息化研究所金融數據倉庫數據量分布情況50T-100T10T以下200T-300T400T-500T1P-10P10T-50T100T-200T500T-1P300T-400T10P以上21.28%11.70%6.38%4.26%1.06%2.13%13.83%2.13%12.77%24.47%08金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、
20、信息安全研究圖 5 不同類型金融機構數據倉庫數據量情況數據來源:金融信息化研究所不同類型金融機構數據倉庫數據量情況(平均值,單位:PB)1.490.260.280.330.250.002.004.006.008.0010.0012.00國有大行股份制銀行城市商業銀行 直轄市農商行、省聯社證券業保險業10.762.3.金融數據倉庫投入情況絕大部分金融機構數據倉庫的投入在所有數據庫投入中的占比均小于50%,機構數量占比達到 86.75%,其中投入占比小于 10%的金融機構占比最高,為 25.3%;數據倉庫的投入在所有數據庫投入中的占比在 70%以上的金融機構數量較少,僅有 4.81%,如圖 6 所
21、示。圖6 數據倉庫在所有數據庫中的投入占比情況數據來源:金融信息化研究所數據倉庫在所有數據庫中的投入占比情況60%-70%20%-30%0-10%80%-90%40%-50%10%-20%70%-80%50%-60%30%-40%90%-100%25.30%20.48%19.28%15.66%6.02%8.43%1.20%0.00%1.20%2.41%09金融數據倉庫發展報告(白皮書)2.4.金融行業使用數據倉庫的痛點及訴求不同類型金融機構現有數據倉庫應用過程中面臨的主要痛點各不相同。其中國有大行因其海量數據,更關注容量瓶頸問題;其他金融機構相對國有大行數據治理體系還不完善,基本都面臨數據質量
22、問題。具體情況如圖 7 所示。圖 7 金融數據倉庫應用的主要痛點分析數據來源:金融信息化研究所金融數據倉庫應用的主要痛點分析數據質量性能數據時效性容量瓶頸原廠服務能力備份容災其他擴容能力周邊配套工具完善性成本數據互通(各系統之間)國有大行股份制銀行城市商業銀行 直轄市農商行、省聯社證券業保險業90.00%80.00%70.00%60.00%50.00%40.00%30.00%20.00%10.00%0.00%10金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究總體來看,由于金融機構實時分析場景和預測分析的需求增加、數據量激增和數據共享需求增加,以及對數據倉庫性
23、能要求不斷提升,金融機構對數據倉庫進一步發展的訴求主要集中在T+0分析、數智融合(AI)、湖倉一體、存算分離及數據共享??紤]實時分析、預測分析、數據量等因素,不同類型金融機構對數據倉庫進一步發展的訴求不盡相同。具體情況如圖 8 所示。圖 8 金融機構對數據倉庫的訴求分析數據來源:金融信息化研究所金融機構對數據倉庫的訴求分析HTAP數據共享T+0分析其他存算分離數智融合(AI)湖倉一體高維分析國有大行股份制銀行城市商業銀行 直轄市農商行、省聯社證券業保險業0.00%20.00%40.00%60.00%80.00%100.00%120.00%11金融數據倉庫發展報告(白皮書)3.金融關鍵業務對數據
24、倉庫的要求目前各家金融機構逐步建立企業級數據倉庫,按照數據統一服務、數據集中存儲、數據高效處理、數據質量和數據安全管理的要求,科學合理地對金融數據進行詳細分類,準確收集和分析信息,確保企業管理層隨時掌握企業的運營情況、經營風險和經營目標。3.1.數據服務要求一是在數據服務方式多樣性方面,支撐金融關鍵業務的數據服務方式有數據文件服務、數據 API 服務、消息服務及數據管道。數據倉庫作為數據生產者,提供數據消費是其業務價值的主要體現,金融數據倉庫對接的部門和分支機構眾多,通常達數百個之多,其數據消費方式多樣,時效性要求也各不相同,數據倉庫需要提供多種數據服務形式,以滿足數據服務多樣化訴求。具體而言
25、,監管報送、客戶對賬單、營銷短信等金融業務場景需要數據文件服務。數據 API 服務主要應用于企業管理者視圖、客戶信息和交易消費記錄的實時查詢。消息服務主要應用于常規消息、系統活性跟蹤、聚合統計系統運營、日志等數據的收集場景。數據管道每日批量從外部數據獲取最新全量數據(如銀聯、匯法網等),實現對外部數據的統一接入、存儲、應用和管理。12金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究二是在數據服務時效性方面,金融數據倉庫的數據服務要包括批量服務和實時服務。金融業務場景對于數據服務的時效性要求不同,對于處理數據量大,計算復雜,時效性要求不高的業務場景需采用批量服務
26、,即根據確定數據范圍進行一次性大規模批量加工計算,應用場景主要是風險指標計算,經營指標計算,監管報送報表計算等。對于計算量級相對較小,主要強調計算過程時間的業務場景需要采用實時服務,即計算當下給出結果,在金融業的應用場景主要是實時風控、實時營銷以及實時報表等。三是在數據服務實用性方面,要提升數據的易讀性、易用性、穩定性和可擴展性。在實際金融業務場景中,數據的易讀性、易用性、穩定性和可擴展性是支持業務發展的必要要求。金融業務數據在實際業務發展過程中,是不斷變化的,因此在建立金融數據倉庫過程中,需要對數據指定統一的業務口徑和業務標準,保證業務人員在進行業務數據分析過程中,能夠快速了解數據指標的業務
27、含義和掌握該數據指標具體的使用場景。此外,還需要提升數據的穩定性和可擴展性,金融業務數據之間要有明確的勾稽關系和關聯關系,數據要結構穩定,能夠在金融業務的不斷發展中進行補充和升級,保證業務的持續發展。3.2.數據存儲要求一是在存儲范圍上要容納內部數據和外部數據。在數據驅動業務發展的潮流下,金融機構僅僅通過業務數據、埋點數據及指標加工數據等內部數據進行分析管理,已遠遠無法滿足目前金融行業的業務發展要求,需要引入用戶調研數據和合作方數據等外部數據,實現內外數據的統一整合,13金融數據倉庫發展報告(白皮書)才能夠更好的得到市場信息,助力金融機構更好地規劃未來的經營戰略。二是在存儲形式上要涵蓋結構化數
28、據、非結構化數據和半結構化數據。雖然傳統金融行業以結構化數據運營為主,但結構化數據已無法滿足金融業務分析的需求,如客戶畫像、客戶滿意度分析、客戶交易異常監控等,需要更多辦公文檔、圖片、音頻、視頻、日志以及地理信息等半結構化、非結構化數據支撐。三是在存儲時效上能實現當日數據和歷史數據的分類和規劃。金融數據倉庫涉及數據分析的業務范圍廣泛,每日匯聚來自源業務系統和外部系統的數據,信息量多、數據量大,必要的存儲策略和分類方法可以讓數據應用更便捷。不同業務對數據的存儲時效要求不同,例如反洗錢、征信報送等監管服務,需要定期對歷史存量交易、客戶信息進行摸底排查,故該部分數據需要按照歷史數據的保留策略進行存儲
29、。每日的交易流水統計、日志行為分析則僅需對最近一日的數據進行統計匯總后即可,保留當日數據。14金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究3.3.數據處理要求金融業務的豐富性和復雜性帶來業務數據的多樣性,金融數據倉庫需要具有對金融業務數據的整合能力,將各類業務數據進行抽絲剝繭地拆分,形成具有公共服務能力的金融業務標簽和管理指標。按照金融數據倉庫集中存儲和高效服務的要求,數據處理可根據數據流轉形式進行數據分層,即貼源數據、模型數據、匯總數據和應用數據。一是貼源數據。對金融各業務系統數據進行采集、匯聚,需要盡可能保留原始業務流程數據,與業務系統基本保持一致,僅
30、做簡單整合、非結構化數據結構化處理或者增加標識數據日期描述信息,不做深度清洗加工。二是模型數據。業務數據模型要實現數據的統一采集、整合、清洗、標準、存儲和服務。從金融機構自身的視角對業務概念進行邏輯化、一致的表述,用數據語言說明業務需求和體現業務規則,將數據模型作為連接業務和技術的橋梁。三是匯總數據。匯總數據包括匯總模型、數據指標、數據標簽等。從客戶、組織、產品、交易等主題劃分匯總模型,建議充分考慮數據通用性,同時應防止數據集中而導致的維度冗余,并以此作為指標、標簽的數據基礎。數據指標為上層應用衡量業務特征提供統計數值,建議兼顧上層應用的共性指標對數據進行匯總。數據標簽是由元數據加工而來,一般
31、都需要結構化到字段粒度,并面向數據應用的業務端,解決數據怎么用、數據價值在哪里的問題。15金融數據倉庫發展報告(白皮書)四是數據應用。應用服務直面金融業務需求,需要按照業務需求從模型數據層和匯總數據層進行數據抽取,形成滿足業務口徑的特定加工數據,以聯機技術和接口方式提供,滿足業務的特性化需求和性能要求。3.4.數據質量要求金融業務發展過程中,會產生多種多樣的數據,有系統自動生成、有客戶錄入、有業務人員手工維護等各類數據。數據的來源不同,導致數據雜亂無章且無統一的標準。因此在金融數據倉庫統一處理過程中,需對數據進行質量管控,形成統一的規范,保證數據能用可用,業務人員、開發人員常用善用。一是保障基
32、礎數據的完整性、及時性、準確性、一致性、唯一性和有效性等。數據完整性是數據質量最基礎的一項要求,要保證數據在創建、傳遞過程中無缺失和遺漏,包括實體、屬性、記錄及字段值完整四個方面。數據及時性是數據交付、抽取及展現要及時,需要保證數據獲取時間在指定時間窗口內,獲取頻率在規定頻率范圍內,數據使用在有效時間周期內。數據準確性是要保證真實、準確地記錄原始數據,無虛假數據和信息。數據一致性是要遵循統一的數據標準記錄、傳遞數據和信息,主要體現在數據記錄是否規范、數據是否符合邏輯。數據的唯一性是要求數據只能有唯一的標識符。數據的有效性是數據的值、格式和展現形式需要符合數據定義和業務定義的要求。二是有效避免指
33、標數據質量問題。指標數據質量問題的產生原因主要包括:口徑和加工需求層面的問題,業務理解和溝通不足,造成需求16金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究和設計層面的質量缺陷;在指標加工的開發實施過程中,因為程序性的錯誤而產生的質量問題;指標在應用層面的誤用或歧義,造成業務應用層面的理解不一致等情況。因此,金融機構針對不同原因應該有不同的管理策略。對于溝通和理解層面的問題,應該通過數據溯源和口徑分析來解決;在加工過程的問題,應該通過數據驗證和測試環節來把關。同時,指標類數據質量還存在應用層面的波動監控問題,在初始投產階段驗證正確的指標,可能在后續因為各種擾
34、動因素而產生質量缺陷,需要針對指標數據進行波動區間的監控和預警,對于重要的經營管理報表所涉及的指標,應該加入指標波動預警的響應機制,快速介入和應急處理。3.5.數據安全要求金融數據涉及大量的客戶基礎信息、客戶交易信息,做好數據安全、防止數據丟失、數據泄露是重中之重。在進行金融數據保護過程中,需要對金融數據倉庫內部的數據進行存儲管理、服務監控、安全類別分級以及數據管控。一是加強數據存儲安全,保障數據出現存儲故障時,能夠備份恢復。數據倉庫系統因發生意外事故而導致存儲數據丟失、系統癱瘓,需要通過軟件或硬件恢復數據存儲,保證數據不丟失、不遺漏。數據倉庫備份可包括硬件備份、系統備份、應用系統及數據備份。
35、17金融數據倉庫發展報告(白皮書)二是保障數據服務安全,在金融數據倉庫在進行復雜計算的過程中,不存在敏感數據的增刪改查等危險操作。金融數據倉庫接入源數據的數據后進行清洗、合并、加工,需在處理過程進行定期跟蹤和測試,保證數據服務安全。在對外交換上,需要制定確定的交互方式,形成數據責任制,避免造成對一份數據多次操作,引起數據變動,導致數據異常。三是強化數據安全等級設置,避免未經授權對敏感數據的增刪改查操作。為開發人員使用便捷,數據表安全等級通常存在安全等級設置偏低的情況,因此,要根據數據分級的目標,通過設置合理的等級,加強對金融數據倉庫平臺下數據的安全管理,確保敏感數據的增刪改查操作都能夠經過適合
36、的授權。四是提升數據安全控制,避免人為故意操作導致數據安全管理問題。不論單位組織內的數據分級如何準確、資產保護目錄如何完備、安全管控技術如何先進、角色分配和數據確權如何明晰,但只要管理流程有人參與,就必定是數據安全管理體系內最薄弱的一環。因此,建立一套完整的數據安全團隊的人員建設和管理策略必不可少,從招聘、能力建設到實施管控,需要全面覆蓋。18金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究4.金融數據倉庫總體設計與關鍵技術金融業在深入推進數字化轉型過程中,通過數字化技術記錄大量的、形式多樣的金融業務全流程數據,并且需要對這些數據進行挖掘分析,因此促進了金融數
37、據倉庫技術的快速發展和不斷創新。4.1.金融數據倉庫模型4.1.1.數據倉庫模型設計原則根據金融行業重點關注的客戶管理、運營和績效管理、財務管理、風險管理、信息管理等領域對數據使用的要求,數據倉庫模型設計應遵循如下原則。一是兼顧泛化性和實用性?;趯I務的分解和梳理,對數據模型進行一定程度的抽象和整合,提高模型的泛化能力和穩定性,但過高的抽象程度會脫離業務實際,不便于理解和交流,增加數據模型的使用難度,因此數據模型要平衡抽象性和實用性。19金融數據倉庫發展報告(白皮書)二是高內聚低耦合。從數據的業務特點和訪問特點兩個角度出發,對于監管報送類同質化較高的業務或者相關的數據,應在數據模型中進行整合
38、,輕度匯總;對于業務差異較大的數據應劃分在不同的模型主題中;對于高頻率同時訪問的數據,應在數據模型中進行整合;對于低概率會同時訪問的數據,考慮分開存放。三是核心模型與擴展模型分離。核心模型描述核心的業務流程和高頻率的業務數據,擴展模型補充非必要信息或服務于個性化需求。擴展模型不應過度入侵核心模型,破壞核心模型的簡潔性和可維護性。四是公共處理邏輯下沉。對于公共的、基礎的數據處理,應在數據模型的底層實現,不應直接暴露給數據服務。相同的數據處理不應在多處存在。五是兼顧成本與性能。綜合考慮數據存儲成本和數據查詢性能的影響,保留一定程度逆規范化設計,制定合理的數據更新策略。六是重視數據質量。數據模型設計
39、不能假設數據質量是符合要求的,應與數據治理緊密結合,實現數據標準的統一,實體表定義、字段命名、枚舉值含義等都應做到清晰、規范、完整、一致,便于模型的使用和理解。為滿足各金融機構合規報送要求,數據模型的定義統一標準化尤其重要。七是持續優化數據模型。數據模型設計不是一蹴而就的事,需要從業務整合能力、數據模型質量校驗、數據模型使用情況三個角度持續進行優化,建立數據模型評價體系,及時優化設計不合理的模型。20金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究4.1.2.數據倉庫模型層次數據倉庫模型按照抽象程度由高到低依次是概念模型、邏輯模型、物理模型。概念模型僅包括給定
40、的領域和職能中基礎和關鍵的業務實體,以及實體和實體之間關系的描述,主要由業務需求驅動,著眼于表現主要業務流程,并不需要考慮具體的實現過程和細節問題。邏輯模型是對數據需求的詳細描述,是對概念模型的進一步分解和細化,通過添加必要的實體屬性描述更多的業務細節,其不受任何技術或者特定實施條件的約束。物理模型設計需要將邏輯數據模型中定義的邏輯數據實體、屬性、屬性約束、關系等內容,如實轉換為數據庫軟件能識別的物理數據實體關系。4.1.3.數據倉庫建模方式數據倉庫建模方式目前流行的是范式建模和維度建模。從不同方式和角度出發看待現實世界和具體的業務問題,不同的建模方式都有其優缺點和適用場景。表 1 不同建模方
41、式優缺點對比建模方式優點缺點范式建模1.范式化設計,數據冗余度低;2.模型穩定,泛化能力強;3.維護成本低。1.開發周期長,設計難度高;2.大量表關聯影響查詢性能;3.模型變動對數據應用的影響較大。維度建模1.面向分析設計,模型簡單,緊密貼合業務目標;2.反范式化設計,開發周期短;3.查詢性能高、使用門檻低。1.數據大量冗余;2.預處理階段開銷大,維護成本高;3.受業務變動影響大。21金融數據倉庫發展報告(白皮書)因此,通過分析不同建模方式優缺點和適用場景,可以得出貼源數據層來自于上游應用系統,不需要數據建模;整合模型層、匯總模型層主要是為了抽象全局統一的數據視圖,其模型的穩定性很重要,為了維
42、持模型的穩定性,這兩層的數據建模一般以范式建模為主;數據集市層和業務層應用貼合緊密,需求變化快,為滿足上層業務快速變化的需求,數據集市層一般以維度建模為主。4.2.金融數據倉庫架構設計4.2.1.數據倉庫架構設計原則數據倉庫建設是一項企業級的浩大工程,需要充分考慮到數據倉庫在整個企業業務發展過程的定位。按照可用性、持續性、可擴展性要求,整體設計原則如下。一是聚焦業務訴求。數據倉庫面向數據分析和決策支撐,建設目標應緊貼業務訴求,確保數據倉庫能夠解決服務于核心業務,并解決業務痛點。二是立足企業級目標。數據倉庫設計不同于普通數據庫設計,應綜合考慮企業整體業務流程,以及全部應用系統設計,形成企業級的數
43、據架構。三是把握核心業務。數據倉庫需要對整個機構的業務數據進行整合與加工,只有把握住核心業務流程,才能夠串聯起其他次要業務,不至于迷失方向,偏離建設目標。22金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究四是數據結構清晰,數據流轉有序。層次結構清晰,分層合理,各層級職責明確,層級間數據流轉有序。五是全流程數據規范。數據倉庫設計建設過程中,需要有明確、詳細、可執行的規范要求,包括設計規范、流程規范、質量管控規范、安全規范。六是結合數據治理。數據治理保障高質量數據倉庫建設,數據倉庫設計協助理清數據流轉,助力數據治理。4.2.2.數據倉庫典型設計架構數據倉庫總體上
44、可以分為四層,分別是貼源數據層、整合模型層、匯總模型層、數據集市層,具體的分層設計應結合具體的業務實際。圖 9 數據倉庫典型設計架構示意圖全周期治理管控數據權限數據分級數據資產質量監測指標口徑內部數據外部數據結構數據非結構數據貼源數據層客戶產品協議合約交易整合模型層匯總加工統一指標加工統一標簽加工匯總模型層智能營銷實時查詢客戶畫像風險監測數據探索AI建模自助BI交易管控風險計量利潤測算監管報送數據應用層交易類場景分析類場景自助類場景數據倉庫數據服務23金融數據倉庫發展報告(白皮書)各個層級的職責如下:貼源數據層主要職責是采集獲取保留原始數據,該層的數據應保留業務數據的原始樣貌,不建議進行數據處
45、理。整合模型層是數據倉庫的核心,按照業務特點建立抽象的數據主題模型,對所有的業務數據進行有效的重組、整合、匯聚,構建穩定的數據底座。匯總模型層是數據模型中的一個重要組成部分,主要是為了提高查詢效率,減少指標重復計算,對各類應用系統的共性指標標簽進行統一加工,確保數出同源。數據集市層是面向不同的業務應用,為滿足多樣化的數據使用需求,進行數據個性化加工,并對外提供數據服務。4.3.金融數據倉庫典型技術架構數據倉庫作為企業的核心數據分析平臺,起到了承上啟下的作用。上游對接企業的交易系統、實時消息、日志及第三方數據等平臺;下游提供給企業管理人員、分析師團隊、交易系統及外部客戶分析加工結果。下面以典型銀
46、行的數據倉庫平臺技術架構為切入點,簡要說明數據倉庫需要具備的關鍵技術。數據倉庫平臺整體分為采集層、存儲計算層和應用層。采集層主要是從交易系統、日志系統、消息系統以及第三方系統進行數據采集。存儲計算層對采集的數據進行加工處理,并對應用層提供數據消費服務。應用層基于存儲計算層的原始數據、中間數據和結果數據,為金融機構經營提供經營決策、風險管理和控制、監管合規等分析應用以及數據展現。24金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究其中,存儲計算層通常分為核心倉庫區和大數據區,核心倉庫區處理金融機構的高價值密度的結構化數據;大數據區處理貼源數據和歷史數據,并進行歷
47、史數據歸檔備份等。核心倉庫區同時要承載數據的加工處理和數據供給消費,這兩部分負載都是非常大的,建議分多集群建設,分別應對不同的負載,主要包括數據倉庫集群、數據探索集群、數據集市集群等模塊功能。數據倉庫集群依據企業的數據模型設計,承載數據的批量計算,具有數據量大、計算量大、時效性要求高等特點,是一個計算密集型的系統。數據探索集群既承載復雜的長周期分析作業,也承載高并發、低時延的查詢,具有并發要求高、混合負載管理能力要求高、擴展性要求高等特點,面向行內分析師、企業管理人員開放,用戶對數據倉庫集群批量運算的結圖 10 典型銀行的數據倉庫平臺技術架構圖個貸催收分析實時事中風控信用卡賬單查詢實時個性化推
48、薦Region2Region1手機銀行用戶行為分析應用層業務應用存儲計算層采集層大數據(歷史數據/流式數據中心)數據湖/數據交換平臺/歷史庫(對象存儲)核心倉庫(高價值密度數據中心)容災集群歷史數據平臺Hive/Spark準實時處理Flink/SparkStreaming容災數據集市監管反洗錢信用卡賬單數據探索集群LAB1SSB AMPNLAB2數據倉庫集群AMRTBMRTSUMPDMODSSTG互聯網數據資信平臺日志數據數據庫消息平臺(Kafka)爬蟲平臺25金融數據倉庫發展報告(白皮書)果進行分析。隨著金融機構對數據分析的依賴度越來越大,獨立建設數據探索集群逐漸成為一種趨勢。數據集市也稱為
49、倉外集市,通?;诓块T或領域的視角,對數據倉庫中的數據做二次加工和分析,服務于特定的主題域,具有部署靈活,資源彈性,兼具批量和聯機的特點。但由于部門和領域的數據多、差異大,數據集市往往建設的數量較多,規模差異較大。4.4.金融數據倉庫的關鍵技術如 4.3 所描述,數據倉庫各個集群的任務,負載特點,技術要求不盡相同,本節從 7 個方面對金融數據倉庫的關鍵技術進行分析,力爭涵蓋金融數據倉庫的核心關鍵技術。4.4.1.超大規模并行處理滿足海量數據的算力要求金融領域有大量的數據,數據總量會達到 PB 級甚至百 PB 級;同時對性能要求很高,很多監管報送、運營報表需要在規定時間內完成,因此需要在基礎架構
50、、數據存儲、SQL 查詢、數據加載等方面實現超大規模并行處理技術來滿足存和算的要求。(1)分布式架構。由于金融數據倉庫是海量數據的處理平臺,首要關注性能和算力擴展性,根據技術原理和實踐經驗來看,MPP(大規模并行計算)+Shared Nothing+Local Storage 更適合這類型負載的數據倉庫架構。26金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究(2)云原生架構。分布式架構在云基礎設施上演進出 MPP+Shared Nothing+Shared Storage(分布式存儲)的存算分離技術。云原生架構對數據的計算和存儲進行解耦,數據持久存儲在底層共
51、享磁盤上,計算和存儲可以獨立擴容,具有明顯優勢。但這種存儲拉遠的技術相比于本地存儲的 I/O 處理的路徑明顯拉長,對存儲設備、存儲網絡的帶寬時延配置要求更高,在架構選擇時要綜合評估。(3)分布式數據存儲。為了解決PB級海量數據的高性能查詢和處理,可采用兩層數據布局機制來利用并發度提高性能。用戶在第一層可在創建表時指定數據分布策略(Hash 分布、隨機分布、復制分布)。在第二層節點內部數據進一步通過用戶指定的分區規則進行細分,將數據表按照指定范圍劃分為多個數據互不重疊的部分。(4)分布式并行 SQL 查詢。采用節點間并行和節點內并行技術,盡量降低查詢時節點之間數據流動,并協同各個節點的計算資源進
52、行任務分解和協作,以提升查詢效率。(5)分布式數據并行加載。以充分利用所有節點的計算能力和 I/O能力以提升導入速度為核心思想,支持對指定格式(例如:CSV/TEXT格式)的外部數據進行高速、并行入庫。4.4.2.高可用及容災技術實現數據永遠在線金融數據倉庫是金融機構的核心分析系統,承載風險控制、監管報送、經營分析等關鍵業務,對可用性要求很高,金融數據倉庫需要具備27金融數據倉庫發展報告(白皮書)完備的高可用能力,制訂高可用策略以滿足業務需求和金融監管要求。從數據可用性來看,匹配金融數據倉庫平臺通用的分布式架構,需要保證數據的全局一致,數據多副本等;支持多種策略的數據備份,包括全量數據備份,增
53、量數據備份等,避免數據誤刪和不可恢復錯誤等。從系統可用性來看,需要支持集群內高可用,避免單節點故障,雙集群容災,以保障系統永遠在線。隨著數據倉庫承載業務的重要性逐年提升,金融機構對數據倉庫容災集群需求也日益迫切。不同于其他系統,由于數據倉庫集群具有系統規模大、成本高、網絡帶寬需求高、使用者眾多、應用升級更新快以及應用層容災維護成本高等特點,數據倉庫容災技術面臨很大的挑戰。但近年來數據倉庫容災技術也得到了快速發展,典型的雙集群系統級容災技術是在異地兩個 Region分別部署數據倉庫主備集群,根據 Region 間網絡帶寬、時延以及業務對數據延遲的容忍度,用戶可自定義兩集群間的同步間隔與策略。同時
54、,通過細粒度、集群級、雙活容災等三種備集群容災形式,保護不同范圍、不同級別業務連續性的數據,從而達到降低備集群的搭建成本的目的。4.4.3.動態負載管理滿足多樣化負載統一管理金融數據倉庫集群、數據探索集群、數據集市集群是一個多任務運行28金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究的系統。數據倉庫集群運行幾萬個作業,并發運行的作業也有上百個。數據探索集群支持上萬分析師的數據任務,需要通過負載管理滿足多樣化負載的統一調度,實現資源的高效利用和系統的高吞吐量。負載管理主要通過業務的并發控制來均衡系統計算資源,避免業務間出現資源爭搶,實現資源利用最優。通常負載管
55、理需要具備以下能力:(1)靜態資源管理。以計算節點為單位實現租戶的并發控制和資源管控,各計算節點分別進行內存管控和并發控制。(2)動態資源管理。用于復雜作業并發控制和內存管控,能夠動態的根據系統實時可用資源進行內存管控和并發控制。(3)優先級控制。單計算節點上運行作業數超過閾值或集群內存不足時觸發優先級管控,資源分配越大優先級越高,租戶作業根據優先級在不同優先級隊列上排隊,有作業運行結束時優先喚醒優先級高的作業。優先級控制需要支持 Session 級設置,實現動態優先級控制。(4)異常管理。為避免質量不高的 SQL 長時間占用系統資源,拖慢整個系統,針對異常占用資源的 SQL 實時監控需要支持
56、設定異常規則,以保障系統的平穩運行。例如對占用內存過多、執行時間過長等異常情況執行自動查殺等干預手段。(5)快慢查詢管理。針對長查詢和短查詢提供更為靈活的并發和資源管控機制,快查詢車道針對資源消耗少、執行時間短的作業進行管控,僅29金融數據倉庫發展報告(白皮書)對作業并發進行管控;慢查詢車道針對資源消耗大、執行時間長的作業進行管控,采用并發和內存聯合對慢車道作業進行管控。(6)容量管控。通常通過永久表空間管控、臨時表空間管控以及中間計算結果集落盤空間管控等三部分實現用戶空間管控。4.4.4.數據安全技術保障數據合規訪問金融數據倉庫中存儲了金融機構最全量的用戶數據、經營數據,其數據價值密度高、敏
57、感度高。為了保障數據倉庫的合規訪問,需要提供用戶管理、基于角色的權限管理、行列訪問控制等安全能力。在數據保護方面,還需要提供透明加密、數據脫敏等數據合規訪問的能力。(1)透明數據加密(TDE)。通過透明數據加密(TDE)提供底層數據文件加密能力,TDE 對數據實時 I/O 加密和解密,只要打開透明加密開關,用戶可正常使用而無感知。該技術對現有 SQL 語句兼容性好,僅需要在創建數據庫時指定啟用加密即可。(2)數據脫敏。通過數據脫敏實現數據高效共享的同時保護敏感信息安全。該技術支持以表的列為單元創建脫敏策略,針對業務中的敏感數據進行策略創建,由客戶結合自身業務場景識別和界定敏感數據。與此同時,脫
58、敏數據可以參與實際運算及使用,僅在數據庫服務最終返回結果時脫敏。在應用開發、測試、培訓等活動中使用脫敏數據,可以匹配金融行業對數據脫敏的天然需求。30金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究(3)三權分立。將系統管理員的權限分立給安全管理員和審計管理員,從而避免系統管理員擁有過度集中的權利帶來高風險。系統管理員將不再具有 CREATEROLE 屬性(分給安全管理員)和 AUDITADMIN 屬性(分給審計管理員)能力,即不再擁有創建角色和用戶的權限,并不再擁有查看和維護數據庫審計日志的權限。4.4.5.融合分析技術打通結構化與非結構化數據分析邊界在 4
59、.3 章節數據倉庫典型平臺技術架構中,數據分析分為核心倉庫和大數據區,非結構化數據往往存儲在大數據區,因此,需要有融合分析技術,把核心倉庫區的數據與大數據區的數據進行關聯融合分析,減少數據搬遷,提升加工效率。當前用于數據處理的引擎組件種類繁多,且各自提供了豐富的接口供用戶使用。但對傳統數據庫用戶來說,SQL 語言依然是最熟悉和方便的一種接口。在一個客戶端中使用 SQL 語句操作不同的數據分析組件,將極大提升使用各種大數據組件的效率。通過 SQL on Anywhere 操作 Hadoop、Spark等異構數據存儲,構筑起統一的大數據計算平臺。4.4.6.彈性擴展技術滿足系統在線按需擴展隨著金融
60、行業在數據倉庫積累的數據量增長,磁盤容量和性能等方面逐步出現瓶頸,通過 scale-out 線性擴展技術可滿足業務增長和利舊的訴求(將閑置的機器加入系統)。典型的彈性擴展有兩種:31金融數據倉庫發展報告(白皮書)(1)物理部署下資源彈性擴展。在數據本地存儲的物理部署形態下,擴展節點時對原節點進行數據搬遷和數據重分布,通過在線重分布的技術實現數據搬遷不影響集群上的業務。相比于其他類型的在線擴展技術,在線重分布技術能夠最快的獲得擴容后計算、存儲算力的提升。(2)云化部署下資源彈性擴展。在云化部署(虛擬機+分布式塊存儲)的情況下,不同于物理機/裸金屬的物理 CPU 和本地磁盤,計算資源采用虛擬機資源
61、(如 ECS),存儲資源采用分布式塊存儲(如 EVS),當需要擴展資源時,動態地增加計算資源或存儲資源以滿足業務對彈性擴展的需求。同時能更好的支持小規格的場景,很契合倉外集市的場景。在云化部署的情況下,計算資源采用裸金屬/虛擬機,存儲采用分布式存儲如 S3、OBS 等,當計算彈性擴展時,僅需要重分布元數據,不需要搬遷存儲設備上的數據,實現計算彈性,快速擴展。4.4.7.管控一體的智能運維釋放運維壓力金融數據倉庫的集群規模大,承載多個業務部門應用的數據需求,是一個重負載的系統,出故障的概率高。由于金融業務高可用的要求,系統出故障后可容忍的修復時間短,運維壓力大。通過智能運維的技術可實現全方位的監
62、控,在線運維能力,釋放運維壓力,關鍵技術包括運維監控、系統監控、智能運維、SQL 診斷等。(1)運維監控。資源監控及管控手段可以對影響作業運行的計算資源和存儲資源進行分配和利用,通過對系統資源的合理分配,避免發生資源的不合理占用導致系統運行效率下降甚至引發運行問題。資源監控32金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究及管控包括資源監控、負載管理及磁盤空間管控。(2)系統監控。多個維度的監控應包括實例層,用戶層與作業層。在實例層對計算節點、存儲節點每個實例的實時系統資源和負載情況進行監控。在用戶層監控多租戶資源的使用情況。在作業層監控用戶執行的每一條 s
63、ql 與對應算子在其運行中和結束后的資源消耗情況,用戶可以根據這個信息對其編寫的 sql 進行調整優化。(3)SQL 診斷能力。金融業務用數過程會包含大量查詢,這些查詢在執行計劃、執行層面有什么樣的問題,比如估算是否有偏差、是否存在數據傾斜、是否存在統計信息未收集并且如何收集統計信息等。SQL 自診斷提供一種更為高效易用的性能問題定位方法。幫助用戶對批處理作業的SQL 調優過程進行簡化,用戶輸入 SQL 之后能夠方便的批量得到 SQL 所存在的問題和針對問題給出的調優建議。(4)在線運維。提供軟件版本在線升級、在線補丁以及升級補丁回退能力,達到新特性快速發布、持續交付可靠版本,以快速響應金融業
64、務上層應用的用戶需求。(5)智能運維。提供無人值守自動運維能力以實現智能運維高可用保障,實例級故障、節點級故障不中斷運維執行;通過感知集群負載資源,智能調節運維任務并發降低運維影響;利用人工智能算法和專家規則,提供數據碎片自動檢測與回收、數據統計信息預測與自動更新等能力,確保性能穩定和高效運行;通過亞健康檢測能力、全庫數據優化檢測能力實現主動運維。33金融數據倉庫發展報告(白皮書)5.金融數據倉庫建設策略5.1.指導原則為達成建設目標、有效支持金融業務發展,金融數據倉庫建設需要遵循設計力求簡單、易于理解且不失精細的簡潔性原則;合理抽象、便于業務和 IT 人員溝通交流的抽象性原則;確保功能組件解
65、耦、可并行開發的隔離性原則;便于高效率溝通和交互的標準化原則;隨業務發展彈性伸縮的擴展性原則;保證數據和處理流程的完整性原則。5.2.建設規劃策略根據金融數據倉庫建設進程先后次序,大致可分為業務規劃、實施規劃和運營規劃共三個階段推進。如圖所示:業務規劃要結合業務調研結果和同業實踐,制定規劃及實施優先級。并參考客戶管理、運營和績效管理、財務管理、風險管理、信息管理等五大模塊,結合企業愿景、整體發展戰略、業務發展規劃以及實際監管要求制定業務目標。金融數據倉庫的應用根據不同特點、不圖 11 數據倉庫建設規劃示意圖建設規劃技術架構規劃數據架構規劃數據模型規劃訪問安全規劃系統容量規劃數據治理規劃環境建設
66、規劃運維管理規劃系統災備規劃持續運維規劃業務規劃實施規劃運維規劃34金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究同使用范圍、不同建設方法主要分為固定報表、應用系統、靈活查詢及數據挖掘共四種模式。本文不對業務規劃進行詳細闡述。5.2.1.實施規劃結合金融關鍵業務對數據服務、存儲、處理、質量、安全要求,并考慮到數據倉庫需要面向金融機構提供全國、全球業務范圍的服務,建議在數據倉庫總體設計完成后,啟動實施規劃。實施建設規劃包括技術架構、數據架構、數據模型、訪問安全、系統容量以及數據治理等六個方面。一是技術架構建設規劃根據數字金融快速發展帶來的業務類型多、海量數據等
67、特點,梳理好采集層、存儲計算層和應用層之間關系,做到技術架構規劃具有先進性、前瞻性、可行性、擴展性、伸縮性;依據監管法規、應用特性,分類實施實時數據倉庫、湖倉一體、雙活容災平臺建設。二是數據架構建設規劃的核心數據倉庫平臺可參照金融業務所需要的貼源數據層、整合模型層、匯總模型層、數據集市層進行落地實施;制定合理、高效的數據生命周期管理策略,拆分在線、近線、歷史區,將已失效、陳舊數據推送到更經濟的存儲平臺,保證核心數據倉庫健康運行;根據數據用途差異,可拆分成核心數據倉庫計算平臺、分析平臺、倉外集市,更好地為上層眾多不同類型金融業務提供數據服務。三是數據模型建設規劃應涵蓋金融機構所有業務的各個層面,
68、包括交35金融數據倉庫發展報告(白皮書)易數據、主數據和參考數據,提供一個完整、一致的數據集成邏輯視圖;根據實際情況,不同金融機構綜合應用范式建模和維度建模,其中整合模型層更多采用范式模型,主題領域及數據集市層更適合采用維度模型;范式模型中可適當增加冗余設計,保障下游易用性。四是訪問安全建設規劃要充分考慮金融數據商業性和保密性要求,重視整體安全設計,確保數據的真實性、保密性、完整性、可用性、可審查性;設計并落實權限管理、密碼管理、認證及會話控制、安全協議、文件權限管理、網絡隔離、安全審計等安全合規控制措施。五是系統容量建設規劃要充分評估業務發展的數據增長需求,依據整體目標要求,梳理系統整體算力
69、和存儲空間;分別對貼源數據層、整合模型層、匯總模型層、數據集市層進行數據容量規劃,估算生產、測試、開發環境配置要求。六是數據治理建設規劃根據數據治理實施帶來的業務價值以及業務的需求緊迫程度,規劃目標和實施路線圖;通過數據治理建設,明確治理主體,統一數據規劃和標準,提升數據質量,實現數據共享,最終實現業務戰略規劃;從戰略、機制、專題、實現、數據認責等五個方面落地數據治理體系框架。5.2.2.運營規劃金融業務復雜,不但有嚴格的內部管控,更要符合各監管機構的合規要求,同時要面向對私和對公客戶提供直接差異化金融服務。因此,需36金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息
70、安全研究要根據金融業務服務等級對數據倉庫建設提出的要求,差異化地落地數據倉庫平臺運營規劃,建議包括環境建設規劃、運維規劃、系統災備規劃及持續運營規劃等四方面。一是環境建設規劃要確定數據倉庫平臺的開發(DEV)、集成測試(ST)、用戶接收測試(UAT)、生產運行(PRD)四套環境建設。其中生產環境與開發測試環境要避免混用,開發和集成測試環境可合并部署以減少投資。利用 ETL 服務器、應用服務器可實現環境隔離。通過規范環境流程,可達到提高數據質量、程序質量以及數據安全性,提升數據可用性與可信度,以及保障企業的信息安全的目標。二是運維規劃的整個框架由流程、組織、技術三大部分組成,涵蓋數據倉庫的數據集
71、成、基礎平臺、應用系統的運營管理。流程上需建立全流程運維保障,做好環境準備、安裝部署、系統運行、系統維護、故障處理、版本變更以及應急演練。組織上需構建三級梯隊運營管理團隊:一線服務臺值班監控、二線由數據倉庫各團隊成員組成處理各類運營問題、三線則由資深專家構成服務賦能二線。技術上應考慮容量規劃與容量管理、性能管理、負載管理、服務級別協議等,并進行數據庫系統監控、中間服務層管理(OLAP 與 BI 工具)、元數據管理、數據質量管理、數據加載服務管理(ETL)等數據倉庫及周邊組件全流程覆蓋監控。三是系統災備規劃需根據業務和現有 IT 系統實際訴求出發,因地制宜、落地實施。建立數據倉庫備份環境要考慮數
72、據備份、恢復效率,配合數據生命周期管理,做好應用 SLA 保障預案,規劃備份網絡,避開業務高峰周期性備份,做好異地歸檔、定期恢復演練。建立數據倉庫容37金融數據倉庫發展報告(白皮書)四是持續運營規劃要能持續監控系統運行情況,周期性整改規范性約束,優化平臺性能,保障運行平穩;針對已落地應用進行審視,適時合并、拆分物理環境,保障數據倉庫環境健康新常態;定期階段性回顧系統運行狀況,修正平臺規劃差異,適時發起算力、容量擴展申請。災環境,解決災難發生時保證數據倉庫平臺業務連續性問題,同時應當考慮跨機房、跨中心、異地等部署形態,避免出現單點故障,以及定期實施對等環境容災演練;可按照細粒度、集群級、雙活容災
73、三種形式,設計保護不同范圍、不同級別業務連續性要求的容災規劃,如圖所示:圖 12 容災規劃的三種形式重要數據區其它數據區整體集群集群級容災主集群容災集群數據操作雙活主集群雙活數據其它數據集群A雙活數據其它數據集群B數據字典同步容災集群細粒度容災容災數據容災數據Schema級容災38金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究5.3.實施要求5.3.1.組織架構金融數據倉庫建設涉及到金融機構、服務供應商等眾多參與單位,且涉及到金融機構不同業務部門,為保障項目進展實施順利,建議在項目啟動之初任命職責明晰的項目組,可參考如下圖的實施組織架構。其中項目領導小組是整
74、個數據倉庫項目的最高領導機構,主要負責整體項目重大問題決策,建議盡可能由公司管理層牽頭,以保障跨業務部門協調順暢,高效推進項目進度;項目管理組負責項目日常管理,包括但不限于范圍管理、資源協調、進度監控等;專家組負責在業務和技術層面給與專業建議和方案;業務組負責承接源業務系統及對接下游應用集市具體業務訴求;架構組負責制定數據倉庫技術規范及技術架構的設計和落地;配置管理組負責數據倉庫平臺版本配置管理工作;模型組負責制定數據倉庫模型設計規范,以及進行模式設計和開發;開發組負責數據倉庫數據加工程序、BI 報表、靈活查詢及數據挖掘的開發;測試組負責數據倉項目領導小組專家組項目管理運維組項目助理配置管理組
75、上線投產組開發組架構組業務組測試組模型組圖 13 實施組織架構圖39金融數據倉庫發展報告(白皮書)庫相關功能和非功能測試工作;上線投產組負責數據倉庫日常具體任務的投產部署工作;運維組負責數據倉庫日常運營維護工作。5.3.2.實施過程基于金融數據倉庫建設規劃特性,數據倉庫龐大的系統性實施需要遵照“整體規劃、分步實施”的方式推進建設,在每個階段中建議可采用迭代方式執行,每個迭代周期中又需要包含需求分析、系統設計、開發測試和上線維護等四個階段:(1)需求分析階段:通過資料研讀、調研問卷、會議訪談等方式進行業務和技術現狀調研,詳細了解需求范圍、數據規范、數據分布等內容,并基于樣本數據進行數據探查。(2
76、)系統設計階段:進行數據倉庫技術架構和模型設計。技術架構設計涵蓋數據交換、調度、ETL、網絡和物理部署等內容。模型設計涵蓋基于通用行業模型進行主題模型、概念模型、邏輯模型和物理模型設計。(3)開發測試階段:基于系統設計完成基礎架構搭建和數據模型開發。(4)上線維護階段:數據倉庫投產及持續維護。5.3.3.規范約束數據倉庫相關開發、測試、上線過程細節繁瑣,為了讓組織架構內40金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究各成員高效開展工作,保障項目實施質量,建議具體實施應涵蓋下表所示的各項規范。表 2 數據倉庫實施規范約束階段規范說明開發測試命名規范數據庫對象
77、、調度作業、應用名稱規范等。流程規范開發、測試流程,環境使用規范。數據加工開發規范ETL 開發規范等。上線維護運維規范日常運維、產品升級回退流程、應急預案、異常處置、高危管理。5.3.4.實施注意事項金融數據倉庫在實施過程中,除上述具體建議外,還需要關注幾個事項:數據平臺的設計不但要解決現有問題,同時應著眼于未來,促進一致性和跨部門整合;數據入倉的過程中應收集滿足現有需要更廣泛的數據,保存最原始的數據,保留事件的歷史和相關內容,對于重復數據可予以刪除;為了提高工具的自動化和復用度,應考慮為用戶使用、使用模式和角色選擇合適的工具。5.3.5.主要交付件金融數據倉庫建設和使用時間較長、支撐業務廣,
78、為便于項目交付過程上下游溝通順暢,并方便回溯項目過程文檔、沉淀可復制技術經驗,41金融數據倉庫發展報告(白皮書)表 3 數據倉庫實施主要交付件階段交付件需求分析數據倉庫模型設計規范文檔數據倉庫 ETL 和調度規范文檔系統設計數據倉庫架構設計文檔數據倉庫模型設計文檔開發測試數據倉庫 ETL 腳本程序上線維護數據倉庫投產部署文檔數據倉庫運維指導文檔除項目管理文檔外,建議數據倉庫實施主要交付文件如表所示:42金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究6.金融數據倉庫十大發展趨勢在七大關注熱點中,六個都是與“融合”相關。除此之外,金融機構還關注“普惠”,比如普惠
79、數據治理、普惠數據倉庫周邊工具。目前業界有三個比較前沿的方向:數據網格(Data Mesh)、數據編織(Data Fabric)及現代數據棧(Modern Data Stack)。綜合調研和研究,最終提出金融數據倉庫的十大發展趨勢。通過對百余家金融機構調研提煉出金融業對數據倉庫技術的七大關注熱度,如圖 14 所示。圖 14 金融行業對數據倉庫技術關注熱度分布數據來源:金融信息化研究所全行業對數據倉庫技術關注熱度分布0.00%20.00%40.00%60.00%80.00%T+0分析數智融合(AI)湖倉一體數據共享存算分離高維分析HTAP43金融數據倉庫發展報告(白皮書)表 4 金融數據倉庫的十
80、大發展趨勢類別名稱特點融合T+0 分析融合流和批湖倉一體融合湖和倉數智融合融合數據和 AI存算分離融合數據倉庫和云計算高維分析融合關系型數據和非關系型數據HTAP融合 TP 和 AP普惠Data Mesh普惠數據治理:利用“數據即產品”的思維更高效的用人Data Fabric普惠數據治理:利用“智能數據管理”技術節省更多的人力現代數據棧普惠數據倉庫周邊工具:Modern ETL,Modern BI 等數據共享普惠數據共享:促成金融數據倉庫從“PC 時代”邁向“互聯網時代”6.1.T+0 分析在一些金融業務場景中,數據分析需求正從離線分析向實時分析轉變。離線分析也稱“T+1”分析,可以告訴用戶過
81、去 1 天或者幾小時前的情況,主要支撐實時性不高的報表分析類應用。實時分析也稱“T+0”分析,告訴客戶目前正在發生什么,典型案例應用場景包括實時風控、實時營銷、實時授信、實時運營(實時大屏)、實時運維等。另外,“T+0”分析也給數據倉庫帶來新的技術挑戰:基于事件的處理需要實時高并發入庫、入庫即分析、流批一體、高性能同時要保證數據一致性等。44金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究6.2.湖倉一體金融業務產生不同類型的源數據,單一的結構化數據處理能力不能滿足業務場景的需求。金融機構探索湖倉一體架構,將數據湖和數據倉庫有機結合,充分融合數據倉庫的高性能與
82、數據湖的低成本,實現冷熱數據分級、價值密度分級,解決海量數據中結構化、半結構化及非結構化的數據處理多樣性,實現“1+12”的效果。湖倉一體關鍵技術包括:統一訪問接口、統一元數據管理、統一存儲格式以及計算引擎互通等。6.3.數智融合金融機構經過電子化、信息化、數字化這幾個發展階段,當前正在向智能化轉型。對金融機構而言,數智化轉型已經成為關鍵戰略,部分機構已經在智能風控、小微信貸、智能投顧、智能客服等業務場景已有具體應用。但僅依靠 SQL 的數據分析難以滿足這些業務需求,需要融合數據平臺和 AI 平臺。數智融合的關鍵是能力互補,將數據倉庫數據管理能力與 ML 流程生命周期管理結合。目前結合主要包括
83、兩種:一是數據倉庫將關系型的數據開放給 AI,并作為 AI 流程中數據準備、特征工程等強數據處理負載的分析引擎。二是非結構化數據(圖像、視頻、語音、文字)處理和模型訓練由 AI 平臺承載,訓練生成的模型可45金融數據倉庫發展報告(白皮書)直接部署在數據倉庫中,由數據倉庫來實現推理,并可以直接與數倉中關系型數據關聯分析。6.4.數據共享數據已成為重要的生產要素,金融數據有序流通與共享開放是釋放數據潛能的關鍵環節。當前各金融機構的數據倉庫還處于“PC 時代”,每個數據倉庫里的數據都是獨立個體,不同機構數據倉庫的數據實現安全合規的互聯互通還存在困難。數據共享有助于發揮數據的要素價值,如何保證數據共享
84、的安全性、隱私性,以及利益的公平分配等問題至關重要。從技術角度,金融數據倉庫需要具備數據共享能力可開放能力,做到細粒度權限控制、加密及隱私計算、安全合規及風險審計。6.5.存算分離目前數據倉庫的架構正向云原生演進,其典型技術特征是存算分離。這種新架構可以給用戶帶來極致的彈性,同時降低成本和提高資源利用率。部署在私有云上的金融數據倉庫,使用存算分離有如下優勢:一是有別于傳統的節點擴容,用戶可以根據業務需要,靈活的單獨擴展算力或存儲,擴縮容更加便捷;二是多集群共享一份數據,避免數據冗余,46金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究不但節省存儲空間,同時減少
85、數據搬運帶來的網絡開銷。同一份數據支持多樣式分析,保障數據一致性。從技術角度講,存算分離面臨兩大挑戰:一是數據倉庫的存、算、管是深度綁定的,需要將這三者解耦,在計算層去除計算元數據、存儲元數據信息,才能做到無狀態。二是存算分離將數據和計算拉遠,可能帶來性能下降,需要利用緩存、謂詞下推及數據預取等技術降低查詢延時。6.6.高維分析金融機構不僅有表格數據,還有圖數據、空間數據、時序數據等。如果每種數據都采用獨立的分析系統,不僅使用不便,也會導致數據孤島問題。高維分析嘗試構建一套系統,能夠實現不同類型數據的融合分析。為了實現這一目標,高維分析需要解決多模存儲和多模計算的問題。6.7.HTAP隨著金融
86、創新業務的蓬勃發展,越來越多的數據應用構建在數據倉庫之上,有些應用需要對數據進行并發的增刪改查。在此情況下,TP數據庫需要考慮如何和金融數據倉庫進行更原生的整合,從而更好的支撐這些數據應用的開發和運行。HTAP 的愿景是構建一套系統,既支持TP又支持AP能力,同時達到降低成本、減少系統運維和ETL開銷的目的。金融業對 TP 和 AP 的查詢性能和資源隔離要求非常高,給 HTAP 技術落地帶來了很大的挑戰。47金融數據倉庫發展報告(白皮書)6.8.數據網格(Data Mesh)數據湖和數據倉庫將所有數據集中存儲,統一由數據中臺部門進行治理。但隨著金融機構接入的數據源越來越多,數據治理也變得愈加復
87、雜,數據中臺部門壓力越來越大。為了緩解數據中臺部門的壓力,數據網格(Data Mesh)倡導金融業務部門參與到數據治理中,這樣業務部門就可以擁有相關數據的所有權,能夠更敏捷、更靈活地開展新業務。當需要整合治理多個業務部門的數據時,可以利用“聯邦數據治理”技術和“數據即產品”思維來實現。同時,建議金融機構可以適當培養員工“數據即產品”的思維(即:利用開發產品的思維開發數據),提升員工在做數據治理時的工作效率。6.9.數據編織(Data Fabric)數據編織(Data Fabric)和數據網格(Data Mesh)所要解決的問題是一致的,并與 Data Mesh 類似,Data Fabric 也
88、是讓金融業務部門擁有一部分數據的所有權。在整合治理多個業務部門的數據時,Data Fabric 采用邏輯的方式把數據連接起來,統一元數據層,提供全局數據目錄供不同部門查找所需數據,利用智能數據技術(Data Fabric 的核心理念)節省人力。隨著智能技術的發展,越來越多的數據治理任務可以自動化或半自動化,最終實現普惠數據治理的愿景。6.10.現代數據棧(Modern Data Stack)金融機構探索利用現代數據棧(Modern Data Stack)從重構數據48金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究棧的角度來發揮數據倉庫的最大價值。在金融機構的
89、數據棧中,數據倉庫是一個核心模塊,周邊還有其它模塊負責 ETL、BI、數據質量及數據安全等。通過降低周邊工具的使用門檻,推動“人人用數”目標的實現。比如在 Modern ETL方面,有如下三方面探索:一是ETL ELT,ELT 是指先做 EL 把數據接入到數據倉庫,再用數據倉庫做 T,優勢是EL 可以無代碼完成,只需要在數據倉庫寫 SQL 就可以解決 T 的問題;二是數據分析師分析工程師,賦能數據分析師成為分析工程師,提供簡化 DevOps 的工具,讓數據分析師不需要依賴數據工程師,可以端到端完成數據分析任務;三是 Reverse ETL,利用無代碼工具自動將數據分析結果從數據倉庫復制到業務系
90、統(ERP、CRM 等),賦能業務發展??傮w來看,可以用融合和普惠來概括金融數據倉庫十大發展趨勢。其中六大趨勢(T+0、湖倉一體、數智融合、存算分離、高維分析、HTAP)都與融合有關,四大趨勢(Data Mesh、Data Fabric、現代數據棧、數據共享)都與普惠有關。此外,通過調研我們發現國內很多金融機構在接下來 1-3 年在融合方面有比較清晰的規劃,但是在普惠方面還準備不足,建議金融機構提高關注度,實現數據價值最大化。49金融數據倉庫發展報告(白皮書)案例 1:工商銀行企業級數據中臺建設實踐工商銀行自 2020 年啟動企業級數據中臺建設,打造了數據體量大、服務場景豐富、使用人數多的企業
91、級數據中臺,在各業務、技術領域取得了豐碩成果。一、案例內容工商銀行數據通過搭建工銀魔方、圖靈為核心的大數據與人工智能技術底座,由傳統軟硬件一體機向自主可控的全棧大數據國產化全面轉型。平臺整體規模超過 4000 節點,容納全行 50P 海量數據,成為當前金融同業最大的GaussDB(DWS)單集群(482臺),覆蓋實時,秒級、分鐘級、小時級的全場景,為全行 100 多個業務系統、40 多家分行提供上千業務場景數據支撐。二、案例成效1.提升平臺容量和性能。面向全行 5000 多名數據研發人員及 13000多名分析師提供用數服務;批量計算服務作業總數 20 萬個,在線讀寫服務達 10 萬筆每秒,實時
92、計算服務達 2 萬筆每秒。2.創建“開放共建”數據生態。構建端到端的 DataOps 敏捷數據研發流水線、一站式建模工作站,創新提供“數據+BI”數樣分離的用數新模式。附錄:金融數據倉庫行業實踐50金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究3.構建多元化智能服務框架。利用 AI 及 BI 平臺能力,實現種類廣、數量多的算法庫,覆蓋主流算法數量 300+,通過 API、服務化、頁面集成等多種方式,將數據智能服務嵌入業務各個環節,實現了即時數據服務的新模式,適應了企業商業智能應用的多樣化需求,探索形成了金融領域的 OLAP+OLTP 服務融合新模式。案例 2
93、:交通銀行建設“湖倉一體”智能數據湖實踐交通銀行在數據中臺與業務中臺的緊密配合下,結合人工智能技術,推進數字化營銷、數字化授信和數字化運營,實現數據業務化、數據價值化。一、案例內容針對原有數據服務模式無法承擔更大規模的計算能力、建模能力不足導致數據應用場景融合不夠、T+0 時效加工覆蓋度不夠等問題。交通銀行選用華為云 FusionInsight MRS 云原生數據湖和 GaussDB(DWS),建立了湖倉一體新范式。圍繞數據服務能力輸出、數字化營運能力提升、計算架構調整等方面,推進全生命周期數據治理,提升數據質量,提升數據服務能力,賦能業務經營。湖倉一體的智能數據湖全新分布式架構提升海量數據服
94、務能力,實現升級過程無數據丟失,應用服務平滑遷移;覆蓋內外部 PB 級海量數據的穩定高效存儲;在業務高并發場景的巨大壓力保持超高性能。51金融數據倉庫發展報告(白皮書)二、案例成效1.提升監管報送質量,建設面向監管的監管數據報送管理臺,將過去手工報送過程逐步自動化、可視化,提升報送效率。2.為行內各層級管理者的經營分析和決策提供全面、準確、快速的“一站式”數據服務,提供總、分、支機構的統一指標管理,將數據報表指標化、數據服務可視化、數據分析產品化。3.建設數字化、配置話、模塊化的實施路徑,助力實現營銷中臺千人千面、客戶分群、定向營銷的新高度,支撐交行零售業務的數字化轉型,構建具有創新性、靈活性
95、的零售服務。圖 1 功能架構圖數據治理平臺華為云平臺數據采集層文件交換消息推送API接口數據庫同步高速數據交換通道日批微批觸發式批量臨時批量實時交換數據服務數據分析服務接口分析工具租戶數據區公共數據區引擎支撐MPP聯機查詢Hbase/Cbase明細查詢多維分析Cube搜索ES集群緩存Redis集群APIBI分析規則引擎圖引擎搜索引擎KylinSASSQLPYTHONBIJDBC批量文件消息訂閱數據計算數據計算數據存儲離線計算MPP+Hadoop批量數據貼源數據基礎數據指標數據近線數據流式數據實時計算Flink+Kafka在線數據52金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論
96、與實務、信息安全研究圖 2 數據倉庫功能架構圖2-報表集群元數據管理統一調度ETL處理1-批量集群3-探索集群4-分行集群5-備份集群全棧國產化部署人民幣跨境支付報表多維分析靈活查詢智能運營智能反洗錢數據挖掘智能審計智能營銷陽光預警經營分析客戶營銷經營決策科學探索監管報送全量備份增量備份恢復策略異常告警績效考核管理評價智慧分行人行支付報表客戶營銷報表統一監管報送報表客戶存款報表存貸款報表風險管理報表接口規范業務狀況報表.數據加載導出接口數據導出負載組策略混合負載管理數據質量核驗數據管理用戶管理權限管理任務管理批量調度主題模型編碼規則導出編碼優先級策略數據標準制定權限管理任務監控拉鏈算法數據清洗
97、導出策略排隊策略數據安全管理角色管理調度引擎報表加工數據校驗傳輸規范懲罰策略元數據管理日志審計抗疫模式數據加載互聯互通生效策略主數據管理認證管理專場模式靈活分析批量加工案例 3:光大銀行湖倉一體數據倉庫大集中建設實踐光大銀行數據倉庫于 2006 年啟動建設,采用 Teradata 軟硬一體數據庫產品,構建以十大主題為核心的數據倉庫基礎數據模型,匯聚全行數據資產。2015 年引入數據庫產品 Greenplum,采用軟硬分離架構,將數據集市遷移到 Greenplum 集群,在提升數據處理性能、用戶體驗的同時,獲得更高的科技和業務價值。為解決 Greenplum 集群橫向擴展局限性,2019 年引入
98、華為云數據倉庫 GaussDB(DWS)。一、案例內容新一代數據倉庫平臺并不是一次簡單的產品選型和替換工作,而是53金融數據倉庫發展報告(白皮書)全新的數據倉庫技術架構重構工作。面對不斷深化、不斷融合、不斷突破的數字未來,光大銀行新一代數據倉庫平臺著力技術、數據兩大方面,激發數據資產價值潛能。此外,光大銀行以“湖倉”一體化打造堅實的基礎數據平臺。聚焦生態融合,實現湖倉一體共生,構建了以數據湖為基礎的貼源數據,以數據倉庫為核心的主題數據,以數據中臺為中樞的共性數據,打造企業級數據服務能力,實現數據敏捷、高效、安全的交付。二、案例成效新一代數據倉庫平臺大集中將 Teradata 和 Greenpl
99、um 上數萬個數據模型、數萬個代碼腳本、數百萬行代碼全部遷移至安全可控的數據倉庫平臺:1.全面提升監管報送、智能營銷、智能運營、智能風控等業務領域的數字化經營水平:集群規模 627 臺,算力提升 3 倍,批量時間縮短 10小時,數據查詢效率提升 6 倍。2.采用集中化建設模式,全行數據統一加工、模型統一設計、開發統一規范、任務統一調度、資源統一管理,從而降低系統管理成本、技術復雜度,提升資源配置效率、數據一致性。3.設計標準化的作業流程指導數十個系統有序遷移,并在遷移過程中,正常承接開發需求、產能不降低,達到了“成本可控、時間可控、風險可控、質量可控、復雜度可控”的效果。54金融信息化研究所(
100、FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究案例 4:招商銀行大規模金融云數據倉庫建設實踐隨著數字化轉型的快速推進,數據采集處理規模大幅增長,逐步呈現“人人用數,人人都是數據分析師”的數據應用模式,招商銀行構建了具有自身特色的云數倉平臺。一、案例內容傳統數據倉庫一體機技術方案存在著生態環境封閉、維護成本高、硬件故障維修復雜、擴容停機時間長等諸多問題,已不能滿足快速、平滑的擴容需求。招商銀行突破封閉技術路線,引入靈活擴展架構,采用華為云 GaussDB(DWS)建設新一代數據倉庫提升平臺性能。二、案例成效招商銀行業務用戶享受到了更輕盈的用數體驗:1.查詢速度快人一步。批量數據
101、處理完成進度整體提前 2 小時以上,業務用戶查詢時長縮短 75%,數據倉庫服務效能顯著提升;2.用數不間斷,人人都是 VIP。集群擴容停機時長由 12-24 小時降至2-4小時,停機追批時長由1-2天降至業務零感知,平臺運維能力大幅提升,用戶隨時取數用數,不再受維護和跑批的影響;3.數據絲滑遷移,替換無感。5千萬業務代碼搬遷量在新舊數據倉庫替換過程中的并行期,通過自研工具實時數據校驗,縮短數據核對間歇,實現一分鐘內完成重要數據在新舊平臺中的數據核對,讓用戶對替換過程無感知。55金融數據倉庫發展報告(白皮書)4.資源彈性管理和按需擴展。在線擴容的重分布速度由 20TB/h 提速至 65TB/h,
102、在線備份速度由 37TB/h 提速至 150TB/h,縮短平臺操作時間窗口,業務快速享用平臺擴展后的更高算力。5.分布式優化技術,全面提升集群處理性能。實現高并發交互式查詢秒級響應,并支撐業務上千并發聯機查詢。案例 5:中信銀行新一代基礎數據平臺建設實踐中信銀行數據倉庫始建于 2014 年,承擔全行業務分析、數據挖掘以及監管報送的數據支撐重任。隨著業務規?;脭敌枨蟊l式增長,原有平臺在性能、擴展性、開放性及服務能力等多個方面均略顯疲態,業務數據供給的時效性問題逐步成為制約數字化轉型的關鍵因素。一、案例內容2020 年中信銀行啟動新一代數據平臺建設,對原有數據倉庫進行重構改造,由一體機下移至分
103、布式服務器,并完成配套研發、管控、運維及測試工藝體系建設,形成基于 GaussDB(DWS)的新一代數據倉庫平臺生態,進一步提高數據倉庫存算能力及數據服務能力。作為行內最重要的數據整合點,新一代數據倉庫為全行各業務部門提供數據服務,包括總行、37 家分行、3 家海外分行、信銀國際及 1 家村鎮銀行,涉及下游100 多個應用,涵蓋所有業務條線。二、案例成效1.新平臺有效解決數據時效性問題,使能業務高效增長。已穩定56金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究運行 1 年以上,重點作業準時率 99%以上,總分行接口下發時效性平均提前 5 小時以上,自助分析響
104、應時間減少 60%以上。2.以自研 B/S 研發平臺為載體,全面建設工具化、線上化、規范化的敏捷研發系統,全鏈路優化傳統數據倉庫研發工藝。3.建立事前、事中、事后的全鏈路管控體系,提前發現并解決問題,最大限度減少生產環境的資源損耗,保證平臺穩定運行。4.建立開發團隊二線運維能力,提升運維團隊大數據技術沉淀;借助移動端預警工具,團隊應急模式由“被動告知”轉變為“主動發現”。案例 6:民生銀行融合型湖倉平臺項目建設實踐民生銀行數據倉庫是全行數據體系的關鍵基礎數據平臺,面向全行業務用戶提供企業級數據應用支撐能力,具有同城對等雙活的特點。隨著數字化轉型快速推進,單一數倉無法滿足數據存儲的多樣性和靈活性
105、,數據應用的多領域(BI、AI、BI+AI)、多生態(SQL 生態、Hadoop 生態、Python 生態)融合的需求,民生銀行同步啟動了新一代數據倉庫平臺和湖倉平臺建設。一、案例內容基于華為 FusionInsight MRS 和 GaussDB(DWS),民生銀行以一體化開發、一體化運維、一體化應用、一體化管理為建設目標,啟動融合型湖倉平臺項目建設。57金融數據倉庫發展報告(白皮書)當前數據湖和數據倉庫平臺均完成基礎資源部署,形成民生銀行新一代湖倉平臺雛形。根據實施規劃,要素遷移從策略上按照各類數據模型的特性,自底向上分層分域方式逐層開展遷移,各分層采用差異化方式向數據湖和數據倉庫遷移實施
106、。二、案例成效1.自動化遷移,提質增效。利用 Data0ps 能力,將代碼遷移開發、各要素(DDL、腳本代碼、數據等要素)的遷移實施、數據一致性檢核以及遷移后異構并行下的部署管理和日常運行管理等功能進行工具集成。2.湖倉協同,降本增效。充分利用華為產品互聯互通的特性,將湖與倉兩種不同技術棧在數據層面、應用層面打通,通過無縫、高速跨源數據同步技術,降低數據流轉成本;通過聯邦 SQL 技術,將湖倉數據關聯運用,支持用戶跨源靈活探索,為數據應用降本增效。3.取長補短,開放兼容。利用湖的多租戶管理能力和湖倉融合后的一體化數據資源,滿足敏捷 BI、AI、BI+AI 等數據應用場景訴求,為數據賦能業務夯實
107、工作基礎。案例 7:華夏銀行湖倉一體化數據中臺建設實踐華夏銀行數據倉庫自 2014 年啟動,經過多年迭代建成完備的數據體系,形成數據應用雙驅動,統一調度的特色基礎平臺。隨著業務快速發展,原數據倉庫平臺從時效性、擴展能力等方面無法滿足業務應用需求。58金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究一、案例內容華夏銀行啟動數字化流程再造工程,選擇 GaussDB(DWS)作為新一代數據倉庫系統平臺,并規劃搭建湖倉一體化數據中臺,按照統一數據模型和實施工藝,對內外部數據進行全域數據整合,實現數據全方位鏈接和融通。充分發揮“數據+模型+技術”主導作用,有效提升業務支
108、撐和風險識別能力。二、案例成效1.整合原數據倉庫、倉外數據集市架構,形成統一數據處理平臺,縮短了數據加工鏈路,提升了數據加工時效。圖 3 數據中臺目標架構BI及數據查詢自助數據探索數據平臺數據倉庫數據湖數據科學與AI平臺數據采集交換報表決策儀表盤開放層引擎層數據訪問層AI及分析模型客戶體驗分行數據服務預測分析建模在線圈人多維數據即席查詢元數據管理數據資產目錄離線開發實時開發算法開發服務開發數據信息中臺訪問計算數據底座領域集市整合層數據資產運營數據資產監控數據資產評價數據標準管理數據質量管理數據安全與隱私API接口(聯機)ODBC批量精準營銷中心智慧運營中心智能風控中心監管合規中心分行特色中心一
109、致性難度應用維度交易事實分布式檢索引擎外部數據整合區實時計算數據區貼源數據區歷史數據區探索數據區機器學習深度學習圖分析非結構化數據處理區客戶風險運營合規分行公共匯總數據主題數據區自動服務引擎圖計算引擎標簽引擎指標引擎消息列隊59金融數據倉庫發展報告(白皮書)2.靈活擴展性方面具有較大優勢,計算能力、存儲規模相對原平臺都有較大提升。3.未來將數據倉庫、數據湖、實時數據等數據資產,按照多種技術模式、多種數據形態進行統一封裝,實現數據成果的直達共享。案例 8:興業銀行數據服務“核心系統”迭代升級實踐自 2006 年建設至今,興業銀行企業級數據倉庫系統已為 120 個總行系統,43家分行及3個子公司提
110、供數據類服務,服務領域涵蓋零售、企金、同業、金融市場、風險、計財、監管等。隨著行內業務數據體量急速增長,原有平臺無法滿足應用快速發展的訴求,2021 年興業銀行啟動了數據科創平臺項目。一、案例內容基于華為云 GaussDB(DWS)建設新一代數字底座 MPP 基礎平臺,構建一套包括數據整合加工、平臺運營監控、數據靈活查詢、API服務等功能的綜合數據服務體系,助力實現最佳生態賦能銀行。當前項目已完成一階段上線,初步形成了新一代數據處理平臺的雛形。2022年底將完成整體建設工作,極大提升我行未來數據處理平臺的高擴展性和可用性,同時擁有批量、實時、時序三大數據服務能力,且充分滿足用戶對平臺的性能要求
111、。二、案例成效1.全棧信創,自主掌控:核心技術自有化,保障數據安全、網絡安全和信息安全,提升金融業務數字化的穩定安全水平。60金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究2.能力融合,橫向擴展:節點數增長 1200%,高可用空間增長2100%,點查詢單集群并發能力增長 2400%。3.一站服務,智能運維:形成一套合理、高效、創新的數據平臺管理方案,以數智化技術與業務流程為數據使用、數據治理、運行維護、業務發展賦能。4.全面開放,助力轉型:以租戶方式向全集團開發數據存儲與計算能力,實現按租戶隔離系統資源,打造綠色、安全、智簡、敏捷的數據生態,賦能集團業務發展
112、。案例 9:中原銀行融合數據湖建設實踐與成效隨著國內銀行業數字化轉型進程的加快,以及數據驅動戰略在銀行的落地實踐,2019 年中原銀行圍繞著分布式數據倉庫與大數據技術,以自主研發架構為主,構建了一套滿足一站式數據集成、存儲、整合、計算與開發的數據技術中臺。一、案例內容中原銀行融合數據湖方案涵蓋了分布式存儲、大數據、數據倉庫等主流技術方案,通過構建湖倉與數據類服務的一體化方案,實現數據在其間按需高效流轉與統一管理,滿足全行不同業務條線的個性化多維度的數據統計分析需求。二、案例成效1.成本節約。支持多類型數據管理和 PB 級海量數據存儲,通過采61金融數據倉庫發展報告(白皮書)圖 4 功能架構圖智
113、慧零售智慧公司智慧風險智慧運營開發工具云原生數據湖云原生數據倉庫數據采集交換平臺外部數據核心系統信貸系統手機銀行行為日志數據開發平臺一站式數據分析平臺冷數據自動遷移代碼智能審核平臺冷數據整合集群應用集群非結構數據貼源層數據用數據智能分層存儲策略,有效降低行內數據單位存儲成本 20%以上。同時也與行內模型管理平臺、反欺詐平臺完成對接,支撐了各類平臺對圖片數據的存儲與使用需求。2.效率提升。通過 Openlookeng 提供的湖倉協同分析能力,有效避免不必要的 ETL,減少 50%以上的數據搬遷,并基于算子下推、元數據緩存、數據緩存等技術,支持數據湖查詢秒級響應。3.研發高效。支持湖倉任務的協同開
114、發與調度,為全行 60+個項目組提供穩定高效的數據開發服務。案例 10:威海市商業銀行湖倉一體數據中臺建設實踐威海市商業銀行于 2012 年開展數據倉庫建設,按需實現數據集中接62金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究圖 5 威海市商業銀行數據架構圖數據消費者業務分析人員管理決策人員監管報送人員業務分析系統貸后風險平臺智能營銷內部數據STA(數據采集與交換)外部數據統一管控平臺實時數據開發平臺DWS(數據倉庫、數據集市)MRS(數據湖)外部數據實時數據數據產生數據規劃數據建設數據治理數據智能數據使用聯盟數據源自有數據源管理駕駛艙BI&報表數據服務運營
115、平臺及門戶標簽管理平臺統一監管報送平臺第三方API外部批次數據源埋點數據流日志數據流現有系統數據平臺數據集市數據工具內部數據流外部數據流外部數據實時流實時數據流訪問信息流數據資產管理平臺統一數據開發平臺數據應用入口數據服務網關TMP 數據臨時區ODS 貼源數據區DWS(數據倉庫)DM(數據集市)LDS 邏輯加工區RTL 零售集市CORP 對公集市RSK 風險集市HR 人力集市FM 財務集市FMKT 金市集市OPT 運營集市FR 監管集市RPT 報表集市HDS 歷史數據區EDS 外部數據區SDS 實驗數據區RDS 實時數據區UDS 非結構數據區數據輸入區臨時加工區數據輸出區基礎主題區匯總主題區公
116、共訪問區FDSADSPDSINPUTMIDD OUTPUT入和應用系統數據供給,支撐全行共性數據加工和報表統計查詢。伴隨行內信息化進程加快,數據孤島、開發周期較長、數據冗余、快速數據服務支撐能力弱、數據架構擴展性差和數據集群算力低等不足亟需解決。一、案例內容2022 年,威海市商業銀行基于 FusionInsight MRS 和 GaussDB(DWS)啟動湖倉一體的數據中臺項目,項目正在持續建設中。目前已經完成全行數據入湖,支撐貸后管理、智慧運營、關聯交易等應用。63金融數據倉庫發展報告(白皮書)新一代分布式數據倉庫構建基礎主題模型,實現行內數據統一整合,構建零售和對公等 9 大業務主題集市
117、,在滿足日常監管報送、數據自助分析等核心業務應用基礎上,支撐業務中臺、智慧營銷和管理駕駛艙業務應用。二、案例成效1.通過基于湖倉一體集群高性能、高擴展、多模融合等特性,日終批量時間可縮短 3 小時,算力提升 3 倍。2.報表查詢實現秒級響應,查詢速度提升 3 倍,數據查詢支持 7*24小時服務,實現 T+0 應用場景。3.集群故障率減少 80%,資源利用率提升 30%。案例 11:江南農村商業銀行融合數據湖建設實踐江南農村商業銀行原數據倉庫采用一體機進行數據加工、清洗、整合以及查詢。隨著國外廠商產品迭代,跨代升級產品和硬件更換的費用高昂,同時原大數據相關組件多年未更新版本,大數據組件中的各種外
118、部數據、非結構化數據與數據倉庫進行關聯分析有較大技術障礙,存在一定的數據孤島問題。一、案例內容隨著分布式數據庫、云原生、湖倉一體等技術的不斷演進,江南農村商業銀行啟動湖倉一體的融合數據湖建設。若干個獨立的物理數據平臺形成一個虛擬數據湖,匯聚多種格式數據源,并通過嚴格的數據權限和資源管控給各種使用者開放數據和算力。64金融信息化研究所(FITI)專注金融科技發展戰略、金融科技理論與實務、信息安全研究二、案例成效1.提供統一的多維加密體系,支持統一安全分析、安全處置、安全態勢感知等高級安全能力,實現信息安全防護與自主可控。2.通過 HetuEngine 實現湖倉聯合查詢分析,連接行內所有系統,打通
119、行內所有數據,覆蓋行內所有人員,強化對全行數字化轉型工作的支撐。3.實時計算能力和標簽加工能力,全面覆蓋我行 12 大交易渠道(手機銀行、網銀等)的 56 個業務場景,實現實時預警交易風險和阻斷欺詐交易,全面防控我行三農客戶免受金融欺詐風險。圖 6 功能架構圖DWS統一數據平臺交互式應用江南融合數據湖數據源搜索應用關系型數據日志數據批/微批實時/準實時外部數據歸檔日志(CDC)數據科學批處理實時處理HBaseElasticSearchRedisFlinkSparkHiveHetuEngine U-SQL實時報表實時決策MRS湖倉一體版CarbonDataKafkaHDFS65金融數據倉庫發展報
120、告(白皮書)本報告是金融信息化研究所聯合金融機構和華為云針對金融數據倉庫開展聯合研究的成果,報告基于行業廣泛調研結果、采用 FITI PIGTH 分析法,數易其稿,終于面世。報告編制得到中國人民銀行科技司有關領導和部門的指導,得到金融機構和科技公司的大力支持;受到中國金電集團公司領導的高度重視,也得到金電信科、國金認證、生態實驗室、金融電子化雜志社等兄弟公司的大力支持。報告完成后,廣泛征集了行業專家的意見,并邀請行業數據庫專家宋瑞、劉文濤、孫科等為報告評審把關,進一步提升報告質量。在此,對上述機構的領導和專家們一并表示感謝。穩妥發展金融科技,深入推進金融業數字化轉型,有難題找 FITI!我們一起攜手并肩,為金融業務數字技術解決方案貢獻力量!致 謝網站:郵箱:更多詳情,歡迎前往金融信息化研究所公眾號FITI 金科智庫,一攬子解決金科難題金融信息化研究所中國金電集團FTPC 金科智庫