新核心業務系統資料架構規劃與資料治理

本文根據【2016 第七屆中國資料庫技術大會】（微信搜尋DTCC2014,關注中國資料庫技術大會公眾號）現場演講嘉賓種磊老師分享內容整理而成。錄音整理及文字編輯IT168@田曉旭@老魚。

　　嘉賓介紹：

　　種磊，經濟師，農銀人壽IT部資深專員、新核心資料組組長。04年進入農總行軟體開發中心，有8年銀行資訊化經驗，09年參與核心銀行應用設計。14年進入農銀人壽，主持資料治理與標準化及新核心模型設計工作。

　　正文：

　　我今天和大家分享一下公司新核心專案的資料架構規劃和資料治理，可能大家對我們公司不太熟悉，藉此機會先介紹一下我們公司。

　　農銀人壽保險有限公司，簡稱農銀人壽。前身是嘉禾人壽，13年年底由農行控股，至此五大國有銀行都擁有了自己旗下的保險公司。

　　我們公司是國內機構佈局最廣的銀行系壽險公司，擁有20多家省級分公司，300多家分支機構。14年的時候，客戶數量是529萬，截止到大會之前，客戶數量是780萬，年增長率達到21%。公司在14年成功扭虧為盈，去年保費規模達到了175億，年複合增長率57%。所以在這兩年期間，無論是在客戶數量還是在保費規模，都出現了迅猛增長的態勢。

　　下面簡單介紹一下專案的背景。我們現在使用的是中科軟保險核心業務系統，於07年10月份上線。這個系統比較陳舊，擴充套件性和穩定性都比較差，已經不能滿足業務快速變化發展的需要，也不能滿足快速推出新產品的需要。

　　在這個背景下，公司於13年立項，15年開始全面推動新核心業務系統的建設。我們為這個系統設計了全新的IT架構，包括資料架構、應用架構和技術架構。大家從這個應用架構圖上可以看出來，新核心專案有眾多的專案群，包括渠道接入、運營支撐、基礎應用平臺、資料管理、資料應用、決策分析以及專案實施，每個域裡又包含多個子系統。我們的資料架構規劃和資料治理標準化的實踐就是在這個背景下展開的。

　　首先介紹一下組織結構，一個清晰的組織架構對於專案來說是十分必要的。新核心專案組，在領導小組下設執行小組，執行小組下設技術實施組，實施組下面又包含多個子專案組和職能組。

　　資料架構組作為職能組之一，與應用架構、技術架構是並列的。由此可見，上級領導對資料工作和資料治理是非常重視的。有一些單位不重視資料工作，也沒有在專案內部設立專門的組織對企業資料進行統一規劃和管理，或者是系統建設先於資料管理，等系統都做完了，才想起來做資料治理，那就太晚了，到時候就是想做也做不清晰、做不好了。資料治理工作應該是先於系統建設，至少得是並行。比如我們的新核心標準化字典，需要在業務模型或者資料模型出來之前，就為它準備好經過標準化處理的基礎詞彙。那麼為什麼還會有並行期呢?有些資料的標準和規則是在各個業務模組需求和設計的逐漸明晰過程中才能被抽取出來的，這些需要在並行期完成。

　　我們經常聽到一些詞，比如企業總體規劃、戰略、架構等等，它們之間到底有什麼關係呢?我按照自己的理解畫了一個圖，企業總體規劃要有企業戰略和企業架構來支撐，企業戰略又分為業務戰略和IT戰略，企業架構由業務架構和IT架構來支撐。IT架構分為應用架構、技術架構和資料架構。

　　我們在對整體IT架構進行設計的時候，要充分考慮到資料架構是否對當前業務進行支援。一個理想的規劃順序應該是這樣的：首先應根據業務架構分析來定義資料架構，然後將資料架構結合業務功能定義應用架構，最後根據資料架構和應用架構的特點和技術要求來設計技術架構。這是資料驅動應該有的順序。

