ETL beschleunigen mit Big Data-Technologien?

Business Intelligence, Data Science

Unter dem Stichwort „Big Data“ entwickelt sich seit einigen Jahren eine immer weiter steigende Anzahl interessanter Technologien, die eine verteilte bzw. parallelisierte Speicherung und Verarbeitung von großen Datenmengen unterstützen. Lassen sich diese Technologien auch für das Data Warehouse nutzen?

Vor allem die parallele Durchführung von ETL-Prozessen, die ja typischerweise IO-intensiv sind, verspricht Vorteile. Doch muss man die ETL-Prozesse dafür neu programmieren? Welche Architektur ergibt sich? Fragen, denen die viadee in einer Studie nachgegangen ist!

Zentral für heutige Big Data-Ansätze ist Hadoop, das quelloffene, verteilte Dateisystem, das eine einfache Möglichkeit zur Speicherung großer Datenmengen in einem Cluster aus günstigen Einzelrechnern bietet. Daten werden in Hadoop auf mehrere Rechner verteilt, auf denen dann auch die Verarbeitung lokal stattfinden kann, so dass jeder Rechner nur „seinen“ Teil der Daten verarbeitet. Je mehr Rechner, desto breiter kann parallelisiert werden, sofern keine Abhängigkeiten zwischen den Rechenschritten bestehen. Typische ETL-Prozessschritte wie Filtern, Bereinigen, Umkodieren, Lookups und Aggregieren erfüllen diese Voraussetzungen. Um dies auszunutzen, ohne die gesamte DWH-Architektur umzuwerfen, bietet sich eine Architektur an, die nur die ETL-Verarbeitung auf Hadoop auslagert:

Zielarchitektur

ETL-Prozesse sind jedoch in vielen Unternehmen das Herz des Data Warehouse – es steckt viel fachliches Wissen darin und dementsprechend viel Arbeit. Muss diese Arbeit erneut investiert werden, um die oben skizzierte Architektur zu verwirklichen? Im Folgenden wird ein Ansatz vorgestellt, der die Hauptarbeit der Umstellung automatisiert vornimmt!

Dabei wird von folgendem Ausgangsszenario ausgegangen: Die Quelldaten liegen in klassischen Datenbanken (oder Dateien) und auch das Data Warehouse wird – dimensional in Sternschemata modelliert – in einer relationalen Datenbank abgelegt. Für den Transport von der Quelle ins DWH wird ein ETL-Werkzeug mit grafisch modellierten, direkt im Werkzeug ausführbaren Prozessen genutzt. In diesem Szenario finden die ETL-Transformationen je nach Ausprägung auf einem ETL-Server oder in der Zieldatenbank statt. Das folgende Bild veranschaulicht den Unterschied zur Zielarchitektur:

Ausgangssituation

Als Beispiel diente in unserer Studie das ETL-Werkzeug Talend – aus zwei Gründen: seine Prozesse sind als XML-Dateien lesbar, und es gibt Hadoop-fähige Versionen seiner ETL-Schritte (in der Big Data Edition von Talend). Selbstverständlich erfüllen auch andere ETL-Werkzeuge diese Voraussetzungen.

Die Aufgabe besteht in diesem Szenario darin, die XML-Definition eines vorhandenen ETL-Prozesses zu lesen und daraus die XML-Definition eines neuen, Hadoop nutzenden Prozesses zu erstellen, der die gleiche inhaltliche Aufgabe erfüllt. Im neuen Prozess dient das ETL-Werkzeug „nur“ zur Steuerung von Transformationen, die in Hadoop ausgeführt werden, aber nicht mehr zur Datenverarbeitung. Durch die Ausführung in Hadoop sind die Transformationen automatisch parallelisiert.

