開發人員的元數據要求

Question

我負責提供我們的數據倉庫開發人員可能需要的元數據需求列表。

這不是變更管理（也稱爲衝擊assesment），數據沿襲等

所需的業務元數據（很好的說明等），而是數據我已經看到了這篇文章Meta Meta Data Data - Ralph Kimball但我我不是第一個這樣做的人，我把它扔到SO社區。

實際的問題是這樣的： 數據倉庫開發人員需要什麼元數據來設計，開發和管理ETL例程中的更改？ PS：我試圖保持答案平臺不可知，但對於上下文，這是一個使用PL/SQL和Datastage的Oracle數據庫。

Answer 1

在最基本的級別上，您可以維護從源系統提取的tablename.fieldname的列表。如果您從文件或其他非數據庫源提取數據，那麼您可能會或可能無法按照字段級別列出相關性。這樣的元數據只會告訴您如果（源字段/文件格式/表更改）然後（在ETL過程中需要更改可能）。我說可能是，因爲有些更改可能足夠小以至於ETL過程沒有中斷，但仍應該執行測試和數據分析，以確保它不會使ETL過程的初始設計過程中的任何假設無效。

儘管ETL開發人員可能非常熟悉源系統和ETL過程，但對於大型ETL項目，將源系統中的每個依賴項綁定到ETL系統的特定過程/組件可能是明智的。例如，如果您的ETL過程由許多存儲過程組成，那麼您希望元數據與每個源系統字段/ fileFormat/table /等關聯。到每個存儲過程。這將是多對多的關係，因爲許多存儲過程可能依賴於特定的字段，並且單個存儲過程可能依賴於許多源字段。這將由ETL開發人員手動更新，因爲他們創建或更新ETL系統時，他們有責任識別他們正在加載/清除/符合的字段，並隨後將該信息輸入到跟蹤這些依賴關係的元數據中。

如果您的ETL系統由除存儲過程之外的某些東西提供支持，或者存在某些組合，那麼您需要想出一些命名方案來引用這些組件。但是概念是一樣的，你把源字段/文件格式/等等聯繫起來。到ETL系統的組件。

這會給你提供足夠的信息來說明在某些方式下，在源系統中「Person.FirstName」發生了變化，那麼你可以編譯一個報告，顯示所有需要驗證的存儲過程，並經過測試以應對源系統的變化。

這種暗示知道Person.FirstName以某種方式更改，無論是大小，數據類型和/或完全刪除，都需要通過某個數據庫設計器手動通知更改並採取相應措施。如果您需要一個非常複雜的系統，那麼您需要在DDL上進行觸發器/審計，以更改您的源系統，以便您可以自動記錄並通知ETL架構師更改。

如果發生這種變化，您應該知道sp_Person_Load，sp_Person_Clean，sp_Person_Transform存儲過程都與Person.FirstName字段有一些交易，因爲這些存儲過程的作者指出在元數據記錄依賴關係中。

您可以使其更加複雜，其中sp_Person_Clean不依賴於Person.Firstname，但實際上取決於sp_Person_Load。這樣你就建立了一系列的依賴關係。這會使變更報告更加複雜，因爲您必須將依賴關係鏈接在一起以確定源系統更改的影響。而且，您還在構建複雜的依賴關係以及潛在的循環引用，這可能會使維護元數據與維護ETL過程本身一樣困難。如果ETL系統足夠簡單以至於ETL架構師可以根據源系統中的字段/文件/表定義依賴關係，那麼請保持簡單。

根據誰對數據倉庫，目標系統有權限，您可能需要跟蹤這些依賴關係。通常ETL開發人員也是數據倉庫開發人員。但是，如果其他人是數據倉庫設計人員，並且他們有權對數據倉庫進行更改，那麼您的ETL開發人員需要擁有一個類似的系統（無論是自動還是手動）來跟蹤並通知更改以及他們對ETL過程的影響。

真的，當我想到如何跟蹤變化時，我想到了權威的界限。如果ETL開發人員更改他的sp_Person_Clean過程，他不需要emtadata告訴他sp_Person_Transform需要更新/測試。他已經非常直觀地知道這一點。另一方面，如果第三方/供應商系統發生變化，或者同一組織內的業務部門更改電子表格或文件格式，那麼ETL開發人員不會制定這些內容。他不會像他自己的ETL系統和數據倉庫那樣擁有與源系統的親密關係。因此，他將從元數據中受益最多，該元數據顯示源系統的組件與ETL系統的組件相關。

決定你想要定義「組件」的粒度要取決於系統的設計方式以及開發者要記錄多少元數據。粒度過細，你淹沒在元數據中。當然，這就像是說「我的房子在佛羅里達州」，這對ETL開發人員的工作並沒有什麼幫助。如果整個ETL過程在單個SQL腳本中編碼，那麼您只有一個組件。因此，系統需要事先設計，因爲您需要能夠參考ETL過程的特定組件和/或步驟。

如果開發人員努力更新元數據，元數據將只會有用。有系統/工具包可以自動更新這種類型的元數據，但他們必須將您放入工具箱，以便工具可以分析依賴關係。我幾乎沒有信心這些系統非常可靠。通常你需要做一些非常黑客的事情，才能將數據從源系統以所需的格式傳輸到目的地，我可以想象一個依賴分析器無法理解依賴關係。例如，如果您使用的是由字符串形成的動態SQL，那麼該工具包無法確定依賴關係是什麼。

但是，我會說我從來沒有深入到很深入的工具，真正知道他們有多好。我總是得到這樣的觀點：我發現在SQL中通常很容易的事情在工具中非常麻煩，並且認爲它比它的價值更麻煩。我一直告訴自己，我會挑選像Talend一樣的東西，並在做出最終裁決之前真正成爲專家，但總有其他優先事項將我拉向其他方向。

Answer 2

在我的工作場所，我們有自制的ETL。我可以看到你提高眉毛:)。我們所描述的最小元數據描述如下。訂閱細節，審計，數據映射，運行順序。

訂閱詳情又分爲兩類，即購買數據的供應商和使用它的團隊/應用程序。ftp/http詳細信息，訪問憑證也被存儲。幸運的是，我們被要求絕對零SP，主要例外「身份生成器」。

審計詳細信息涉及，數據日期，上次修改時間，運行它的用戶，失敗/成功計數。數據映射表描述了保存數據的表格和列名稱。我們曾經有一個額外的組合鍵描述符表。然而，我們決定取消這一點。通過要求數據表所有者創建適當的分區策略來彌補性能損失。

運行順序表是我們用來確定用戶是否可以運行（Y/N）和運行順序的另一個表。

元數據也與歷史（基於日期）一起存儲。因此，如果有人決定運行存檔/歷史訂閱。運行將繼續。

以上使用：我們可以根據訂閱的重要性優先處理數據加載。我們可以在通用級別監控故障（鳥瞰）。我們可以編寫能夠創建動態SQL查詢的通用代碼（不需要硬編碼）。我們的加載和提取進程被迫使用數據映射表，所以沒有用戶可以擺脫陳舊的信息。

這似乎在我們的經驗迄今工作。