　　資料架構目標主要是解決兩個問題，如何使用資料和如何管理資料。實現資料標準化;減少資料冗餘、提升資料質量以及系統效能;消除資訊的孤島，實現資料在系統間的廣泛共享;發揮資料資產的價值，為企業帶來高附加值的回報。

　　資料架構總體原則是在基於對老系統的發現問題、分析問題、解決問題的基礎上，提出改進分析的意見，結合當前需求和業務特點以及主流技術和行業實踐去設計目標架構規劃。

　　這裡有一些更細緻的原則。比如資料的組織劃分要靈活，要能夠快速應對業務變更;資料的ETL過程、抽取、載入、資料移動要能夠高效;資料架構要具有柔性擴充套件能力，以此來應對新業務、新技術對架構帶來的衝擊;提高資料項在企業範圍內的全域性性和一致性，只有這樣才能在系統內和系統間實現資料的廣泛共享;資料必須具有使用價值，必須能夠滿足資料消費系統的要求;資料的安全性。

　　資料架構的主體設計思路是從需求分析和業務特徵出發去進行資料分類，劃分主題域，然後採用領域驅動設計方法進行業務模型設計和資料模型設計，再結合老核心的資料治理和標準化的產物，結合資料架構設計原則以及主流技術和行業實踐去設計資料架構規劃。資料架構規劃包括資料的分佈與儲存、資料的加工與流轉，以及資料的管控與應用。這裡提到的主題域，其實就是從較高的層次對業務資料進行的抽象和歸納。

　　新核心專案中使用了一些資料高效操作的方法。第一個是資料整合操作，這由我們的開發平臺提供支援。大家都知道傳統的ORM框架是以單個POJO實體為單位與後臺資料庫進行互動，而開發平臺支援從多個POJO實體中抽取所需資料項形成一個業務服務物件整體BO，以BO為單位與資料庫進行互動，這種方式在重複查詢時極大減少了訪問次數，提高了訪問效率。

　　第二個是快取記憶體，它由快取平臺來提供支援。可以使用快取平臺存放一些資料量比較小但是訪問頻率很高的資料，比如碼錶的資料、費率相關的資料以及使用者機構和許可權的資料。

　　第三個是讀寫分離、冷熱分離。

　　資料量很大的話，就要考慮表分割槽。我們資料建模時在表中預留了“時間欄位”和“管理機構”欄位，等資料量增大到一定程度的時候，我們就可以按時間做範圍分割槽，按管理機構做列表分割槽，或是二者結合的複合分割槽。資料量要是再大的話就要考慮拆庫拆表。Oracle提供了資料分片技術(Data Sharding)，現在Oracle最新版的12C資料庫已經能夠做到從CDB$ROOT層面直接聚合查詢多個PDB中同一張表的資料。

　　下面我通過一張圖來介紹一下新核心資料架構的規劃設計。大家從這張圖上可以看到，我們將資料架構劃分了八大區，分別是資料來源區、資料整合操作區、資料交換區、資料儲存區、資料準備區、資料加工區、資料管理區以及資料應用區。

　　資料來源區中，我們有來自核心業務系統的多個系統，也有內部渠道和外部渠道多個系統以及其他來源的多個系統;

　　資料整合操作區由開發平臺支援;

　　資料交換區主要由資料交換平臺支援;

　　資料儲存區的資料主要分為兩類，一類是結構化資料，一類是半結構化和非結構化資料。生產庫是寫資料庫，儲存的是結構化資料，查詢庫是讀資料庫，二者同構，之間採用OGG方式實現準實時同步，讀寫分離減輕了業務系統壓力。內容管理平臺用來儲存半結構化和非結構化資料。

　　資料準備區，我們沒有設立單獨的主資料庫對主資料實施集中管理，而是採用分而治之的策略，由各個系統管理各自的主資料。我們設定了ODS，用來儲存通過ETL從各個業務系統抽取出來的、經過清洗、過濾、標準化和輕度整合的業務資料，為資料倉儲供數。

