我的任务是提供我们的数据仓库开发人员可能需要的元数据要求列表。
这不是业务元数据(很好的描述等),而是变更管理(也称为影响评估)、数据沿袭等所需的数据。
我看过这篇文章Meta Meta Data Data - Ralph Kimball但由于我不是第一个这样做的人,所以我把它扔给了 SO 社区。p>
实际的问题是: 数据仓库开发人员需要哪些元数据来设计、开发和管理 ETL 例程中的变更?
PS:我试图让答案与平台无关,但就上下文而言,这是一个带有 PL/SQL 和 Datastage 的 Oracle 数据库。
最佳答案
在我的工作场所,我们有自制的 ETL。我可以看到你扬起眉毛 :)。我们拥有的最小元数据描述如下。订阅详细信息、审核、数据映射、运行顺序。
订阅详细信息再次分为两类,即购买数据的供应商和使用数据的团队/应用程序。还存储了 ftp/http 详细信息、访问凭据。幸运的是,我们被要求拥有绝对零的 SP,主要异常“身份生成器”。
审计细节包括数据日期、最后修改时间、运行它的用户、失败/成功计数。
Data-mapping table 描述了保存数据的表和列名。我们曾经有一个额外的复合键描述符表。但是我们决定取消它。通过要求数据表所有者创建适当的分区策略来补偿性能损失。
Run_order 表 是我们拥有的另一个表,用于确定用户是否可以运行 (Y/N) 以及运行的顺序。
元数据也与历史记录一起存储(基于日期)。因此,如果有人决定运行存档/历史订阅。运行将继续进行。
上述用途:我们可以根据订阅的重要性对数据加载进行优先排序。我们可以在通用级别(鸟瞰图)监控故障。我们可以编写可以创建动态 sql 查询的通用代码(无硬编码)。我们的加载和提取过程被迫使用数据映射表,因此任何用户都无法摆脱陈旧的信息。
根据我们的经验,到目前为止这似乎有效。
关于database - 开发人员的元数据要求,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2545581/