从Oracle收购sunopsis看ETL和ELT产品的趋势

10月10日收到Oracle收购sunopsis的消息。开始觉得有些意外。仔细一考虑应该在情理之中。
第一sunopsis采用ELT架构换句话说也就是说Sunopsis用它采用的RDBMS的功能去完成ETL
工作，这应该和oracle这样的RDBMS厂商在ETL产品上采取的策略是一致的。

第二
Sunopsis采用开放的架构不但能够支持Oracle，几乎所有的目前流行的RDBMS它都支持。
这点对于Oracle一直觊觎的非oracle平台的数据仓库解决方案，Sunopsis在ETL工具上是一个不可替代的产品。第三点
Sunopsis产品的重点在于EAI的应用，这方面也是Oracle要涉足的。第四点也是一个重要之点就是Sunopsis是用java开发的，这方面和Or­acle是一致的，也利于Oracle把其纳入其未来的Fusion中间件中。


好了说了一些题外话，我们要切进今天的主题了"ETL和ELT之争"，它更像是是一场下赌注。


一方是目前占主流的ETL厂商用自己开发的数据引擎去完成Extract
，Load，Transformation任务。而ELT厂商在把赌注压在目前流行的RDBMS厂商上（也就是用它采用的各自的RDBMS的本地SQL语句和工­具完成
E，L，T这三个任务）。其实ELT厂商的思路和我们手工编写完成ETL任务的思路是一致的。即都是充分利用源和目的RDBMS的功能来完成ETL任务。不过E­LT工具把很多ETL工具的功能实现了（如元数据管理，可视化设计环境，负载平衡， 自动生成代码 ，多个用户协同开发，版本控制，CDC，缓慢变化维的处理等等。 而且也支持自动生成ETL实现过程的代码。


上个星期我和一个客户交流，他就一直追问ELT工具到底怎么实现ELT这个流程的每一个步骤。他说你把源数据抽取到staging area后，然后再装载到目的数据库去完成转换。不是和我用ETL工具把ETL工具装载在目的端的效果不是一样吗？


我这里要说的是ELT最早是由Sunopsis提出这个概念。但我们从它产品完成一个标准的ELT过程所产生的代码看，它的转换不仅发生在目的端，stagin­g
同样发生在源数据端。它的原则就是在那完成转换最利于提高效率，那就在那里进行转换。我到觉得ELT更像是它提出的一个招牌性广告语言。另一个原因也是因为目的­端的RDBMS的功能比较强，从效率角度看比较多的T发生在目的端，它才把LT改了一个顺序。这样更能引起大家的注意吧了。


从本质上说ELT之类的工具（像Sunopsis）。其实是一个手动完成ETL任务的代码自动生成器。大家设想一下如果我们不采用ETL工具，而采用手写完成一­个ETL任务。我们肯定不会把所有的转换的工作都放在目的端。我们也会遵循效率优先的原则，能在源端转速度快转换就在源端，如果源端不可以完成这个转换，我们会­在staging area 或是目的端。


那有的读者会问，说了半天ELT工具比ETL工具能够处理大数据量效率更高的原因在那里？
答案在于ETL厂商开发的数据引擎的装载和SQL语句和目前主流的RDBMS在装载和本地SQL语句谁强的问题。ELT工具充分的利用了源和目的RDBMS­的本地SQL语句和相应的工具。就像我们手写代码一样。ELT效率更高的根本原因在于当前RDBMS厂商的产品的功能和本地SQL语句太强大

了，而且这种强大随着时间的推移还要继续扩大。它比九十年代中期RDBMS产品在数据装入，转换方面增强太多了。而当前主流ETL工具都是在90年代就已经开发­出来了，它们那个时代不得不自己开发出一个数据引擎，否则就不能完成数据仓库级别的数据转换，转换任务。


其实症结就在于那时的RDBMS厂商的产品在转换，装载方面的功能几乎没有。ETL厂商不自己开发一个数据引擎没有别的指望。到了今天主流RDBMS厂商 （像 Oracle ，DB2，SQL Server）的转换和装载功能和其开发未来此类更强功能的实力已经不容置疑了。那么大家还有谁会怀疑RDBMS将成为ETL工业的标准那？