　　資料加工區規劃了資料倉儲和資料集市，資料倉儲的模型參考了TeraData FS-LDM。

　　資料管理區規劃了設計平臺，它是後設資料管理和資料建模的工具，主要提供業務模型管理、資料模型管理、後設資料管理、資料字典管理以及碼錶管理的功能，是後設資料管理和資料標準化的核心所在。

　　資料應用區包含了若干個資料消費系統，比如決策分析域的多個系統，以及一些查詢類的應用，比如：即席查詢、標準和複雜報表、MIS;一些分析類的應用，比如：多維OLAP分析、風控、KPI績效;一些管理類的應用，比如：高管駕駛艙、決策支援等。

　　設計清晰的資料架構可以為劃分應用邊界、明確資料間引用關係、定義系統間整合介面提供依據。大家可能發現了這個資料架構中並不涉及大資料和機器學習的內容。因為適合公司目前新核心建設、適合現有系統資料現狀的架構才是最好的。我們公司現在的資料量在未來可預見的相當長的一段時間內，距離PB級或EB級還差得遠，所以我們的架構設計更偏向於傳統的OLTP交易型架構，輔以ODS、資料倉儲來提供基本的資料分析功能。

　　下面我們分別從資料來源區、資料準備區、儲存區、加工區、交換區來深入地介紹一下資料架構規劃。

　　資料來源分為內部資料和外部資料。內部資料來自於核心業務系統和渠道接入系統。外部資料來自於銀行、保險等金融同業或者是像保監會這樣的政府監管部門，未來可能還有來自第三方機構、網際網路的。保險產品和服務相對於銀行產品來說，是一種弱需求的產品。我們沒事兒的時候，可能會用手機銀行或者微信銀行查查賬戶餘額、信用卡賬單和理財什麼的，但誰不會沒事兒把保單拿出來看看。所以說保險公司與客戶的互動不像銀行那麼頻繁，不容易獲得客戶行為特徵的資料，這就決定了我們以後可能會從第三方機構購買資料。阿里收購投資了很多公司，其中也不乏網際網路公司，比如高德導航、蝦米音樂等等。收購它們並不是這些公司的品牌價值有多麼大，阿里真正想要得到的是這些公司多年來積累的使用者行為特徵及偏好的大資料，從中汲取製作大資料生態版圖和綜合應用的素材。所以，如果我們以後要做大資料的話，可能也會去購買資料。

　　資料來源應該去關注一下它的非功能屬性，它會對資料儲存分佈的設計起到參考作用。比如是基於資料介面的交換還是基於檔案伺服器的交換;全量還是增量;變動頻率是極少、偶爾還是固定週期，像客戶機構名稱這類資料是很少變動的，像地址和聯絡電話可能是偶爾變動的，像定期結算收費就可能是按固定週期變動的;資料格式是結構化、半結構化還是非結構化;共享程度，主要取決於業務模組對資料的需求強度，如果按標準來區分的話，主資料是跨系統、相對靜態穩定的，可以高度共享，那麼它的共享程度為高，相對來說分佈在特定業務領域的業務資料的共享程度就是低了。

　　目前ODS是把從業務資料抽取過來的資料進行清洗過濾、標準化以及輕度整合後存放。我們可以把ODS分為兩半，左邊是後設資料增量層和標準增量層，它採用的是貼源設計，與生產庫基本是同構的。右邊是基礎資料層和共性加工層，做輕度整合和進一步整合。所以整個ODS可以整合業務資料的全貌，並提供跨系統的細節查詢，比如清單查詢。經過ODS清洗過濾及標準化後的資料，提升了資料質量，然後為資料倉儲提供資料。

