ELT steht für „Extrahieren, Laden, Transformieren“ und ist eine weitere Art von Datenintegrationsprozess, der dem ETL-Prozess (Extrahieren, Transformieren, Laden) ähnlich ist. Bei diesem Prozess werden Rohdaten von einem Quellensystem zu einer Zielressource, z. B. einem Data-Warehouse, übertragen. ELT ähnelt zwar ETL, ist aber ein grundlegend anderer Ansatz für die Datenvorverarbeitung, der sich erst in letzter Zeit mit der Einführung von Cloud-Umgebungen durchgesetzt hat.
ELT besteht aus drei Hauptphasen: Extrahieren, Laden und Transformieren. Jede dieser Phasen wird unten detailliert beschrieben.
Bei der Datenextraktion werden die Daten von den Quellenpositionen in einen Staging-Bereich kopiert oder exportiert. Das Dataset kann aus vielen Datentypen bestehen und aus praktisch jeder strukturierten oder unstrukturierten Quelle stammen, einschließlich:
Allerdings wird es eher mit unstrukturierten Daten verwendet.
In diesem Schritt werden die transformierten Daten aus dem Staging-Bereich in einen Datenspeicherbereich (z. B. ein Data-Warehouse oder einen Data-Lake) verschoben.
In den meisten Unternehmen ist der Datenladeprozess automatisiert, genau definiert, kontinuierlich und stapelgesteuert. Normalerweise wird ELT während der Geschäftszeiten ausgeführt, wenn der Datenverkehr auf den Quellensystemen und im Data-Warehouse am höchsten ist und die Anwender darauf warten, die Daten für Analysen oder andere Zwecke zu nutzen.
In dieser Phase wird ein „Schema-on-write“-Ansatz verfolgt, bei dem das Schema für die Daten mithilfe von SQL angewendet oder die Daten vor der Analyse transformiert werden. Diese Phase kann Folgendes beinhalten:
ELT kann leicht mit dem verwandten Prozess, der zudem ganz ähnlich heißt, verwechselt werden. Es gibt jedoch einige deutliche Unterschiede zwischen ELT und dem ETL-Prozess, der für Extrahieren, Transformieren und Laden steht. Dabei handelt es sich um einen Datenintegrationsprozess, der Daten aus verschiedenen Datenquellen in einem einzigen, konsistenten Datenspeicher zusammenführt, der in ein Data-Warehouse oder ein anderes Zielsystem geladen wird. Ursprünglich wurden ETL-Tools für die Erstellung von Data Warehousing zur Unterstützung von Business-Intelligence- und Artificial-Intelligence-Anwendungen entwickelt.
Der offensichtliche Unterschied ist, dass der ELT-Prozess die Ladefunktion vor der Transformationsfunktion ausführt – also eine Umkehrung des zweiten und dritten Schritts des ETL-Prozesses. ELT kopiert oder exportiert die Daten von den Quellspeichern, aber anstatt sie zur Transformation in einen Staging-Bereich zu verschieben, lädt es die Rohdaten direkt in den Zieldatenspeicher, wo sie nach Bedarf transformiert werden können. ELT transformiert Daten nicht während der Übertragung.
Aber die Reihenfolge der Schritte ist nicht der einzige Unterschied. Bei ELT kann der Zieldatenspeicher ein Data-Warehouse sein, häufiger ist es jedoch ein Data-Lake, ein großer zentraler Speicher, der sowohl strukturierte als auch unstrukturierte Daten in großem Umfang speichern kann.
Data-Lakes werden mit einer Big-Data-Plattform (z. B. Apache Hadoop) oder einem verteilten NoSQL-Datenmanagementsystem verwaltet. Sie können Business Intelligence unterstützen, aber häufiger werden sie zur Unterstützung von künstlicher Intelligenz, maschinellem Lernen, Predictive Analytics und Anwendungen entwickelt, die von Echtzeitdaten und Ereignisströmen gesteuert werden.
Darüber hinaus gibt es weitere Unterschiede zwischen ETL und ELT. Da ETL Daten transformiert, bevor sie in das zentrale Repository verschoben werden, kann dieser Prozess einfacher und systematischer für die Einhaltung des Datenschutzes sorgen als ELT (z. B. wenn Analysten sensible Daten nicht transformieren, bevor sie sie verwenden müssen, könnten sie unmaskiert im Data-Lake vorliegen). Data-Scientists bevorzugen jedoch ELT, mit dem sie in einer „Sandbox“ mit Rohdaten experimentieren und ihre eigenen, auf spezifische Anwendungen zugeschnittenen Datentransformationen vornehmen können. In den meisten Fällen wird die Entscheidung zwischen ETL und ELT jedoch von den verfügbaren Unternehmensressourcen und -anforderungen abhängen.
ELT bietet mehrere Vorteile für Benutzer, die den Prozess in ihre Arbeitsabläufe integrieren wollen. Im Folgenden werden einige der bemerkenswerten Vorteile vorgestellt:
Wenn große Mengen von Streaming-Daten erzeugt werden, ermöglicht ELT das sofortige Laden dieser Daten und transformiert die Daten, nachdem sie ihr Ziel erreicht haben. Dadurch wird eine Verlangsamung verhindert, die häufig auftritt, wenn das Transformieren vor dem Laden erfolgt, wie z. B. bei ETL. Häufig müssen Entscheidungen auf der Grundlage dieser Daten getroffen werden und dabei sind Verzögerungen inakzeptabel. Ein Beispiel dafür ist der Aktienmarkt, bei dem große Datenmengen anfallen, die in Echtzeit verarbeitet werden müssen. In solchen Szenarien ist ELT die Lösung der Wahl, da die Transformation erst erfolgt, nachdem die Daten ihr Ziel erreicht haben.
Da die Daten transformiert werden, wenn sie am Zielort ankommen, ermöglicht ELT dem Empfänger der Daten, die Manipulation der Daten zu beeinflussen. Bei ELT wird durch die Entkopplung von Transformations- und Ladephase sichergestellt, dass sich ein Codierungsfehler oder ein anderer Fehler in der Transformationsphase nicht auf eine andere Phase auswirkt.
ELT nutzt das Potenzial und die Größe des Data-Warehouse, um eine Transformation oder skalierbare Berechnungen in großem Maßstab zu ermöglichen. Das Ziel-Data-Warehouse kann die Anzahl der Knoten je nach Bedarf erhöhen oder verringern, insbesondere in einem Cloud-Szenario, in dem es mehrere Knoten innerhalb jedes Clusters gibt und mehrere Cluster, die genutzt werden können. Dies ermöglicht bedarfsgerechte Flexibilität und Skalierbarkeit.
ELT erfordert einen weniger leistungsfähigen Server für die Datentransformation und nutzt die bereits im Warehouse vorhandenen Ressourcen. Dies führt zu Kosteneinsparungen und Ressourceneffizienz.
ELT ermöglicht die Nutzung des gewünschten Zielspeichers, um Kosten und Ressourcen flexibel zu halten. Data-Warehouses nutzen die MPP-Architektur (Massively Parallel Processing), einschließlich der spaltenbasierten Speicherung großer Datenmengen. Data Lake-Prozesse, die ein Schema oder ein Transformationsmodell anwenden, sobald die Daten empfangen werden (auch als „Schema-on-Read“ bezeichnet), werden ebenfalls unterstützt. Diese effizienten Prozesse bieten Flexibilität für große Datenmengen.
Der kontinuierliche Betrieb eignet sich ideal für alle Umgebungen, in denen ein schneller Zugriff auf die Daten erforderlich ist. ELT eignet sich gut für Daten, die in Cloud-Umgebungen verwendet werden, die häufig Anwendungen enthalten, auf die bei Bedarf immer wieder zugegriffen wird. Außerdem bietet die cloudnative ELT-Transformation die bereits erwähnte Skalierbarkeit und Flexibilität.
Ein Unternehmen kann sich für den Umstieg von einer ETL- zu einer ELT-Architektur entscheiden. Der Grund für die Umstellung könnte eine veränderte Nutzung des Produkts oder Service sein, die eine Reaktion und Interaktion in Echtzeit erfordert, oder die Datenmenge ist exponentiell gewachsen und die Transformation verzögert die Ladephase aufgrund der hohen Verarbeitungsanforderungen an die Infrastruktur. Ein Unternehmen kann sich auch für den Umstieg von ETL auf ELT entscheiden, wenn es auf die Cloud umgestellt hat und die Verarbeitung auslagern oder die Daten am Ziel früher nutzen möchte.
In einem solchen Umstellungsszenario ist es realistisch, mit Herausforderungen zu rechnen. Zunächst einmal werden in ELT und ETL völlig unterschiedliche Logiken und Codes verwendet. Dies könnte eine vollständige Neukonfiguration und möglicherweise eine neue Infrastruktur oder einen neuen Anbieter mit Infrastruktur in der Cloud erfordern. Darüber hinaus werden bei ELT die Rohdaten an das Ziel-Data-Warehouse gesendet. Daher ist die Sicherheit ein wichtiger Aspekt und muss gewährleistet werden, um die Daten zu schützen.
ELT ist keine neue Technologie. Früher wurden Staging-Tabellen verwendet, um Daten zur Verarbeitung und Transformation in ein Warehouse zu verschieben, oft unter Verwendung von SQL-Scripts. SQL-Scripts sind fest codiert und daher anfällig für Codierungsfehler. Bei Verwendung von SQL hatten die Kunden die Wahl zwischen nativer Ausführung im Warehouse mit SQL-Scripts und deklarativer Programmierung, auch bekannt als deklaratives Authoring. Das deklarative Authoring bietet die Vorteile modernerer, cloudbasierter Data-Warehouse-Umgebungen durch das Erstellen von Code, der beschreibt, was das Programm erreichen muss, und nicht, wie es dies erreicht. Dieser Prozess verhindert Codierungsfehler, die bei anderen Prozessen auftreten, insbesondere wenn die Transformation vor der Ladefunktion erfolgt.
ELT wird in der Regel in Umgebungen mit hohem Datenaufkommen oder Echtzeitnutzung eingesetzt. Konkrete Beispiele sind:
IBM Cloud Pak for Data ist eine offene, erweiterbare Datenplattform, die ein Data Fabric zur Verfügung stellt, um alle Daten für KI und Analytics in jeder Cloud verfügbar zu machen.
KI erschließt den Nutzen Ihrer Daten auf neue Weise. Organisieren Sie Ihre Daten, um sie mit DataOps-Lösungen für KI und Multicloud vorzubereiten.
Die Datenintegration ermöglicht es Ihnen, strukturierte und unstrukturierte Daten zu transformieren und jedem beliebigen System auf einer skalierbaren Big-Data-Plattform bereitzustellen.