一篇萬字長文講清如何作數據治理

乾貨：解碼OneData，阿里的數倉之路。

免費開通大數據服務：https://www.aliyun.com/product/odps

據IDC報告，預計到2020年全球數據總量將超過40ZB(至關於4萬億GB)，這一數據量是2013年的10倍。正在「爆炸式」增加的數據的潛在巨大價值正在被髮掘，它有可能成爲商業世界的「新能源」，變革咱們的生產，影響咱們生活。當咱們面對如此龐大的數據之時，若是咱們不能有序、有結構的進行分類組織和存儲，那麼在價值被發現前，也許數據成本災難已經來臨。它猶如堆積如山的垃圾，給咱們企業帶來的是極大的成本，並且很是難以消費和發掘價值，也許數據更可悲的命運是在價值發現以前它以死去。不得已的歷史數據清理還在進行中嗎？

那麼，企業大數據體系的數據架構應該如何創建？如何保障數據快速支撐業務而且驅動業務發展？在2016數據庫技術大會上，數據中臺的高級技術專家王賽結合阿里數據的實踐成果，按照背景、方法思路以及如何落地實現、效果如何的邏輯，爲你們詳細介紹阿里數據中臺的祕密武器——OneData體系。

 

背景》》》》》》》

在企業發展初期，數據研發模式通常緊貼業務的發展而演變的，數據體系也是基於業務單元垂直創建，不一樣的垂直化業務，帶來不一樣的煙囪式的體系。但隨着企業的發展，一方面數據規模在快速膨脹，垂直業務單元也愈來愈多，另外一方面基於大數據的業務所須要的數據不只僅是某個垂直單元的，使用數據類型繁多(Variety)的數據才能具有核心競爭力。跨垂直單元的數據建設接踵而至，混亂的數據調用和拷貝，重複建設帶來的資源浪費，數據指標定義不一樣而帶來的歧義、數據使用門檻愈來愈高……這些問題日益凸顯，成爲企業發展迫在眉睫必需要解決的問題。

 

1）數據標準不統一

在創建OneData以前，阿里數據有30000多個指標，其中，即便是一樣的命名，但定義口徑卻不一致。例如，僅uv這樣一個指標，就有十幾種定義。帶來的問題是：都是uv，我要用哪一個？ 都是uv，爲何數據卻不同？

 

2）服務業務能力

  因爲數據模式是跟着垂直業務，致使一開始只支持了淘寶、天貓、1688等少數業務團隊。而更多有個性化需求的業務團隊卻沒法提供更多支持。

 

3）計算存儲成本

因爲沒有統一的規範標準管理，形成了重複計算等資源浪費。而數據表的層次、粒度不清晰，也使得重複存儲嚴重，僅淘系的數據表就超過了25000張，集團總數據的存儲量每一年以2.5倍的速度在增加，能夠預見的將來的將會帶來巨大的數據成本負擔，咱們不得不去作一些改變。

 

4）研發成本

每一個工程師都須要從頭至尾瞭解研發流程的每一個細節，對一樣的「坑」每一個人都會從新踩一遍，對研發人員的時間和精力成本形成浪費

 

創建的方法和思路》》》》》》》》

基於這樣的問題和挑戰，阿里集團規劃建設一個全集團的全域數據公共層，將公共的數據、計算沉澱於此，下降數據存儲和計算成本，提高數據互通和消費的效率，從而支撐快速數據業務應該的創新。公共層中重要的一環是數據模型的構建，那麼咱們先從行業看看一些方法體系和經驗：

 

1）他山之石——行業內是如何作的？

A、實體關係（ER）模型

數據倉庫之父Immon的方法從全企業的高度設計一個3NF模型，用實體加關係描述的數據模型描述企業業務架構，在範式理論上符合3NF，它與OLTP系統中的3NF的區別，在於數據倉庫中的3NF上站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關係抽象，它更多的是面向數據的整合和一致性治理，正如Immon所但願達到的：「single version of the truth」。可是要採用此方法進行構建，也有其挑戰：

 

• 須要全面瞭解企業業務和數據
• 實施週期很是長
• 對建模人員的能力要求也很是高

B、維度模型

維度模型是數據倉庫領域另外一位大師Ralph Kimall所倡導，它的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling》是數據倉庫工程領域最流行的數倉建模經典。

 

維度建模以分析決策的需求出發構建模型，構建的數據模型爲分析需求服務，所以它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。典型的表明是咱們比較熟知的星形模型，以及在一些特殊場景下適用的雪花模型。

 

C、DataVault

DataVault是Dan Linstedt發起建立的一種模型方法論，它是在ER關係模型上的衍生，同時設計的出發點也是爲了實現數據的整合，並不是爲數據決策分析直接使用。它強調創建一個可審計的基礎數據層，也就是強調數據的歷史性可追溯性和原子性，而不要求對數據進行過分的一致性處理和整合；同時也基於主題概念將企業數據進行結構化組織，並引入了更進一步的範式處理來優化模型應對源系統變動的擴展性。它主要由：Hub（關鍵核心業務實體）、Link（關係）、Satellite（實體屬性）三部分組成 。

 

 

 

D、Anchor模型

Anchor模型是由Lars. Rönnbäck設計的，初衷是設計一個高度可擴展的模型，核心思想：全部的擴展只是添加而不是修改，所以它將模型規範到6NF，基本變成了K-V結構模型。Anchor模型由：Anchors 、Attributes 、Ties 、Knots 組成，相關細節能夠參考《Anchor Modeling-Agile Information Modeling in Evolving Data Environments》

 

 

 

2）阿里的數倉模型體系要如何構建？

阿里巴巴集團在很早就已經把大數據作爲戰略目標實施，並且其各個業務也很是依賴數據支撐運營，那麼阿里究竟採起何種方法構建本身的體系？阿里的數據倉庫模型建設經歷的多個發展週期：

 

