銀行數據倉庫體系實踐(1)--銀行數據倉庫簡介

銀行數據倉庫體系實踐(1)--銀行數據倉庫簡介

      大家好,我是leo,一個ITer,在銀行從事系統開發多年。對銀行系統架構特別是數據倉庫/ODS等數據類系統有一定的經驗積累,準備將之前的一些經驗整理成文,一來爲自己工作做個總結梳理,二來也希望能和大家互相討論,共同學習,探討新技術、新架構以及趨勢。以下是第一部分簡介。

銀行數據倉庫簡介

        數據倉庫之父比爾(Bill Inmon)在1991年出版的“Building the Data Warehouse”(《建立數據倉庫》)一書中所提出的定義被廣泛接受:數據倉庫(Data Warehouse)是一個面向主題的(Subject Oriented)、集成的(Integrated)、相對穩定的(Non-Volatile)、反映歷史變化(Time Variant)的數據集合,用於支持管理決策(Decision Making Support)。比爾在著作《Building the Data Warehouse》中提出數據倉庫的特徵:

面向主題的 (Subject-Oriented)

集成的 (Integrated)

保留歷史的 (Time-variant)

面向決策支持的 (Decision Support)

面向全企業的 (Enterprise Scope)

最明細的數據存儲 (Atomic Detail)

數據快照式的數據獲取 (Snap Shot Capture)

        建立數據倉庫的目的是爲企業業務分析、市場營銷、成本控制、戰略決策提供所需要的數據支持,那在銀行中,數據倉庫匯聚了銀行主要系統的客戶、業務、財務等數據,爲銀行的日常運營分析、市場營銷、風險控制、財務分析、內部審計、監管報送提供數據支持和服務。

銀行系統羣介紹及數據倉庫的定位

        銀行作爲我國金融體系中的支柱行業,銀行業務涉及種類衆多,業務流程複雜,且像工行、建行等國有銀行服務億級的客戶,每天交易量和BAT等互聯網公司不相上下,同時不能造成1分錢的誤差。因此沒有健壯高效的信息系統做支撐,銀行的業務是無法快速發展的。

        由於業務的複雜性和高業務量,銀行的軟件系統也錯綜複雜且不斷迭代,小的銀行可能是幾十上百個系統,國有大銀行可能有成百上千個系統。銀行的軟件系統從功能劃分主要有交易類系統、數據類系統;

1、交易類系統:交易類系統是承載業務流程的實時交易系統,它們一般是7*24小時運行,是銀行業務正常運轉的關鍵系統,交易系統主要分爲渠道系統和業務系統(賬務系統)兩類:

  1. 渠道系統:渠道系統就是客戶接觸銀行的系統,這些系統大家都比較熟悉並經常使用,如ATM、手機銀行、網上銀行等系統;

  2. 業務系統:主要進行賬戶管理、業務邏輯和賬務處理的系統,如核心系統、個貸系統、票據系統等;

        以前銀行的核心繫統包括了存款、貸款、中間業務等所有業務功能,但隨着客戶數、交易量的增加以及信息技術架構的發展,目前許多銀行的核心繫統已經按業務或功能進行了拆分,演變成了多個系統,如個人貸款系統、公司貸款系統、票據系統、總賬系統、基金理財系統等,從系統上看這樣演變系統間耦合性更低,擴展性更好,從業務上看,各系統的業務分工更加明確;

        隨着核心系統的拆分,系統間的交互原來從核心系統內部的模塊調用變爲了系統間的調用,如從手機銀行查詢客戶存款賬戶的餘額,那需要手機銀行發送交易到核心系統查詢。隨着越來越多的子系統將獨立出來,系統間的交互也更加頻繁。因此很多銀行在2000年後就開始建立了交易總線系統並規範系統間調用的服務,所有系統請求方的系統請求都先發送到 交易總線系統,由交易總線系統進行轉發到服務提供方並將結果返回,統一了系統交互的協議、並且制定了系統間交互的規範。

