最近公司在做一个ODS的项目,同时完成元数据管理功能,如果是ETL工具的话,元数据自然是融入到ETL中来的,但是,如果没有ETL工具,我们的ETL,比如存储过程,是要跟元数据管理系统紧密耦合的吗? 所有的存储过程都通过元数据驱动,并通过元数据的映射配置屏蔽数据内部的变化,这样是不是有点太复杂了,的确元数据也很重要,很强大,但是对于大多数的ETL,每次都要通过存储过程访问元数据配置,然后动态生成ETL脚本,效率且不说,这样是不是也太复杂,跟元数据系统是紧密耦合啊,而且这个元数据系统是比较严格的3NF设计,访问起来特别费劲,经常为了查一个属性要关联很多表才能实现,这样基于元数据驱动的ETL真的可行吗?有没有这样做的?我觉得元数据只要能完全反应数据的本质,数据的关系,让ETL透明,让数据库对用户透明,就行了,真是ETL的脚本不用这么依赖元数据系统吗?做成通用的配置化的ETL,固然比较理想,但是真正实施出来的产品有那么好用吗?元数据管理能支持多样化且复杂的ETL处理吗?你们说呢,想听听大家的意见.
------解决方案--------------------
1. 文档中注明目标与源的对应关系
2. ETL尽量参数化，一定不要用硬编码
------解决方案--------------------
------解决方案--------------------
如楼主所说的那种元数据驱动的ETL过程，如果对小型的逻辑不复杂的DW估计还有可行性性，可是如果业务逻辑复杂点的就不好说了，估计是个失败的项目了。
不知道我理解的对不对啊，单针对元数据来说，如果能将ods或者dw的元数据分成不同的部分来管理，是不是会好点呢。例如，业务元数据要包含主题信息，业务逻辑描述信息和业务指标等。这部分可以开发几个页面来管理。ETL元数据就要包括源于目标表的结构信息，ETL字段映射信息，表关联信息，调度时间窗等。这部分可以写个文档，放在svn上，以方便进行版本控制。
O(∩_∩)O哈哈~闲聊啊