第一階段：徹底應用驅動的時代，阿里巴巴第一代的數據倉庫系統構建在Oracle上，數據徹底以知足報表需求爲目的出發，將數據以與源結構相同的方式同步到Oracle後，咱們叫ODS（Operational Data Store）層，數據工程師基於ODS數據進行統計，基本沒有模型方法體系，徹底基於對Oralce數據庫特性的利用進行數據存儲和加工，部分採用了一些維度建模的緩慢變化維方式進行歷史數據處理。那時候的數據架構只有兩次層ODS+DSS。

 

第二階段：隨着阿里業務的快速發展，數據量也在飛速增加，性能已是一個較大問題，所以引入了當時MPP架構體系的Greenplum，同時阿里的數據團隊也在着手開始進行必定的數據架構優化，但願經過一些模型技術改變煙囪式的開發模型，消除一些冗餘，提高數據的一致性。來作傳統行業數倉的工程師，開始嘗試將工程領域比較流行的ER模型+維度模型方式應用的阿里集團，構建出一個四層的模型架構ODL（操做數據層）+BDL(基礎數據層)+IDL（接口數據層）+ADS(應用數據層)。ODL保持和源系統保持一致，BDL但願引入ER模型，增強數據的整合，構建一致的基礎數據模型，IDL基於維度模型方法構建集市層，ADL完成應用的個性化和基於展示需求的數據組裝。其中咱們在構建ER模型遇到了比較大的困難和挑戰，互聯網業務的快速發展，人員的快速迭代變化，業務知識功底的不夠全面致使ER模型設計遲遲不能產出，至此，咱們也獲得了一個經驗，在一個不太成熟，快速變化的業務面前，構建ER模型的風險很是大，不太適合去構建。

 

第三階段：阿里集團的業務和數據還在飛速發展，這個時候迎來了以hadoop爲表明的分佈式存儲計算平臺的快速發展，同時阿里集團自主研發的數加大規模計算服務MaxCompute（原ODPS）也在緊鑼密鼓的進行中；咱們在擁抱分佈式計算平臺的同時，也開始建設咱們的第三代模型架構，咱們須要找到一個核心問題，找打適合阿里集團業務發展，又能充分利用分佈是計算平臺能力的數據模型方式。

 

咱們選擇了以Kimball的維度建模爲核心理念基礎的模型方法論，同時對其進行了必定的升級和擴展，構建了阿里集團的數據架構體系——OneData

 

OneData體系分爲：數據規範定義體系、數據模型規範設計、ETL規範研發以及支撐整個體系從方法到實施的工具體系。

 

落地實現》》》》》》

A）數據規範定義

將此前個性化的數據指標進行規範定義，抽象成：原子指標、時間週期、其餘修飾詞等三個要素。

 

例如，以往業務方提出的需求是：最近7天的成交。而實際上，這個指標在規範定義中，應該結構化分解成爲：

原子指標（支付訂單金額 ）+修飾詞-時間週期（最近7天）+修飾詞-賣家類型（淘寶）

 

 

B）數據模型架構

將數據分爲ODS（操做數據）層、CDM（公共維度模型）層、ADS（應用數據）層。

其中：

ODS層主要功能

這裏先介紹一下阿里雲數加大數據計算服務MaxCompute，是一種快速、徹底託管的TB/PB級數據倉庫解決方案，適用於多種數據處理場景，如日誌分析，數據倉庫，機器學習，個性化推薦和生物信息等。

 

 

• 同步：結構化數據增量或全量同步到數加MaxCompute（原ODPS）；
• 結構化：非結構化(日誌)結構化處理並存儲到MaxCompute（原ODPS）；
• 累積歷史、清洗：根據數據業務需求及稽覈和審計要求保存歷史數據、數據清洗；

CDM層主要功能

CDM層又細分爲DWD層和DWS層，分別是明細寬表層和公共彙總數據層，採起維度模型方法基礎，更多采用一些維度退化手法，減小事實表和維度表的關聯，容易維度到事實表強化明細事實表的易用性；同時在彙總數據層，增強指標的維度退化，採起更多寬表化的手段構建公共指標數據層，提高公共指標的複用性，減小重複的加工。

 

ADS層主要功能

 

• 個性化指標加工：不公用性；複雜性（指數型、比值型、排名型指標）
• 基於應用的數據組裝：大寬表集市、橫錶轉縱表、趨勢指標串

其模型架構圖以下，阿里經過構建全域的公共層數據，極大的控制了數據規模的增加趨勢，同時在總體的數據研發效率，成本節約、性能改進方面都有不錯的結果。 

 

C）研發流程和工具落地實現

將OneData體系貫穿於整個研發流程的每一個環節中，並經過研發工具來進行保障。

 

 

實施效果》》》》》》

 

 

1. 數據標準統一：數據指標口徑一致，各類場景下看到的數據一致性獲得保障
2. 支撐多個業務，極大擴展性：服務了集團內部45個BU的業務，知足不一樣業務的個性化需求
3. 統一數據服務：創建了統一的數據服務層，其中離線數據日均調用次數超過22億；實時數據調用日均超過11億
4. 計算、存儲成本：指標口徑複用性強，將本來30000多個指標精簡到3000個；模型分層、粒度清晰，數據表從以前的25000張精簡到不超過3000張。
5. 研發成本：經過數據分域、模型分層，強調工程師之間的分工和協做，再也不須要從頭至尾每一個細節都瞭解一遍，節省了工程師的時間和精力。

背景

做爲一家高度數字化和技術驅動的公司，美團很是重視數據價值的挖掘。在公司平常運行中，經過各類數據分析挖掘手段，爲公司發展決策和業務開展提供數據支持。通過多年的發展，美團酒旅內部造成了一套完整的解決方案，核心由數據倉庫+各類數據平臺的方式實現。其中數據倉庫整合各業務線的數據，消滅數據孤島；各類數據平臺擁有不一樣的特點和定位，例如：自助報表平臺、專業數據分析平臺、CRM數據平臺、各業務方向績效考覈平臺等，知足各種數據分析挖掘需求。早期數據倉庫與各類數據平臺的體系架構如圖1所示：

 

圖1 酒旅早期各數據平臺和數據倉庫體系架構圖

