ETL vs ELT:Wir behaupten, Sie beurteilen

Vollständige Offenlegung:Da dieser Artikel von einem ETL-zentrierten Unternehmen verfasst wurde, das stark auf die Manipulation von Big Data außerhalb von Datenbanken spezialisiert ist, wird das Folgende für viele nicht objektiv erscheinen. Dennoch soll es Denkanstöße geben und das Wort zur Diskussion eröffnen.

Seit ihren Anfängen haben Data Warehouse Architects (DWA) die Aufgabe, ein Data Warehouse mit Daten aus unterschiedlichen Quellen und Formaten zu erstellen und zu füllen. Aufgrund des dramatischen Wachstums der Datenmengen stehen dieselben DWAs vor der Herausforderung, ihre Datenintegrations- und Bereitstellungsvorgänge effizienter zu implementieren. Die Frage, ob die Datenumwandlung innerhalb oder außerhalb der Zieldatenbank erfolgt, ist aufgrund der damit verbundenen Leistung, Bequemlichkeit und finanziellen Folgen zu einer kritischen Frage geworden.

Bei ETL-Operationen (Extrahieren, Transformieren, Laden) werden Daten aus verschiedenen Quellen extrahiert, separat transformiert und in eine DW-Datenbank und möglicherweise andere Ziele geladen. In ELT werden die Extrakte in die einzelne Staging-Datenbank eingespeist, die auch die Transformationen verarbeitet.

ETL bleibt weit verbreitet, weil der Markt mit bewährten Akteuren wie Informatica, IBM, Oracle – und IRI mit Voracity floriert, das FACT (Fast Extract), CoSort- oder Hadoop-Transformationen und Massenladen in derselben Eclipse-GUI kombiniert – um Daten zu extrahieren und zu transformieren. Dieser Ansatz verhindert, dass Datenbanken, die zum Speichern und Abrufen (Abfrageoptimierung) entwickelt wurden, durch den Overhead einer groß angelegten Datentransformation belastet werden.

Mit der Entwicklung neuer Datenbanktechnologien und Hardware-Appliances wie Oracle Exadata, die Transformationen „in a box“ verarbeiten können, kann ELT jedoch unter bestimmten Umständen eine praktische Lösung sein. Und das Isolieren der Staging- (Laden) und Semantik- (Transformations-)Schichten hat besondere Vorteile.

Ein genannter Vorteil von ELT ist die Isolierung des Ladeprozesses vom Transformationsprozess, da es eine inhärente Abhängigkeit zwischen diesen Phasen aufhebt.

Wir stellen fest, dass der ETL-Ansatz von IRI sie trotzdem isoliert, weil Voracity Daten im Dateisystem (oder HDFS) bereitstellt. Jeder für die Datenbank gebundene Datenblock kann vor einem (vorsortierten) Laden extern erfasst, bereinigt und transformiert werden. Dies entlastet die Datenbank (sowie BI-/Analyse-Tools usw.) durch groß angelegte Transformationen.

Datenvolumen und Budgets entscheiden oft darüber, ob ein DWA eine ETL- oder ELT-Lösung entwickeln sollte. In seinem ITToolbox-Blogartikel „So What Is Better, ETL or ELT?“ stellt Vincent McBurney seine Vor- und Nachteile für beide Ansätze dar, die ich hier unten wiederholt habe, und folgte dann jeweils mit einer typischen Antwort, dass IRI ETL -orientierte Nutzer treffen auf den Punkt (nach meinem anfänglichen Subjektivitätsvorbehalt):

Pro ETL

ETL kann die Arbeitslast ausgleichen und die Arbeitslast mit dem RDBMS teilen – und diese Arbeitslast tatsächlich entfernen, indem Daten über das SortCL-Programm oder Hadoop ohne Codierung in Voracity transformiert werden

ETL kann komplexere Operationen in einzelnen Datenflussdiagrammen über Datenzuordnungen durchführen – wie bei Voracity-Mapping und Workflow-Diagrammen, die auch kurz, offen abstrahieren 4GL-Skripts im Vergleich zu SQL

ETL kann mit separater Hardware skaliert werden – Sie können sich auf Commodity-Boxen zu viel geringeren Kosten selbst beschaffen und warten als Appliances von einem einzelnen Anbieter

ETL kann Partitionierung und Parallelität unabhängig vom Datenmodell, Datenbanklayout und der Architektur des Quelldatenmodells handhaben – obwohl die CoSort SortCL-Jobs von Voracity muss überhaupt nicht partitioniert werden …

ETL kann Daten in-stream verarbeiten, während sie von der Quelle zum Ziel übertragen werden – oder auch im Batch, wenn das sinnvoll ist

ETL erfordert keine Co-Location von Datensätzen, um seine Arbeit zu erledigen – so dass Sie bestehende Datenquellenplattformen ohne Sorgen um die Datensynchronisierung pflegen können

ETL erfasst heute riesige Mengen an Metadatenherkunft - wie gut oder intuitiv kann eine Staging-DB das tun?

ETL kann auf SMP- oder MPP-Hardware ausgeführt werden – die Sie wiederum kostengünstiger verwalten und nutzen können und sich keine Gedanken über Leistungskonflikte mit der DB machen müssen

ETL verarbeitet Informationen Zeile für Zeile, und das scheint mit der Datenintegration in Produkte von Drittanbietern gut zu funktionieren – besser noch vollständiger Block, Tabelle oder Datei(en) gleichzeitig, die Voracity im Volumen ausführt.

Kontra ETL

Für ETL-Engines sind zusätzliche Hardwareinvestitionen erforderlich – es sei denn, Sie führen sie auf dem/den Datenbankserver(n) aus

