由兩個執行個體看中繼資料管理

由兩個執行個體看中繼資料管理

 

設計BI系統，免不了要跟中繼資料打交道，但有時候人們感覺不到它的存在。比如要瞭解資料庫結構的時候，並不需要從系統資料表中去查看，可能只需要一個文檔、一個命令或者通過資料庫治理工具輔助查看即可；但假如要開發一種查詢器，以供半業務半技術人員使用，讓他們基於業務術語拖拖拽拽拼湊成SQL提交查詢，這樣的查詢器就必然要去訪問中繼資料了。
是什嗎？
中繼資料究竟是什嗎？用”描述資料的資料”(Data About Data)來定義確實是非常精簡的，不過作為一種迭代式的定義，似乎並不夠準確。從名稱上理解，中繼資料也是資料，那麼描述中繼資料的資料是什嗎？元中繼資料？如此迭代下去，就沒完沒了了。
用打比方的方法來輔助這個定義可能更加清楚一點。將中繼資料治理想象成是一個客戶治理系統。企業為了更好地服務客戶（其實是如何從客戶身上賺取更多的利潤），需要將客戶治理起來，搞好客戶關係。同樣的道理，中繼資料治理系統也是為了更好地利用資料。客戶有生命週期，比如什麼時候被企業服務，什麼時候脫離企業服務，處於什麼狀態等等；資料也是如此，什麼時間產生，什麼時間被什麼人使用，狀態的變遷等等。
在資料倉儲中，中繼資料的概念被強化了，在每個資料倉儲項目的總體架構圖中，幾乎都有”中繼資料治理”模組來橫貫其他模組。顯然，這表示它是一種基礎模組，可以服務於諸如OLAP、ETL等其他模組。但實際上，卻很少見一個完成了的資料倉儲項目中有獨立的中繼資料部分。大多項目，中繼資料都是分散在各種BI工具中。
這些分散的中繼資料是不一致的，例如對一張表的結構定義，可能出現在ER設計工具中，當然也會在資料庫的資料字典中，還有可能在ETL工具的源、目標定義中。如此多的重複定義，當然會發生資料不一致現象，卻也正好為中繼資料治理工具留下廣闊空間，它們的作用就是集中治理這些分散的中繼資料，就像資料倉儲一樣，從不同的源採集資料，有ETL，也有清洗，甚至重建立模。

誰做過？
對於一些大型企業來說，儘管有時候還不能確定建立中繼資料治理系統的作用，但這方面的需求還是有的。例如中國移動就有吉林、湖北兩個省公司高調宣傳自己的中繼資料治理項目，這算是一種積極的嘗試，也在為整個業界的中繼資料治理應用起到了推動作用。假如從宣傳文字看，都是冠冕堂皇一個味道，沒什麼意思，但另外一家D省公司和這些先行者一份對比報告，卻顯得頗為有趣。
D省公司其實也有中繼資料治理的內容，只是尚未形成系統，這份報告就圍繞著組織架構、建設時間、項目投資、系統功能等方面與吉林移動中繼資料系統展開了比較。從架構和投資上的比較很簡單：吉林移動的中繼資料治理系統從建設時間稍晚一些，但是當作一個項目來建設，而D省則是夾雜在經營分析系統中一起建設，因此在組織圖上肯定不同；項目投資上，吉林移動投資了幾百萬，而D省公司由於並未單獨立項，所在在報告就顯示分文未花。
最重要的差別還是在系統功能上。吉林中繼資料作為一個項目提供了應用且易用的前端；而D省公司的中繼資料治理偏重於後台，提供系統監控、治理和最佳化等技術上的應用，都是面向技術人員，對業務中繼資料考慮較少，幾乎沒有提供給業務人員使用的介面。
不管兩省公司的比較結果如何，從總體來看，兩公司的中繼資料治理都還缺乏深入的應用，例如資料品質治理、影響分析、血統分析等，大都是在強調中繼資料治理的平台性。所謂平台，就是搭好了檯子，上面唱什麼戲就不管。至於這個平台是不是能夠支援人家唱戲，是不是平整，目前還沒有什麼東西來衡量。

怎麼樣？
總的來說，中繼資料治理還是一個不成熟的領域。具體原因有業務和技術兩個方面。
從業務上看，很多人對於建立一個中繼資料治理、交換平台的目的並不明確，也沒有人知道集中這些中繼資料究竟給企業帶來多大價值。
從目前國內企業所處的階段看，建立這樣一個平台並不能產生多少價值。即便是在平台的建設初衷和誰來使用這個平台等問題上，也有多種說法。例如有人說這是企業資料標準的前提，也有人認為是企業Data Integration的基礎，可以使系統變得可擴充。這些聽起來確實有道理，但也太過空洞。假如追問下去，這些說法都經不起推敲。比如建立企業資料標準又是為了什麼目的？Data Integration又是為了什麼目的？
這樣追問並不是要否定資料標準或是Data Integration，而是說其目的都不夠直接。你可以將中繼資料治理作為企業的基礎設施來做，就像城市修路、造林一樣，是為了一個宏大的目標，可以造福廣大群眾。但是對於一般的企業來說，在整個IT系統體系不夠成熟的時候，奢談什麼基礎設施無疑有些過於超前。做中繼資料治理本身沒問題，要害是你要給誰用？功能是什嗎？假如有人要求做資料品質控制、效能最佳化或者系統監控、靈活報表查詢等等，這些都可以直接做，可假如你站在雲端裡面說 “我要建立企業的資料標準”，那麼，還是先撇開中繼資料，先看看如何解決不同部門的溝通鴻溝以及工作習慣問題吧。
從技術上看，統一的中繼資料標準尚未真正建立起來。
一般中繼資料治理工具大多提供的是中繼資料交換功能，基於某種標準，從其他BI工具（諸如ER建模工具、資料倉儲、ETL工具、OLAP工具等）中抽取中繼資料到集中的庫中，目前既成事實的中繼資料標準是CWM（Common Warehouse Model）。
但問題是，這類工具涉及到與眾多工具的互動，即便是它遵從某一標準，假如其他工具不遵循，問題依然不能解決。例如DAG（Data Advantage Group）公司的Metacenter，應該算是中繼資料治理工具領域的佼佼者，但其功能也非常有限。它在項目組裡面應用，確實可以從Oracle、Essbase等產品中提取中繼資料，對於ER建模工具，可以從ERWin中提取表的設計資訊，有內嵌的抽模數塊。但在另一方面，卻沒有對PowerDesigner的抽模數塊，問題是，項目裡面就是用PowerDesigner設計ER模型。由此，這類工具假如不能完全集中所有的中繼資料，整個資料倉儲中資料流就出現斷層，所謂一致性分析、血統分析也就無法建立起來。
目前，將資料看作企業的資訊資產這種觀念已經逐漸被接受且重視。業務人員想去瞭解資料的渴望，治理人員對資料品質的要求，都將使得中繼資料提供更多實際的應用並起到越來重要的作用。

原文選自: ChinaBI

本文連結：由兩個執行個體看中繼資料管理
轉載請註明出處：商業智慧BLOG-DinosBoy