圖1所示的體系架構，在業務需求的知足上很是高效，但在長時間的使用過程當中，也產生了以下一些問題：

· 各數據平臺或平臺內不一樣模塊的指標定義不一致。

· 各數據平臺或平臺內不一樣模塊指標計算口徑不一致。

· 各數據平臺或平臺內不一樣模塊指標數據來源不一致。

上述這些問題總結概括起來，就是指標數據不一致的問題，最終帶來的後果是指標數據可信度底，嚴重影響分析決策。經過後續追蹤分析，上述問題的由來，主要是不一樣業務線的數據分析人員、數據開發人員，以及不一樣的產品之間，缺少有效的溝通，也沒有一個統一的入口，來記錄業務的發生和加工過程。在加上人員的流動，長時間積累以後就產生了這些問題。針對這些問題，酒旅內部啓動了數據治理項目，經過建設一個專業數據治理平臺，實現指標維度及數據的統一管理，也探索一套高效的數據治理流程。

挑戰

在建設起源數據治理平臺的過程當中，主要面臨的挑戰以下：

· 起源數據治理平臺應該在架構中的哪一個位置切入，減小對原有系統的侵入，並實現數據治理目標。

· 探索一套簡潔高效的管理流程，實現指標維度信息統一管理，保證信息的惟一性、正確性。

· 整合各類存儲引擎，實現一套高併發、高可用的數據惟一出口。

· 作好各業務線間的信息隔離和管理，確保數據安全。

解決思路

爲了達成數據治理的目標，起源數據治理平臺就必須記錄下業務發展過程，並映射到數據加工和數據提取，規範約束這些過程。所以起源數據治理平臺概括到數據治理層，該層就位於數據倉庫層（或數據集市層）之上，數據應用層之下起到橋樑的做用，並且提供一系列規則，改變原來無序交互方式，將數據倉庫層和數據應用層的交互變爲有序的、可查詢、可監控。新的體系架構如圖2所示：

 

圖2 數據治理後的新體系架構圖

如上圖所示，在新的體系架構下：對於數據倉庫層，起源數據治理平臺綜合業務組織形式、指標數據來源、上層產品的使用及查詢的效率，指導數據倉庫模型的建設；對於應用層的產品，業務元數據信息及數據信息都是由起源數據治理平臺提供，保證了各數據產品獲取到的信息一致，並且還簡化了應用層產品數據獲取成本，也下降了對原有系統的侵入。

平臺架構

起源數據治理平臺核心是保證數據一致，在數據安全的前提下，儘量提高數據分發能力。所以平臺內部有着極其複雜的關係，須要在建設過程當中進行抽象，造成具備相對單一功能的模塊；合理地組織模塊的層級和鏈接關係，下降平臺的開發難度，並提高平臺的可維護性。平臺架構如圖3所示，展現了平臺的內部模塊組織方式。

圖3 起源數據治理平臺架構圖

如上圖所示起源數據治理平臺在功能模塊上由數據存儲、數據查詢、數據緩存、元數據管理、業務管理、安全管理、應用管理、對外API接口構成，各模塊的功能介紹以下。

數據存儲

起源數據治理平臺管理的數據存儲範圍包括：數據倉庫中的Topic層和數據應用層，存儲方式包括：Hive、MySQL、Kylin、Palo、ES、Druid。以下圖4所示：

 

圖4 起源數據治理平臺管理的數據存儲

上圖所示的這些數據存儲中的數據的加工過程，由數據開發工程師負責，具體採用哪一種存儲介質，由數據開發工程師綜合所需數據存儲空間、查詢效率、模型的組織形式等因素決定。但後續的使用維護都由起源數據治理平臺管理，管理方式是經過管理這些數據表的元數據信息和查詢實現，具體實現細節會在下面章節中詳解。

數據存儲託管以後，數據表元數據信息變動監控、表數據生產（存儲空間、生產狀態及完成時間）監控、表數據波動（同環比等）監控以及表的使用（模型的構建及查詢效率等）監控及評估，都由起源數據治理平臺自動完成，全部信息的變更都會自動周知對應的負責人，保證數據應用的安全和穩定。

元數據管理

元數據信息宏觀上包括兩大部分：業務元數據信息和數據元數據信息。其中業務元數據信息包括：指標業務定義、維度的業務定義等；數據元數據信息包括：數據表元數據信息、模型元數據信息、維表與維度的綁定關係、數據模型字段與指標的綁定關係。

起源平臺爲了實現元數據信息的管理，設計了四個模塊實現，分別是：數據表管理模塊、模型管理模塊、指標管理模塊、維度管理模塊。元數據管理是起源數據治理平臺的核心，起源平臺就是經過控制好元數據，來驅動數據的生產和消費。

數據表管理模塊

數據表管理模塊管理了數據庫信息和數據表信息。其中數據庫信息包括數據庫連接信息，數據庫信息維護後，起源數據治理平臺自動獲取對應庫中表的元數據信息。數據表信息包括：表的元數據信息（引擎、字段等）、表類型（維表或事實表）、表的使用狀況（是否被模型使用）、表對應的ETL、表的負責人、表的推薦度、描述信息、表的監控配置及報警歷史、以及樣例數據等。上述這些信息爲業務用戶提供指導，爲模型管理提供數據支持，爲數據表和數據的穩定提供監控和預警。

模型管理模塊

模型管理模塊可以還原業務落地後數據表的組織關係，包括：數據表的關聯方式（join、left join、semi join等）、數據表的關聯限制、模型ER圖、模型包含字段、模型字段與維度的綁定關係、模型與指標的綁定關係。不過在實際使用過程當中，面向業務和麪向分析的模型有所不一樣，起源數據治理平臺是面向分析的，因此主要的模型包括維度建模中的星型模型或雪花模型，再就是OLAP多維分析的MOLAP或ROLAP。模型管理以下圖五、圖6所示：

圖5 起源數據治理平臺數據表模型

 

圖6 起源數據治理平臺SQL模型

維度管理模塊

