淺談數據倉庫與集市構建中小銀行的基礎數據平臺

【摘要】隨著國家對金融市場的進一步開放，小型地方性銀行的政策性優勢也在逐步下降，面對競爭日趨激烈的市場以及高度信息化時代，小銀行的發展必須依靠后臺科技的強力支撐，“數據挖掘”這一關鍵詞也越來越多的出現在各家銀行的規劃日程當中。然而數據挖掘的基礎“數據倉庫”或“數據平臺”的建設尤為重要，只有打下堅實的數據基礎建設出一套完整的標準化基礎數據平臺才能更有效的驅動下一步的數據挖掘與分析，以及為日后建立更多樣化的管理類分析系統提供強有力的支持。

【關鍵詞】小型銀行 數據倉庫 基礎數據平臺 構建

一、背景介紹

近年來隨著銀行業的不斷發展，競爭日趨白熱化。外部監管機構、銀行管理層、業務部門對決策、管理信息的需求也在不斷提高，各種管理信息系統不斷引入如：客戶關系、績效考核、管理會計、貸后、風險管理等。銀行一方面希望通過先進的技術及管理思想提高自身的管理能力，增強銀行在市場上的競爭力，而另一方面，在系統的建設過程中，內部多個業務系統之間又缺乏統一的規范和數據接口標準。因此，在系統建設中經常需要重復建設業務數據的加載功能，這不僅浪費了網絡及存儲資源，而且會給系統造成過大的壓力，甚至產生風險。同時，這些有針對性的數據集市很難做到面向整個銀行的全面性、標準性與統一性。面對業務部門及外部監管部門各式各樣的數據需求，科技部門的數據提取工作往往會出現一團亂麻，東拼西湊的情況。因此，建立一套統一標準的數據平臺已顯得非常必要。

余姚農村合作銀行是浙江省的一家區域性銀行，在浙江省農信聯社實現全省核心業務系統與數據大集中后，由省農信聯社下發核心業務數據包到轄內各行社，供行社數據分析使用。2012年，為進一步加大對轄內農信系統行社的數據支撐，浙江省信用聯社建立了新的業務數據統一下發平臺，增加了重要的外掛系統數據源，對下發數據結構進行了優化調整。但由于各行社的規模、管理水平參差不齊，各行社對數據的利用程度也千差萬別。我作為合作銀行一名數據平臺開發人員，根據近幾年的工作經驗和對農村合作銀行數據平臺建設的了解，從開發人員的視角提出適用中小銀行統一數據平臺的建設的思路，力求建立一套全面、標準、統一的基礎數據平臺，從而解決在以往的工作中所面臨的諸多問題，以供同行參考。

二、解決方案的選擇

如何建設或到底建設什么樣的數據平臺才是真正符合小銀行自身發展的數據平臺，是我們首先需要考慮的問題。明確的目標將指導我們在建設過程中正確的面對應用范圍、系統架構、數據結構、開發技術、應用產品、軟硬件等一系列問題。通常在明確這些需求時很多人會引入“數據倉庫”這個名詞，在這之后便是很多高層次的問題，高投入、高性能、高擴展、高冗余、面向主題模型重組、歷史性等一系列的問題，當這些問題考慮過之后你將面對的將是一個龐大的、高投入的系統，這要求銀行在這方面不單是龐大的資金投入，同時還需要有配套的科技力量予以支撐。

一是TearData、IBM等都是在金融領域有著不錯口碑的解決方案提供商，國內很多軟件廠商通過這些年與之在大中型銀行項目中的積累對于數據倉庫的解決方案也都是駕輕就熟。但通常這種概念的數據倉庫卻并不適用于小型銀行。第一是從系統的整體資金投入出發，通常這種系統軟硬件合計動輒數百萬上千萬的投入讓小型銀行望而卻步。其次是從科技投入出發，小型銀行的科技力量相對來說比較薄弱，要想深入到數據倉庫核心就必然需要有相關科技人員的深度參與，而往往由于科技力量的不足導致系統在建設完成之后難以獨立維護，需要依賴于科技公司，甚至被科技公司所綁架。

二是通過對國內幾家大中型銀行數據倉庫模型的分析來看（TearData或IBM解決方案），整個銀行的數據系統構成并不單是一個數據倉庫（DW）能夠解決的。與之配套的必然有業務歷史數據庫系統（SysHis）、ODS多層次標準化后的業務數據系統等。而數據倉庫建設在這些系統之上，是將業務數據模型拆分或重組之后行成星形或雪花形的模型，并且統計與綜合業務數據之后才進入倉庫。其數據倉庫的建設更是著眼于若干年后，通過SysHis+ODS+DW等多系統配合使用來完善企業整體的數據系統。如圖1所示：

