之前的元數據系列文章（《90后美女程序員：元數據什么鬼？》、《輕松理解元數據，只需懂點心理學》......）讓我們了解到，元數據的概念已經充分體現在企業數據建設的方方面面。很多企業也意識到了元數據重要性，并購買了元數據系統，但系統如何發揮價值，是需要考慮的問題。元數據到底應該管理哪些數據？分析哪些環節？看似抽象的系統的功能在企業IT、數據建設中有哪些應用場景？下面我們舉三個例子讓你更形象地理解元數據在業務中的作用。
場景一：元數據對比分析——讓系統上線/變更高效、可控
在企業IT運維上線的時，我們有沒有碰到過以下場景？
系統上線的Deadline臨近了，BUG還沒改完，需求還在天天變。程序員每天還在加班加點的寫代碼，腦子已經昏昏沉沉了。系統上線的前幾天，各位程序員同學提交代碼。經過從測試環境中簡單測試后，打包最后一個上線版本提交給上線運維部門。
上線的那一天晚上項目經理心里沒底啊，程序員都想早點回家，項目經理要求同學們再堅持一晚上，“您回去了，萬一有問題我去找誰呢”項目經理說到。
上線開始了，運維人員給配置好操作權限，程序員開始按照上線操作步驟進行上線操作。一開始操作建表語句還很順利，導入初始化數據時候發現報錯。
一問程序員發現，最后提交程序上線腳本的時候，測試庫的模型建表語句與生產庫提交的版本不一致，提交上線包的時候是程序員疏漏了。怎么辦？
運維管理人員與整個項目組的氣氛都不好了。只有一個字“改”。表那么多怎么改？重新從測試環境傳一個上線包到生產環境還要走審批流程。我們試想一下后面的場景，誰也別想早回家了，此處省略一萬字……
類似上面的場景還很多，是不是似曾相識呢？想一下為什么會發生上面的問題，那么咱們以銀行為例分析一下，一般銀行內的系統建設環境分為三個：開發環境、測試環境與生產環境，每一個系統建設的周期都需要經過前兩個環境才能正式進入生產環境。然而在系統的設計、開發、測試、上線過程中，無論是需求變更還是BUG修改都避免不了數據模型也就是元數據的改動。大到庫表結構重新設計，小到一個字段類型的變更，都可能對程序造成影響。我們以往只重視程序功能測試，卻往往忽視了對元數據的管控。往往在開發庫、或測試庫測試通過，而由于人工疏忽在在上線過程中遇到問題。運維部門也很頭疼，由于對系統的數據結構并不了解，事先無法判斷，但是每次出了問題我們都需要陪著解決。
有沒有好的辦法呢？我們先來看看元數據系統的對比分析功能。元數據系統可以自動化采集三個環境的庫結構、表結構、字段結構、視圖與存儲過程結構等等。自動化采集保證了各自環境中都是最新的、最真實的、最準確的元數據結構。我們把系統提交上線的數據環境與測試庫進行對比，與測試環境中元數據不一致的地方則一目了然。試想一下如果，如果把系統的開發庫、測試庫、生產庫的元數據都管理起來，運維部門上線則不再被動的接受上線腳本，而是對元數據結構了如指掌，將元數據管控環節作為系統上線的必經環節之一，類似問題發生的概率則會大大降低。
場景二：數據流向分析——讓IT部門迅速響應業務數據問題，降低技術調研成本
很多企業都有做了數據平臺方面的建設，如數據平臺、數據倉庫、數據集市等。主要目標無外乎于由操作型數據向分析型數據的轉換。通過大量的數據ETL過程最終形成業務分析統計數據。我們來看一個元數據分析典型的例子，業務人員拿到分析報表，發現其中的若干業務數據項明顯不符合業務邏輯，則找到IT部門說你們加工出的報表有明顯錯誤，今天必須改出來，明天要看到正確的數字并給業務部門的領導匯報。
由于數據加工鏈路往往很長，由：業務生產類系統->數據倉庫->數據集市->報表系統內往往需要跨多個系統庫。涉及多個項目組、不同公司程序員通過不同的技術手段實現，有的項目組用存儲過程進行數據加工，有的項目組則使用ETL加工工具。所以沒有一個人能把問題所涉及的業務相關的表與具體字段定位清晰。因此需要組織相關人員討論，而且每次開會都要叫上許多人，分析問題的速度很慢，成本很高。
有沒有比較快速定位問題的方法？我們看一下元數據系統的數據流向分析，也就是影響分析（上游->下游）與血統分析（下游->上游），提供了字段級的數據解析，上下游之間的數據加工鏈路可以通過圖形的方式快速定位。每次分析問題都可以快速定位在特定的幾張表的某些字段，然后再詳細邏輯分析。大大簡化了數據問題分析的環節，今后再有類似問題的分析，再也不需要叫上原本不相關的人員進行開會。分析問題的平均時間只有原來的1/3。
場景三：交易鏈路分析-助力快速梳理服務調用關系
上面兩個場景介紹了系統運維與數據中心的兩個應用場景，下面我們再來看元數據如何輔助快速梳理系統服務之間的調用關系與服務間的接口。
我們還以銀行為例，銀行的IT業務系統眾多，之間的業務交易鏈路復雜。比如最常見的我在銀行網點存錢，就涉及到記賬、存取客戶信息等業務。所涉及的銀行業務系統包括柜面、核心、ECIF等，以及一系列復雜的系統接口服務調用。我們把一整套的接口服務調用關系稱之為交易鏈路。當業務系統的交易鏈路邏輯關系復雜達到一定程度，往往會需要對服務重新梳理、整合。
隨之而來的問題就是如何梳理交易鏈路。系統之間調用的服務方與提供方復雜度不同，輸入與輸出的參數各異，只能訪談每一個相關的開發項目組，投入大量的人力與時間成本。也有企業通過管理制度解決，新的系統上線、現有系統升級改造需要經過系統服務治理小組進行評審。但是服務治理小組本身梳理工作就很忙，無暇評估其他系統的變更，最后制度難以落實到位。這樣人工的系統梳理花費了大量人力成本卻難以見到效果。
有沒有有效的自動化的的辦法呢？答案是肯定的，用元數據的鏈路分析能力可以自動化的完成服務梳理。元數據可以通過服務接口的采集，自動獲取服務的信息，包括參與接口調用的輸入字段、輸出字段的長度、類型等信息，并通過系統自動采集相關的數據字典與關系映射，避免了人工梳理的問題。更進一步，我們可以讓元數據驅動，以元數據為核心，用服務的業務元數據規范新的服務，完善了整個服務體系，大大提高了服務治理的水平。
總結
其實像上面的元數據在企業中應用場景還很多，我們只要管理了企業的元數據信息，無論在企業的數據治理、數據管理、數據應用，企業應用架構，企業服務等等方面都可以發揮重要的作用。隨后的系列文章我們還會具體講解元數據產品在具體項目中的實施案例，更深入介紹元數據的價值。
京公網安備 11010502049343號