維度管理模塊包括基礎信息和技術信息，對應着不一樣人員維護。其中基礎信息對應維度的業務信息，由業務管理人員維護，包括維度名稱、業務定義、業務分類。技術信息對應維度的數據信息，由數據開發工程師維護，包括是否有維表（是枚舉維度仍是有獨立的維表）、是不是日期維、對應code英文名稱和中文名稱、對應name英文名稱和中文名稱。若是維度有維表，則須要和對應的維度表綁定，設置code和name對應的字段；若是維度是枚舉維，則須要填寫對應的code和name。維度的統一管理，有利於之後數據表的標準化，也方便用戶的查看。

指標管理模塊

指標管理模塊核心包括基礎信息和技術信息管理，衍生信息包括關聯指標、關聯應用管理。基礎信息對應的就是指標的業務信息，由業務人員填寫，主要包括指標名稱、業務分類、統計頻率、精度、單位、指標類型、指標定義、計算邏輯、分析方法、影響因素、分析維度等信息；基礎信息中還有一個比較重要的部分是監控配置，主要是配置指標的有效波動範圍區間、同環比波動區間等，監控指標數據的正常運行。

技術信息構成比較複雜，包括數據類型、指標代碼，可是核心部分是指標與模型的綁定關係，經過使用演進造成了當前系統兩類綁定關係：綁定物理模型和構建虛擬模型。綁定物理模型是指標與模型管理中的物理模型字段綁定，並配置對應的計算公式，或還包含一些額外的高級配置，如二次計算、模型過濾條件等；建立虛擬模型是經過已有指標和其對應的物理模型，具體步驟首先配置已有指標的計算方式或指標維度的過濾，而後選擇指標已綁定的物理模型，造成一個虛擬模型，虛擬模型的分析維度就是所選指標基礎模型的公共維度。

衍生信息中的關聯指標、關聯應用管理，是爲了方便觀察指標被那些其餘指標和數據應用使用，這是由於指標技術信息採用了嚴格權限控制，一旦被使用爲了保證線上的運行安全是禁止變動的，只有解綁並審覈經過後才能夠編輯，因此這些衍生信息就是方便管理人員使用。指標技術信息如圖7所示：

圖7 起源數據治理平臺指標技術信息

業務管理

業務管理按照功能劃分爲業務線管理、主題管理和工單管理三部分，在系統的實際建設中是拆分爲業務主題管理、數據主題管理和工單管理三大模塊實現的。相關模塊的建設主要保證業務人員和數據人員業務主題建設，相關模塊的權限控制，業務流程審覈，對應資源的隔離以及業務資源加工申請和加工過程的記錄追蹤。具體實現和功能以下：

業務主題管理

實現業務業務線管理和業務主題管理，實現不一樣業務線的管理以及業務線下的業務主題管理。業務線的拆分還隱藏着其餘模塊的權限管控和資源隔離的功能，不一樣業務線的用戶只能看到有權業務線的指標和維度；並且業務線的用戶劃分爲普通用戶和管理員，分別查看或編輯維度和指標的業務信息。並且業務線和業務主題中分別維護的商分負責人對指標進行二級審覈，由於新建立的指標僅僅是普通指標，若是想要全網都能查看，則須要發起認證，由這些人員審覈。

數據主題管理

數據主題管理實現數據業務線和數據主題管理，實現不一樣數據線的管理以及數據線下的數據主題管理。數據線的拆分也隱藏着對數據表、模型、指標、維度的資源隔離和權限管控的功能，不一樣數據線的用戶只能查看有權數據線的資源；並且數據線的用戶分爲普通用戶和管理員，對有權資源進行查看或編輯。數據線的接口人在工單模塊中具備審覈工單的權限功能。數據主題的負責人擁有審覈模型和指標技術信息的權限功能。

工單模塊管理

工單模塊管理實現了指標維度和對應模型加工線上申請、審覈、加工、審批的流程。整個模塊也是圍繞着這四個流程實現的，具體是業務人員發起指標和維度集合的加工申請，而後由數據線接口人審覈工單的合理性並分配對應的數據開發工程師，數據開發工程師加工模型並與對應的維度指標綁定，而後在工單中提交由數據接口人審覈是否合理，最終由工單發起人驗收。

這個流程是一個標準的工單流程，每一個節點的業務流程可能會反覆，可是每次操做都進行記錄，方便業務人員後期追蹤。工單管理以下圖8所示：

 

圖8 起源數據治理平臺工單管理

安全管理

安全管理是起源數據治理平臺核心功能之一，分爲平臺操做權限管理和接口調用權限管理兩大部分。其中平臺操做權限管理是經過與公司將軍令權限管理系統打通，並配合平臺其餘模塊中權限控制代碼，實現了權限管理、審批、審計三大功能模塊；接口權限管理是經過平臺內的數據應用管理和外部應用管理模塊的映射關係，並在接口調用時鑑權實現，這部分會在下面的應用管理章節中介紹。

權限管理模塊

權限管理模塊是將平臺的資源分劃分爲頁面權限、業務線&數據線用戶權限、數據應用權限來實現的。頁面權限實現平臺內頁面訪問控制。業務線&數據線用戶權限是將用戶分類爲普通用戶和管理員，普通用戶只能查看業務線和數據線內資源，管理員能夠操做業務線和數據線內的資源；而且經過業務線和數據線的獨立管理實現資源隔離，業務線實現了所屬維度和指標的隔離；數據線實現了所屬數據表和模型的隔離，而且經過創建業務線和數據線的關聯關係，也保證了指標和維度的技術信息操做隔離。數據應用中每一個應用都是獨立管理的，每一個應用權限都拆分普通用戶和管理員，普通用戶能夠訪問查詢應用，管理員能夠操做應用。

審批模塊

審批模塊包含審批工做流、個人申請、個人審批構成。審批工做流是根據不一樣的應用場景實現不一樣層級的審批，例如：在指標管理中服務於我的的普通指標變動爲服務於整個業務線的認證指標，就須要發起兩級審批，由業務主題負責人和業務商分審覈經過才能夠；模型管理中新增或修改模型上線，都須要數據主題負責人審批；數據應用的變動，都須要下游全部依賴外部應用負責人審批才生效。個人申請和個人審批是平臺頁面方便用戶查看流程進度和操做審覈。審批模塊目標是保證發佈信息的正確性、系統服務的穩定性。