圖1所示，銀行的整個數據系統的完善過程必定要耗費大量的人力物理投入，小型銀行在資金及人力投入上幾乎不可能達到以上的程度，很難建設一套完整的數據系統。但如果從開始就以標準的數據倉庫模型架構去建設，隨著時間的推移歷史數據將大大的喪失其集中的業務屬性特性，那么在以后系統的使用過程中將會非常麻煩。所以在這里我的出發點或者說目標就并不是標準的數據倉庫，而是適合小銀行自身發展的基礎數據平臺。省去SysHis及DW部分，而通過擴展后ODS系統（圖1中第②部分）作為全行統一的基數數據平臺。

三、數據平臺建設思路

就我所看到的幾家大中型銀行的標準數據倉庫借據方案都來自TD或IBM。從模型設計特征來看，業務數據進入倉庫后按照維度被拆分為星形或雪花狀。從海量業務數據的角度出發，這種模型設計在數據檢索和響應效率上有絕對優勢，但同時也因為拆分使得原始的業務系統所下發數據的集中業務屬性特征也不再存在。以往在一張數據表中存在的數據將被分拆到以事實表為主題的若干個數據表中，從操作層面來看日后的操作效率將會大大降低。接下來我將根據自己的經驗，從系統目標和系統架構方面闡述符合小型銀行特點的基礎數據平臺設計思路。

（一）建設目標

區別于大中型銀行，小型銀行的數據規模遠遠低于大中型銀行。只要系統架構合理，數據層次清晰，數據效率和存儲的問題在小型銀行幾乎不會存在，我認為小型銀行的系統建設重點目標要圍繞著以下幾點：規模全+標準化+便捷性+歷史性+適當的資源投入。

1.規模全。是指系統的數據范圍要涵蓋各業務系統數據，通過篩選將各業務系統中有用的數據都納入到數據平臺之中。小型銀行的數據規模雖然較小，但目前所開展的業務種類卻日益豐富，以往單純的核心系統取數已經很難滿足業務部門的需要。因此在平臺建設初期就必須要考慮多業務系統并入的原則。

2.標準化。標準化要做到模型標準化、代碼標準化以及開發標準化。

模型標準化：各業務系統的數據結構以及命名規范一般都不相同，那么我們需要在數據平臺內對其進行統一整改，包括模型名稱、字段名稱、字段類型等，最終所要達到的效果是在不參照數據字典的情況下能夠讀懂數據模型中的數據內容。

代碼標準化：不同的業務系統會定義自己的代碼含義，如同樣一個客戶狀態代碼有可能在核心系統與外圍業務系統中所表示的意義是不同的，這樣我們就需要定義一套標準的代碼，盡量在數據進入數據平臺之后使用相同的代碼。

開發標準化：開發標準化是指在開發過程中需要有一套完整并且標準的開發規范，整個系統的建設都依照規范中定義的規則進行開發，這樣在新的人員進入后能很快的進入開發角色。

3.便捷性。便捷性是指要做到開發便捷、使用便捷、維護便捷、拓展及改造便捷。

開發便捷：最主要的是值要邏輯清晰，等級架構層級低，開發語言簡單便捷。

使用便捷：指要求最終用戶在使用系統時界面友好、操作簡單、易上手。

維護便捷：通常在項目上線后能由一個后臺+一個前端維護人員即可完成日常的維護工作及小量的開發工作。

拓展及改造便捷：要求能夠在外部系統數據結構發生變化是只修改接口模型就能完成絕大部分的改造工作，能便捷的向其他應用系統提供增量或全量數據以及一些基礎的加工匯總數據，如賬戶日均，客戶資產負債等。

4.歷史性。歷史性不僅要求整個系統的歷史周期長，同時還要保證歷史模型對需求應用的響應效率。

5.適當的資源投入。主要指合適的資金和人力投入。整個系統的設計必須圍繞資金投入去考慮，如投入100萬的軟件費用就需要清晰的認識這100萬（40～50人/月）所能夠完成的工作目標。否則會對項目的既定目標產生影響。

（二）系統架構

整體數據流向：

業務系統數據文件→到基礎數據平臺→各個應用系統。基礎數據平臺采用多層次的具有歷史性的ODS系統架構思想，在整個基礎數據平臺部分對上文中目標所關心的點加以實現。如下圖：

1.基礎模型層。如圖2所示，其中基礎模型層保持與業務系統數據結構基本相同，通常只擴展必要的業務日期及系統來源字段，模型采用面向主題的命名規則對模型名稱重新統一命名，將各個業務系統中對應的模型劃分到不同的主題下（如賬戶余額、主擋、合同及簽約信息、登記簿等劃分到協議主題；客戶相關如客戶信息、地址聯系信息等劃分到團體主題；交易、流水相關劃分到事件主題……），以便于以后使用。

