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工業的標準那？

轉載于:https://blog.51cto.com/replication/41882

總結

以上是生活随笔為你收集整理的从Oracle收购sunopsis看ETL和ELT产品的趋势的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。