Das traditionelle Data Warehouse

Das traditionelle Data Warehouse

In einer typischen IT-Umgebung übernehmen, modellieren und speichern traditionelle Data Warehouses die Daten im Rahmen eines Extraktions-, Transformations- und Ladeprozesses (ETL). ETL-Tools  verschieben große Datenmengen in einer Batch-orientierten Arbeitsweise – und das in der Regel jeden Tag. Die tägliche Ausführung dieser Prozesse bedeutet im besten Falle, dass die Warehouse-Daten einige Stunden, meistens aber einen Tag oder älter sind. Eine häufigere Ausführung lässt sich nur schwer rechtfertigen, da ETLs erhebliche CPU-, Arbeitsspeicher-, Festplatten- und Netzwerkkapazitäten beanspruchen. Als APIs noch nicht so flächendeckend eingesetzt wurden wie heute, waren ETL-Tools die Lösung der Wahl für den operativen Einsatz. Jetzt, da es APIs und damit eine riesige Vielfalt an Daten gibt, ist die ETL-Methode nicht mehr praktikabel.

Doch schon in den Zeiten vor API und Big Data stellten ETL-Tools eine große Herausforderung dar, denn sie verlangten umfassende Kenntnisse über jede operative Datenbank und Anwendung.

Interkonnektivität ist sehr komplex und erfordert ein fundiertes Wissen zu jeder einzelnen Datenquelle – bis hin zur Feldebene. Je größer die Zahl miteinander verbundener Systeme, die in das Data Warehouse integriert werden sollen, desto komplizierter ist diese Aufgabe.

Schneller als je zuvor tauchen im digitalen Zeitalter neue Anforderungen auf – und die alten ändern sich. Deshalb sind Agilität und Reaktivität erfolgsentscheidende Faktoren.

So kommt es, dass Data-Warehouse-Projekten mittlerweile nachgesagt wird, eine erschreckend hohe Misserfolgsquote zu haben. Wenn sie nicht direkt scheitern, verursachen sie häufig Mehrkosten und Verzögerungen bei der Implementierung. Große Sorgfalt ist bei der Datenbank-Konzeption und der Definition der Anforderungen gefragt, um komplizierte und fragile Verbindungen nicht neu bearbeiten zu müssen. Denn selbst kleinste Änderungen haben aufgrund enger Interdependenzen oft unvorhersehbare und weitreichenden Konsequenzen.

Ein weiterer Nachteil des ETL-Warehouse-Konzepts: Die Mitarbeiter bekommen die Ergebnisse selten vor Abschluss des mehrmonatigen Entwicklungsprozesses zu sehen. Bis zu diesem Zeitpunkt haben sich die Anforderungen aber oft schon geändert. Manchmal sind auch Fehler entdeckt worden oder die Projektziele haben sich verlagert. Jeder einzelne dieser Faktoren kann die IT-Abteilung  zurück an den Schreibtisch zwingen, um die neuen Anforderungen zusammenzustellen und aller Wahrscheinlichkeit nach mehrere Monate Arbeit über Bord zu werfen. Laut Schätzungen von Gartner liefern zwischen 70 und 80 Prozent der durchgeführten Business-Intelligence-Projekte nicht die erwarteten Ergebnisse.

Ursprünglich wurden Data Warehouses eher für das betriebliche Reporting statt für die interaktive Datenanalyse entwickelt. Um ein traditionelles Data Warehouse für Analyseabfragen zu nutzen, muss man sehr sorgfältig eine passende Struktur entwickeln und umfassende, spezifische Performance-Optimierungsmaßnahmen durchführen. Wer die Daten später anders nutzen möchten, muss die Datenstruktur ändern – ein umständlicher und kostenaufwändiger Prozess.

Das grundsätzliche Problem des traditionellen ETL-Ansatzes liegt jedoch in der schieren Anzahl verfügbarer Datenquellen und den unzähligen Möglichkeiten des Datenzugriffs, z. B. in der Zunahme von APIs. APIs basieren auf Datenimport und -export und besitzen immer ein eigenes Zugriffsprotokoll. Technisch ist es zwar möglich, diese Art von Konnektivität mit ETL zu implementieren, doch die Implementierung ist extrem komplex, schwer zu managen und teuer zu erweitern. Und diese Probleme sind noch gravierender, wenn die APIs keine Datenaustauschstandards wie ODBC oder JDBC verwenden.

Mit dem digitalen Zeitalter kommen immer schneller neue Anforderungen an den Umgang mit Daten – und die altern ändern sich stetig.  Deshalb sind Agilität und Reaktivität erfolgsentscheidende Faktoren. Traditionelle Data Warehouses können mit den Anforderungen moderner Unternehmen und den Trends des digitalen Wandels einfach nicht Schritt halten. Diese Defizite waren der Grund für die Entstehung neuer Datenverarbeitungsmethoden – und der nächste Ansatz, der entwickelt wurde, hieß Multidimensionales Online Analytical Processing (OLAP).