從Oracle收購sunopsis看ETL和ELT產品的趨勢

標籤：

從Oracle收購sunopsis看ETL和ELT產品的趨勢

日期：2008-6-17 來源：amteam    我要評論

 大 | 中 | 小

• 投稿
 
• 列印

 

導讀：本文主要從Oracle收購sunopsis分析ETL和ELT產品的趨勢以及說明ELT工具比ETL工具能夠處理大資料量效率更高的原因。

關鍵詞：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開發的，這方面和Oracle是一致的，也利於Oracle把其納入其未來的Fusion中介軟體中。

　　好了說了一些題外話，我們要切進今天的主題了"ETL和ELT之爭"，它更像是是一場下賭注。

　　一方是目前佔主流的ETL廠商用自己開發的資料引擎去完成Extract，Load，Transformation任務。而ELT廠商在把賭注壓在目前流行的RDBMS廠商上（也就是用它採用的各自的RDBMS的本地SQL語句和工具完成E，L，T這三個任務）。其實ELT廠商的思路和我們手工編寫完成ETL任務的思路是一致的。即都是充分利用源和目的RDBMS的功能來完成ETL任務。不過ELT工具把很多ETL工具的功能實現了（如中繼資料管理，可視化設計環境，Server Load Balancer，自動產生代碼，多個使用者協同開發，版本控制，CDC，緩慢變化維的處理等等。而且也支援自動產生ETL實現過程的代碼。

　　上個星期我和一個客戶交流，他就一直追問ELT工具到底怎麼實現ELT這個流程的每一個步驟。他說你把來源資料抽取到staging area後，然後再裝載到目的資料庫去完成轉換。不是和我用ETL工具把ETL工具裝載在目的端的效果不是一樣嗎？

　　我這裡要說的是ELT最早是由Sunopsis提出這個概念。但我們從它產品完成一個標準的ELT過程所產生的代碼看，它的轉換不僅發生在目的端，staging同樣發生在來源資料端。它的原則就是在那完成轉換最利於提高效率，那就在那裡進行轉換。我到覺得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工業的標準

從Oracle收購sunopsis看ETL和ELT產品的趨勢