In der Zielarchitektur werden Daten aus den Quellsystemen im ersten Schritt unverändert in den Hadoop-Cluster geladen. Dazu bietet sich das freie Werkzeug Sqoop (SQL to Hadoop) an, das Daten aus klassischen Datenbanken nach Hadoop laden kann oder aus Hadoop zurück in die Datenbank; Dateien mit Quelldaten können direkt ins Hadoop-Dateisystem kopiert werden. Die Sqoop-Skripte zum Lesen aus den Quellsystemen können automatisch aus den früher programmierten Zugriffen auf die Quellsysteme abgeleitet werden, da Sqoop SQL nutzt; somit bleiben auch die Selektionsbedingungen erhalten. Sqoop parallelisiert bereits das Schreiben nach Hadoop (indem es MapReduce-Jobs zur Ausführung des Datentransports generiert).

Nachdem so die unveränderten Quelldaten in Hadoop angekommen sind, folgen nun die Transformationen. Betrachten wir als einfaches Beispiel einen Schritt innerhalb eines ETL-Prozesses, in dem nur eine Filterbedingung angewendet wird. Talend stellt eine Komponente zur Verfügung, mit der eine Filterung in Hadoop ausgeführt werden kann – dabei wird Pig-Code erzeugt, der in Hadoop ausführbar ist (Pig ist eine für ETL nützliche Sprache, deren Anweisungen wiederum in MapReduce-Jobs übersetzt werden). Der neue ETL-Prozess wird also diese Hadoop-fähige Komponente einsetzen, wo der alte Prozess den klassischen Filter eingesetzt hatte. Die Filterbedingung wird dabei in diesem Fall von Java-Syntax in Pig-Syntax übersetzt.

Grundsätzlich funktioniert dieses Vorgehen in gleicher Weise auch für komplexere Schritte (und es funktioniert auch für andere Zielsprachen als Pig, sofern diese vom verwendeten ETL-Werkzeug unterstützt werden). So wird der neue, Hadoop-fähige Prozess Schritt für Schritt erstellt und die Schritte werden gemäß der vorgefundenen Abhängigkeiten verbunden. Auch Aggregationen, Joins, Unions und Umkodierungen können grundsätzlich so behandelt werden. Im Fall von Joins kann die Auswahl der verteilten Join-Methode (replicated vs. regular join) von gespeicherten Metadaten zur Größe der verknüpften Tabellen abhängig gemacht werden oder dem Nutzer überlassen werden.

Wenn wir von einem dimensional modellierten Zielschema im DWH ausgehen, müssen die neu eintreffenden Daten mit den Dimensionen des DWH verglichen werden, um den „Slowly changing dimensions“-Mechanismus abzubilden. Dabei müssen Änderungen gegenüber dem DWH je Datensatz erkannt werden. Dies geschieht am besten über Hashwert-Vergleiche, bei denen der Hashwert über alle relevanten Attribute gebildet wird. Dazu werden die fachlichen Schlüssel und die aktuellen Hashwerte jeder Dimension vor Beginn der ETL-Ausführung ebenfalls in den Hadoop-Cluster kopiert und dort als eine Hilfstabelle je Dimension abgelegt. Die Hilfstabellen dienen als Lookup-Tabellen während der ETL-Ausführung. Da sie nur wenige Spalten haben (eine pro fachlichem Schlüsselattribut plus Hashwert), sind die Lookups über einen „Replicated Join“ ausführbar, bei dem die Hilfstabellen auf alle Rechner des Clusters verteilt werden, um parallel arbeiten zu können.

In der Regel wird ein auf diese Weise automatisch Hadoop-fähig gemachter Prozess noch manuell nachbearbeitet werden müssen. Die automatische Übersetzung spart jedoch sehr viel Detailarbeit und ist deutlich weniger fehleranfällig. Sie sorgt außerdem dafür, dass die ETL-Schritte nach einem einheitlichen Muster migriert werden; und wer den Ausgangsprozess kennt, wird sich im übersetzten Prozess auch sofort zurechtfinden, da die Struktur bzw. die wesentlichen Datenflüsse erhalten bleiben. Mit 20 Prozent des Aufwands sind 80 Prozent der Arbeit getan!

Sie möchten mehr über Big Data im Kontext von Data Warehousing wissen? Sprechen Sie uns an!