隨着銀行業務規模和交易數量的增長，爲了實現全行統一的數據存儲及分析，各商業銀行普遍實施了以Teradata、GreenPlum等爲代表的中高端數據倉庫系統項目，通過彙總銀行內部各交易系統的數據，並根據數據標準化要求，進行清洗、轉換，最終統一存儲用於行內數據統計與分析。

但近幾年，面對互聯網金融的挑戰，銀行業務已經發生巨大變化，各種結構化、非結構化海量數據蜂擁而至，而基於海量數據下的精細化管理以及快速業務決策需求正成爲一種普遍情況，對數據應用的時效性、複雜性提出了巨大的挑戰，因此形成了對傳統數據倉庫解決方案的質疑：難以支持實時數據服務、過高的海量數據存儲成本、無法支持非結構化數據處理等等。

由此廣東華興銀行創新的提出了混合型數據倉庫架構，將數據倉庫定義擴大爲全行統一的數據服務中心，整合了內存數據庫、關係型數據庫、Hadoop等多種數據處理技術，根據不同業務場景對數據應用的需求，靈活提供數據服務，同時滿足低成本、安全性、可用性、敏捷性、自動化的需求。

目前該混合架構已在廣東華興銀行實現了第一階段的功能落地，對商業銀行特別是中小型商業銀行具有重大的借鑑意義。

一、數據應用的發展方向

數據倉庫（Data Warehouse）廣泛被接受的定義由比爾·恩門（Bill Inmon）於1990年提出：數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，主要用於信息共享和高層的管理決策。近幾年來，國內外很多金融機構從支持商業智能和優化業務的角度出發，相繼開展數據倉庫的建設，數據倉庫及數據分析技術在業界引起廣泛探討和實踐。

隨着金融服務的不斷創新，以及互聯網技術的快速發展，金融機構對於數據的應用已不再侷限於經營報表、管理決策等傳統數據分析需要，而是期望在更多的金融服務場景發掘數據的應用價值。在這樣的背景下，除了企業內部產生的各類交易和管理數據，部分金融機構已開始通過從互聯網，以及第三方合作機構獲取外部數據進行補充；同時除了已明確定義的結構化數據外，也開始嘗試挖掘音頻、視頻、地理信息、文件、資訊信息等無法直接進行分析的非結構化數據的價值。

從各個渠道所獲取的數據數量龐大、種類多樣、實時性強，傳統的數據倉庫技術難以完全支持相應數據的處理，因此近幾年大數據的概念逐漸流行起來，同時針對大數據的存儲、處理和分析技術也得到了迅速的發展。但大數據技術也存在其侷限性，例如Hadoop技術在超大文件、流數據處理、分佈處理等方面具有較大優勢，但在低延遲數據訪問、數據多次寫入、大量小文件處理的支持上還存在較大缺陷。

在進行數據倉庫項目的建設選型中，採取傳統數據倉庫技術難以支持大數據的處理，而採取Hadoop等大數據技術又在傳統數據應用支持上存在缺陷，因此，華興銀行提出一種混合型數據倉庫架構，以發揮各類數據技術的優勢，同時形成技術短板的互補，以應對金融機構的各種數據應用場景需求。

二、數據倉庫的能力設計

傳統數據倉庫更多用於支撐數據分析和數據挖掘應用，通過分析各種常見業務需求，並考慮數據倉庫爲全行數據中心的定位，可以擴充數據倉庫對於各類業務場景的應用支持：

1）實時數據共享： 支持各業務系統通過接口查詢數據倉庫的各類實時數據，例如支持各渠道系統實時展示客戶全資產負債視圖，由數據倉庫實時彙集客戶最新的資產負債信息，則各類渠道系統（如網上銀行、手機銀行等）只需訪問數據倉庫實時獲取信息，無需分別到各個產品系統獲取客戶產品餘額再組合。

2）批量數據獲取： 支持通過接口或文件方式獲取批量數據，例如綜合報表系統通過文件方式批量獲取數據倉庫的每日數據，用於進行各類經營管理報表的生成和展示。

3）歷史數據查詢： 支持通過接口或文件方式查詢金融機構開業以來的各類報表、回單、單據等靜態數據，以及支持查詢開業以來的各系統的歸檔數據。

4）非結構化數據處理： 支持對文件、影像、視頻、音頻等非結構化數據進行存儲及查詢訪問。

考慮到以上的各類數據應用場景，數據倉庫架構應提供以下核心能力支持：

1）數據時間範圍： 可在數據倉庫中訪問各個時點的數據，包括當日實時數據和所有歷史數據。

