阅读<DataStage 企业版产品白皮书> 有感!

 

通常认为ETL 就是数据抽取, 转换, 加载的过程, 完全正确. 就像数据库就是存储和管理数据的工具一样, 然而数据库并不全部是数据的存储, 最重要的是管理, 即数据的并发性一致性可恢复性管理, 包括一系列的进程和内存的管理等等.ETL 工具本身也是同样的问题. 如果只是抽取转换加载, 相信通过PowerBuilder 的数据管道技术并加以封装或者一系列的语言工具编码可以做到, 并非很难的事情. 之所以思考, 是因为阅读了一下<DataStage 企业版产品白皮书>, 当然也只是粗略的看了一下, 其实所有成熟的ETL 工具都是相类似的, 都是在相互借鉴中不断的完善的结果.

简单的总结一下:

Ø 元数据管理, 不管通过DBMS 进行存储也好, 通过XML 或者自己的管理系统也好. 元数据的管理是必须的, 提供了一个可视化的数据字典.

Ø 和配置工具的集成, 或者内置一个配置库管理工具.

Ø 项目化管理和集成环境, 统一对系统内的工作流和任务进行管理

Ø 任务包中都包含源数据, 目标数据的管理, 其中也包括关系数据库, 平面文件,XML 文件,WebService,COBOL 等文件的管理

Ø 任务包中提供了一系列的排序, 转换, 合并, 连接, 过滤, 聚合, 查找表, 复制, 分裂, 条件分割等等一些通用的数据转换.

Ø 数据流架构和流水线即工作流管理, 几乎所有的ETL 工具都是根据时序进行任务流的处理, 这也符合数据仓库的过程化处理要求. 其中包括错误处理方式, 错误报表, 并行处理, 时序等待等等.

Ø 可伸缩硬件环境支持, 最大限度的利用硬件的支持.

Ø 并行支持, 发挥DBMS 的优势, 或者通过内置的内存管理进行处理.

 

不过我有些怀疑ETL 的功效, 据权威人士统计80% 的时间和IO 消耗是集中在ETL 的抽取和加载环节, 而抽取和加载的速度是由DBMS 或者其他数据源所决定的, 也就是说无论怎么优化,ETL 工具的优化也只有20% 的余地. 有个玩笑:ETL 工具执行的效率肯定比不上最好的程序员写的代码的效率, 但是起码要比最差的程序员写的代码要强.

也许ETL 工具本身就是一个管理的平台, 它的意义在于屏蔽底层编码的细节和异构数据源, 通过图形化的方式实现数据流程的调度, 从而提供开发和管理上的效率, 而并非程序执行效率.