2.3　定義需求

元數據目錄服務能夠提供元數據的一站式服務，并且該服務是事后的，即在各種管道創建或更新數據集之后收集元數據，而不影響數據集所有者或用戶。元數據目錄服務在后臺以非侵入的方式收集有關數據集及其使用情況的元數據。與傳統的企業數據管理（EDM）相比，事后方式（post-hoc）不需要對數據集進行前期管理。

該服務有兩個接口：

• 一個Web門戶，用于支持導航、搜索、沿襲可視化、注釋、討論和社區參與。
• 一個API終端，提供統一的REST接口，以訪問各種數據存儲的元數據。

構建目錄服務需要三個關鍵模塊：

技術元數據提取器

專注于連接數據源，提取與數據集相關的基本元數據。

操作元數據提取器

在數據轉換中跨系統縫合元數據，創建一個端到端（E2E）視圖。

團隊知識聚合器

允許用戶對數據集相關的信息進行注釋，從而實現整個數據團隊的知識擴展。

2.3.1　提取技術元數據的需求

需求的第一部分是了解提取技術元數據所需的技術清單。目標是確保使用合適的方式來提取元數據，并正確表示數據模型。所涉及的系統列表可以分為以下幾類（如圖2-4所示）：調度器（如Airflow、Oozie和Azkaban）、查詢引擎（如Hive、Spark和Flink），以及關系型數據存儲和NoSQL數據存儲（如Cassandra、Druid和MySQL）。

需求的另一部分是元數據的版本支持——跟蹤元數據的版本與最新版本的差異。例如，包括跟蹤特定列的元數據變化，或者跟蹤表大小隨時間變化的趨勢。能夠查詢元數據在過去的某個時間點是什么樣子，這不僅對于審計和調試很重要，對于重新處理和回滾用例也很有用。作為這個需求的一部分，了解需要持久化的歷史記錄數量，以及訪問API來查詢快照的歷史記錄很重要。

2.3.2　操作技術元數據的需求

為了提取處理作業的數據沿襲信息，需要解析查詢以提取源表和目標表。需求分析包括獲取所有數據存儲和查詢引擎（包括流處理和批處理）的查詢類型清單，包括UDF。目標是找到支持這些查詢的合適的查詢解析器。

這些需求的另一部分與數據分析統計相關——監控、SLA告警和異常跟蹤。特別地，需要明確是否需要支持：a）數據集的可用性告警；b）作為數據質量指示的元數據的異常跟蹤；c）管道執行的SLA告警。

2.3.3　團隊知識聚合器的需求

對于這個模塊，我們需要了解以下需求：

• 是否需要業務術語。
• 需要限制可以添加到團隊知識中的用戶類型，即限制訪問控制和添加團隊知識所需的審批流程。
• 需要驗證規則或元數據檢查。
• 需要使用沿襲來傳播團隊知識（例如，如果一個表列用細節進行了注釋，那么該列的后續派生也將被注釋）。