導語

本文講述了金融數據倉庫從無到有的整體設計思路，以及對數據建模、質量控制、元數據管理及開發規範各方面的經驗思考，希望對大家在數倉建設工作方面有所幫助。

背景

自2018年以來，隨着業務體系的不斷豐富與發展，數據分析與應用需求越來越豐富，對金融數據倉庫建設的要求也越來越迫切。
金融數據倉庫建設需要解決的問題，主要包括如下幾點：
1、數據存儲和組織不成體系，數據集成的開發、維護及分析應用成本高；
2、數據質量缺乏定義，缺乏有效統一的數據質量監控體系；
3、缺失元數據規範管理，數據開發、表結構定義不統一，數據任務、數據表維護成本高；
綜上，數據倉庫的建設，將根據數倉建模方法論，構建一整套架構合理，並具有元數據管理和數據質量監控的現代數倉體系。

大數據領域建模綜述

1、爲什麼需要數倉建模

業界認爲數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合。數據在數倉中進行有序、有結構地分類組織和存儲。通過建立適合業務和基礎數據存儲環境的模型，可以帶來以下優點：

1） 成本降低：減少數據冗餘，計算結果複用；

2） 性能提升：快速查詢數據，減少數據的I/O吞吐；

3） 效率提高：提高用戶的使用數據體驗，使用數據效率；

4） 質量改善：解決數據統計口徑的不一致性，統一對外的數據發佈。

 2、數倉建模方法論選擇

行業內，常用的數據倉庫建模方法主要分爲以下幾種：

1） ER模型——站在企業角度面向主題的抽象

優點：ER模型從數據庫的角度出發，結合業務系統的數據模型，能夠非常方便的實現數倉建模；

缺點：由於建模限定在數據庫結構之上，且是建立於企業角度，會限制整個數倉模型的靈活性，性能等，特別是對數倉的底層數據向數據集市的數據進行彙總時，需要開發複雜邏輯才能滿足需求，所以更適合於小規模、邏輯簡單的建模；

2） 維度模型——從分析決策的需求出發構建模型

優點：維度建模非常直觀，緊緊圍繞着業務流程，直觀地反映業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模；

缺點：構建星型模式之前需要進行大量的數據預處理，因此在數倉低層會有大量的數據處理工作；而且，當業務發生變化，需要重新進行維度的定義和預處理，而這些處理過程往往會導致大量的數據冗餘；

3） Data Vault模型——出發點是爲了實現數據的整合

優點：提出了一套設計原則和結構，在數倉中增加歷史跟蹤性能；數倉模型足夠靈活，可以在迭代過程中的任何時間點採用這些結構，並且可以不需要熟悉業務並進行前瞻規劃設計；

缺點：DV代表了對關係、業務鍵和屬性的分解方法，因此與非規範化結構(如星型模式)相比，創建的表的數量更多，由於這個原因，需要許多  joins來查看DV中的數據，使用不太常規和方便；

比較三種建模方式優缺點，並經過對實際業務的分析，基本抽象出業務模型，同時，爲了避免業務變化對上層報表產生較大影響。選擇採用維度建模方法來搭建數倉，面對業務技術構建技術主題模型，面對業務需求構建分析主題模型，將業務變化消化在技術主題模型而不用修改分析主題模型，這樣對用戶的使用盡量透明化。

數倉體系建設

下圖爲數倉體系架構圖：

圖1 數據倉庫架構

1、數據概述

業務數據主要包含車分期、房金融、消費金融等業務線上的運營概況、風險控制、營銷轉化、財務覈算等數據集合。

 2、數倉架構分層

數據倉庫構建過程中，採用分層思想，各層功能及建模方式和原則如下。

1） I(Inbound)層

功能：

從原系統獲取數據做的備份，一般不做其它邏輯處理；

建模方法：

  • 數據保留時間根據實現業務需求而定；

  • 源系統以增量或全量方式經過ETL到I層；

  • 可以分表進行週期存儲，存儲週期不長；

2）

C(Consolidation)層----核心層

功能：

  • 根據業務設計技術主題模型，目的是可靈活支持業務需求；

  • 屏蔽業務底層複雜邏輯和變化，業務系統變化削弱在數據模型層；

  • 簡單、完整、集成的將數據暴露給高層；

建模方法：

  • 按技術主題劃分；

  • 數據清洗轉換；

  • 維度建模；

方案特點：相比傳統的三層(ODS-DW-APP)架構，當業務複雜時，業務的需求紛繁複雜，直接從DW滿足需求：

  • DW可複用對象較少，開發和維護成本較高；

  • ODS的變化會極大可能影響到APP的數據計算，影響業務地使用；
    而本方案構建了技術主題層(核心層)，通過抽象各個相對獨立的技術主題數據(比如訂單、風控、放款模型)，屏蔽和消化了I層的變化帶來的影響，不至進一步影響上層模型的相對穩定；

3） S(Subject)層

功能：
面向業務需求設計分析主題，支持明細查詢和指標計算；
建模方法：

  • 面向業務過程、面向分析；

  • 基於維度的寬表或指標；

方案特點*：通過C層屏蔽I層的變化，S層的分析主題模型更加貼合用戶的分析需求並可以保持相對穩定，同時也讓分析主題模型的構建可以不用侷限於業務數據庫的設計，而可以根據實際業務需求來建模；
4） R(Report)層
功能：
報表指標層，存儲根據業務需求計算後的維度指標數據；
建模方法：

  • 面向決策；

  • 保持數據量較小，支持快速查詢、分析；

  • 指標預先計算彙總；

