你與一個優秀的元數據系統只差一個採集器

今年兩會後銀監會發布《銀行業金融機構數據治理指引（徵求意見稿）》，將數據治理納入機構治理範疇，並將數據治理情況與機構治理評價和監管評級掛鉤。可以看到不管是企業自身還是監管部門，都將對數據治理的重視提升到了一個新的高度。

在此背景下，很多公司都開始將更多的資源投入到數據治理相關制度或系統的建設。其中科技方面最直接的就是元數據管理系統，我相信絕大多數專於數據平台建設的公司，在數據治理制度或產品開發能力都有一定的積累，服務水平差別不大，在元數據應用方面，也都有各自新穎的創新及特色，然而真正體現系統能力高下的，是在一個核心問題上有沒有完善的解決方案。這個核心問題就是元數據的採集，確切的說是SQL腳本中包含的元數據的採集，這個問題是無法避免的，而且這個問題解決的能力直接決定了後續數據治理系統的服務能力。

1.為什麼SQL腳本中的元數據如此重要

如果需要繪製企業級的數據地圖，需要全面的採集分布在各個系統中的元數據，但是企業經過多年的系統建設，元數據構成十分複雜，ETL工具，SQL腳本，報表工具，等等，數據流轉的每個轉換過程中，都存在要採集的元數據。

其中，工具類的元數據有工具自帶的知識庫，本身就已經提供了結構化的元數據，大部分工作集中在知識庫與元模型的映射。

剩下的就是SQL腳本中包含的元數據了，這部分元數據有如下特徵：

元數據內容含量佔比大：在數據加工過程中，絕大部分邏輯都是通過SQL進行處理的。SQL腳本在原生的資料庫中執行，無需額外採購，優化手段較多，邏輯靈活，同時使用SQL腳本的工程師人數眾多，等等多方面因素，使得基於SQL的數據加工成為整體數據轉換中的主要處理方式。

包含了數據標準的使用情況：數據標準發布後，在過渡階段，一定需要通過數據轉化進行統一化處理。在治理過程中，數據標準的應用情況，最直接的反饋就是SQL中的處理邏輯。

包含了深度的技術元數據：一般的元數據採集能覆蓋到常規的數據處理，深度採集能夠覆蓋到數據優化層面的信息，如：自定義執行計劃，數據歷史版本，內置索引，並行插入等。將這部分數據結合索引，分區等元數據，就能夠分析得到腳本優化建議。更有甚者，在處理邏輯中會批量執行動態SQL，更是解析的噩夢。

存在於ETL工具中：在ETL工具中也不是完全都使用圖形化編輯的邏輯進行處理，在多種控制項，尤其是查詢控制項中，基於多種考慮，也會使用原生的SQL，所以元數據採集器在抽取ETL工具的元數據時只採集知識庫，也是無法得到全部元數據信息的。

綜上，一套元數據管理系統或平台做的好不好，決定性因素就是原生SQL採集是否能做到全自動無人工參與，全信息無遺漏，全兼容無不識別腳本。基於完善的採集結果，才能構築豐富的上層應用，衍生出多樣的系統功能。

2.為什麼SQL腳本中的元數據採集如此之難

在各個數據服務企業中，在數據治理方面的投入都很大，對SQL腳本解析的重要性都有很高的認識，但最後還是鮮有做到全解析，足見解析難度之大：

編寫過程人為因素較多在數據平台項目或特定主題的集市建設過程中，都涉及了大量的數據加工，轉換，計算功能，很多有豐富經驗的公司在實施過程中，會事先定義開發規範，保證程序的可讀性，可維護性，甚至在通用的基礎處理方面，會有腳本生成工具，批量生成SQL腳本。但是最終無法迴避的是，大量包含複雜邏輯的加工步驟，必須依賴於開發人員的定製化處理，而且這部分腳本會由於很多因素導致寫法的差別，如：同一個業務場景，不同的開發人員，不同的基礎數據量，甚至是同一個開發人員開發經驗成長都會導致寫法不同。

資料庫產品及版本種類繁多元數據管理系統作為產品進行研發，面對的採集目標是所有產品資料庫，以及資料庫的不同版本。不能局限於指定的庫或版本。同時，在資料庫新版本升級後，元數據採集器也要很快的兼容。各資料庫產品會支持通行的SQL標準，但是在一些個性化功能中，這部分語法就是非標準的了。

追求SQL執行效率的特殊寫法在一些用戶規模較大的客戶項目中，處理的數據量都在億級以上，這樣，對腳本的編寫要求就很高，同一個語法，在數據量少是運行沒問題，但是數據量一大，就運行不完，甚至會導致資料庫服務的異常。在這樣的情況下，SQL腳本就需要根據實際情況進行優化，還可能會用到一些基於特定資料庫的特定寫法，這些語法也基本是非標準SQL，又提升了採集難度。

腳本邏輯歷史版本的不斷迭代數據平台建設一般是長期過程，到目前為止，運行時間在十年以上的也不在少數。邏輯變更時最大的痛點是不敢貿然修改正在運行的腳本，原始開發人員在的情況下，他很了解腳本的來龍去脈，歷史背景，影響範圍等，變更風險可控，但是腳本在經過多個版本變更，甚至經過很多人交接後，即使有很完善的文檔，也很難準確的確定腳本的變更風險，最終解決辦法有可能就變成增加分支甚至增加版本，多個分支或重複的腳本同時運行，導致伺服器壓力越來越大，同時腳本也越來越不可維護。

3.我助您邁入數據治理專家行列

個人長年從事數據平台建設以及數據治理項目，用業餘事件開發了一套基於SQL腳本的元數據採集器，可無人工參與，無信息丟失的採集SQL中的內容，形成標準的結構化數據，助力有數據治理系統或平台研發需求的企業，提供核心採集功能，無侵入的集成到產品中。

採集器主要特點如下：

1.採集器與語法分離

採集器為基於java開發的通用程序，運行環境jdk1.5以上。

語法配置外置，動態載入，不同資料庫產品，以及產品的不同版本的語法，我會緊跟資料庫的版本更新，定期發布語法庫，並提供更新手冊或駐場更新服務。

2.輸出為標準結構對象，方便處理

採集器輸出的結構對象支持多種形式：1)輸出多層JAVA的MAP和LIST對象。2)輸出為標準的XML或JSON格式。

以XML格式為例，結構化後的數據形式為：

…參數列表

…變數列表

…過濾條件分解對象

…插入語句的分解對象

…異常聲明

3.方便集成與維護，靈活升級

採集器提供了多種集成方式：

1)提供處理jar包，深度集成到元數據管理產品中，傳入SQL腳本的字元串，輸出結構化的java對象，進行靈活操作。

2)推薦使用獨立服務部署的模式，通過http或遠程調用以標準格式的XML或JSON進行交互。

個人聯繫方式：

歡迎有志做一流數據治理平台的公司垂詢。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！