　　簡單介紹一下內部劃分的四個功能層：ODS從各個系統抽取業務資料以後，會放到後設資料增量層，然後經過清洗過濾標準化以後，放到標準增量層。對資料做了輕度整合就進入到基礎資料層，共性加工層就是在基礎資料層的基礎上又提煉出一些共性指標，對資料做了進一步整合加工，只包含彙總資料。

　　ECM主要是用來存放半結構化和非結構化的資料，比如語音、影像、掃描件或者PDF和Word的文字檔案。它主要對這些種類的資料進行處理、儲存、捕獲，分為前端的資訊採集平臺和後端的內容管理平臺。如果以後要做大資料的話，可能還需要建立非結構化資料的後設資料，並且將這些非結構化資料的後設資料，經過一些結構化的處理技術，比如像文字摘要、打標籤等等，與結構化資料產生關聯，這樣才能共同發揮作用。

　　資料倉儲的內容比較多，現在還處於規劃階段，在這裡我只簡單分享一下資料模型。資料模型我們打算參考 TeraData FS-LDM。TeraData是全球最大的資料分析、資料倉儲以及整合營銷解決方案的供應商，它能夠在一個整合的模型內支援銀行、保險、證券三大行業的金融模型，內含十大主題域。我們在這個基礎上，根據自身的業務特點和資料分類劃分了八大主題域，每個主題域下面又細分有小主題。比如說“參與方”這個大主題，下面細分有人員、客戶、代理人、法人四個小主題，其中，客戶小主題又包含客戶的基本資訊、聯絡資訊、健康資訊、財務資訊、資產資訊等具體內容。

　　這是我們在資料交換區構建的資料交換平臺，因為我們現有核心繫統存在著一些問題，比如說核心系統內部和各個系統之間，以及核心與外部系統之間的資料整合、資料同步、資料共享困難;系統耦合度比較高，A系統的表結構發生變化，B系統程式也得跟著改;dblink使用氾濫，效能開銷大、存在資料安全隱患。

　　為了解決以上的問題，我們建設了資料交換平臺，並規定了建設目標。第一，提供統一的資料整合規範、資料獲取與分發、資料交換與共享、資料監控;第二，提高資料加工、資料流轉效率，加快資料在系統內、系統間的快速移動;第三，改變傳統的“多對多交換模式”，實現“一源多目標”的資料更新。

　　我們還有一個設想就是以“後設資料”驅動DEP中的ETL過程，在ETL中嵌入資料質量檢查與監控;將後設資料管理應貫穿於資料流動的全過程。

　　資料交換平臺的功能定位是讓它作為資料交換樞紐，通過一定的“資料獲取及分發”策略、作業排程策略，結合內建於各系統內的資料交換區，實現核心業務系統內各子系統、核心業務系統與外圍各系統之間的資料交換、資料同步、資料共享，為各個OLTP和OLAP系統提供資料介面服務或資料檔案交換服務。

　　各系統要與資料交換平臺做一定的配合，也就是在系統內部設立資料交換區或檔案交換區。比如在交換區內提供介面表，我能為別人提供什麼樣的資料?我需要消費什麼樣的資料。如果是檔案交換服務，就需要提供符合一定資料格式的檔案。

　　大家可能會問什麼樣的東西走ESB企業服務匯流排，什麼樣的東西走DEP資料交換平臺?舉個例子，如果想實現對等的交易，A系統的交易必須等待B系統返回結果之後，才能繼續處理，像這種對實時性要求比較高的就走ESB，但是它的報文不能太大，我們規定是控制在500K之內。如果要是對實時性要求不高、可以準時傳送、資料量又比較大，就走資料交換平臺。

　　我覺得資料交換平臺更像是資料服務匯流排，而ESB是是企業服務匯流排，他們一個是實現應用服務的虛擬化，一個是實現資料服務的虛擬化，一個提供的是應用服務的連通性，一個提供的是資料服務的連通性。ESB可以讓處於不同裝置、使用不同協議的系統連起來，而資料交換平臺可以基於資料庫或者基於檔案伺服器，通過提供資料服務使各系統連起來。

