10月10日收到Oracle收購sunopsis的消息。開始覺得有些意外。仔細(xì)一考慮應(yīng)該在情理之中。
第一sunopsis采用ELT架構(gòu)換句話說也就是說Sunopsis用它采用的RDBMS的功能去完成ETL
工作，這應(yīng)該和oracle這樣的RDBMS廠商在ETL產(chǎn)品上采取的策略是一致的。

第二
Sunopsis采用開放的架構(gòu)不但能夠支持Oracle，幾乎所有的目前流行的RDBMS它都支持。
這點(diǎn)對(duì)于Oracle一直覬覦的非oracle平臺(tái)的數(shù)據(jù)倉庫解決方案，Sunopsis在ETL工具上是一個(gè)不可替代的產(chǎn)品。第三點(diǎn)
Sunopsis產(chǎn)品的重點(diǎn)在于EAI的應(yīng)用，這方面也是Oracle要涉足的。第四點(diǎn)也是一個(gè)重要之點(diǎn)就是Sunopsis是用java開發(fā)的，這方面和Or­acle是一致的，也利于Oracle把其納入其未來的Fusion中間件中。


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


一方是目前占主流的ETL廠商用自己開發(fā)的數(shù)據(jù)引擎去完成Extract
，Load，Transformation任務(wù)。而ELT廠商在把賭注壓在目前流行的RDBMS廠商上（也就是用它采用的各自的RDBMS的本地SQL語句和工­具完成
E，L，T這三個(gè)任務(wù)）。其實(shí)ELT廠商的思路和我們手工編寫完成ETL任務(wù)的思路是一致的。即都是充分利用源和目的RDBMS的功能來完成ETL任務(wù)。不過E­LT工具把很多ETL工具的功能實(shí)現(xiàn)了（如元數(shù)據(jù)管理，可視化設(shè)計(jì)環(huán)境，負(fù)載平衡， 自動(dòng)生成代碼 ，多個(gè)用戶協(xié)同開發(fā)，版本控制，CDC，緩慢變化維的處理等等。 而且也支持自動(dòng)生成ETL實(shí)現(xiàn)過程的代碼。


上個(gè)星期我和一個(gè)客戶交流，他就一直追問ELT工具到底怎么實(shí)現(xiàn)ELT這個(gè)流程的每一個(gè)步驟。他說你把源數(shù)據(jù)抽取到staging area后，然后再裝載到目的數(shù)據(jù)庫去完成轉(zhuǎn)換。不是和我用ETL工具把ETL工具裝載在目的端的效果不是一樣嗎？


我這里要說的是ELT最早是由Sunopsis提出這個(gè)概念。但我們從它產(chǎn)品完成一個(gè)標(biāo)準(zhǔn)的ELT過程所產(chǎn)生的代碼看，它的轉(zhuǎn)換不僅發(fā)生在目的端，stagin­g
同樣發(fā)生在源數(shù)據(jù)端。它的原則就是在那完成轉(zhuǎn)換最利于提高效率，那就在那里進(jìn)行轉(zhuǎn)換。我到覺得ELT更像是它提出的一個(gè)招牌性廣告語言。另一個(gè)原因也是因?yàn)槟康?amp;shy;端的RDBMS的功能比較強(qiáng)，從效率角度看比較多的T發(fā)生在目的端，它才把LT改了一個(gè)順序。這樣更能引起大家的注意吧了。


從本質(zhì)上說ELT之類的工具（像Sunopsis）。其實(shí)是一個(gè)手動(dòng)完成ETL任務(wù)的代碼×××。大家設(shè)想一下如果我們不采用ETL工具，而采用手寫完成一­個(gè)ETL任務(wù)。我們肯定不會(huì)把所有的轉(zhuǎn)換的工作都放在目的端。我們也會(huì)遵循效率優(yōu)先的原則，能在源端轉(zhuǎn)速度快轉(zhuǎn)換就在源端，如果源端不可以完成這個(gè)轉(zhuǎn)換，我們會(huì)­在staging area 或是目的端。


那有的讀者會(huì)問，說了半天ELT工具比ETL工具能夠處理大數(shù)據(jù)量效率更高的原因在那里？
答案在于ETL廠商開發(fā)的數(shù)據(jù)引擎的裝載和SQL語句和目前主流的RDBMS在裝載和本地SQL語句誰強(qiáng)的問題。ELT工具充分的利用了源和目的RDBMS­的本地SQL語句和相應(yīng)的工具。就像我們手寫代碼一樣。ELT效率更高的根本原因在于當(dāng)前RDBMS廠商的產(chǎn)品的功能和本地SQL語句太強(qiáng)大

了，而且這種強(qiáng)大隨著時(shí)間的推移還要繼續(xù)擴(kuò)大。它比九十年代中期RDBMS產(chǎn)品在數(shù)據(jù)裝入，轉(zhuǎn)換方面增強(qiáng)太多了。而當(dāng)前主流ETL工具都是在90年代就已經(jīng)開發(fā)­出來了，它們那個(gè)時(shí)代不得不自己開發(fā)出一個(gè)數(shù)據(jù)引擎，否則就不能完成數(shù)據(jù)倉庫級(jí)別的數(shù)據(jù)轉(zhuǎn)換，轉(zhuǎn)換任務(wù)。


其實(shí)癥結(jié)就在于那時(shí)的RDBMS廠商的產(chǎn)品在轉(zhuǎn)換，裝載方面的功能幾乎沒有。ETL廠商不自己開發(fā)一個(gè)數(shù)據(jù)引擎沒有別的指望。到了今天主流RDBMS廠商 （像 Oracle ，DB2，SQL Server）的轉(zhuǎn)換和裝載功能和其開發(fā)未來此類更強(qiáng)功能的實(shí)力已經(jīng)不容置疑了。那么大家還有誰會(huì)懷疑RDBMS將成為ETL工業(yè)的標(biāo)準(zhǔn)那？

轉(zhuǎn)載于:https://blog.51cto.com/replication/41882

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。