ETL架构是否可标准化？

esestt

原帖由 innovate511 于 2009-6-1 12:43 发表
我在另一个帖子提到过
“现有的ETL工具都支持多种手段实现ETL，而更易维护、更易快速复制开发的手段则必须有一个统一的规范。就像去年我放开团队去开发ETL，结果即便总体规范和思路统一，但实际具体到逐个的mapping，以及session设置、workflow调度，都有很多明显差异，导致后期较难维护。

工具给的规范都是泛泛的，我这里说的标准，可能需要详细到某个细节该怎么处理。如汇总，按照工具的特性，就是在mapping里需要先sort再agg，处理mapping之前的事务，就只能调用统一开发的SP，而不能在session里pre sql里写SQL！这些细节必须规范，而工具的规范不会这么细，而作为团队的大批量开发，你必须细到这个程度，形成标准！！”

你这个明显是informatica的思路。ETL过程中确实每个人有自己的设计习惯，思路上的不统一造成了逻辑的可理解性和维护比较麻烦。Informatica的mapping、session、workflow的这种设计很多时候是把简单的问题复杂化了。
你可以尝试一下其他的ETL工具。

esestt

原帖由 vikiv 于 2009-6-2 21:38 发表
感觉etl没什么技术难度，主要还是规则，还有后期的维护，比较头疼啊

确实，ETL很多时候就是体力活。而且有些时候是整个项目中风险最高的，之前一个项目居然要从eMail的图表中读数据；还有只提供XML的接口的数据源，连标准的WSDL都没有；还有从一个网页上扣一个数值的要求……
这种情况就没有什么规范不规范的了

Frameworker

拜读中..........

whaisheng

學習

vikiv

原帖由 esestt 于 2009-6-15 13:06 发表



我只是针对他说要逻辑标准化的说法，用informatica只是举例子而已，例子而已。
用这类工具团队开发，确实要事先要在团队成员之间做一些约定，但每个人的设计风格还是很难标准化的。这就造成了项目交接、维护、设计的可读性、可理解性很差。
如果你再要抽象，是否还需要用powerdesigner或visio这种工具画流程图呢？
informatica只适合10人以上的团队，项目成员各司其职，manager的负责deployment和validate，至于每个mapping具体的实现形式就不要管太多了。

所以我建议根据项目的规模选择不同的实现途径，比如直接用存储过程反而更好理解、调试、管理，只要事先约定SP的名称即可，不用过多讨论标准化的问题。
或者是使用简便的ETL工具，像ODI这种。这样的话，项目管理会更轻松、效率更高。

没觉得odi简便，感觉很不好用

w122271282

学习中。。。

wolfheat

Informatica的PowerCenter之所以能成为业界领头的工具，说明他在设计上确实有其优秀之处。在使用工具之前，我要求项目实施团队提交的设计文档包括基于RLOAP模型设计文档，源、目标的映射关系，这些映射执行的工作流。这些文档很容易就能在Informatica中找到对应的对象。使用了此工具，使设计与开发实现了一体化。
IBM的DataStage虽然没有非常强调制ETL JOB制作过程，他采用一种先布局后实现的方式，先将多个映射、Lookup、筛选放入一个流程中，然后再逐步实现这个流程中每个部件实际内容。当你最后做完一个JOB后，回头去看仍然是mapping与各个mapping运行的顺序问题。
ODI，BODI，PowExchange，DataMirror等这类工具，我个人更看重他基于数据库日志的CDC功能。用这类工具构建ODS，或者实现应用层的数据镜像，对于剥离系统的业务操作和分析查询有着非常巨大的作用。
作为数据仓库的用户，我们要理解数据仓库的构建是不断变化持续发展的。业务系统变化，ODS，DW，DM都要跟着变。供应商倒了，或者供应商人员变动了，都会导致服务质量下降。所以使用好的ETL工具对数据仓库的持续发展有着非常重要的作用。

wolfheat

原帖由 esestt 于 2009-6-15 13:06 发表



我只是针对他说要逻辑标准化的说法，用informatica只是举例子而已，例子而已。
用这类工具团队开发，确实要事先要在团队成员之间做一些约定，但每个人的设计风格还是很难标准化的。这就造成了项目交接、维护、设计的可读性、可理解性很差。
如果你再要抽象，是否还需要用powerdesigner或visio这种工具画流程图呢？
informatica只适合10人以上的团队，项目成员各司其职，manager的负责deployment和validate，至于每个mapping具体的实现形式就不要管太多了。

所以我建议根据项目的规模选择不同的实现途径，比如直接用存储过程反而更好理解、调试、管理，只要事先约定SP的名称即可，不用过多讨论标准化的问题。
或者是使用简便的ETL工具，像ODI这种。这样的话，项目管理会更轻松、效率更高。

我想您应该属于BI实施供应商吧。我在做BI供应商的时候也是坚决拥护代码方式，因为用了工具结果就是减少我的团队收入，增加了产品采购费用。我反对用PLSQL或者其他代码方式实现ETL，主要因为当你维护一个6年7年的数据仓库后，你会发现面对海量级别的存储过程是多么的无奈。一切的项目在交付的时候是最清晰的，但是如何保证运行维护了6 7年之后文档与代码还能保持一致性，供应商开发人员变动后还能保持维护质量。SP的注释永远是对的，但是其内部产生的错误，你找一个其他人去理解作者的思路是非常困难的。

我的理解与您恰恰相反，Informatica并不是一个适合10人以上的团队，它最大的作用就是简化开发，很多地方体现出设计完成即完工的思想。一个原来需要3-5人完成的ETL模块开发项目，使用了工具我只需要1-2人配置工具。工具中的对象逆向导出的文档也能保持与实际流程的一致性。

penghaijun

呵呵，学习了，谢谢innovate511 。

DataStager

非常感谢楼主共享