　　我們還提出一個設想就是要建立IP(整合平臺)。ESP提供聯機實時、小資料量的資料服務，DEP提供批量、大資料量、準實時的資料服務，而MP提供非同步的訊息服務，三位一體地構成一個整合平臺來提供應用連通性服務和資料連通性服務。

　　下面介紹下我們的新核心專案在資料治理以及標準化過程中分階段實施的進展。

　　說到資料治理，我們在14年的時候曾經請恩核公司做過技術諮詢，在過程中應用了恩核提供的方法論，取得了不錯的效果。我認為要做好資料治理，首先要選定一套行之有效的方法論，再建立起一套原則、處理流程和資料組織，如果再配上一個得心應手的工具，應該會達到事半功倍的效果。

　　為什麼現在越來越多的公司都比以往更加重視資料治理工作?因為資料治理、後設資料管理及其中的資料標準化是實現商業智慧的重要環節，如果資料不一致、資料質量達不到要求，你是無法進行資料整合和整合的，也就無法進行資料分析和資料探勘，更談不上商業智慧了。所以說資料治理的重要性在被逐漸提高。

　　資料治理的核心是後設資料管理，而後設資料管理的核心就是資料標準化，我們說後設資料是Data about Data，它是描述資料的資料，其實後設資料就是定義資料項的框架和標杆，它除了包括資料名稱、資料型別等基本資訊以外，還包括資料歸屬、取值範圍、校驗規則、資料來源等這些擴充套件資訊。後設資料管理的應用領域是十分廣泛的，比如模型設計、資料儲存和交換等。

　　我們現有的核心繫統中存在很多資料質量問題，比如不符合業務技術規則、資料格式錯誤、多套重複編碼等。我們現有的碼錶裡面非常冗餘，因為我們現在的系統是由外包人員來維護的，他們的流動性比較大，有些人為了圖方便，可能來一個新人就訂一套新的編碼項。我們在梳理時候發現，僅銷售渠道方式的編碼方法就有6套重複的。

　　我們在資料治理的時候也發現了很多問題：命名規則不統一，英文、漢語拼音混在一起，有的縮寫根本無法從字面去理解它的準確含義。我剛來公司的時候，JYX、HYX、XPS、SOS這些都不知道什麼意思，後來是老員工告訴我，JYX是借意險、HYX是航意險、XPS是學平險、SOS我剛開始以為是救命呢，後來才知道是境外救援險;資料型別不統一，同一個欄位在不同表裡的資料型別、長度不一樣，這會給資料交換造成很大的隱患;相似表、空欄位太多，且大多都廢棄不用了，現在總表是2500張，而在用的資料表只有1400多張，基本上有將近40%的表都是空置的;模型擴充套件性非常差，新增業務的時候通常要新增表;資料結構變更難以評估對應用造成的影響。

　　主資料管理這塊重點需要關注：哪些系統是產生主資料的系統?哪些系統是消費主資料的系統?主資料是怎麼獲取、怎麼分發的?

　　我們的主資料管理沒有采用集中管理，而是由各系統分別管理。客戶資訊系統、統一使用者管理系統，設計平臺、產品工廠分別維護客戶資訊、使用者機構許可權資料、碼錶資料、產品套餐險種資料。拿客戶資訊系統來說，通過客戶資訊五要素：姓名、性別、出生日期、證件型別、證件號碼去識別客戶資訊，通過覆蓋、歸併、整合、追加等方法生成客戶的黃金記錄，最後為客戶分配唯一標識。

　　我們以客戶資訊系統為例講一下主資料的清洗。因為客戶資訊資料是通過業務系統呼叫介面進入到系統中的，出於使用者體檢的考慮，我們可能不會對介面控制得那麼嚴格。但是放鬆控制的結果會使髒資料進入系統，所以說資料質量的提升，其根本在於通過規章制度、績效考核來規範和約束一線錄單人員，在源頭就將高質量的資料錄入系統。

