Ein zentraler Part des Data Warehousings besteht darin, die Daten in dieses verflixte DWH reinzubekommen. Typischerweise als ETL-Prozess bezeichnet. Nach Schätzungen eines einflussreichen Beratungsunternehmens dieser Branche, gehen 70-80% der Entwicklungskosten eines BI-Projektes zu Lasten von ETL.
Die meisten der am Markt etablierten ETL-Anbietern konzentrieren sich auf völlig eigenständige Softwarelösungen, die von den Datenbanksystemen getrennt agieren. Das bedeutet, dass sie eine eigene Datenhaltung haben und alle Datentransformationen auf diesen Daten durchführen. Erst wenn alle Transformationen durchgeführt sind, werden die Daten in die Datenbank geschrieben, wo sie von BI-Tools für Auswertungen herangezogen werden. Aufgrund dieses Vorgehens hat sich auch der Begriff ETL (Extract-Transform-Load) entwickelt: weil die Daten zunächst aus den Quellen extrahiert (E), dann transformiert (T) und anschließend geladen (L) werden. Der Vorteil in diesem Vorgehen bestand darin, dass die Datenbanken an sich relativ eingeschränkte Möglichkeiten boten, um logische Transformationen durchzuführen. Die zur Verfügung stehende Abfrage-Sprache SQL hat diverse Einschränkungen, die sie zwar leicht verständlich und anwendbar, jedoch für komplexe logische Konstrukte ungeeignet machen. Zudem ist es bei der Verwendung der datenbankeigenen Mittel rund um SQL notwendig, selbst Skripte zu programmieren. Dies macht die Wartung sehr komplex, weil für alle Anpassungen SQL-Spezialisten hinzugezogen werden müssen. Aus diesem Grund sah man sich gezwungen eigene Lösungen zu entwickeln, welche die notwendige Logik zur Verfügung stellen können. Dabei haben sich grafische Benutzeroberflächen durchgesetzt, die es dem Entwickler ermöglichen Transformationen zu entwickeln, ohne manuell programmieren zu müssen. Dies kann die Entwicklungsdauer massiv verkürzen.
Ich denke, dass das Vorgehen der von den Datenbanken völlig getrennten Datentransformation heute nicht mehr als zeitgemäß ist, sondern andere Wege beschritten werden müssen. Eine Trennung der Verarbeitungslogik von den Datenbanken ist nicht mehr notwendig. Die Datenbankhersteller haben mittlerweile nachgerüstet und bieten verschiedenste Mechanismen um komplexe Verarbeitungen direkt in der Datenbank durchzuführen. Ebenso führen die steigenden Datenvolumina zu größer werdenden Performanceproblemen bei der Kommunikation zwischen ETL-Tools und Datenbanken. Deshalb lautet meine Philosophie:
Die Daten liegen in der Datenbank, also findet dort auch die Verarbeitung statt.
Deshalb sollte gute Software die Datenverarbeitung nicht selbst vornehmen, sondern sie ist als eine logische Schnittstelle zur Datenbank zu verstehen. Der Entwickler kann somit in einer grafischen Benutzeroberfläche seine Verarbeitungsvorschriften definieren und die Software setzt diese Vorschriften in entsprechende Datenbankbefehle um. Somit müssen die Daten nicht erst aus den Datenbanken zum ETL-Tool transferiert werden und nach der Verarbeitung wieder zurück, sondern die Daten verbleiben in der Datenbank.
Daraus ergibt sich der ELT-Ansatz. Die Abkürzung ELT kennzeichnet, dass die Daten eben gerade nicht vor dem Laden (L) in die Datenbank transformiert werden, sondern die Daten erst in die Datenbank gelangen und dann verarbeitet werden. Somit werden die Buchstaben (L) und (T) vertauscht.
Das alles ist nun nicht wirklich neu, und ich habe ELT auch nicht erfunden … aber ich denke die Anbieter gehen diesen Weg noch viel zu selten und nötigen die Kunden somit dazu, mehr teure Hardware zu kaufen als notwendig …