2）數據訪問性能： 可根據訪問需求保證數據的訪問性能，如當天的數據用於實時交易要求在毫秒級響應；歷史數據用於分析挖掘可在分鐘級響應。

3）數據類型支持： 可支持正常結構化數據的存儲和處理，也可支持視頻、音頻、文件等非結構化數據的存儲和處理。

4）訪問方式支持： 可支持數據的實時報文查詢，也可支持數據的批量文件查詢。

5）數據標準支持： 數據倉庫的結構化數據應遵循數據標準，以保證外部數據使用的易用性和一致性。

三、混合數據倉庫的整體架構

基於數據倉庫的核心能力設計，並針對各類數據倉庫方案的技術優勢，可按以下架構開展數據倉庫的建設（見圖1）：

圖1 數據倉庫整體架構

根據數據時間範圍、數據訪問性能、訪問方式支持、數據類型支持等不同，數據倉庫的整體架構可分爲 實時數據倉庫、歷史數據倉庫、歸檔數據倉庫、數據總線 這四大模塊：

1、實時數據倉庫

實時數據倉庫所存儲數據時間範圍爲T日的實時數據及近期（T+7日），主要提供業務系統需高訪問頻度數據，幷包含實時的輕度彙總數據（如客戶資產總額）。其通過源系統信息推送方式實時獲取交易系統及外部的數據，實現價值信息實時而高效的獲取，爲業務系統的數據查詢和分析型系統的實時決策等提供數據支持。

由於實時數據倉庫需要支持數據的實時更新和實時訪問，其應對場景爲需及時響應、高併發的交易場景，因此在技術選型上可採用內存數據庫，利用高效內存計算技術，進行實時彙總、整合處理，同時可以支持高頻讀寫的應用訪問場景。

2、歷史數據倉庫

歷史數據倉庫所存儲數據時間範圍爲T+1日至3年，每日日終從全行各源系統批量獲取T+1的數據，採用統一模型策略，集成全行各業務系統有商業價值的基礎數據，實現對基礎明細數據的存儲、整合和加工處理。

歷史數據倉庫的定位和能力要求與傳統的數據倉庫一致，主要是爲經營分析和管理決策提供全方位、多角度、深層次的數據支持，滿足分析型應用需求，因此可採取傳統的數據倉庫技術搭建。

3、歸檔數據倉庫

歸檔數據倉庫所存儲數據時間範圍爲3年以上的歷史數據，以及各類文件、音頻、視頻、圖像等非結構化數據，主要用於在線長期保存歷史數據倉庫、文服和下游各應用系統的離線歸檔數據，爲客戶交易明細歷史查詢等歷史數據查詢提供支持，同時可支持非結構化數據的存儲、查詢和處理。

歸檔數據倉庫存儲的數據量巨大，且涉及非結構化數據的支持，應用上較爲符合大數據的處理要求，因此可採用Hadoop等大數據平臺搭建，除滿足基本的數據歸檔和查詢需求外，還可支持後續對非結構化數據及大數據處理的擴展。

4、數據總線

數據總線定位爲針對外圍應用系統訪問實時、歷史、歸檔數據倉庫的數據查詢服務，通過統一的接口服務，實現外圍應用對跨系統、跨週期數據的查詢。數據總線提供聯機的查詢服務，滿足高併發、小數據量的查詢；對於大數據量的查詢，採取異步方式，在數據總線中生成數據文件後，通過通用文件服務平臺進行文件的傳輸和處理。

數據總線主要是向外圍應用提供訪問數據倉庫的服務，因此在功能要求上與企業服務總線（ESB）類似，可採用企業服務總線類似的架構和技術。

四、混合數據倉庫的詳細設計和實現

1、實時數據倉庫設計

1）詳細設計

實時數據倉庫需要滿足實時數據的大量併發讀寫和毫秒級響應要求，因此在覈心技術選型上選擇基於Redis數據庫（一款開源的Key-Value內存數據庫）搭建，架構設計如下圖（見圖2）：

圖2 實時數據倉庫架構設計

實時數據倉庫的架構主要分爲兩層，數據存儲層和應用層：

① 數據存儲層

數據存儲層使用最基本的數據庫功能進行數據模型的落地和數據存儲，Redis數據庫用於存儲交易明細和輕度彙總數據，MySQL數據庫用於每日日終與歷史數據倉庫進行明細數據和彙總數據的核對，以保證可自動發現由於交易實時推送出錯導致的數據不不一致問題。

其中Redis數據庫採用主從集羣方式提高讀寫性能和系統可用性，此外也使用Redis數據庫的AOF（掉電保護文件）模式來確保服務器宕機後可通過物理文件進行數據庫的恢復。

② 應用層

