ETL oder ELT? Ein Praxistest in Microsoft Fabric

Datenintegration in Microsoft Fabric: Theorie trifft Praxis

Moderne Unternehmen treffen täglich Entscheidungen auf Basis von Daten. Damit diese Daten zuverlässig analysiert werden können, müssen sie zunächst aus unterschiedlichen Quellsystemen zusammengeführt und aufbereitet werden. Genau hier kommen Datenintegrationsprozesse ins Spiel.

Zwei der bekanntesten Ansätze sind ETL (Extract, Transform, Load) und ELT (Extract, Load, Transform). Während bei ETL die Daten bereits vor dem Laden in das Zielsystem transformiert, werden bei ELT die Rohdaten zunächst gespeichert und erst anschließend verarbeitet.

In der Theorie gilt ELT insbesondere in modernen Cloud-Plattformen als leistungsfähiger Ansatz. Doch wie sieht das in einem realen Unternehmensprojekt aus?

Um diese Frage zu beantworten, haben wir innerhalb eines Kundenprojekts einen experimentellen Vergleich von ETL- und ELT-Prozessen in Microsoft Fabric durchgeführt.

Ausgangssituation: Zentrale BI-Lösung für einen internationalen Automobilzulieferer

Im Rahmen eines Kundenprojekts bestand die Herausforderung darin, vertriebsrelevante SAP-Daten aus verschiedenen Modulen in einer zentralen Business-Intelligence-Lösung zusammenzuführen.

Die vorhandenen Berichte wurden überwiegend manuell erstellt und eine einheitliche Datengrundlage fehlte. Ziel war deshalb der Aufbau eines zentralen Datenmodells auf Basis von Microsoft Fabric, um Geschäftsprozesse transparent darzustellen und datengetriebene Entscheidungen zu unterstützen.

Als Datenbasis dienten mehrere SAP-Tabellen:

• VBAK (Auftragskopfdaten)
• VBAP (Auftragspositionen)
• MARA (Materialstammdaten)
• MAKT (Materialbezeichnungen)
• KNA1 (Kundenstammdaten)

Diese Tabellen bilden einen typischen Anwendungsfall für Datenintegration und ermöglichen unterschiedliche Transformationsszenarien hinsichtlich Datenvolumen und Komplexität.

Was wurde getestet?

Neben dem ursprünglichen Kundenszenario wurden zusätzliche Testfälle erstellt, um den Einfluss verschiedener Faktoren zu untersuchen.

1. Basisdurchlauf
Der reale Projektstand mit originaler Datenmenge und typischen Transformationen.

2. Höhere Datenvolumen
Die Daten wurden mithilfe eines kontrollierten Skalierungsverfahrens auf das 10-fache und 50-fache Volumen erweitert.

3. Komplexere Transformationen
Zusätzlich wurden Szenarien mit mehreren Joins und komplexeren Gruppierungen aufgebaut, um die Auswirkungen steigender Transformationskomplexität zu analysieren.

Jeder Test wurde mehrfach durchgeführt, um statistisch belastbare Ergebnisse zu erhalten.

Die Ergebnisse auf einen Blick

Die Resultate waren überraschend deutlich. 

In sämtlichen Testfällen war die ETL-Variante deutlich schneller als die ELT-Variante.

Ressourcenverbrauch

Auch beim Ressourcenverbrauch zeigte sich ein klares Bild.

Bereits im Basisszenario benötigte der ETL-Prozess nur rund 304 Kapazitätssekunden, während der ELT-Prozess über 1.180 Kapazitätssekunden verbrauchte.

Dieser Trend setzte sich über alle Testdurchläufe hinweg fort. Die ETL-Lösung arbeitete durchgehend ressourcenschonender. 

Warum sind die Ergebnisse interessant?

In vielen Fachartikeln wird ELT als bevorzugter Ansatz für moderne Cloud-Architekturen beschrieben. Der Gedanke dahinter: Die Rechenleistung der Cloud-Plattform wird direkt genutzt, wodurch große Datenmengen effizient verarbeitet werden können.

Unsere Untersuchung zeigt jedoch, dass diese Annahme nicht automatisch auf jeden Anwendungsfall übertragbar ist.

Im betrachteten Kundenprojekt konnte ETL sowohl bei kleinen als auch bei größeren Datenmengen überzeugen. Auch steigende Transformationskomplexität führte nicht dazu, dass ELT einen Vorteil erzielen konnte.

Das bedeutet nicht, dass ELT grundsätzlich schlechter ist. Vielmehr zeigt sich, wie wichtig eine individuelle Bewertung der jeweiligen Architektur und Anforderungen ist.

Welche Erkenntnisse nehmen wir aus dem Projekt mit

Für den konkreten Anwendungsfall in Microsoft Fabric ergeben sich mehrere wichtige Erkenntnisse:

Im untersuchten Anwendungsfall erwies sich ETL als die effizientere Lösung
Sowohl hinsichtlich Laufzeit als auch Ressourcenverbrauch schnitt ETL in allen Tests besser ab.

Datenvolumen allein macht ELT nicht automatisch überlegen

Selbst bei einer Skalierung auf das 50-fache Datenvolumen konnte kein Vorteil für ELT festgestellt werden.

Architekturentscheidungen sollten datenbasiert getroffen werden

Theoretische Vorteile sind wichtig, ersetzen aber keine praktische Evaluation im eigenen Systemumfeld.

Microsoft Fabric bietet beide Ansätze

Die Plattform ermöglicht sowohl klassische ETL-Prozesse über Dataflow Gen2 als auch ELT-Architekturen über Pipelines und SQL-basierte Transformationen. Dadurch können Unternehmen den für ihren Anwendungsfall passenden Ansatz wählen

Fazit

Die Digitalisierung erzeugt stetig wachsende Datenmengen und damit auch steigende Anforderungen an Datenintegrationsprozesse. ETL und ELT sind dabei zwei wichtige Ansätze, die je nach Rahmenbedingungen unterschiedliche Vorteile bieten können.

Die Ergebnisse unseres Kundenprojekts zeigen jedoch deutlich, dass ETL in Microsoft Fabric unter den untersuchten Bedingungen die bessere Wahl war. Die Prozesse liefen schneller, verbrauchten weniger Ressourcen und lieferten gleichzeitig dieselben fachlichen Ergebnisse.

Für Unternehmen bedeutet das: Architekturentscheidungen sollten nicht allein auf theoretischen Annahmen basieren. Erst die Analyse realer Daten, Prozesse und Anforderungen zeigt, welcher Ansatz tatsächlich den größten Mehrwert bietet.