关于非工具版的ETL元数据驱动的讨论

最近公司在做一个ODS的项目,同时完成元数据管理功能,如果是ETL工具的话,元数据自然是融入到ETL中来的,但是,如果没有ETL工具,我们的ETL,比如存储过程,是要跟元数据管理系统紧密耦合的吗? 所有的存储过程都通过元数据驱动,并通过元数据的映射配置屏蔽数据内部的变化,这样是不是有点太复杂了,的确元数据也很重要,很强大,但是对于大多数的ETL,每次都要通过存储过程访问元数据配置,然后动态生成ETL脚本,效率且不说,这样是不是也太复杂,跟元数据系统是紧密耦合啊,而且这个元数据系统是比较严格的3NF设计,访问起来特别费劲,经常为了查一个属性要关联很多表才能实现,这样基于元数据驱动的ETL真的可行吗?有没有这样做的?我觉得元数据只要能完全反应数据的本质,数据的关系,让ETL透明,让数据库对用户透明,就行了,真是ETL的脚本不用这么依赖元数据系统吗?做成通用的配置化的ETL,固然比较理想,但是真正实施出来的产品有那么好用吗?元数据管理能支持多样化且复杂的ETL处理吗?你们说呢,想听听大家的意见.

8 个解决方案

#1

1. 文档中注明目标与源的对应关系
2. ETL尽量参数化，一定不要用硬编码

#2

引用 1 楼 innovate911 的回复:

1. 文档中注明目标与源的对应关系
2. ETL尽量参数化，一定不要用硬编码

1.目标和源的对应关系,在元数据里的确是有配置的.
2.你说的不用硬编码是说通过元数据配置生成通用的ETL,以后只要通过配置维护就行了是吧.
这样的ETL以后的可用性如何,觉得对复杂的ETL,紧靠元数据配置会不会显得太繁琐,不如直接写ETL来得快,另外,当这个元数据变得很庞大,如果不熟悉这个元平台的话,岂不是连ETL也做不了了?

#3

说一说嘛

#4

你用的是什么工具？

#5

引用 2 楼 a120852620 的回复:

引用 1 楼 innovate911 的回复:
1. 文档中注明目标与源的对应关系
2. ETL尽量参数化，一定不要用硬编码


1.目标和源的对应关系,在元数据里的确是有配置的.
2.你说的不用硬编码是说通过元数据配置生成通用的ETL,以后只要通过配置维护就行了是吧.
这样的ETL以后的可用性如何,觉得对复杂的ETL,紧靠元数据配置会不会显得太繁琐,不如直接写ETL来得快,另外,当……

从你的描述中你们应该关注的是技术元数据，也就是需要监控你的ETL过程，比如你说的PROCEDURE层级吧，这些PROCEDULE的名称和作用维度表，PROCEDULE的SHCEDULE维度表，PROCEDULE的运行事实表就可以构成PROCEDURE这个层级的一个元数据主题域，如果再详细的话，可以根据表级，字段级来见对应的元数据管理模型，实现更细粒度的技术元数据管理，呵呵

#6

DATASTAGE .good !

#7

如楼主所说的那种元数据驱动的ETL过程，如果对小型的逻辑不复杂的DW估计还有可行性性，可是如果业务逻辑复杂点的就不好说了，估计是个失败的项目了。
不知道我理解的对不对啊，单针对元数据来说，如果能将ods或者dw的元数据分成不同的部分来管理，是不是会好点呢。例如，业务元数据要包含主题信息，业务逻辑描述信息和业务指标等。这部分可以开发几个页面来管理。ETL元数据就要包括源于目标表的结构信息，ETL字段映射信息，表关联信息，调度时间窗等。这部分可以写个文档，放在svn上，以方便进行版本控制。

O(∩_∩)O哈哈~闲聊啊

#8

我想问下，如果要做这个测试，该怎么入手呀。我是一名测试人家，最近要测这种东西，BI的数据抽取，工具是informatic ，可是我不懂这个工具，不知道从何处下手，请多多指点，谢谢。 QQ：419549883