通過本方案的層次和模型實際，整個數倉低層(I、C)可以完全面向技術建模，完成數據的整理、清洗和集成，高層(S、R)則可以完全面向需求建模，根據實際業務構建適用、好用的分析主題模型，而無需被技術層設計所約束。不僅完成了模型層次劃分，同時也給後續數倉兩段模型的並行設計和開發提供了基礎。

 3、數據質量監控 數據輸出需要保證正確性，數據質量監控可以從技術手段輔助及時發現問題。

圖2 數據質量監控系統結構圖

目前涵蓋自動生成基礎校驗、即時監控報警、人員打分及每週質量報告功能，以輔助監控數倉運行過程中出現的問題。

圖3 數據質量監控流程

4、元數據規範管理 以減低數據任務開發、數據表維護及數據一致性保證的成本，輔助開發了元數據管理系統。

圖4 元數據管理系統

通過技術約束和管理輔助的方案，保證了所有的線上開發都在元數據管理體系下進行：
1） 命名機制：
① 詞根：通過梳理金融業務常用維度和指標含義，建立和維護可收斂的詞根庫，提供數倉開發的字段組合使用；
② 字段：必須使用詞根庫裏的詞根構造字段，並保證不同表中同一含義的字段命名一致，方便數據開發傳遞的一致性，也爲後續血緣分析提供基礎；
*在添加字段時，爲了降低生成字段的工作量，會調用開源分詞工具輔助開發人員初步生成合符詞根規則的字段名。
③ 數據表：根據主題統一命名數據表名，字段必須來源於元數據管理系統中的維護字段，以方便開發、產品、業務對錶的使用；
2） 審覈機制：新增詞根或字段需嚴格按照規定命名並經過多層審覈
3） 追責機制：實行追責機制，定位到責任人，提高所有人員的責任意識；
4） 一致性保證：一鍵建表功能可以自動在落地庫建表，保證元數據表和落地庫的表結構一致，表添加字段也可以直接同步到落地庫。同時每天會進行一致性檢測，並進行異常報警；

圖5 元數據管理執行方案

5、數倉建設規範

58金融數倉建設過程中，從字段命名規範、表命名規範、編碼規範來減低模型後續開發、維護成本。

5.1 字段命名規範

1） 表字段採用下劃線命名法，字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字；

2） 數倉所有字段名稱必須從元數據字段命名庫中獲取，禁用保留字，如 desc、range、match、delayed 等；

3） 元數據字段必須從詞根庫中組合獲取；

4） 字段命名庫中不存在的名稱，在翻譯後首先添加到字段命名庫中，然後在建表中使用；

5.2 表命名規範

1） 通用前綴：

  • 分層：層次對應小寫字母(i、c、s、r) 類型

  • 類型：t 表示表，v 表示視圖

  • 數據類別：f 表示事實數據，d 表示維度數據，s 表示快照數據

2） I 層自動抽取表命名規範
格式：分層類型數據類別_主題_原數據庫名_原表名
表示例：CRM用戶表：itf_usr_db58_customercrm_customer
視圖示例：CRM用戶表視圖：
itf_usr_db58_customercrm_customer_view
3） C、S、R 層表命名規範

  • 格式：分層類型數據類別_主題_描述[__分區]
    目標表示例：訂單表：ctf_ord_order
    臨時表：如果是臨時表，則在的描述後面添加 temp 及序號，示例：訂單臨時表：ctf_ord_order_temp_001，從 001 遞增。

  • 視圖命名：cvf_ord_order__car，注意描述跟分區之間使用2個下劃線連接。

  • 通用字典表：itd_表名
    彙總參考：

5.3 編碼規範
1） SELECT 語句選擇的字段按每行一個字段方式編排
2） SELECT 單字後面一個空格後直接跟首個選擇的字段，其它字段前與第一個選擇的字段對齊，逗號放置字段名前面
3） AS語句必須有，並且應與相應的字段在同一行
4） 同一級別的子句間要對齊，與相應的SELECT語句左對齊編排
5） 子句後續的代碼離子句首字母二個縮進量起編寫
6） where 子句下的邏輯判斷符 and、or 等與 where 左對齊編排
7） 超過兩個縮進長度的子句加空格後編寫後續代碼，如 order by 和 group by等
8） CASE WHEN 語句使用如下對齊方式：WHEN 和 ELSE 對齊，CASE 和 END 對齊
9） 每行寬度不超過 250 字符，超過行寬的代碼可換行與上行對齊編排
10） 代碼編寫完成後，統一先使用 plsql 工具進行美化，再進行微調

總結和展望

在數據倉庫建設過程中，
1、初步構建相對合理的數據體系結構，能夠快速支持數據的集成，降低了業務迭代變化對數據模型的衝擊；
2、業務知識體系初步建立，降低數據使用成本；
3、元數據管理體系初步建立，能夠對核心字段和數據指標進行管理監控，基本覆蓋核心數據應用分析場景；
後續將圍繞以下幾點繼續進行數據建設：
1、易用性：推進S層、R層數據對外易用性迭代，不斷降低用戶使用數據的成本；
2、時效性：圍繞數據產出穩定性與時效性，持續優化已有數據作業。

參考文獻

1、《大數據之路-阿里巴巴大數據實踐》
2、《數據倉庫工具書-維度建模權威指南》

作者簡介

胡明昊，58金融技術中心數據平臺部，數據高級開發工程師。

閱讀推薦

相關文章