　　這是我們針對個人客戶資訊提出的一些清洗規則，這些規則基本上都是基於資料格式的清洗，而不是針對資料文字內容的清洗。因為針對資料具體內容的清洗是無能為力的，有的廠商說我可以提供中國郵政大字典，把地址進行清洗，但如果內容都是一些“的的的了了了”，根本無法清洗。所以IT技術只能作為一種輔助手段，它可以做資料質量檢查、也可以給業務部門提供資料質量報告，但是沒有辦法從根本上解決資料質量問題，也沒有辦法徹底修復資料。所以，必須讓資料質量與外包錄入人員的績效掛鉤，才能從根本上提升資料質量。

　　下面我們介紹下資料標準化應用。上圖是新核心單證系統業務模型，藍色部分是業務實體類物件，黃色部分是業務操作類物件。業務實體類物件通常是指單證的定義、單證的明細、單證的軌跡等等。業務操作類物件通常是指單證的入庫、發放、單證的回銷、回退等等。業務操作類物件比較像Java類，有成員變數以及成員操作。怎麼將業務模型轉化為資料模型呢?具體的方法有兩種，一種是大家比較熟悉的ER模型分析方法，它是面向結構的，優點是比較容易向底層物理模型轉換，缺點是不夠靈活，抽象和複用程度不夠，如果你要是全用這種方法來設計資料模型，那麼以後就只能新增一個業務增加一個表。第二種是物件類模型分析方法，它是物件導向的，優點是能夠很好地實現抽象和複用，缺點是不好物理落地，所以要使用物件類模型分析方法將業務模型轉化為資料模型，需要資料建模人員具備一定的設計經驗、知識背景或者有一定的模型設計規範來指導他完成。

　　這是新核心渠道接入資料平臺的資料模型，也是新核心資料治理與標準化產物綜合性應用的體現。這個專案於去年11月份成功上線同時也獲得了一些獎項，它的整體設計過程體現出了我們的領域設計思想。他的資料庫符合《資料庫資料規範》、模型符合《資料模型設計規範》，它的所有產物都應用了《新核心標準化字典》。這是我們進行資料治理的一個成果。

　　這裡主要講一個“業務資料樣例”的概念。我們將業務場景與資料樣本相結合，編制了業務資料樣例，它關注的是實際發生了的業務活動將導致資料模型中的哪些內容發生變化。這裡以“簽單請求”的業務場景為例，給出了資訊流資料在各個步驟中是如何通過資料模型來表達的。它可以用來指導開發人員正確理解和使用資料模型，指導測試人員編寫測試用例。

　　接下來為大家展示一下資料標準化的其他成果。

　　這是老核心資料治理的產物，為了配合新核心的建設，我們對老核心的資料物件及重要資源進行了整理，上圖展現的是表和欄位的整理。資料表的整理有表的名稱、所屬模組、表的型別、活躍程度、使用場景以及表間關係。資料欄位的整理有欄位含義、標準化名稱、資料型別、長度精度、碼錶取值、業務規則、技術規則以及欄位來源。重點提一下欄位來源，同一個欄位在不同表中的來源可能是不同的，有可能是前臺輸入的，也有可能是後臺系統插入的，還有可能是通過規則公式計算彙總得到的。

　　這是我們標準化的一個最重要的產物——新核心標準化字典之基礎詞彙，同時它還是漢譯英的基準和標杆。從分詞標準化實踐的經驗來看，最好是一個人做全程，並且要有一個好的工具來支援。分詞的主觀成分較大，主要取決於分詞人的業務知識、工作經驗、常識以及詞彙量。大家可能從圖上看到我們的這些產物都是在用office文件來維護的，這是因為我們的後設資料管理工具(設計平臺)正在根據試用意見進行改造，在正式投入使用前，我們會採用一些輔助手段，比如用eclipse編寫一些小程式去檢查字典的覆蓋度、正確度、冗餘度是否符合要求。