Zusätzliche Kosten für den Aufbau eines ETL-Systems oder die Lizenzierung von ETL-Tools – die im Vergleich zu ELT-Appliances immer noch billiger sind, aber noch billiger sind IRI-Tools wie Voracity, die Fast Extract (FACT) und CoSort kombinieren, um ETL ohne solche Komplexität zu beschleunigen

Mögliche reduzierte Leistung des zeilenbasierten Ansatzes – richtig, und warum die Fähigkeit von Voracity, Daten in größeren Blöcken zu profilieren, zu erfassen, umzuwandeln und auszugeben, schneller ist

Spezialkenntnisse und Lernkurve für die Implementierung des ETL-Tools erforderlich – es sei denn, Sie verwenden eine ergonomische GUI wie die von Voracity, die mehrere Job-Design-Optionen in derselben Eclipse-IDE bietet

Eingeschränkte Flexibilität aufgrund der Abhängigkeit vom ETL-Tool-Anbieter – Ich bin mir nicht sicher, wie sich das verbessern lässt, wenn man sich stattdessen auf einen einzelnen ELT-/Appliance-Anbieter verlässt; ist herstellerunabhängigkeit nicht der schlüssel zu flexibilität und kosteneinsparungen?

Daten müssen eine weitere Ebene durchlaufen, bevor sie im Data Mart landen – es sei denn, der Mart wäre nur ein weiteres Ergebnis des ETL-Prozesses, typisch für Multi-Target-Voracity-Operationen.

Pro ELT

ELT nutzt RDBMS-Engine-Hardware für die Skalierbarkeit – belastet aber auch DB-Ressourcen, die für die Abfrageoptimierung vorgesehen sind. CoSort- und Hadoop-Transformationen in Voracity nutzen linear skalierende Algorithmen und Aufgabenkonsolidierung, nicht den Speicher oder die E/A-Ressourcen der DB

ELT hält alle Daten ständig im RDBMS – was in Ordnung ist, solange sich Quell- und Zieldaten in derselben DB befinden

ELT wird entsprechend dem Datensatz parallelisiert, und Festplatten-E/A wird normalerweise auf Engine-Ebene für einen schnelleren Durchsatz optimiert – ja, aber das gilt noch mehr für externe Transformationen, die nicht mit DB-Serverressourcen konkurrieren

ELT skaliert, solange die Hardware und die RDBMS-Engine weiter skaliert werden können – was kostet wie viel im Vergleich zur obigen Alternative?

ELT kann das 3- bis 4-fache der Durchsatzraten auf der entsprechend abgestimmten MPP-RDBMS-Plattform erreichen – was die Appliance auch im Vergleich zu ETL-Tools auf das Voracity-Leistungsniveau bringt, aber zu 20-fachen Kosten.

Die ELT-Transformation wird auf dem RDBMS-Server durchgeführt, sobald sich die Datenbank auf der Zielplattform befindet, und sie belastet das Netzwerk nicht mehr – also belastet sie stattdessen die Datenbank (Benutzer)?

ELT hat einfache Transformationsspezifikationen über SQL – die nicht so einfach, flexibel oder funktionsreich sind wie die CoSort SortCL-Syntax oder die Drag-and-Drop-Feldzuordnung in der Eclipse-GUI von Voracity.

Nachteile ELT

Eingeschränkte Tools mit voller Unterstützung für ELT verfügbar – und zu sehr hohen Preisen für DB-Appliances, die für hohe Leistung werben

Verlust detaillierter Laufzeitüberwachungsstatistiken und Datenherkunft – insbesondere Metadaten-Auswirkungsanalysen bei Änderungen an unterschiedlichen Dateien, Tabellen oder unstrukturierten Quellen

Verlust der Modularität durch satzbasiertes Design für Leistung – und der daraus resultierende Verlust an Funktionalität/Flexibilität

Umwandlungen würden Datenbankressourcen nutzen, was sich möglicherweise auf die Leistung der BI-Berichte auswirkt – ganz zu schweigen von der Leistung von Abfragen und anderen DB-Vorgängen

Hybridarchitekturen wie ETLT, TELT und sogar TETLT tauchen in der Folge auf, um die Schwächen beider Ansätze auszugleichen. Aber diese scheinen Prozesse, die bereits so angespannt sind, noch komplexer zu machen. Es gibt wirklich keine Wunderwaffe, und viele Datenintegrationsprojekte scheitern unter der Last von SLAs, Kostenüberschreitungen und Komplexität.

Aus diesen Gründen hat IRI Voracity entwickelt, um Daten über das CoSort SortCL-Programm in bestehende Dateisysteme oder Hadoop-Strukturen ohne Neucodierung zu integrieren. Voracity ist die einzige ETL-orientierte (aber auch ELT-unterstützende) Plattform, die beide Optionen für externe Datentransformationen bietet. Neben einem hervorragenden Preis-Leistungs-Verhältnis bei der Datenbewegung und -manipulation umfasst Voracity:

erweiterte Datentransformation, Datenqualität, MDM und Berichterstellung
sich langsam ändernde Dimensionen, Änderungsdatenerfassung, Datenföderation
Datenprofilerstellung, Datenmaskierung, Generierung von Testdaten und Metadatenverwaltung
einfache 4GL-Skripte, die Sie oder Eclipse-Assistenten, -Diagramme und -Dialoge erstellen und verwalten
nahtlose Ausführung in Hadoop MR2, Spark, Spart Stream Storm und Tez
Unterstützung für erwin Smart Connectors (Konvertierung von anderen ETL-Tools)
native MongoDB-Treiber und Verbindungen zu anderen NoSQL-, Hadoop-, Cloud- und Legacy-Quellen
eingebettete Berichts-, Statistik- und Vorhersagefunktionen, KNIME- und Splunk-Einbindungen und Daten-Feeds von Analysetools.

Siehe auch:

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