SSIS (Integration Services) – ETL vs. ELT Lösung?
Und wieder war es ein Meeting, welches mich zu einen Blogpost animiert.
Wir sprachen über die Einführung eines Data Warehouses, ETL etc. pp. und dann kam da einer mit einer ganz tollen Frage: Was ist denn mit ELT und wo sei der Unterschied? Und ob das denn die Integration Services auch könnten? Ist doch die Zukunft des Integrationsprozesses, sagt doch der andere Hersteller. Also wäre ja zu erwarten, dass Microsoft solche Innovationen unterstützt. Der klassische ETL Prozess wäre ja quasi von gestern und mit ELT dann ja auch dazu noch überflüssig geworden.
Erwartungsvolle Gesichter in der Runde. Was ist denn nun ELT und kann das der SQL Server? Ich liebe meinen Job…
Also, klassisches ETL (Extract, Transform, Load) meint, stark vereinfacht ausgedrückt, dass Daten aus verschiedenen Vorsystemen extrahiert werden. Diese werden in der Regel in Form von “Datenpaketen” in einer sogenannten Landing Zone gesammelt. Von dort aus werden die Pakete i. d. Regel mehrstufig weiterverarbeitet, sprich transformiert. Der letzte Schritt ist das Laden der Daten in das relationale Data Warehouse, wobei dann noch die Historisierung von Daten durchgeführt werden kann.
Was kann nun eine ELT Lösung dazu Innovatives beitragen? Das Offensichtliche zuerst. ELT steht für Extract, Load & Transform. Ok, ist halt vertauscht. Und? :-)
Die Idee dabei ist, dass Daten wiederum zuerst aus Vorsystemen extrahiert werden. Die Methoden, Konzepte, Ideen und auch Herausforderungen sind 100% identisch zur ETL Welt. Auch können diese Daten in Form von Datenpaketen organisiert werden. Nur dann kommt der wesentliche Unterschied! Die Daten werden beim ELT Ansatz gleich wieder in ein relationales Datenbanken System geladen. Häufig ist es das System, welches auch das eigentliche Data Warehouse hält. Und auf diesem System werden die Daten mittels SQL Statements transformiert. Das ist schon alles.
Ok, ok… wozu jetzt die ganze Aufregung? Dazu müssen wir noch ein wenig mehr ins Detail gehen beim ETL Prozess. Beim ETL findet häufig eine Verarbeitung der Daten außerhalb einer relationalen Datenbank statt. In der Regel werden die Daten zeilenweise verarbeitet. In den Integration Services wird das durch den konsequenten Einsatz der Datenflusskomponente und des RAW-Dateiformates erreicht. Ab einer sehr großen Datenmenge ist dieses Vorgehen deutlich schneller als die relationale Engine zu bemühen.
Bei ELT gibt es aber keine extra Verarbeitungsengine, sondern “alles” findet innerhalb einer relationalen Datenbank statt. Es wird damit eine Technologie “gespart”. Das ist der häufig ins Feld geführte Vorteil einer ELT Architektur. In der Praxis heißt das auch oft, dass ein extra System gespart wird.
Meine 2 Cent dazu sind:
ELT klingt gut, kann es sogar sein, ja wenn… die Rahmenbedingungen stimmen! Wenn ich keine wirklich komplexe und unübersichtliche Umgebung habe. Des Weiteren sollte die Anzahl der Vorsysteme überschaubar sein. Und, steht ja schon oben, die Datenmenge sollte auch gewisse Grenzen haben (und nein, da gibt es keine one-size-fits-all Antwort drauf!).
Die Wahrheit ist, dass es da draußen eine Unmenge an ETL Prozessen gibt, welche sehr wahrscheinlich ELT Prozesse sind. Und bisher hat es keinen gestört! :-)
Ach ja, und natürlich lassen sich auch ELT Integrationsprozesse mit dem Microsoft SQL Server abbilden. Alles eine Frage der Architektur!
