关于非工具版的ETL元数据驱动的讨论解决方案

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

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

探讨

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


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

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

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

查看更多 下一篇