審計模塊

審計模塊包括用戶操做記錄和記錄查看追蹤。用戶操做記錄是平臺各模塊調用接口記錄用戶每次操做先後的數據變動；記錄查看追蹤是檢索查詢頁面，查看對應的變動。審計模塊保證了用戶操做追蹤追責，也保證誤操做的信息恢復。

應用管理

應用管理由數據應用、外部應用、數據地圖三大模塊組成，它們構成了對外服務的主體，記錄了外部應用與平臺內管理的指標、維度、模型和表的關聯關係，也提供數據查詢展現、應用層ETL生產的能力。並且數據開發人員從底層向上觀察，能夠追蹤數據最終的全部流向；業務分析人員從頂層向下觀察，能夠看到構成服務的全部數據來源。

數據應用模塊

數據應用模塊是記錄生成每一個服務所需的指標、維度和數據模型的關係。每次服務中能夠包含多個指標，這些指標能夠來源於多個數據模型，不過不一樣的數據模型中須要包含公共維度，由於是經過這些公共維度將不一樣模型關聯起來。

數據應用中構建的服務能夠發佈成查詢服務、應用層ETL生產服務、對外API數據接口服務、通用報表配置服務，來知足業務的不一樣需求。數據應用管理以下圖9所示：

 

圖9 起源數據治理平臺數據應用

外部應用模塊

外部應用模塊管理外部應用和應用內的模塊，以及這些模塊訂閱的對應數據應用，目標是實現API接口調用的權限管理和數據最終流向的記錄。具體的實現上模塊首先建立對應的外部應用，記錄外部應用的名稱、URL、APPKEY等信息，而後由對應應用的負責人建立模塊，記錄模塊名稱、URL、moduleKey等信息。這些信息完善後，由對應的數據應用賦權給對應的模塊，創建起數據應用與外部應用的聯繫。最後在外部應用調用平臺對外API接口時，進行權限管理。

數據地圖

數據地圖功能是追查數據的流向，能夠從數據表、模型、指標、數據應用、外部應用任意節點查看上游數據來源和下游數據去向。起源數據治理平臺核心功能也是組織這些節點間的關係，造成完整的服務，數據地圖就是經過上面介紹模塊記錄的關係，追蹤數據流向，方便數據開發人員和業務分析人員瞭解數據消費和數據來源。數據地圖以下圖10所示：

 

圖10 起源數據治理平臺數據地圖

對外API

對外API接口是一套完整的對外信息提供接口，提供的功能分爲元數據信息類的接口、數據類接口、監控統計類接口，分別知足外部平臺和分析人員的對應需求。外部系統經過起源數據治理平臺獲取到的元數據和數據是通過認證並由平臺自動校驗後的，能夠保證信息的一致性、正確性。

元數據信息接口

元數據信息接口提供的包括指標、維度業務元數據信息和數據表、模型、指標計算、維度維表相關的數據元數據信息，實現與上游系統信息共享，達到信息一致性的目標。

數據類接口

數據類接口提供指標維度數據查詢服務，不僅僅知足常見的單條SQL查詢，並且能夠實現屢次查詢聚合運算（例如：同環比等）以及跨引擎查詢，並經過併發處理，能夠有效提高查詢效率，知足更多的業務場景。接口具備監控功能，可以評估每次查詢效率，提供查詢指導或預警的能力。

監控統計類接口

監控統計類接口提供指標數據監控信息、指標維度使用統計、數據接口的調用效率統計等服務，幫助下游服務平臺瞭解服務質量。

內部工做原理

起源數據治理平臺內部工做原理就是實現指標、維度業務信息與數據模型計算關係的映射管理，並根據外部應用所需的指標、維度以及查詢條件選擇最優的模型動態的實現查詢SQL或查詢Query的拼接，而後經過分佈式查詢引擎實現數據的高效查詢，具體過程以下圖11所示：

 

圖11 起源數據治理平臺內部工做原理

上圖所示的分佈式查詢引擎，整合了大數據分析常見的各類存儲，經過封裝的接口提供服務。並且分佈式是經過Akka Cluster自主實現，經過Cluster Singleton解決單點故障的問題，經過Redis實現了任務隊列的持久化，經過平衡子節點任務量實現任務的合理調度，經過查詢狀態監控自動實現查詢降級和任務隊列的拆解，而且也完善了整個調度的監控，能夠實時查看任務和節點的運行狀況。

管理流程

起源數據治理平臺生產所需參與的角色包括：業務人員和數據開發人員（RD）。爲了保證信息的正確性，平臺內有着嚴格的管理流程，須要不一樣的角色在對應的節點進行維護管理，平臺的管理流程以下圖12所示：

 

圖12 起源數據治理平臺管理流程

 

所上圖所示，指標的業務信息須要業務人員首先進行維護，而後數據RD同窗進行相應的數據表的建設，維護對應的數據表和模型的元數據信息，並完成指標與模型的綁定，最後由數據RD同窗構建數據應用爲用戶、業務系統及數據產品等提供服務。

建設成果

通過長時間的探索開發，完成了起源數據治理平臺的建設，成功的解決了上面提到的問題，而且已經完成了酒旅內部10+個數據平臺（包括定製化產品和通用報表服務平臺）的數據治理支持。起源數據治理平臺還帶來了一些額外的收穫，總結概括起來實現了3個目標，提供了4種能力，以下：

· 統一指標管理的目標。保證指標定義、計算口徑、數據來源的一致性。

· 統一維度管理的目標。保證維度定義、維度值的一致性。

· 統一數據出口的目標。實現了維度和指標元數據信息的惟一出口，維值和指標數據的惟一出口。

· 提供維度和指標數據統一監控及預警能力。

· 提供靈活可配的數據查詢分析能力。

· 提標數據地圖展現表、模型、指標、應用上下游關係及分佈的能力。

· 提供血緣分析追查數據來源的能力。

