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　团队知识聚合器的需求

对于这个模块，我们需要了解以下需求：

• 是否需要业务术语。
• 需要限制可以添加到团队知识中的用户类型，即限制访问控制和添加团队知识所需的审批流程。
• 需要验证规则或元数据检查。
• 需要使用沿袭来传播团队知识（例如，如果一个表列用细节进行了注释，那么该列的后续派生也将被注释）。