我的任务是提供我们的数据仓库开发人员可能需要的元数据需求列表。
这不是业务元数据（漂亮的描述等），而是变更管理（也称为影响评估）、数据沿袭等所需的数据。
我看过这篇文章Meta Meta Data Data - Ralph Kimball但由于我不是第一个这样做的人，所以我把它扔给了 SO 社区。
实际的问题是：数据仓库开发人员需要哪些元数据来设计、开发和管理 ETL 例程中的变更？
PS：我试图保持答案平台不可知，但就上下文而言，这是一个带有 PL/SQL 和 Datastage 的 Oracle 数据库。
在我的工作场所，我们有自制的 ETL。我可以看到你扬起眉毛:)。我们拥有的最小元数据描述如下。订阅详细信息、审计、数据映射、运行顺序。
订阅详细信息再次分为两类，从其购买数据的供应商和使用它的团队/应用程序。ftp/http 详细信息、访问凭据也被存储。幸运的是，我们被要求绝对零 SP，主要例外是“身份生成器”。
审核详细信息包括数据日期、上次修改时间、运行它的用户、失败/成功计数。
数据映射表描述了保存数据的表和列名。我们曾经有一个额外的复合键描述符表。但是我们决定取消它。通过要求数据表所有者创建适当的分区策略来补偿性能损失。
Run_order 表 是我们拥有的另一个表，它确定用户是否可以运行 (Y/N) 以及运行发生的顺序。
元数据还与历史记录（基于日期）一起存储。因此，如果有人决定运行存档/历史订阅。跑步将继续进行。
上述用途：我们可以根据订阅的重要性对数据加载进行优先级排序。我们可以在通用级别（鸟瞰图）监控故障。我们可以编写可以创建动态 sql 查询的通用代码（无硬编码）。我们的加载和提取过程被迫使用数据映射表，因此任何用户都无法摆脱过时的信息。
到目前为止，这似乎在我们的经验中有效。
在最基本的层面上，您可以维护从源系统中提取的 tablename.fieldname 的列表。如果您从文件或其他非数据库源中提取，那么您可能会也可能无法将依赖项列出为字段级别的粒度。这样的元数据只会告诉您 If(source field/fileFormat/table changes) then（在 ETL 过程中可能需要一些更改）。我之所以说可能是因为某些更改可能足够小，以至于 ETL 流程不会被破坏，但仍应执行测试和数据分析，以确保它不会使 ETL 流程初始设计期间的任何假设无效。
虽然 ETL 开发人员可能非常熟悉源系统和 ETL 流程，但对于大型 ETL 项目，将源系统中的每个依赖项与 ETL 系统的特定流程/组件联系起来可能是明智的。例如，如果您的 ETL 流程由许多存储过程组成，那么您可能希望元数据关联每个源系统字段/fileFormat/table/etc。到每个存储过程。这将是多对多的关系，因为许多存储过程可能依赖于特定字段，而单个存储过程可能依赖于许多源字段。这将是 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 这样的东西并真正成为这方面的专家，但总是有其他优先事项将我拉向其他方向。