資料治理之資料模型管控方案

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

　　嘉賓介紹：

　　鄭保衛於2013年12月被北京市朝陽區認定為“鳳凰計劃”海外高層次人才，參與過大量關於資料架構、資料建模、資料治理、系統效能優化等方面專案，長期致力於資料架構及資料治理技術方面的研究和實踐。榮獲2015年中國大資料領域領軍人物獎，由國家資訊公共服務平臺及國家軟體公共服務平臺頒發。

　　正文：

　　大家好，今天我主要想和大家分享一些資料治理的經驗和資料模型管控的方法。其實資料治理的難度很大，因為牽扯的東西太多、外圍的環境太複雜。尤其是IT系統建設到一定程度的時候，你才開始做資料治理，難度真的會非常大。資料治理的技術問題不大，但是想要落地卻不是那麼簡單。我主要講解2個方面的內容：第一個是資料治理遇到的困難，通過什麼樣的方式才能保證資料治理的落地。第二個是資料模型的管控方案。

　　從去年的後半年開始，我們就可以非常明顯的感覺到傳統行業都開始做資料治理了。最近，我去過至少20家左右的銀行，他們無一例外都在做資料治理。他們通常的做法是先找諮詢公司做諮詢，做完諮詢之後開始往下一步走。一般諮詢公司都是做兩件事。第一個是設計資料主題域，其實就是業務後設資料，把企業的資料分成幾個大的主題域，並定義每個域裡面包含哪些資料項。第二個是定義資料標準，主要是定義業務用語，包括它的內容、英文含義等等。做得深入的一些企業，資料治理成果在資料倉儲建設過程中可能已經落地，但是效果不是太好。還有一些企業可能有自己的資料部門，比如跨區域性的銀行的資料部門可能有十幾個人左右、地區性的銀行可能只有四五個人。

　　IT建設從60年代開始，軟硬體技術在發生翻天覆地的變化，但是資料方面的技術和應用卻在不斷深化，從最早的資料應用、儲存到現在的資料分析、管理、統計、整合、挖掘等。

　　大家有沒有思考過為什麼從去年的後半年到今年為止，資料治理會這麼火?前兩年很多企業都在做大資料應用，但是傳統企業幾乎都是很慘烈的失敗了，為什麼?技術人員說資料質量太差了，然後領導就會問怎麼辦?那就做資料治理唄。基於這個原因，今年有很多企業在嘗試做資料治理。

　　現在，資料治理已經是一個普遍的話題了。前兩年我還在給大家宣講什麼是資料治理?怎麼做資料治理?現在不用講這個事情了，我去很多客戶發現他們已經在做了。

　　大家可以看一下這個趨勢，就會發現2-10年間，資料治理方面的技術需求一直處在上升期，圖中標註為紅色的部分都是與資料治理有關的技術需求。

　　資料質量問題是一個歷史問題，並不是做了資料治理就能完全解決，只能是在一定程度上有所緩解，從制度上、工具上、流程上有所保障。

　　上圖是資料治理在國內的發展變化。14年之前，我一直在給大家宣講什麼是資料治理?什麼是資料架構?為什麼一定要做資料治理，不做的話會帶來什麼問題。但是有很多人覺得這個東西太虛了，離他太遠了。有些大企業的IT全部是外包，他們只負責管理，在買來的半成品或者成品的軟體中資料標準是不可能被使用的。有時，我建議一些企業管理資料模型，他們覺得沒必要，同時也沒有人力和精力去管理，需要開發的時候就外包。

　　早些年這種現象特別普遍，但是隨著大家對資料的理解越來越深，尤其是從今年開始，這種情況逐漸發生變化，大家已經進入到第二個的階段了。我預測16-18年一定是個高速的發展階段，這種專案從諮詢開始到落地大概需要一到兩年的發展時間，那麼到18年，第一期的效果就會展現出來。所以說經過16-18年的高速發展之後，企業會對資料治理和落地方式有一個全新的認識，也會找到一種適合自己企業的方案。

　　18-22年的4、5年時間一定是成熟發展的階段，資料質量的治理是一個長期的過程，不可能一朝一夕就解決問題，所以我認為18年以後是一個長期的過程。

　　資料治理的發展其實也是資料發展的方向，做資料治理和從事資料方面的技術人員不妨可以朝這個方面去努力，我認為路還很長，未來一定是大有可為的，大家會越做越有經驗、越做越深。

　　我個人認為可以從三個方面來看資料治理的專案：第一個是目標。企業資料治理的巨集觀目標就是為資料應用、專案管理、專案開發提供資料支援，提升資料獲取、共享或資料規劃的能力。具體目標是構建資料標準，資料模型、提升資料質量。另外就是要構建一套適合自己企業實際情況的資料治理體系，這裡麵包含內容的梳理、資料標準、資料模型。有些企業將資料標準分成2部分，一個是業務的，另一個是偏技術的。管理流程，要有相應的人員和相應的流程來保障資料管理的落地，以及資料治理平臺的構建，還要構建一套自動化校驗體系。

