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