2、數據類系統:由於交易類系統屬於面向聯機事務處理(OLTP),需要確保交易的穩定和高效,因此消耗大量計算資源的數據加工分析不適合在交易系統中進行,因此數據類系統主要彙集各交易類系統的數據並進行加工,爲各業務部門提供運營管理、風險控制、精準營銷所需的數據和報表。數據類系統面向聯機分析處理(OLAP)。時效性和可用性沒有交易系統高,但是處理的數據量大,業務分析邏輯更復雜。常見的數據類系統有客戶關係管理系統、審計系統、監管報送、報表系統等。

        那數據類系統的數據主要源於各交易系統,是否每個數據類系統都各自去從交易系統獲取數據並各自加工呢?答案顯示是否定的,這樣做不僅浪費系統獲取數據、加工數據的資源,也會使各系統加工口徑不一致。因此許多銀行會建立數據倉庫或者叫數據總線的系統,統一從交易系統抽取數據並進行存儲計算。因此數據倉庫在整個銀行的系統中是作爲全行的數據中心、數據流轉的樞紐,從系統架構的定位來看主要有以下功能:

  1. 數據抽取:採用統一工具從源系統(數據提供系統)獲取數據;

  2. 數據存儲:存儲源系統的數據以及加工計算的數據結果,按時間進行數據的積累;

  3. 數據加工計算:對源系統數據進行關聯、清洗、轉換、彙總計算;

  4. 數據分發:對源系統數據以及加工計算結果進行分發到目標系統(數據使用系統);

                                         圖1.1

        數據倉庫發展已有幾十年,期間也出現了不少新的數據架構,數據倉庫架構也不斷吸收和演變,不斷完善和發展。以下也簡單介紹下與幾個常見的數據架構以及和數據倉庫的關係。

