数据仓库项目应该如何选择ETL工具：ETL or E-LT?，
根据以往数据仓库项目的经验，在一个数据仓库项目中，ETL设计和实施的工作量一般要占总项目工作量的40%-60%，而且数据仓库项目一般会存在二次需求的问题，客户在项目的实施过程中或者使用过程中会提出新的业务需求，而任何前端业务模型的改变都会涉及到ETL设计，因此ETL工具的选择对于整个数据仓库项目的成功是非常重要的。Oracle在收购Sunopsis后宣称自己的ETL工具是基于EL-T架构的，很多同行都在问：ETL到底和ET-L有什么区别？<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
本人认为，要了解传统的ETL架构和EL-T架构的区别，首先应该清楚选择一个好的数据清洗转化加载工具应该考虑哪几个方面：
1. 工具的图形化设计、维护方面：在ETL中，其实最关键的是T(transform)，而这一部分也是随着需求的变更经常变化的，因此对其中的业务逻辑进行维护非常关键，ETL工具必须提供非常简单易用的维护界面来定义和维护这种变化，同时能提供相关元数据管理，以便于将来对整个ETL过程进行维护和监控。在这一方面，原来基于传统ETL架构的厂商象Ascentia,Informatica都比较早地提供了一个相对比较傻瓜型的IDE环境，非常适合入门级用户。而Teradata早期的automation采用EL-T架构，所有的东西就是一大堆基于操作系统的SHELL脚本，使用起来难度比较大，比较适合专业级用户，直到Sunopsis的出现，基于EL-T架构的IDE环境才能和datastage以及powercenter有一拼，目前基于EL-T架构的数据清洗转化加载工具，如Oracle OWB(oracle warehouse builder),ODI都能提供非常强大的IDE设计界面，丝毫不逊色于以前传统ETL架构的工具。以前在做一个数据仓库项目时，由于时间紧，客户预算有限，就决定直接使用PL/SQL进行数据的转换，当时一个人一晚上能写30个存储过程来做ETL，觉得效率非常高，特有成就感，但后来随着项目的向前推进，用PL/SQL实现的ETL需要经常改动,而当时在原厂商的我已经将工作移交给集成商，回北京了，结果是在接下来的半年里，经常接到SI的骚扰电话，询问ETL部分的业务逻辑和实现思路。真是后悔当时没找一个直观的设计工具。
2. 系统的效率：数据仓库的数据抽取、转化、加载一般都是批量进行，系统一般会为整个ETL过程预留一个时间窗口（大部分是在晚上）。如果用户每天产生的数据量非常大，那么整个ETL的设计就非常关键，因为整个过程必须在预留的时间窗口内完成。传统的ETL架构和EL-T架构的主要区别也在这里。我们先看ETL架构的实现机制：
在 传统的ETL架构中，数据的流向是从源数据流到ETL工具，ETL工具是一个单独的数据处理引擎，一般会在单独的硬件服务器上，实现所有数据转化的工作，然后将数据加载到目标数据仓库中，如果要增加整个ETL过程的效率，则只能增强ETL工具服务器的配置，优化系统处理流程（一般可调的东西非常少），IBM的datastage和Informatica的powercenter原来都是采用的这种架构。
EL-T的实现机制，如下图：
在EL-T架构中，EL-T工具只负责提供图形化的界面来设计业务规则，数据的整个加工过程都在目标和源的数据库之间流动，EL-T工具只是负责协调相关的数据库系统来执行相关的应用，数据加工过程既可以在源数据库端执行，也可以在目标数据仓库端执行（主要取决于系统的架构设计和数据属性）。当ETL过程需要提高效率，则可以通过对相关数据库进行调优，或者改变执行加工的服务器就可以达到。一般数据库厂商会力推该中架构，象Oracle和Teradata都极力宣传EL-T架构。
其实有关ETL和EL-T的架构之争在2006年就已经开始了，当时的Teradata极力宣传EL-T架构，Informatica和Acential最终也开始采用各种方式来支持EL-T架构，有一位Teradata的写手在其网站上对EL-T架构和传统ETL架构的优势和劣势进行了分析：
EL-T架构的优势：
* EL-T主要通过数据库引擎来实现系统的可扩展性（尤其是当数据加工过程在晚上时，可以充分利用数据库引擎的资源）
* EL-T可以保持所有的数据始终在数据库当中，避免数据的加载和导出，从而保证效率，提高系统的可监控性。
* EL-T可以根据数据的分布情况进行并行处理优化，并可以利用数据库的固有功能优化磁盘I/O.
* EL-T的可扩展性取决于数据库引擎和其硬件服务器的可扩展性。
*通过对相关数据库进行性能调优，ETL过程获得3到4倍的效率提升一般不是特别困难。
EL-T架构的问题
* EL-T没有单独的硬件服务器，一切依赖于数据库
* EL-T有可能会和数据库上其它应用争用硬件资源
* EL-T只能在数据库中对数据进行加工，不能同时从多种数据源实现加工
* EL-T由于依赖数据库存储大量临时表，会增加数据库系统的存储容量。
ETL架构的优势：
* ETL可以分担数据库系统的负载（采用单独的硬件服务器）
* ETL相对于EL-T架构可以实现更为复杂的数据转化逻辑
* ETL采用单独的硬件服务器。.
* ETL与底层的数据库数据存储无关。
ETL架构的问题
* ETL为了提高扩展性，需要单独的强有力的硬件服务器支撑.
*传统的ETL架构对数据的处理都是一行一行进行的，从实现机制上就决定了它不能象数据库那样成批对数据进行并行处理。
* ETL是单独的独立于数据库的数据加工引擎，和擅长于数据库处理的数据库引擎而言，必然在可扩展性和效率上稍逊一筹。
l ETL如果需要达到和EL-T架构一样的性能，一般需要两倍于EL-T架构的硬件配置。（内存和CPU）.