Fuld afsløring:Da denne artikel er forfattet af et ETL-centreret firma med dens stærke egenskaber i at manipulere big data uden for databaser, vil det følgende ikke virke objektivt for mange. Ikke desto mindre er det stadig meningen, at det skal give stof til eftertanke og åbner ordet for diskussion.
Siden deres begyndelse har datavarehusarkitekter (DWA) haft til opgave at skabe og udfylde et datavarehus med forskelligt kildede og formaterede data. På grund af den dramatiske vækst i datamængder er de samme DWA'er udfordret til at implementere deres dataintegration og iscenesættelsesoperationer mere effektivt. Spørgsmålet om, hvorvidt datatransformation vil finde sted i eller uden for måldatabasen, er blevet et kritisk spørgsmål på grund af ydeevne, bekvemmelighed og økonomiske konsekvenser.
I ETL-operationer (extract, transform, load) udtrækkes data fra forskellige kilder, transformeres separat og indlæses til en DW-database og muligvis andre mål. I ELT føres uddragene ind i single-staging-databasen, der også håndterer transformationerne.
ETL forbliver udbredt, fordi markedspladsen blomstrer med gennemprøvede spillere som Informatica, IBM, Oracle — og IRI med Voracity, som kombinerer FACT (Fast Extract), CoSort- eller Hadoop-transformationer og masseindlæsning i den samme Eclipse GUI — for at udtrække og transformere data. Denne tilgang forhindrer belastende databaser, der er designet til lagring og genfinding (forespørgselsoptimering) med omkostningerne ved storskala datatransformation.
Men med udviklingen af ny databaseteknologi og hardwareapparater som Oracle Exadata, der kan håndtere transformationer 'i en boks', kan ELT være en praktisk løsning under visse omstændigheder. Og der er specifikke fordele ved at isolere iscenesættelses- (belastning) og semantiske (transformere) lag.
En nævnt fordel ved ELT er isoleringen af belastningsprocessen fra transformationsprocessen, da den fjerner en iboende afhængighed mellem disse stadier.
Vi bemærker, at IRIs ETL-tilgang isolerer dem alligevel, fordi Voracity iscenesætter data i filsystemet (eller HDFS). Enhver datadel, der er bundet til databasen, kan erhverves, renses og transformeres eksternt før en (forudsorteret) belastning. Dette fjerner byrden af store transformationer fra databasen (såvel som BI/analytiske værktøjer osv.).
Datamængder og budgetter er ofte det, der afgør, om en DWA skal udvikle en ETL- eller ELT-løsning. I sin ITToolbox-blogartikel "Så hvad er bedre, ETL eller ELT?", Vincent McBurney angiver sine fordele og ulemper ved begge tilgange, som jeg har gentaget her nedenfor, og derefter fulgte hver med et typisk svar, som IRI ETL -orienterede brugere gør på punkt (ifølge min indledende subjektivitetsadvarsel):
Pros ETLImod ETL
- ETL kan afbalancere arbejdsbyrden og dele arbejdsbyrden med RDBMS – og faktisk fjerne denne arbejdsbyrde ved at transformere data via SortCL-programmet eller Hadoop uden kodning i Voracity
- ETL kan udføre mere komplekse operationer i enkelte dataflowdiagrammer via datamaps – som med Voracity-mapping og workflow-diagrammer, der også abstraherer korte, åbne 4GL-scripts vs. SQL
- ETL kan skaleres med separat hardware – på råvarekasser kan du købe og vedligeholde dig selv til meget lavere omkostninger end apparater fra en enkelt leverandør
- ETL kan håndtere partitionering og parallelitet uafhængigt af datamodellen, databaselayoutet og kildedatamodelarkitekturen – selvom Voracitys CoSort SortCL-job behøver slet ikke at være opdelt …
- ETL kan behandle data in-stream, da det overfører fra kilde til mål – eller i batch, hvis det også giver mening
- ETL kræver ikke samplacering af datasæt for at udføre sit arbejde – giver dig mulighed for at vedligeholde eksisterende datakildeplatforme uden bekymringer om datasynkronisering
- ETL fanger enorme mængder af metadata-afstamning i dag - hvor godt eller intuitivt kan en iscenesættelse af DB gøre det?
- ETL kan køre på SMP- eller MPP-hardware – som du igen kan administrere og udnytte mere omkostningseffektivt og ikke bekymre dig om ydeevnestridigheder med DB
- ETL behandler oplysninger række for række, og det ser ud til at fungere godt med dataintegration i tredjepartsprodukter – men det er endnu bedre fuld blok, tabel eller fil(er) ad gangen, som Voracity kører i volumen.
Pros ELT
- Yderligere hardwareinvestering er nødvendig for ETL-motorer – medmindre du kører det på databaseserveren(e)
- Ekstra omkostninger ved at bygge ETL-system eller licensere ETL-værktøjer – som stadig er billigere i forhold til ELT-apparater, men stadig billigere er IRI-værktøjer som Voracity, der kombinerer Fast Extract (FACT) og CoSort for at fremskynde ETL uden en sådan kompleksitet
- Mulig reduceret ydeevne af rækkebaseret tilgang – rigtigt, og hvorfor Voracitys evne til at profilere, erhverve, transformere og outputte data i større bidder er hurtigere
- Specialiserede færdigheder og læringskurve, der kræves for at implementere ETL-værktøjet – medmindre du bruger en ergonomisk GUI som Voracitys, der giver flere jobdesignmuligheder i den samme Eclipse IDE
- Reduceret fleksibilitet på grund af afhængighed af ETL-værktøjsleverandør – Jeg er ikke sikker på, hvordan det er forbedret ved i stedet at stole på en enkelt ELT/apparatleverandør; er leverandøruafhængighed ikke nøglen til fleksibilitet og omkostningsbesparelser?
- Data skal rejse på tværs af et lag mere, før de lander i datamart – medmindre mart blot var endnu et output fra ETL-processen, typisk for multi-target Voracity-operationer.
Imod ELT
- ELT udnytter RDBMS-motorhardware til skalerbarhed – men beskatter også DB-ressourcer beregnet til forespørgselsoptimering. CoSort- og Hadoop-transformationer i Voracity udnytter lineært skaleringsalgoritmer og opgavekonsolidering, ikke hukommelsen eller I/O-ressourcerne i DB
- ELT opbevarer alle data i RDBMS hele tiden – hvilket er fint, så længe kilde- og måldata er i samme DB
- ELT er paralleliseret i henhold til datasættet, og disk I/O er normalt optimeret på motorniveau for hurtigere gennemløb – ja, men det er endnu mere sandt for eksterne transformationer, der ikke kæmper med DB-serverressourcer
- ELT skalerer, så længe hardwaren og RDBMS-motoren kan fortsætte med at skalere – hvilket koster hvor meget i forhold til alternativet ovenfor?
- ELT kan opnå 3x til 4x gennemløbshastighederne på den korrekt tunede MPP RDBMS-platform – hvilket sætter apparatet på Voracity-ydeevneniveauer i forhold til ETL-værktøjer også, men til 20 gange prisen.
- ELT-transformation udføres på RDBMS-serveren, når databasen er på målplatformen, og den ikke længere belaster netværket – så det lægger vægt på databasen (brugerne) i stedet?
- ELT har enkle transformationsspecifikationer via SQL – som ikke er så enkle, fleksible eller så funktionsrige som CoSort SortCL-syntaks eller træk-og-slip-feltkortlægning i Voracitys Eclipse GUI.
- Begrænset tilgængelige værktøjer med fuld understøttelse af ELT – og til meget høje priser for DB-apparater, der fremhæver ydeevne i høj volumen
- Tab af detaljerede runtime-overvågningsstatistikker og dataafstamning – især metadatapåvirkningsanalyser på ændringer af forskellige filer, tabeller eller ustrukturerede kilder
- Tab af modularitet på grund af sætbaseret design for ydeevne – og tabet af funktionalitet/fleksibilitet, der følger af det
- Transformationer vil bruge databaseressourcer, hvilket potentielt påvirker BI-rapporteringsydelsen – for ikke at nævne udførelsen af forespørgsler og andre DB-operationer
Hybride arkitekturer som ETLT, TELT og endda TETLT dukker efterfølgende op i et forsøg på at afhjælpe svagheder i begge tilgange. Men disse synes at tilføje yderligere niveauer af kompleksitet til processer, der allerede er fyldt med disse. Der er virkelig ikke nogen sølvkugle, og mange dataintegrationsprojekter mislykkes under vægten af SLA'er, omkostningsoverskridelser og kompleksitet.
Det er af disse grunde, at IRI byggede Voracity til at integrere data via CoSort SortCL-programmet i eksisterende filsystemer eller Hadoop-stoffer uden omkodning. Voracity er den eneste ETL-orienterede (dog også ELT-understøttende) platform, der tilbyder begge muligheder for eksterne datatransformationer. Ud over overlegen prisydelse inden for databevægelse og -manipulation inkluderer Voracity:
- avanceret datatransformation, datakvalitet, MDM og rapportering
- langsomt skiftende dimensioner, ændring af datafangst, dataføderering
- dataprofilering, datamaskering, testdatagenerering og metadataadministration
- enkle 4GL-scripts, som du eller Eclipse-guider, diagrammer og dialogbokse opretter og administrerer
- sømløs udførelse i Hadoop MR2, Spark, Spart Stream Storm og Tez
- understøttelse af erwin Smart Connectors (konvertering fra andre ETL-værktøjer)
- native MongoDB-drivere og forbindelser til andre NoSQL-, Hadoop-, cloud- og ældre kilder
- indlejret rapportering, statistik og forudsigelsesfunktioner, KNIME- og Splunk-tilknytninger og datafeeds til analyseværktøj.
Se også:
- 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