數據倉庫和ODS

        和數據倉庫經常一起出現的是ODS(操作型數據存儲),有些銀行叫ODS,而有些銀行則叫數據倉庫,那兩者有何區別呢? ODS (操作型數據存儲)是集成的(Integrated)、反映當前數據值的(Current-valued)、經常更新的(Volatile(including update)和詳細的(Detailed)數據集合,用來滿足企業集成的操作型的處理需求。和數據倉庫相比主要區別在於:

  1. ODS側重於操作型查詢,查詢數據範圍較小,DW則側重於分析型,查詢數據範圍以及時間跨度較大;

  2. ODS對響應速度要求較高,通常在秒級;

  3. DW側重於歷史數據,ODS以當前爲主,歷史較少;

  4. ODS偏重於準實時更新,也可批量加載,DW偏重於批量加載;

  5. DW採用主題範式化建模,ODS多采用與業務系統同構方式建模;

  6. DW將對數據進行清洗和整合,ODS則儘量保持源數據原貌,以滿足那些強調原樣數據的需求,同時爲數據質量檢查提供原始資料;

 

        舉個例子,如業務需要每隔1分鐘統計下手機銀行的交易量,或者統計某個網點在1小時內的存取現金情況都屬於ODS的範疇,如統計去年每個月的手機銀行交易量以及變化趨勢,並分析那個時間段是手機銀行訪問的高峯期則屬於數據倉庫的範疇。

        但隨着技術平臺以及銀行數據需求的發展,銀行的數據倉庫或ODS逐漸合二爲一,也就是說在同一個平臺既能滿足ODS實時或準實時的數據查詢也能滿足數據倉庫的全行範圍近幾年的數據統計和趨勢變化分析。因此從功能和作用上來看,銀行的ODS和數據倉庫其實說的就是同一個系統了。

                                   圖1.2

數據倉庫和數據集市

        數據集市(Data Mart)是數據倉庫的一個子集,用於從數據倉庫獲取相關的數據加工後提供給用戶,數據集市通常面向特定的業務或者團隊,如市場部門有對應的營銷數據集市,運營部門有運營數據集市等。

銀行的數據集市主要有財務、營銷、風險等集市,這些集市爲各對應的數據系統進行數據加工,另外也會爲各業務部門數據分析人員提供分析集市,由數據倉庫提供相關數據後,由業務人員自行進行數據探索分析。銀行的數據倉庫體系一般包括了數據集市,將數據集市作爲數據倉庫體系的一部分。

 

數據倉庫和數據湖

        數據湖是一個集中化存儲海量的、多個來源,多種類型數據,並可以對數據進行快速加工,分析的平臺。數據湖以其本源格式保存大量原始數據,包括結構化的、半結構化的和非結構化的數據。在需要數據之前,沒有定義數據結構和需求。那與數據倉庫的區別主要在以下幾方面:

  1. 數據格式:數據湖保留了數據的原始格式,包括圖片、WORD、PDF等文檔、影像、語音等多種數據格式,而數據倉庫一般是將原始數據進行一定處理後,獲得結構化的數據放到關係數據庫中。

  2. 數據存儲:數據湖採用大容量低成本的存儲,目前流行使用Hadoop進行數據湖數據存儲和計算, 數據倉庫以前常用MPP架構並行處理數據庫,存儲成本較高,目前互聯網公司也採用Hadoop進行數據倉庫的建設;

  3. 數據使用:數據湖數據不需要提前定義數據模型,主要進行探索分析,數據湖中的數據通過map-reduce等大數據技術來處理,而進入數據倉庫中的數據一般是已經有確定的使用用途,達到一定的分析目標,常使用SQL、數據分析軟件如SAS等方式進行分析處理。

        筆者認爲數據湖和數據倉庫是互相補充的關係,原始數據的保留爲數據分析提供更多的嘗試。目前隨着Hadoop生態發展越來越成熟,許多銀行已經將Hadoop平臺納入到了數據倉庫體系中,作爲非結構化數據的存儲和計算平臺,因此也具備了數據湖的功能,但是銀行的數據分析人員還是習慣於使用結構化的數據即數據倉庫中的數據進行業務分析。

                                             圖1.3

數據倉庫和數據中臺

        數據中臺這個概念是由阿里首次提出,阿里現在擁有衆多業務分支系統,如淘寶,天貓,阿里媽媽,阿里巴巴等,每套系統都有自己的體系和數據源,都在各自的系統上做了很多服務,但數據在各系統之間無法共享,各系統之間還會有功能和數據,服務和應用的衝突,爲了解決這些問題,阿里開始整合挖掘數據,打造數據中臺,從一開始知識做數據的監測和統計到後來的數據化運營和分析,再到搜索個性化,定製化營銷,再到智能化,漸漸讓各個體系融合在一起,建立統一的體系,就算再擴展業務也是納入這個中臺,用相同的技術和模式進行運營。

        所以數據中臺是指通過數據技術,對海量數據進行採集、計算、存儲、加工,同時統一標準和口徑。數據中臺把數據統一之後,會形成標準數據,再進行存儲,形成大數據資產層(數據模型,算法服務,數據產品,數據管理),進而爲客戶提供高效服務。這些服務跟企業的業務有強關聯性,是這個企業獨有的且能複用的,是企業業務和數據的沉澱。比如企業自建的2000個基礎模型,5萬個標籤。數據中臺還包括了數據技術,比如採用統一的技術及框架對海量數據進行採集、計算、存儲、加工的一系列技術集合。

        數據中臺不僅能降低重複建設,減少煙囪式協作的成本,也能快速提供業務數據進行分析,使數據產生價值,同時數據中臺通過爲業務場景提供數據服務,業務場景也不斷產生新的數據及分析模型反饋,滋養給數據中臺,使數據中臺不斷髮展。

        那從銀行來說,銀行數據倉庫體系應該包括數據中臺的功能,許多銀行特別是國有銀行和股份制銀行借鑑國外先進銀行的經驗和架構,在2000年後都開始建立數據倉庫,進行了各業務數據的整合並統一提供數據服務,有些金融集團也在集團層面上整合了各子公司的數據。在數據規範和整合方面許多銀行已經完成,數據平臺技術架構也已經統一,但是在數據意識、數據思維方面和互聯網企業還是有不少差距,許多銀行業務拓展更多依賴經驗、客戶經理、簡單的數據統計,大多應用往往集中在報表、監管報送、審計、風險控制等管理應用,在客戶行爲分析、精準營銷、風險控制等方面還未深挖,在機器學習、AI方面的新技術使用也較遲緩。

        互聯網公司在發展初期着重於產品功能及用戶拓展,需要依靠數據來了解客戶,分析客戶,雖然一開始沒有數據中臺,各產品各自獲取產品、客戶相關數據並進行分析挖掘。通過數據發現用戶在使用產品中的阻礙和問題,找出客戶的痛點。那隨着多個產品的成熟以及發展,數據量快速增加,數據分析工作越來越複雜,數據分析知識經驗也需要沉澱,所以數據中臺也爲了各產品能更好的共享經驗、共用數據而應用而生。

       後續將進行銀行數據倉庫體系的架構介紹

       謝謝!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章