　　分詞過程有一些細節需要注意，比如術語拆分的斷點和粒度，在漢譯英過程中英文詞彙的選取、同義詞的處理、詞彙多對多的問題，副詞、介詞、數量詞的提取規範及表示法，全稱或縮寫的選擇以及縮寫程度的把握，單體詞或複合詞的選取，名稱超長後的縮短處理等等。

　　基礎詞彙字典的用途十分廣泛。在對錶、欄位等資料物件進行標準化命名的同時，我們對新核心各子系統的名稱及重要資源都進行了標準化。比如說釋出在ESB上的原子服務、銷管系統的崗位編碼，等等所有需要標準化的地方都用到了這本字典。現在這本字典可以做到英譯漢幾乎一字不差。

　　這是對碼錶的整合，它也是資料標準化的一項重要內容。我們從業務角度對老核心碼錶進行了整合，分為公共編碼和私有編碼。像證件型別、婚姻狀況、性別這種通用性很強的，屬於公共編碼;像銷售渠道、保單型別、保單狀態這種業務含義很強的屬於私有編碼。我們根據保險標準委員會制定的國家金融行業標準(保險通用業務程式碼集)，對老核心公共編碼進行了替換和擴充。

　　私有編碼比較特殊，每一個保險公司都有自己的私有編碼。由於每個公司的發展戰略和業務側重點不同，私有編碼的數量和取值範圍在資訊化落地時會存在較大差異。因此，我們在沿用老核心的基礎上進行了整合與標準化，合併同類項，消除冗餘。

　　這是我們從技術角度制定的碼錶規範，包括編碼項的准入標準、命名規範、取值編碼原則、碼錶結構、分發策略等內容。我們通過設計平臺定義和維護碼錶，通過資料交換平臺將它們分發到各個業務系統。碼錶規範會使顯示或列印資料更加準確，新核心各子系統之間無需轉碼，這有助於提升系統效能，也便於開發運維人員理解。

　　這是資料治理與標準化的兩大標誌性產物，一個是資料庫設計規範，一個是資料模型設計規範。資料庫設計主要是用來指導運維人員在資料庫搭建和引數配置的時候對資料庫效能進行初步優化。資料模型設計規範用來指導建模人員將一些典型的業務場景或業務模式通過規範化的資料模型來表達，類似於JAVA的設計模式。這樣我們就可以避免設計人員按照自己的設計經驗或技能水平自由發揮，讓他們設計出來的產物具有一定的規範性，再經過1-2次評審就可以交付專案組開發使用了。

　　這是主資料管理方案，主要是對主資料管理的概念、方法論、關鍵技術及當前主資料的主流應用進行了闡述。

　　我們做新系統少不了資料遷移，資料遷移必然會涉及到對老模型分析、新模型設計以及新老模型之間的對映和轉碼等問題，所以遷移之前要做好充分準備。遷移總體方案，從遷移準備、實施步驟、關鍵點控制、應急處理等幾個方面進行了闡述。

　　從技術層面來說，資料治理可以幫助我們提升資料質量，提升資料的一致性、準確性和完整性;使資料的生命期更加清晰，能夠很好地發現資料的產生、變遷;使系統執行更加平穩，一定程度上提升了系統效能。

　　從業務角度來說，當IT系統發展到一定階段的時候，有效的資料治理可以使企業內的資料資源變為戰略資產;減少運營成本，降低運營風險;支援業務運營和高層決策;增強應對監管部門審計性、合規性要求，最終資料價值的發揮將回饋於業務，體現為企業利潤的增加。

　　我個人覺得資料治理不僅應該貫穿於專案的始終，更應該貫穿於整個企業生命期的始終。資料治理是一項很長遠的工作，我們任重而道遠。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31137683/viewspace-2154035/，如需轉載，請註明出處，否則將追究法律責任。