若是換位到指標的角色，以辯證的角度分析，起源數據治理平臺解決了一個終極哲學問題：我是誰，我從哪裏來，我到哪裏去。

將來展望

起源數據治理平臺是天工體系（從數據管理、查詢到展現的一個完整生態）的一部分，整個天工體系還包括如意通用報表系統、筋斗雲數據查詢系統。經過對天工體系的建設，直接目標是爲業務提供一整套高效、高質量的數據服務平臺；可是在天工體系的建設中，進行微服務治理，抽象形出一套統一標準，吸納更多的業務參與建設，爲業務提供開發降級，避免服務的重複建設，提高服務建設速度。以下圖13所示：

 

圖13 天工體系架構圖

如上圖所示，天工體系開放三套交互標準，實現模塊的可插拔和自由擴展，分別是：

· 元數據交互標準，實現元數據管理的可插拔。

· 數據查詢標準，實現數據查詢引擎的可插拔。

· 可視化組件數據交互標準，實現可視化組件的可插拔。

股份制改革對我國銀行業來講只是一個開始，企業在風險管理、創造價值等方面還有很長的路要走。風險管理要求提供精準的數據模型、創造價值要求充分銀行數據資產，這是數據治理的外部推進因素。此外，隨着第三次工業革命的到來，銀行業也須要進入定製化時代，以更低的成本，生產多樣化的金融產品，從而知足不一樣顧客的不一樣需求。對數據自己而言，業務發展加快了數據膨脹的速度，也帶來了數據不一致等問題，業務部門的頻繁增長和剝離一樣會對數據治理提出挑戰。這些日益複雜的內外因決定了我國銀行業對數據治理的超高標準要求，而目前對應的經驗能力卻稍顯薄弱。

 

 

數據治理不只須要完善的保障機制，還須要理解具體的治理內容，好比咱們的數據該怎麼進行規範，元數據又該怎麼來管理，每一個過程須要哪些系統或者工具來進行配合呢？這些問題都是數據治理過程當中最實際的問題，也是最複雜的問題，今天咱們將從數據治理的各個核心領域來解答這些問題。

 

銀行數據治理核心領域

 

每一個數據治理的領域均可做爲一個獨立方向進行研究治理，目前總結的數據治理領域包括但不限於一下內容：數據標準、元數據、數據模型、數據分佈、數據存儲、數據交換、數據生命週期管理、數據質量、數據安全以及數據共享服務。

 

同時各領域之間須要有機結合，如數據標準、元數據、數據質量等幾個領域相互協同和依賴。經過數據標準的管理，能夠提高數據合法性、合規性，進一步提高數據質量，減小數據生產問題；在元數據管理的基礎上，可進行數據生命週期管理，有效控制在線數據規模，提升生產數據訪問效率，減小系統資源浪費；經過元數據和數據模型管理，將表、文件等數據資源按主題進行分類，可明確當事人、產品、協議等相關數據的主數據源歸屬、數據分佈狀況，有效實施數據分佈的規劃和治理。

 

 

數據治理領域是隨着銀行業務發展而不斷變化的，領域之間的關係也須要不斷深刻挖掘和分佈，最終造成一個相互協同與驗證的領域網，全方位的提高數據治理成效。

 

數據治理核心領域

 

 

1.數據模型

 

數據模型是數據治理中的重要部分，合適、合理、合規的數據模型，可以有效提升數據的合理分佈和使用，它包括概念模型、邏輯數據模型和物理數據模型，是數據治理的關鍵、重點。數據模型包含三個部分，數據結構、數據操做、數據約束。

 

數據結構。數據模型中的數據結構主要用來描述數據的類型、內容、性質以及數據間的聯繫等。數據結構是數據模型的基礎，數據操做和數據約束都基本是創建在數據結構的之上的。不一樣的數據結構有不一樣的操做和約束。

 

數據操做。數據模型中的數據操做主要用來描述在相應的數據結構上的操做類型和操做方式。

 

數據約束。數據模型中的數據約束主要用來描述數據結構內數據間的語法、詞義聯繫、他們之間的制約和依存關係，以及數據動態變化的規則，以保證數據的正確、有效和相容。

 

2.元數據管理

 

元數據分爲業務元數據、技術元數據和操做元數據，三者之間關係緊密。業務元數據指導技術元數據，技術元數據以業務元數據爲參考進行設計，操做元數據爲二者的管理提供支撐。

 

業務元數據。業務元數據是定義和業務相關數據的信息，用於輔助定位、理解及訪問義烏信息。業務元數據的範圍主要包括：業務指標、業務規則、數據質量規則、專業術語、數據標準、概念數據模型、實體/屬性、邏輯數據模型等。

 

技術元數據。它能夠分紅結構性技術元數據和關聯性技術元數據。結構性技術元數據提供了在信息技術的基礎架構中對數據的說明，如數據的存放位置、數據的存儲類型、數據的血緣關係等。關聯性技術元數據描述了數據之間的關聯和數據在信息技術環境之中的流轉狀況。技術元數據的範圍主要包括：技術規則（計算/統計/轉換/彙總）、數據質量規則技術描述、字段、衍生字段、事實/維度、統計指標、表/視圖/文件/接口、報表/多維分析、數據庫/視圖組/文件組/接口組、源代碼/程序、系統、軟件、硬件等。技術元數據通常以已有的業務元數據做爲參考設計的。

 

操做元數據。操做元數據主要指與元數據管理相關的組織、崗位、職責、流程，以及系統平常運行產生的操做數據。操做元數據管理的內容主要包括：與元數據管理相關的組織、崗位、職責、流程、項目、版本，以及系統生產運行中的操做記錄，如運行記錄、應用程序、運行做業。

 

不少初學者，對大數據的概念都是模糊不清的，大數據是什麼，能作什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深刻了解，想學習的同窗歡迎加入大數據學習扣裙：805+127+855，有大量乾貨（零基礎以及進階的經典實戰）分享給你們，而且有清華大學畢業的資深大數據講師給你們免費授課，給你們分享目前國內最完整的大數據高端實戰實用學習流程體系

 

3.數據標準

 

