Fullständig avslöjande:Eftersom den här artikeln är författad av ett ETL-centrerat företag med dess starka förmåga att manipulera big data utanför databaser, kommer det som följer inte att verka objektivt för många. Ändå är det fortfarande tänkt att ge en tankeställare och öppnar ordet för diskussion.
Sedan starten har datalagerarkitekter (DWA) haft i uppdrag att skapa och fylla i ett datalager med olika källor och formaterade data. På grund av den dramatiska tillväxten i datavolymer utmanas samma DWA:er att implementera sin dataintegration och iscensättningsverksamhet mer effektivt. Frågan om huruvida datatransformation kommer att ske inom eller utanför måldatabasen har blivit en kritisk fråga på grund av prestanda, bekvämlighet och ekonomiska konsekvenser.
I ETL-operationer (extrahera, transformera, ladda) extraheras data från olika källor, transformeras separat och laddas till en DW-databas och eventuellt andra mål. I ELT matas utdragen in i singelstagingdatabasen som också hanterar transformationerna.
ETL är fortfarande utbredd eftersom marknaden blomstrar med beprövade spelare som Informatica, IBM, Oracle — och IRI med Voracity, som kombinerar FACT (Fast Extract), CoSort- eller Hadoop-transformeringar och bulkladdning i samma Eclipse GUI — för att extrahera och transformera data. Det här tillvägagångssättet förhindrar att databaser som är designade för lagring och hämtning (frågeoptimering) belastas med omkostnader för storskalig datatransformation.
Men med utvecklingen av ny databasteknik och hårdvaruutrustning som Oracle Exadata som kan hantera transformationer "i en låda", kan ELT vara en praktisk lösning under vissa omständigheter. Och det finns specifika fördelar med att isolera iscensättnings- (belastning) och semantiska (transformera) skikt.
En nämnt fördel med ELT är isoleringen av belastningsprocessen från transformationsprocessen, eftersom det tar bort ett inneboende beroende mellan dessa steg.
Vi noterar att IRI:s ETL-metod isolerar dem ändå eftersom Voracity iscensätter data i filsystemet (eller HDFS). Alla databitar som är bundna till databasen kan erhållas, rensas och transformeras externt innan en (försorterad) laddning. Detta tar bort bördan av storskaliga transformationer från databasen (liksom BI/analytiska verktyg etc.).
Datavolymer och budgetar är ofta det som avgör om en DWA ska utveckla en ETL- eller ELT-lösning. I sin ITToolbox-bloggartikel "So What Is Better, ETL or ELT?", ponerar Vincent McBurney sina för- och nackdelar med båda tillvägagångssätten, vilket jag har upprepat här nedan, och sedan följde var och en med ett typiskt svar som IRI ETL -orienterade användare gör på punkt (enligt min ursprungliga subjektivitetsförbehåll):
Pros ETLNackdelar ETL
- ETL kan balansera arbetsbelastningen och dela arbetsbelastningen med RDBMS – och faktiskt ta bort den arbetsbelastningen genom att transformera data via SortCL-programmet eller Hadoop utan kodning i Voracity
- ETL kan utföra mer komplexa operationer i enstaka dataflödesdiagram via datakartor – som med Voracity-mappning och arbetsflödesdiagram som också abstraktar korta, öppna 4GL-skript kontra SQL
- ETL kan skalas med separat hårdvara – på råvaruboxar kan du köpa och underhålla själv till mycket lägre kostnader än apparater från en leverantör
- ETL kan hantera partitionering och parallellitet oberoende av datamodell, databaslayout och källdatamodellarkitektur – även om Voracitys CoSort SortCL-jobb behöver inte vara partitionerad alls ...
- ETL kan bearbeta data in-stream, eftersom den överförs från källa till mål – eller i batch om det är vettigt också
- ETL kräver inte samlokalisering av datamängder för att kunna utföra sitt arbete – så att du kan underhålla befintliga datakällplattformar utan bekymmer med datasynkronisering
- ETL fångar enorma mängder metadatalinje idag - hur bra eller intuitivt kan en iscensätta DB göra det?
- ETL kan köras på SMP- eller MPP-hårdvara – som du återigen kan hantera och utnyttja mer kostnadseffektivt och inte oroa dig för prestandastrider med DB
- ETL bearbetar information rad för rad och det verkar fungera bra med dataintegrering i tredjepartsprodukter – ännu bättre fullständiga block, tabeller eller fil(er) åt gången, som Voracity kör i volym.
Pros ELT
- Ytterligare hårdvaruinvestering krävs för ETL-motorer – såvida du inte kör den på databasservrarna
- Extra kostnad för att bygga ETL-system eller licensiera ETL-verktyg – som fortfarande är billigare jämfört med ELT-apparater, men fortfarande billigare är IRI-verktyg som Voracity som kombinerar Fast Extract (FACT) och CoSort för att snabba upp ETL utan sådan komplexitet
- Möjlig reducerad prestanda för radbaserad metod – rätt, och varför Voracitys förmåga att profilera, förvärva, transformera och mata ut data i större bitar är snabbare
- Specialiserade färdigheter och inlärningskurva som krävs för att implementera ETL-verktyget – om du inte använder ett ergonomiskt gränssnitt som Voracitys som ger flera jobbdesignalternativ i samma Eclipse IDE
- Minskad flexibilitet på grund av beroende av ETL-verktygsleverantör – Jag är inte säker på hur det har förbättrats genom att förlita mig på en enda ELT/apparatleverantör istället; är inte leverantörsoberoende nyckeln till flexibilitet och kostnadsbesparingar?
- Data måste färdas över ytterligare ett lager innan den landar i datamart – såvida inte mart bara var ytterligare en utdata från ETL-processen, typiskt för multi-target Voracity-operationer.
Nackdelar ELT
- ELT utnyttjar RDBMS-motorhårdvara för skalbarhet – men beskattar också DB-resurser avsedda för frågeoptimering. CoSort- och Hadoop-transformationer i Voracity utnyttjar linjära skalningsalgoritmer och uppgiftskonsolidering, inte minnet eller I/O-resurserna i DB
- ELT behåller all data i RDBMS hela tiden – vilket är bra så länge käll- och måldata finns i samma DB
- ELT är parallelliserat enligt datamängden, och disk I/O är vanligtvis optimerad på motornivå för snabbare genomströmning – ja, men det är ännu mer sant för externa transformationer som inte kämpar med DB-serverresurser
- ELT skalar så länge som hårdvaran och RDBMS-motorn kan fortsätta att skala – vilket kostar hur mycket i förhållande till alternativet ovan?
- ELT kan uppnå 3x till 4x genomströmningshastigheten på den lämpligt inställda MPP RDBMS-plattformen – vilket sätter enheten på Voracity-prestandanivåer även i förhållande till ETL-verktyg, men till 20 gånger kostnaden.
- ELT-transformation görs på RDBMS-servern när databasen är på målplattformen och den inte längre belastar nätverket – så det lägger stressen på databasen (användarna) istället?
- ELT har enkla transformationsspecifikationer via SQL – som inte är lika enkla, flexibla eller lika funktionsrika som CoSort SortCL-syntax eller dra-och-släpp-fältmappning i Voracitys Eclipse GUI.
- Begränsade verktyg tillgängliga med fullt stöd för ELT – och till mycket höga priser för DB-apparater med hög volymprestanda
- Förlust av detaljerad körtidsövervakningsstatistik och datalinje – särskilt analyser av metadatapåverkan på ändringar av olika fil-, tabell- eller ostrukturerade källor
- Förlust av modularitet på grund av uppsättningsbaserad design för prestanda – och förlusten av funktionalitet/flexibilitet som härrör från det
- Transformationer skulle använda databasresurser, vilket potentiellt skulle påverka BI-rapporteringsprestanda – för att inte tala om prestandan för frågeformulär och andra DB-operationer
Hybridarkitekturer som ETLT, TELT och till och med TETLT dyker sedan upp i ett försök att stödja svagheter i båda tillvägagångssätten. Men dessa tycks lägga till ytterligare nivåer av komplexitet till processer som redan är så fyllda. Det finns verkligen ingen silverkula, och många dataintegrationsprojekt misslyckas under tyngden av SLA, kostnadsöverskridanden och komplexitet.
Det är av dessa skäl som IRI byggde Voracity för att integrera data via CoSort SortCL-programmet i befintliga filsystem eller Hadoop-tyger utan omkodning. Voracity är den enda ETL-orienterade (men även ELT-stödjande) plattform som erbjuder båda alternativen för externa datatransformationer. Förutom överlägsen prisprestanda vid datarörelse och manipulation, inkluderar Voracity:
- avancerad datatransformation, datakvalitet, MDM och rapportering
- långsamt ändrande dimensioner, ändra datainsamling, datafederation
- dataprofilering, datamaskering, testdatagenerering och metadatahantering
- enkla 4GL-skript som du eller Eclipse-guider, diagram och dialogrutor skapar och hanterar
- sömlös utförande i Hadoop MR2, Spark, Spart Stream Storm och Tez
- stöd för erwin Smart Connectors (konvertering från andra ETL-verktyg)
- inbyggda MongoDB-drivrutiner och anslutningar till andra NoSQL-, Hadoop-, moln- och äldre källor
- inbäddade rapporter, statistik och prediktiva funktioner, KNIME- och Splunk-kopplingar och dataflöden för analytiska verktyg.
Se även:
- http://www.iri.com/blog/data-transformation2/etl-elt-iri-in-between
- http://www.iri.com/solutions/data-integration/etl
- http://www.iri.com/solutions/data-integration/elt
- http://www.iri.com/solutions/data-integration/implement