开发人员的元数据要求

在最基本的级别上,您可以维护从源系统中提取的tablename.fieldname的列表。如果是从文件或其他非数据库源中提取,则可能无法列出与字段级别一样细粒度的依赖项。这样的元数据只会告诉您如果(源字段/文件格式/表更改)那么(某些更改 可以 在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 pr的影响。奥克斯。

真的,当我想到应该如何跟踪变化时,我想到了权力的界限。如果etl开发人员更改了sp_person_clean过程,则不需要emtadata告诉他sp_person_transform将需要更新/测试。他已经很直观地知道了这一点。另一方面,如果第三方/供应商系统更改,或者同一组织内的业务部门更改电子表格或文件格式,则这些都不是etl开发人员制定的。他不会像对待自己的etl系统和数据仓库那样,与源系统有同样程度的亲密关系。因此,他将从元数据中受益匪浅,元数据显示了源系统的组件如何与etl系统的组件相关。

决定您想要定义“组件”的粒度实际上取决于系统的设计方式,以及您希望开发人员记录多少元数据。太细了,就会淹没在元数据中。当然,这就像说“我的房子在佛罗里达”,这并不能真正帮助etl开发人员的工作。如果整个etl过程是在一个sql脚本中编码的,那么您只有一个组件。因此,系统需要预先设计,知道您需要能够引用etl过程的特定组件和/或步骤。

只有当开发人员努力更新元数据时,元数据才是好的。有一些系统/工具包可以自动更新此类元数据,但它们必须将您放入它们的工具包中,以便该工具可以分析依赖关系。我不太相信这些系统是非常可靠的。有时候,你必须做一些真正的黑客操作,才能以所需的格式将数据从源系统获取到目的地,我可以想象依赖项分析器无法理解依赖项。例如,如果您使用的是由字符串构成的动态sql,那么工具箱就无法真正找出依赖关系是什么。

不过,我要说的是,我从来没有深入研究过这些工具,以真正了解它们有多好。我一直认为,我发现在sql中通常很容易的事情在这个工具中非常麻烦,并认为这比它的价值更麻烦。我一直告诉自己,我会选择像塔伦德这样的东西,并真正成为一个专家,在我作出最后的决定之前,但总是有其他优先事项把我拉向其他方向。

在我的工作场所,我们有自制etl。我可以看到你扬起眉头:)。我们描述的最小元数据如下。订阅详细信息、审核、数据映射、运行顺序。

这个 订阅详细信息 再次分为两类:购买数据的供应商和使用数据的团队/应用程序。还存储ftp/http详细信息、访问凭据。幸运的是,我们被要求拥有绝对零的sps,主要的例外是“身份生成器”。

审核详细信息 包括,数据日期,上次修改时间,运行它的用户,失败/成功计数。

数据映射表 描述保存数据的表和列名。我们以前有一个额外的组合键描述符表。不过,我们决定不再那样做了。通过要求数据表所有者创建适当的分区策略来补偿性能损失。

运行顺序表 是另一个表,用于确定用户是否可以运行(y/n)以及运行的顺序。

元数据还与历史记录(基于日期)一起存储。因此,如果有人决定运行存档/历史订阅。跑步会继续的。

上述用途 :我们可以根据订阅的重要性来确定数据加载的优先级。我们可以在一般级别(鸟瞰图)监控故障。我们可以编写能够创建动态sql查询的通用代码(无硬编码)。我们的加载和提取过程被迫使用数据映射表,因此任何用户都无法摆脱陈旧的信息。

从我们的经验来看,这似乎是有效的。