由於數據存儲層不支持數據的邏輯處理，需通過應用層部署各類數據服務功能，包括數據服務池模塊、事務處理模塊、批處理模塊、SQL適配器、管理後臺功能等。

數據服務池： 提供對外接口服務的管理，包括處理標準服務數據的標準組件、處理特殊服務或業務邏輯的專用組件、接口及組件定義的參數配置和對外服務的管理發佈。

事務處理模塊： 由於Redis不支持事務，需通過應用層的事務處理模塊實現事務提交或回滾，在明細同步和輕度彙總處理中如果出錯，需控制進行數據回滾，保證數據的一致性。

批處理模塊： 提供日終批次處理服務，主要用於與歷史數據倉庫的明細和彙總數據覈對處理。

SQL適配器： 封裝對Reids和MySQL等數據庫的訪問。

管理後臺： 向管理員提供系統參數配置、日誌查看、系統運行情況監控的管理界面功能。

2）關鍵技術總結

由於實時數據倉庫採用的Redis數據庫爲Key-Value類型數據庫，與傳統的關係型數據庫無論在數據存儲結構還是數據查詢語言上都有極大的不同，如果每類數據在Redis數據庫上的落地都需要進行特殊設計和開發，將導致後續的維護成本非常高。爲解決該問題，在方案中實現了傳統關係型數據庫表結構和Key-Value類型結構的轉換模型，以保證關係型數據庫的任意表結構均可直接在Redis數據庫上落地；此外也針對Redis數據庫設計了專用SQL適配器，讓開發人員可以直接使用標準SQL操作和查詢Reids數據庫的數據。

① 數據存儲模型

a.  關係型數據表的每行記錄在Redis中存儲爲一個Key-Value值。

b.  Key值字符串格式爲“Detail:表名:主鍵字段1值||主鍵字段2值||…”；如果數據表並無主鍵，則自動生成一個不重複的自增序號作爲主鍵，以便可區分記錄並進行數據訪問。

c.  Value存儲的是一個Hash類型，存放1行表記錄的所有“字段名-字段值”鍵值對（Key-Value）。

d.  如果可確定要訪問數據的主鍵值，可通過“HGETALL key”命令直接訪問行記錄的hash對象，或通過“HGET key field”命令獲取記錄指定字段的值。

② 索引模型

對於檢索非主鍵字段值的查詢需求，需要建立相應的字段索引，以提高數據的訪問速度。

a.  關係型數據表的每個字段的每一類值，可建立一個Key-Value鍵值對存儲相應的索引信息。

b.  每插入一行數據，需在現有索引值Key-Value上增加對應的key字符串，或新增一類索引值Key-Value鍵值對。

c.  字符型字段的索引Key值字符串格式爲“Index:表名:主鍵名:字段名:字段值”，Value值爲對應記錄主鍵字符串列表。

d.  數字類型字段的索引Key值字符串格式爲“Index:表名:主鍵名:字段名”，Value爲sorted-sets結構，其中字段值直接作爲sorted-sets結構的分數(score)，對應記錄的主鍵字符串爲sorted-sets結構的值，通過對分數(score)排序來提高檢索數據的效率。

2、歷史數據倉庫設計

歷史數據倉庫基本沿用傳統數據倉庫的技術方案，方案上與傳統數據倉庫的區別僅在於數據標準轉換的落地工作在源系統實現，歷史數據倉庫內部直接使用經過數據標準轉換後的數據，無需轉標的處理，架構設計如下圖：

圖4 歷史數據倉庫架構設計

歷史數據倉庫的設計基本採用傳統數據倉庫的方案，說明如下：

1）使用Oracle數據庫，通過Oracle RAC實現數據庫的高可用性。

2）在數據倉庫的建設過程中同步制定相關的數據標準，以及設計對應的數據標準接口，由源系統按數據標準要求實現標準轉換後，再將已實現標準轉換的數據供給數據倉庫進行處理。

3）由於數據標準已在源系統落地，數據倉庫內部的層級只設計4層，與傳統數據倉庫的5層結構有所區別。

4）ETL過程與傳統數據倉庫方案一致，通過統一調度服務實現ETL的調度。

3、歸檔數據倉庫設計

歸檔數據倉庫主要存儲兩大類數據，第一是來源於歷史數據倉庫的明細數據歸檔，該歸檔爲結構化的數據，通過數據總線提供查詢服務；第二是非結構化數據歸檔，針對對賬單、報表等非結構化數據，可以通過數據總線進行查詢。

歸檔數據倉庫的總體架構設計如下圖：

圖５歸檔數據倉庫架構設計