數據標準是銀行創建的一套符合自身實際，涵蓋定義、操做、應用多層次數據的標準化體系。它包括基礎標準和指標標準（或稱應用標準）。與數據治理其餘核心領域具備必定的交叉，好比元數據標準、數據交換和傳輸標準、數據質量標準等。商業銀行的數據標準通常以業界的標準爲基礎，如國家標準、監管機構（如國家統計局、中國人民銀行、工信部）制定的標準，結合商業銀行自己的實際狀況對數據進行規範化，通常會包括格式、編碼規則、字典值等內容。良好的數據標準體系有助於商業銀行數據的共享、交互和應用，能夠減小不一樣系統間數據轉換的工做。數據標準的主要由業務定義、技術定義和管理信息三部分構成。

 

數據標準的主體構成

 

 

業務定義。業務定義主要是明確標準所屬的業務主題以及標準的業務概念，包括業務使用上的規則以及標準的相關來源等。對於代碼類標準，還會進一步明確編碼規則以及相關的代碼內容，以達到定義統1、口徑統1、名稱統1、參照統一以及來源統一的目的，進而造成一套一致、規範、開放和共享的業務標準數據。

 

技術定義。技術定義是指描述數據類型、數據格式、數據長度以及來源系統等技術屬性，從而可以對信息系統的建設和使用提供指導和約束。

 

管理信息。管理信息是指明確標準的全部者、管理人員、使用部門等內容，從而使數據標準的管理和維護工做有明確的責任主體，以保障數據標準可以持續的進行更新和改進。

 

4.數據質量管理

 

數據質量管理已經成爲銀行數據治理的有機組成部分。高質量的數據是商業銀行進行分析決策、業務發展規劃的重要基礎，只有創建完整的數據質量體系，纔能有效提高銀行數據總體質量，從而更好的爲客戶服務，提供更爲精準的決策分析數據。

 

 

制度和規範。從技術層面上，應該完整全面的定義數據質量的評估維度，包括完整性、時效性等，按照已定義的維度，在系統建設的各個階段都應該根據標準進行數據質量檢測和規範，及時進行治理，避免過後的清洗工做。

 

數據質量評價維度

 

明確相應的管理流程。數據質量問題會發生在各個階段，所以須要明確各個階段的數據質量管理流程。例如，在需求和設計階段就須要明確數據質量的規則定義，從而指導數據結構和程序邏輯的設計；在開發和測試階段則須要對前面提到的規則進行驗證，確保相應的規則可以生效；最後在投產後要有相應的檢查，從而將數據質量問題儘量消滅在萌芽狀態。數據質量管理措施，宜採用控制增量、消滅存量的策略，有效控制增量，不斷消除存量。

 

商業銀行數據質量管理流程

 

5.數據生命週期管理

 

任何事物都具備必定的生命週期，數據也不例外。從數據的產生、加工、使用乃至消亡都應該有一個科學的管理辦法，將極少或者再也不使用的數據從系統中剝離出來，並經過覈實的存儲設備進行保留，不只可以提升系統的運行效率，更好的服務客戶，還能大幅度減小由於數據長期保存帶來的儲存成本。數據生命週期通常包含在線階段、歸檔階段（有時還會進一步劃分爲在線歸檔階段和離線歸檔階段）、銷燬階段三大階段，管理內容包括創建合理的數據類別，針對不一樣類別的數據制定各個階段的保留時間、存儲介質、清理規則和方式、注意事項等。

 

數據生命週期中各參數間的關係

 

從上圖數據生命週期中各參數間的關係中咱們能夠了解到，數據生命週期管理可使得高價值數據的查詢效率大幅提高，並且高價格的存儲介質的採購量也能夠減小不少；可是隨着數據的使用程度的降低，數據被逐漸歸檔，查詢時間也慢慢的變長；最後隨着數據的使用頻率和價值基本沒有了以後，就能夠逐漸銷燬了。

 

6. 數據分佈和存儲

 

數據分佈和存儲主要涵蓋了數據如何劃分和存儲，總行系統以及總分行數據如何分佈，主數據及參考數據（也稱爲副本數據或者輔數據）如何管理。只有對數據進行合理的分佈和存儲，纔能有效的提升數據的共享程度，才能儘量的減小數據冗餘帶來的存儲成本。

 

一般狀況下，綜合數據規模、使用頻率、使用特性、服務時效等因素，從存儲體系角度，能夠將商業銀行的數據存儲劃分爲四類存儲區域，即交易型數據區、集成型數據區、分析型數據區、歷史型數據區。

 

一、交易型數據區。交易型數據區包括渠道接入、交互控制、業務處理、決策支持與管理等各種聯機應用數據；存儲客戶自助或與銀行操做人員在業務交互辦理過過程當中產生的原始數據的存儲，包括業務處理數據，內部管理數據和一些外部數據，其存儲的是當前狀態數據。

 

二、集成型數據區。集成型數據區包括操做型數據（OLTP）和數據倉庫型數據（OLAP）。

 

三、分析型數據區。分析型數據主要是用於決策支持與管理的各種集市應用的數據。爲了對業務執行狀況進行深刻分析，須要對原始數據進行進一步彙總統計分析，統計分析結果用於最終的決策展現，所以分析型數據區存儲了這些統計、分析模型結構的指標數據。

 

四、歷史數據區。這裏存儲了全部近線應用、歸檔應用、外部審計數據平臺應用等的數據，主要知足各類歷史數據歸檔後的數據保管和數據查詢服務。

 

數據存儲佈局

 

 

7.數據交換

 

數據交換是銀行進行數據交互和共享的基礎，合理的數據交換體系有助於銀行提升數據共享程度和數據流轉時效。通常商業銀行會對系統間數據的交換規則制定一些原則，好比對接口、文件的命名、內容進行明確，規範系統間、銀行系統與外部機構間的數據交換規則，指導數據交換工做有序進行。創建統一的數據交換系統，一方面能夠提升數據共享的時效性，另外一方面也能夠精確掌握數據的流向。

 

8.數據安全

 