圖2中的基礎模型層將所有的業務系統數據按照數據特征劃分到公共、協議、團體、事件、產品、渠道、總賬、其他這8大主題當中，這種主題劃分為銀行業內使用較多的劃分方式。各家銀行也可以根據自身的需要進行相應的補充拓展。同時基礎模型除數據表名稱、字段名稱、類型標準化外還應進行必要的代碼標準化處理。代碼標準化盡量以核心系統代碼為主同步到其他業務系統中。以達到在不參考數據字典的前提下能夠讀懂大部分模型內容的效果。

2.加工模型層。加工層為整個基礎數據平臺的通用整合層，合理地進行一些基礎的業務匯總統計（如賬戶日均、月均）、模型整合和拆分、分戶合并（儲蓄、定期存款合并）、全行統一客戶視圖整合、相關交易流水整合等。完成后的加工層模型力求將常用的數據查詢范圍由多表向單表進行整合，這樣將極大的方便科技人員應對業務部門繁多的數據提取工作。

平臺應用層為建立在平臺之上的統計分析報表層。這一部分也可以獨立BI應用。

3.數據交互。整個系統具有開放性，這三個層次均可對外圍應用數據及時提供數據，出于系統整體邏輯性的考慮，基礎數據平臺與外圍系統的數據交互均采取落地文件交互的形式，以避免各系統之間的依賴程度。

4.歷史機制。歷史性是建立基礎數據平臺中的關鍵點，好的歷史數據存儲機制配合當前性能較高的服務器，對于小型銀行來說一般至少能夠滿足5年以上的歷史數據存儲。圖2中基礎模型層采用普通的增量數據模型保存由業務系統下發的每日增量數據，除明細、登記簿及一些公共應用等模型以外的主擋、余額及客戶相關數據采用當日模型+歷史模型的形式存儲，當日模型中儲存全量的最新的數據，歷史模型中保存每日增量。這樣能夠使正常業務處理過程中避免直接使用歷史數據以保證系統的性能。加工層中盡量整合常用的數據模型后采用拉鏈歷史存儲機制進行歷史數據存儲。這樣既能保證基礎模型層與業務系統的切合度，又能保證歷史數據的使用效率。如下圖：

（三）優勢及風險

小型銀行的科技信息系統正處于發展階段，很多銀行亦在初期階段，我認為標準的基礎數據平臺的建設必須著重考慮，無論是獨立建設還是依托某一具體的系統建設都需要經過系統的分析，其目標一定要圍繞企業發展的需要開展。以上文章中所描述的設計思路的主要優勢為：

1.從系統層面來吸收DW數據倉庫的優點，按主題劃分數據模型，結構清晰、業務貼合度高，科技人員容易且比較好接受。

2.從投入成本來看因為其設計簡單，無論從資金投入還是人員投入都要比建設標準數據倉庫所要投入的資源低。同時建設周期短，能讓企業很快的投入使用，及早的完成更多管理分析系統的建設，以體現其價值。

3.從長遠使用來看其在外圍業務系統發生變化之后改造成本低，只需要改造接口基礎數據層結構即可，同時因為整個基數數據平臺采用的標準化的模型設計其更能為企業打造出一套標準化后的基礎數據，為日后的DW及應用系統打下堅實的基礎。

通過系統整體的實施經驗來看，在系統的建設過程中需要注意以下幾點：

1.小型銀行在建設企業統一數據平臺的過程中切不能貪大，在企業自身沒有標準的基礎數據時盡量避免業務數據模型的拆分。否則將會給日后的系統升級改造及使用埋下嚴重的隱患。給企業帶來不必要的麻煩。

2.數據準確性的保證是整個基礎數據平臺至關重要的一步，在系統建設過程中一定要有完整的數據校驗機制，如總分核對、邏輯層次間核對以及數據完整性檢查等，每日的數據批處理完成之后進行上述檢查，否則一旦出現數據丟失或完整性缺失而重新處理歷史數據將會是一個漫長及痛苦的過程。

3.從系統架構上盡量降低或避免基礎數據平臺與其他依賴應用集市的緊密程度，如基數數據平臺所有與其他依賴的應用系統的交互都采用落地文件的形式，這樣可以保基礎數據平臺不受其他業務系統的影響能夠按時完成業務數據處理工作。

以上內容是作者根據多年在銀行數據領域所積累的經驗之談，水平有限，考慮問題難免有疏漏，謹供同行參考。

名詞解釋

ODS：Operational Data Store，ODS具備數據倉庫的部分特征，它是“面向主題的、集成的、當前或接近當前的、不斷變化的”數據。

SysHis：業務系統歷史數據庫。

DW：Data Warehouse數據倉庫。

作者簡介：張兵（1987-），漢族，新疆烏魯木齊市人，任職于寧波余姚農村合作銀行，研究方向：軟件設計。