Volledige openbaarmaking:aangezien dit artikel is geschreven door een ETL-gecentreerd bedrijf dat sterk is in het manipuleren van big data buiten databases, zal het volgende voor velen niet objectief lijken. Desalniettemin is het nog steeds bedoeld om stof tot nadenken te geven, en geeft het ruimte voor discussie.
Sinds hun begin hebben datawarehouse-architecten (DWA) de taak gehad om een datawarehouse te creëren en te vullen met gegevens uit verschillende bronnen en opgemaakte gegevens. Door de dramatische groei van de datavolumes worden deze zelfde DWA's uitgedaagd om hun data-integratie en staging-operaties efficiënter te implementeren. De vraag of gegevenstransformatie binnen of buiten de doeldatabase zal plaatsvinden, is een kritieke vraag geworden vanwege de prestaties, het gemak en de financiële gevolgen die ermee gemoeid zijn.
Bij ETL-bewerkingen (extract, transform, load) worden gegevens uit verschillende bronnen gehaald, afzonderlijk getransformeerd en in een DW-database en mogelijk andere doelen geladen. In ELT worden de extracten ingevoerd in de enkele staging-database die ook de transformaties afhandelt.
ETL blijft gangbaar omdat de markt floreert met beproefde spelers zoals Informatica, IBM, Oracle en IRI met Voracity, dat FACT (Fast Extract), CoSort of Hadoop-transformaties en bulklading in dezelfde Eclipse GUI combineert om gegevens te extraheren en te transformeren. Deze aanpak voorkomt dat databases die zijn ontworpen voor opslag en ophalen (query-optimalisatie) belast worden met de overhead van grootschalige gegevenstransformatie.
Met de ontwikkeling van nieuwe databasetechnologie en hardware-appliances zoals Oracle Exadata die transformaties ‘in a box’ aankunnen, kan ELT onder bepaalde omstandigheden echter een praktische oplossing zijn. En er zijn specifieke voordelen verbonden aan het isoleren van de fasering (load) en semantische (transform) lagen.
Een genoemd voordeel van ELT is de isolatie van het laadproces van het transformatieproces, omdat het een inherente afhankelijkheid tussen deze fasen wegneemt.
We merken op dat de ETL-aanpak van IRI ze toch isoleert omdat Voracity gegevens in het bestandssysteem (of HDFS) zet. Elk gegevensblok dat voor de database is bestemd, kan worden verkregen, opgeschoond en extern worden getransformeerd voordat het (voorgesorteerd) wordt geladen. Dit neemt de last van grootschalige transformaties uit de database (evenals BI/analytische tools, enz.).
Datavolumes en budgetten bepalen vaak of een DWA een ETL- of ELT-oplossing moet ontwikkelen. In zijn ITToolbox-blogartikel "Dus wat is beter, ETL of ELT?", poneert Vincent McBurney zijn voor- en nadelen van beide benaderingen, die ik hieronder heb herhaald, en vervolgens elk gevolgd door een typisch antwoord dat IRI ETL -georiënteerde gebruikers maken duidelijk (volgens mijn aanvankelijke voorbehoud bij subjectiviteit):
Pros ETLNadelen ETL
- ETL kan de werklast in evenwicht brengen en de werklast delen met het RDBMS - en die werklast in feite verwijderen door gegevens te transformeren via het SortCL-programma of Hadoop zonder codering in Voracity
- ETL kan complexere bewerkingen uitvoeren in enkelvoudige gegevensstroomdiagrammen via gegevenskaarten - zoals met Voracity-toewijzing en werkstroomdiagrammen die ook kort, open abstract samenvatten 4GL-scripts versus SQL
- ETL kan worden geschaald met afzonderlijke hardware - op basisverpakkingen kunt u zelf kopen en onderhouden tegen veel lagere kosten dan apparaten van één leverancier
- ETL kan partitionering en parallellisme aan, onafhankelijk van het gegevensmodel, de databaselay-out en de architectuur van het brongegevensmodel – hoewel de CoSort SortCL-taken van Voracity hoeft helemaal niet te worden gepartitioneerd ...
- ETL kan gegevens in-stream verwerken, omdat deze worden overgedragen van bron naar doel - of in batch als dat ook logisch is
- ETL vereist geen co-locatie van datasets om zijn werk te doen - waardoor u bestaande gegevensbronplatforms kunt onderhouden zonder zorgen over gegevenssynchronisatie
- ETL legt tegenwoordig enorme hoeveelheden metadata-afstamming vast - hoe goed of intuïtief kan een enscenering van DB dat doen?
- ETL kan worden uitgevoerd op SMP- of MPP-hardware - die u opnieuw kosteneffectiever kunt beheren en exploiteren, zonder dat u zich zorgen hoeft te maken over prestatieconflicten met de DB
- ETL verwerkt informatie rij voor rij en dat lijkt goed te werken met gegevensintegratie in producten van derden - beter is echter volledig blok, tabel of bestand(en) per keer, die Voracity in volume uitvoert.
Voordelen ELT
- Er is extra hardware-investering nodig voor ETL-engines - tenzij u deze op de databaseserver(s) uitvoert
- Extra kosten voor het bouwen van een ETL-systeem of het licentiëren van ETL-tools - die nog steeds goedkoper zijn in vergelijking met ELT-appliances, maar nog steeds goedkoper zijn IRI-tools zoals Voracity, die Fast Extract (FACT) en CoSort combineren om ETL te versnellen zonder zo'n complexiteit
- br />
- Mogelijke verminderde prestaties van op rijen gebaseerde benadering - juist, en waarom het vermogen van Voracity om gegevens in grotere brokken te profileren, verwerven, transformeren en uitvoeren, sneller is
- Gespecialiseerde vaardigheden en leercurve vereist voor het implementeren van de ETL-tool - tenzij u een ergonomische GUI zoals die van Voracity gebruikt, die meerdere taakontwerpopties biedt in dezelfde Eclipse IDE
- Verminderde flexibiliteit vanwege afhankelijkheid van leverancier van ETL-tools - Ik weet niet zeker hoe dat is verbeterd door in plaats daarvan te vertrouwen op één enkele ELT-/apparaatleverancier; is leveranciersonafhankelijkheid niet de sleutel tot flexibiliteit en kostenbesparingen?
- Gegevens moeten nog een laag doorlopen voordat ze in de datamart terechtkomen - tenzij de mart gewoon een andere uitvoer van het ETL-proces is, typisch voor Voracity-bewerkingen met meerdere doelen.
Nadelen ELT
- ELT maakt gebruik van RDBMS-enginehardware voor schaalbaarheid - maar belast ook DB-resources die bedoeld zijn voor query-optimalisatie. CoSort- en Hadoop-transformaties in Voracity maken gebruik van lineair schalende algoritmen en taakconsolidatie, niet van het geheugen of I/O-resources van de DB
- ELT bewaart alle gegevens altijd in het RDBMS - wat prima is zolang de bron- en doelgegevens zich in dezelfde DB bevinden
- ELT wordt geparallelliseerd volgens de dataset en schijf-I/O wordt meestal geoptimaliseerd op engine-niveau voor een snellere doorvoer - ja, maar dat geldt nog meer voor externe transformaties die niet te maken hebben met DB-serverbronnen
- ELT wordt geschaald zolang de hardware en de RDBMS-engine kunnen blijven schalen - wat kost hoeveel ten opzichte van het bovenstaande alternatief?
- ELT kan 3x tot 4x de doorvoersnelheid behalen op het goed afgestemde MPP RDBMS-platform - waardoor het apparaat ook op Voracity-prestatieniveaus komt ten opzichte van ETL-tools, maar tegen 20 keer de kosten.
- ELT-transformatie wordt uitgevoerd op de RDBMS-server zodra de database zich op het doelplatform bevindt en het netwerk niet langer wordt belast – dus in plaats daarvan de druk op de database (gebruikers) legt?
- ELT heeft eenvoudige transformatiespecificaties via SQL - die niet zo eenvoudig, flexibel of rijk aan functies zijn als CoSort SortCL-syntaxis of slepen en neerzetten van veldtoewijzing in de Eclipse GUI van Voracity.
- Beperkte tools beschikbaar met volledige ondersteuning voor ELT - en tegen zeer hoge prijzen voor DB-appliances die hoge-volumeprestaties aanprijzen
- Verlies van gedetailleerde runtime-bewakingsstatistieken en gegevensafstamming - vooral metadata-impactanalyses op wijzigingen aan ongelijksoortige bestanden, tabellen of ongestructureerde bronnen
- Verlies van modulariteit als gevolg van op set gebaseerd ontwerp voor prestaties - en het verlies van functionaliteit/flexibiliteit die daaruit voortvloeit
- Transformaties zouden databasebronnen gebruiken, wat mogelijk van invloed is op de prestaties van BI-rapportage - om nog maar te zwijgen van de prestaties van query's en andere DB-bewerkingen
Hybride architecturen zoals ETLT, TELT en zelfs TETLT duiken vervolgens op in een poging de zwakheden in beide benaderingen te versterken. Maar deze lijken extra niveaus van complexiteit toe te voegen aan processen die al zo beladen zijn. Er is echt geen wondermiddel, en veel data-integratieprojecten mislukken onder het gewicht van SLA's, kostenoverschrijdingen en complexiteit.
Om deze redenen heeft IRI Voracity gebouwd om gegevens via het CoSort SortCL-programma te integreren in bestaande bestandssystemen of Hadoop-fabrics zonder opnieuw te coderen. Voracity is het enige ETL-georiënteerde (maar ook ELT-ondersteunende) platform dat beide opties biedt voor externe gegevenstransformaties. Naast superieure prijs-prestatieverhoudingen bij het verplaatsen en manipuleren van gegevens, omvat Voracity:
- geavanceerde datatransformatie, datakwaliteit, MDM en rapportage
- langzaam veranderende dimensies, gegevensregistratie wijzigen, gegevensfederatie
- gegevensprofilering, gegevensmaskering, het genereren van testgegevens en metagegevensbeheer
- eenvoudige 4GL-scripts die u of Eclipse-wizards, diagrammen en dialoogvensters maken en beheren
- naadloze uitvoering in Hadoop MR2, Spark, Spart Stream Storm en Tez
- ondersteuning voor erwin Smart Connectors (conversie van andere ETL-tools)
- native MongoDB-stuurprogramma's en verbindingen met andere NoSQL-, Hadoop-, cloud- en legacy-bronnen
- ingesloten rapportage, statistieken en voorspellende functies, KNIME- en Splunk-koppelingen en datafeeds van analytische tools.
Zie ook:
- 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