　　第二個是專案成功的要素。依照我多年的經驗，如果資料治理從以下四個方面著手的話，或大或小都會獲得成功。首先專案實施的人員一定要有經驗，如果沒有經驗的話會有很多彎路要走。另外，前期資料標準的制定、資料模型的設計都需要技術有非常豐富的經驗人員。其次，要基於資料架構去做資料治理。第三，要有一套管理流程，這個流程是要通過軟體把流程部署到產品裡面，然後管理起來，同時要可以進行校驗。最後是資料視覺化，資料治理方面的資料視覺化說的更詳細一些是後設資料的視覺化，不管是業務後設資料還是技術後設資料都要有一定的視覺化。

　　下面我們來詳細介紹一下這四個方面的內容。

　　1.實施人員必須具備豐富專案經驗，提供可落地方案

　　這一部分沒有什麼可多說的，資料治理的實施人員如果沒有5-10年的經驗，那麼一定會出現很多問題的。

　　2.提供基於資料架構的資料治理體系

　　這個架構裡面包含了業務架構、應用架構、資料架構，業務部分其實包含了2個部分，資料部分和功能部分，把業務描述裡的資料提取出來，就是將來資料治理的物件。所以它一定是首先基於首先業務架構，然後才是應用架構。

　　那麼什麼才是資料架構，資料架構裡面包含什麼呢?主要包括資料標準、邏輯模型、物理模式等內容，其中我們一直強調資料標準化一定要做到單詞級的標準化，什麼叫單詞級的?假設使用者是一個單詞，姓名、電話、地址分別是不同的單詞，這些單詞可以拼接成使用者姓名、使用者電話、使用者地址等等用語。接下來為單詞定義英文縮寫，英文單詞縮寫與縮寫，便可按照一定規則拼接欄位名，這種方法很容易在開發過程中落地。邏輯模型向物理模型轉換的過程才能基於資料標準去做。緊接著就是要根據業務功能和資料功能去設計模型，設計邏輯、繼承關係模型。資料收集，包括資料域。最後是工具和流程的使用。

　　資料治理很多年前就已經在做了，但是為什麼不成功呢?主要原因就是大家都在做偏向業務後設資料的治理，而沒有基於此對技術後設資料做很好的設計和治理。為什麼不做呢?究其原因就是太難了，拿著一套標準體系要求開發人員按你的要求去做開發，那是幾乎不可能的事情。失敗的案例太多了，很多領導對資料治理都失去信心了。所以，大家又換了一個高大上的名字叫資料資產化，通過資料治理將資料變成資產。其實，無論它的名字叫什麼，其實都是在做一樣的事情，只要產品想要落地，那麼模型裡一定要應用標準。只有基於業務和應用架構去做，才能在最後實際生產環境裡面落地和應用。

　　3.提供管控型管理流程和自動化應用資料治理系統

　　之前資料治理不成功的原因還有一個就是管理。資料治理做完之後肯定要通過軟體來管理。在設計和開發階段都按標準來管理，那麼測試、上線、運營的時候也會有一些相關的資料要管理起來，那麼怎麼管呢?如果是要人工載入的話，那麼勢必得派一個人專門去管理，如果沒有專人管理，時間一長，實際生產系統和資料管理系統就完全脫節了，時間再一長的話，這個東西就沒有價值了，那麼也就意味著這個專案失敗了。

　　這時我們應該改變思路，採用管控型的資料治理方案。資料標準在設計階段或者分析階段設計完之後，到模型設計的時候，只要把邏輯模型建完，物理模型就千萬不要動了，邏輯模型向物理模型轉換的時候一定是基於資料標準去轉換的。所以說從邏輯模型向物理模型轉換的時候，一定是要基於前面設計的資料標準去做，資料治理和生產系統只有在這裡才可以合併，如果合併不了的話，後面又會出現問題。原來是兩套並行的生產線，一定會在某個情況下有交叉點，交叉起來後面事情就簡單了，現在有大量的工具可以保證資料治理成果的落地至生產系統的設計、開發、測試、運維等階段。

　　還有一個比較重要的部分就是單詞，單詞的英文縮寫，包括域的英文縮寫都要做到標準用語中去才好落地。如果做不到這個程度的話那就很麻煩。就像我前面介紹的，邏輯設計完成之後，就不需人力參與了，物理轉換以及指令碼生成全部由工具的實現。

　　4.提供視覺化和共享知識庫的資料治理系統

　　視覺化的方法有很多，只要能把東西展現出來就可以。這裡重點強調一下視覺化資料模型。很多企業資料庫裡的很多資料是說不清楚的，所以一定要通過模型來管理。

