从管理软件角度看ETL开发
BIDW说白了，还是个企业管理软件系统，既然是管理软件，那么越是方便管理的软件和代码，且符合软件工程原理，才是优秀的代码。有人比较过ETL工具和人工编程的比较，其实ETL工具最大的优势就是管理，其他效率、编程速度都不见得有优势，而且有的工具熟悉的人还不是非常多，但大型项目几乎都还是放弃了人工代码而选择工具。
那么我们用ETL工具开发，能怎么最大限度用好ETL工具的管理作用呢？
个人觉得需要注意以下几点：
1. ETL需要以批量、复用为最大管理思想，忌讳对于某个具体过程单独处理某个策略，更忌讳hard coding。
2. 策略预先细分，然后将各个过程详细分类，各自归类管理，忌讳同样的策略和逻辑过于重复开发
3. 尽量在主逻辑ETL开发中少用或不用非工具手段，如存储过程、视图（除非这些数据库对象能被元数据管理工具管控起来），可以用存储过程、控制表等处理ETL策略类事务
4. 忌讳开发风格多变，比如Informatica开发的时候，一会过滤在SQL，一会在source filter过滤，统一科学的规范是管理的前提。
5. 忌讳草率测试，工具开发的软件系统相对稳定容易管理，所以一旦合格的测试通过后，软件价值要比普通手工代码大一些。测试需要符合软件工程思想，需要熟悉相关流程和ETL策略的人写test cases，而且非开发者本人，然后逐步测试，且三个环境都有检验通过，方可验收，不然有风险的代码对于工具来说风险更高，但处理好了，价值更大。
我想还有相当多的项目停留在仅仅想办法用工具去“实现”，并没有过多考虑整体和软件工程。这也是我最近老在技术论坛碰见有朋友发些奇怪的技术问题，其实这些问题在正规项目根本就不存在，是属于工具本质没认准，没用好而自己提出的“需求”。放眼整体系统，不要局限在个体过程的实现，才能有更大的突破。 这个帖的内容和我目前工作中的情况太切合了:emn23:
顶顶顶 同上，一样一样 有相当多的项目停留在仅仅想办法用工具去“实现”，并没有过多考虑整体和软件工程，同意 还有就是开发ETL，要实现某个功能，至少要有2种办法以选择，才能对ETL有较深刻的理解，对规范和管理也有很大的帮助。
比如要实现一个SQL里的not in的逻辑，如果使用informatica，在两个数据源在不同数据库的话，至少有2个方法，一是informatica自己的动态lookup功能，不过这个功能，如果数据量大就会有效率问题，但特点是开发方便。第二种就是先将两个数据源在工具中join，过滤为空的数据，就达到not in的逻辑了，而且这在所有工具都能使用。 学习了～～～
页:
[1]