歸檔數據倉庫的核心技術是利用開源的Hadoop集羣及相應組件，提供數據庫存儲、文件存儲、數據檢索、分佈計算等功能，同時在對外的應用層中封裝數據交互接口、文件處理、文檔檢索、數據查詢等常用功能，對外提供相應數據服務。

4、數據總線設計

數據總線功能要求上與企業服務總線（ESB）類似，因此採用企業服務總線類似的架構和技術實現，總體架構設計如下圖：

圖６ 數據總線架構設計

數據總線的架構說明如下：

1）外部服務接口層

接收外部WebService請求，經過安全模塊檢查通過，發送報文消息給消息服務層，等待消息服務層返回響應交易報文消息，取回響應報文返回外部。

接受流量監控接口層流量進行控制。

2）安全模塊層

進行交易報文的檢查，操作人員權限檢查，系統安全檢查。

3）服務控制層

接收消息服務層指定消息隊列消息，分拆請求報文，發出調用數據接口交易的消息給消息服務層，等待消息服務層返回消息，解析返回消息，組合成響應交易報文，發送響應消息報文至消息服務層。

接受流量監控服務層流量進行控制。

4）消息服務層

接收消息服務層指定隊列消息，轉發至指定消息隊列。對阻塞的消息進行緩存，並在適當時候重新載入消息隊列。

5）數據訪問層

接收消息服務層指定消息隊列消息，解析數據訪問信息，調用制定的數據訪問適配器，訪問對應數據倉庫，得到返回數據，組織成返回消息，發送至消息服務層。

接受流量監控訪問層流量進行控制。

6）流量控制模塊

監控接口層、服務層、接口層的報文，依據設定的參數進行流量控制。超出流量的直接返回系統流量控制超出信息。

負載均衡在系統接近流量控制時，啓動備機資源，進行負載均衡。

7）公共模塊

配置化管理、參數管理、文件管理。

五、混合數據倉庫的應用

廣東華興銀行在2015年按照混合數據倉庫的架構進行了可行性研究，並於當年按照混合架構啓動了數據倉庫項目，該項目於2016年5月完成建設，實現了混合架構中的數據總線、實時數據倉庫、歷史數據倉庫的投產和實際應用。

在歷史數據倉庫的建設中，嘗試了源系統落地數據標準，以標準接口向數據倉庫供轉換後數據的實施方式，目前已按該模式順利完成了貸款類數據的數據標準制定及數據入倉，並對應完成了貸款類數據報送集市的投產應用，主要效果如下 ：

1、由於入倉數據均在源系統進行標準轉換，可通過該模式推動源系統建設中注重對數據標準落地執行，以應對傳統數據倉庫建設無法推動數據標準在全行各系統落地執行的難點。

2、由於入倉的數據均已完成了數據標準轉換，歷史數據倉庫的開發人員無需熟悉源系統數據結構，只需專注於業務數據的處理和應用本身，可降低開發人員的經驗和能力要求，降低項目實施難度。

3、源系統建設過程中的數據結構變更，只需在該源系統上對應調整標準轉換邏輯，數據倉庫及下游應用無需進行改造，可有效降低源系統數據變更的業務影響，並減少數據倉庫及下游應用的成本投入。

另外，通過數據總線和實時數據倉庫的建設，實現了實時業務場景的數據支持，並取得了良好的業務效果。主要的業務場景是在手機銀行向客戶展示實時的全資產視圖，客戶在廣東華興銀行進行轉賬、理財購買、基金購買等金融交易後，交易及賬戶餘額信息將實時推送至實時數據倉庫進行客戶資產視圖的彙總，手機銀行等電子渠道只需直接訪問實時數據倉庫即可快速獲取客戶全資產信息，並且不會對核心、理財等賬戶管理系統造成性能壓力。  

以下是廣東華興銀行手機銀行客戶全資產視圖應用的效果截圖：

圖7 手機銀行總資產及各類資產查詢截圖

混合型數據倉庫架構的應用，不僅改變了數據倉庫項目的實施方式和技術選型，更重要的是擴展了數據倉庫的在實時數據和大數據兩方面的服務能力，讓數據倉庫的應用不再侷限於報表展示、分析決策等交易後的業務場景，而是可以直接爲交易前、交易中的業務處理提供數據支持，進一步擴大了數據應用的價值體現。

時代給予傳統金融業的危機感從未停止過，不論是互聯網的衝擊，還是疫情引發的新一輪挑戰。爲此 Gdevops全球敏捷運維峯會北京站 精選出近10家銀行的金融科技探索，分享其在中臺建設、數據庫遷移、運維轉型上的實戰經驗，助力Fintech戰略落地。部分主題：