　　校驗一定要有一套自動化的校驗工具。標準資料模型在一定程度上是可以實現自動化校驗的，但是無法實現100%校驗。不管是開發人員還是測試人員都需要制定一些規則去校驗，只有校驗了才能及時發現問題，比如，把員工的同義詞定為職員或者管理員，可能在使用過程中，大家沒有使用標準用語，這邊是職員、那邊是員工，但是自動校驗工具可以自動把它們都轉換成員工。校驗可以避免在使用中出現錯誤的使用或不正確的使用。

　　現在知識庫做的並不複雜，基本不會出現問題，但是有些大企業是資料質量一套庫、資料標準一套庫、資料模型一套庫，資料庫一套庫，但是最終的資料治理只能用一套知識庫來管理，否則的話，像構建IT系統去構建資料治理體系，肯定也會出現問題。因為你的標準是企業級的，那麼就要覆蓋企業的各種業務系統，如果你拆分在不同的系統裡面或者不同的應用裡面，就無法實現企業級。我們做資料治理的最終目標一定是面向企業，而不是面向某個部門或者某個業務系統，所以我建議一定要有一套統一的知識庫來實現資料治理。

　　為什麼要做資料模型管控?資料治理最核心的就是資料模型管控，我們先看看現在都存在哪些問題。第一個是生產庫裡面存在大量的欄位和表沒有註釋，意思含糊不清，同名不同義、同義不同名，冗餘欄位、列舉值不一致的現象是普遍存在的，這些問題都會直接影響到你對資料的識別。舉個例子，有一家很大的公司要做新一代的CRM系統，在過程中發現普遍存在上述的問題，因為很多人都離職了，而且環境換了很多次，所以沒有辦法只能把核心的功能改造了，把剩下的功能直接原封不動的遷移過去。所以，如果不做資料模型管控，那麼這些歷史問題會給新一代系統改造帶來很多困擾。

　　第二個問題，模型變更前的合理性是沒有任何判斷的。很多專案都是以開發為主，開發人員說變就變。管理稍微好一些的企業可能會去追究變更是否合理。但是很多企業是不管的，任由開發人員變更。

　　第三個是修改過程中缺乏監管和管理，因為有很多模型變更的評審通過了，但是變更的過程是否按照原來的標準變更是不得而知的。

　　第四個就是大家經常會遇到的問題。因為工期特別緊，有的時候就直接寫指令碼進生產庫了，變更完之後沒有人知道。但是要上線時出現問題了，回頭調查問題的時候發現，原來是誰給某個地方加了個欄位或者加了一個表，但是這個問題解決之後就又不管了。所以我們經常說，很多企業的資料模型就是一個黑盒子，好多大型業務系統裡面表結構幾萬個，能說得清楚的也就一兩百個，這是一件多麼可怕的事情!

　　下面我們來總結一下這些問題。第一個是審計工作或者評審工作的缺失，評審有沒有指標?變更合不合理?人員能力夠不夠?第二個就是管理流程缺失，沒有把資料模型變更的事情納入到開發管理的流程體系裡去。第三個方面缺乏管理工具來輔助我們完成這件事情。第四個是沒有彌補措施，一旦發現問題了，沒有很好的彌補措施。

　　如何解決這些問題呢?我認為應該從這三個方面去著手：第一個是崗位設定;第二個是管理工具;第三個是管理流程。

　　崗位設定方面，我認為一個企業裡面最少得有一個架構師，來做資料建模、資料標準管理、資料質量方面的工作。前期管理是有很大幫助的。管理工具方面是指要有資料建模、資料標準變更的工具支撐完成工作;管理流程方面，要儘量說服企業把模型的變更流程納入到生產管理流程裡面去。最後就是事前的監控和事後的彌補措施，資料模型的管控其實應該分成事前、事中、事後三個階段，其中最主要的就是事前和事後。

　　銀行行業在事前的階段就做的比較好，在模型變更之前它會有相應的人員去判斷變更的合理性。這就說明他們有這樣的崗位設定，但是每個企業的審計指標是不一樣的，也是需要逐漸去完善的。目前，審計工具沒有特別好的，大多數是在靠人力。事中就是監測變更過程中是不是按照原來規劃好的去變更。

　　事後包含兩個部分，一個是資料庫物件不同版本之間的比對，另外一個是模型與資料庫的比對。比如上週的資料庫版本、尤其是表裡的資料，和今天的版本是不是一致?模型與資料庫是否一致?

　　上圖是某個企業的管控模型，大家可以看到他將每個模型都管控起來了，這是一個14年建立的移動行業的企業，它的IT系統建立的非常快，僅僅一年就全部建立起來了，而且效率非常好、質量也很高。這裡還有一個非常值得我們借鑑的地方，就是他每個專案組裡一定有一個專門的人去負責資料架構，每一個模型之間有一個模型負責人，上面有一個總負責人來負責整個資料架構的管理。

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