銀行數據倉庫體系實踐(7)--數據模型設計及流程


數據倉庫作為全行或全公司的數據中心和總線,匯集了全行各系統以及外部數據,通過良好的系統架構可以保證系統穩定性和處理高效性,那如何保障系統數據的完備性、規范性和統一性呢?這里就需要有良好的數據分區和數據模型,那數據分區在第三部分數據架構中已經介紹,本節將介紹如何進行數據模型的設計。

1、各數據分區的模型設計思路:

       數據架構部分中提到了在數據倉庫中主要分為以下區域,那各數據區域的主要設計原則如下:

       (1)主數據區:主數據區是全行最全的基礎數據區,保留歷史並作為整個數據倉庫的數據主存儲區,后續的數據都可以從主數據區數據加工獲得,因此主數據區的數據天然就要保留所有歷史數據軌跡。

        1) 近源模型區:主要是將所有入數據倉庫的數據表按歷史拉鏈表或事件表(APPEND算法)的方式保留所有歷史數據,因此模型設計較簡單,只需要基於源系統表結構,對字段進行數據標准化后,增加保留歷史數據算法所需要的日期字段即可。

        2)整合模型區:該模型區域按主題方式對數據進行建模,需要對源系統表字段按主題分類划分到不同的主題區域中,並主要按3范式的方式設計表結構,通過主題模型的設計並匯總各系統數據,可以從全行及集團角度進行客戶、產品、協議(賬戶、合同)分析,獲得統一視圖。比如說,全行有多少客戶、有多少產品?通過主題模型事先良好的設計和梳理,可以很快獲得相關統計數據。

       主數據區的模型設計按頂層設計(自上而下)為主,兼顧應用需求(自下而上)的方式,即需要有全局視角,也要滿足應用需求。那頂層設計主要是需要從全行數據角度對源系統的主要業務數據進行入倉,獲得全行客戶、業務數據的整體視角,同時又保存所有交易明細數據,滿足后續的數據分析需求;應用需求指源系統數據的入倉也需要考慮當前集市、數據應用系統的數據需求,因為數據需求是千變萬化的,但是只要保留全面的基礎的業務數據,就有了加工的基礎,當前的數據需求只是考慮的一部分,更多的需要根據業務經驗以及主題模型進行數據入倉和模型設計。

        主數據模型的設計主要自上而下,近源模型層雖然比較簡單,但設計步驟和整合模型類型,分為以下幾個步驟:

      步驟1:系統信息調研,篩選入倉的系統並深入了解業務數據;

      步驟2:對入倉系統進行表級篩選和字段篩選,並將字段進行初步映射;

      步驟3:根據入倉字段按一定規范設計邏輯模型;

      步驟4:對邏輯模型進行物理化;

       (2)集市區:集市區的設計表結構設計主要按維度模型(雪花模型、星形模型)進行設計,主要是為了方便應用分析,滿足數據應用需求,集市區一般以切片的形式保留結果歷史數據,但保留期限不會太長,比如只保留月末數據以及當前月份的每日切片數據。

       數據集市需要從數據倉庫獲得基礎數據,對於倉內集市,可以直接訪問或通過視圖訪問,減少數據存儲,倉外集市則需要從數據倉庫獲得批量數據作為基礎數據進行存儲加工。因此倉外集市還需要設計基礎數據的保留策略。

      集市區的設計步驟如下:

      (3)接口區:接口區的設計完全根據數據應用系統的接口方式來進行,一般也是維度模型(事實表+維度表)方式,接口區之前也提到過,不做復雜計算,只做簡單關聯,可以將復雜計算放到集市或指標匯總層加工。

 

      (4)指標匯總區:作為集市接口區和主數據區的中間層,主要是提供基於各集市和接口數據的共性需求,基於主模型區數據進行統一加工。即面向所有的應用需求來設計,那中間層一般采用維度模型,按從細粒度到粗粒度的方式逐步匯總。由於各數據應用及集市的需求不斷變化,指標匯總區也是不斷進行完善,許多一開始在集市的加工由於其它集市或應用也需要,則會從集市轉移到指標匯總層。常見的數據就是客戶、賬戶、合同等常用的數據實體的寬表(事實表),統一進行匯總后供各數據應用使用。

        另外指標匯總層也包括共性指標的加工,指標可以通過基礎指標配置指標計算加工方式獲得衍生指標,那這些基礎指標和衍生指標的定義、口徑以及加工方式可以由指標管理系統來維護並集成到數據標准系統和元數據管理系統中。

        指標匯總區設計步驟如下:

        (5)非結構化數據存儲區:非結構化存儲區的設計不僅需要考慮非結構化數據本身的存儲,同時需要考慮非結構化數據所帶有的結構化屬性,因此在設計時主要考慮以下幾點:

         1)存儲路徑規划:是需要將非結構化數據按源系統、類型、日期、外部來源等角度進行存儲路徑的規划,分門別類,便於管理。

         2)對非結構化數據的元數據建立索引:比如對於憑證的影像,需要有賬戶、流水號、客戶名等相關結構化數據,以便完整描述影像圖片的來源,通過對這些結構化數據建立索引,方便查找。

         3)對部分文檔內容建立索引:對於部分文檔如合同電子版、紅頭文件PDF需要建立內容索引,以便快速搜索查找文件內容,一般可用支持HADOOP的ElasticSearch來實現。

         4)設立計算區和結果區:由於非結構化數據往往需要使用MAPREDUCE或程序化語言進行處理,也會產生中間臨時文件和結果數據,因此需要規划計算區和結果區來存放這些數據。

 

        (6)歷史數據存儲區:歷史數據區作為歷史數據的歸檔,即包括結構化數據,也包括非結構化數據,對於歷史數據除了存儲也需要方便查找,歷史數據區的規划設計需要考慮非結構化數據存儲區的存儲、索引設計外,還需要考慮以下幾點:

        1)壓縮,由於歷史數據使用頻率低,可以選擇壓縮率較高的算法,降低存儲空間。

         2)容量規划:由於歷史數據歸檔會越來越大,因此需要提前進行容量規划以及歷史數據清理。比如10年以上的數據進行刪除。

         3)可設計一個管理系統對歷史數據進行歸檔、查找以及管理。

 

        (7)實時數據區:實時數據區需要使用部分批量數據來和實時流數據進行關聯加工,因此可從主數據區獲得所需要的數據后進行存放在實時數據區的關聯數據區,同時對於加工結果不僅可以推送到KAFKA等消息中間件,同時也可輸出到實時數據區的結果區進行保留。

 

        (8)在線查詢區:在線查詢區主要在線提供計算結果查詢,常用HBASE來實現,設計按照接口來分別存放到不同的HBASE表,字段內容也主要是接口字段內容。HBASE表可以根據應用或者接口類型進行分目錄和分用戶。由於在線查詢區和實時數據區考慮到作業的保障級別以及資源競爭,往往會單獨建立一套集群,與批量作業集群進行隔離,在線查詢的結果計算可以在批量集群計算后加載到在線查詢區。


免責聲明!

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



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