商業銀行的重要且敏感數據大部分集中在應用系統中，例如客戶的聯絡信息、資產信息等，若是不慎泄露，不只給客戶帶來損失，也會給商業銀行帶來不利的聲譽影響，所以數據安全在數據管理和治理過程當中是至關重要的。

數據存儲安全。包括物理安全、系統安全存儲數據的安全，主要經過安全硬件的採購來保障數據存儲安全。

 

數據傳輸安全。包括數據的加密和數據網絡安全控制，主要經過專業加密軟件廠商進行規範設計和安裝。

 

數據使用安全。須要增強從業務系統層面進行控制，防範非受權訪問和下載打印客戶數據信息；部署客戶端安全控制工具，創建完善的客戶端信息防泄漏機制，防範將客戶端上存儲的我的客戶信息非受權傳播；創建完善的數據安全管理體系，創建數據安全規範制度體系，組建數據安全管理組織機構，創建有效的數據安全審查機制；對於生產及研發測試過程當中使用的各種敏感數據進行嚴密管理；嚴格與外單位合做中的我的客戶信息安全管理等。

 

9.數據服務

 

數據的管理和治理是爲了更好的利用數據，是數據應用的基礎。銀行應該以數據爲根本，以業務爲導向，經過對大數據的集中、整合、挖掘和共享，實現對多樣化、海量數據的快速處理及價值挖掘，利用大數據技術支持產品快速創新，提高以客戶爲中心的精準營銷和差別化客戶服務能力，加強風險防控實時性、前瞻性和系統性，推進業務管理向信息化、精細化轉型，全面支持信息化銀行的建設。

 

創建結構化數據處理分析平臺。數據倉庫建設可以實現企業異構數據的集成，企業按照分析主題重組數據，創建面向全行的一致的信息視圖。下圖是一個典型的銀行數據倉庫服務體系：

 

銀行典型的數據倉庫服務體系

數據資產視圖。在創建了數據倉庫以後，須要創建統一的分析和可視化平臺，解決數據在哪裏，數據怎麼用的問題。一個典型的應用是創建全行統一客戶視圖，包含客戶信息統一視圖、客戶信息風險視圖和網點業績視圖。

 

數據資產視圖示例

 

 

數據治理的展望

 

數據治理不是一個臨時性的運動，從銀行業務發展、數據治理意識造成、數據治理體系運行的角度，須要一個長效機制來進行保證。在大數據時代，通過數據治理的銀行數據能夠發揮更大的做用。

 

1

利用大數據挖掘技術分析各種海量信息，發現市場熱點與需求，實現產品創新服務

 

能夠將大數據應用到產品生命週期，深刻挖掘客戶需求，把握客戶痛點，推進產品創新。利用大數據技術對社交網絡信息、在線客戶評論、博客、呼叫中心服務工單、用戶體驗反饋等信息進行深度挖掘和分析，充分洞察客戶，分析客戶的情緒，瞭解客戶對產品的想法，獲知客戶需求的變化趨勢，從而對現有產品進行及時的調整和創新，事情貼近客戶的生活場景和使用習慣。

 

基於大數據創新產品評價方法，爲產品創新提供數據支撐。經過大數據分析，改變目前以規模、總量爲主的業務評價方式，創建一整套完整的以質量、結構爲主的全新的評價方式，以引導全行真正追求有質量、有效益的發展。

 

2

增強內外部信息聯動，重點利用外部信息提高銀行風險防控能力

 

進一步增強與稅務、海關、法院、電力部門、水務部門、房產交易登記中心、環保部門以及第三方合做機構的數據互聯共享，有效拓寬信息來源渠道，深度挖掘整合系統內外客戶信息、關聯關係、交易行爲、交易習慣、上下游交易對手、資金週轉頻率等數據信息，利用大數據技術查找與分析不一樣數據變量間的關聯關係，並創建相應的決策模型，提高銀行風險防控能力。

 

在信用風險方面，能夠結合外部數據，完善信用風險防範體系，基於可視化分析有效防控信用風險的傳導。引入大數據理念和技術，統一信用風險模型管理，構建覆蓋信用風險訓練、模型管理、平常預警、評分評級、客戶信用視圖以及業務聯動控制的信貸大數據平臺，創建多維度、全方位的縫隙愛你預警體系。

 

在市場風險方面，基於市場信息有效預測市場變更，基於大數據處理技術提高海量金融數據交易的訂價能力，構建訂價估值引擎批量網格計算服務模式，支持對海量交易的實時訂價，有效提高銀行風險管控與訂價能力，爲金融市場業務的發展提供有力支撐。

 

在操做風險方面，依託大數據信息整合優點，有效防控操做風險。經過可視化技術，從業務網數據中發現識別風險線索，實現由「風險監控」向「業務監控」模式轉變，提高風險的提早預警能力。增強跨專業風險監控模型的研發，經過由點帶線、由線及面的矩陣式關聯監控，提早識別風險交織趨勢，防範風險傳染。

 

3

利用大數據技術提高經營管理水平，優化業務流程，實現精細化經營決策

 

在經營決策方面，經過外部數據的補充和整理，實現經營分析外延的拓展，從市場和經營環境的高度分析各級機構的發展方向、競爭壓力，制定更合理、更有效的經營策略。同時，應用大數據可視化技術，實現複雜分析過程和分析要素向用戶的有效傳遞，加強分析結果說服力和指導性，向經營人員提供有力的信息支撐。

 

在資源配置方面，依託大數據採集和計算能力，提高測算的敏感性和有效性，增強財務預測的可靠性和有效性，爲整體資源配置提供更好的信息支撐，實現對具體資源配置的動態管理。

 

在過程改進方面，優化業務流程，對交易、日誌的專業挖掘，探索當前業務處理流程節點的瓶頸，尋求最有的解決方案。好比經過分析客戶從排隊到等候完成所有交易的流程合理性，提出過程改進方法，提高網點總體運營效率和客戶體驗。

 

在運維保障方面，基於流數據處理技術，搭建準實時的應用交易級監控平臺，實現交易運行狀況的即時監控，保障業務運行穩定高效。