ETL / ELT

Was bedeutet ETL?
ETL steht für Extract, Transform, Load und meint, Daten aus einer oder mehreren Datenquellen zu lesen (extrahieren), aufzubereiten (transformieren) und dann in eine Senke – normalerweise eine Datenbank – hineinzuladen. Auch die Quellen sind wohl in den meisten Fällen Datenbanken. ELT macht dasselbe, dreht nur etwas an der Reihenfolge der Schritte.

Hier geht es meist um Massendaten; z.B. könnte die Aufgabe darin bestehen, den Artikelbestand der WaWi regelmäßig in die Datenbank des Webshops zu schubsen. Da können ganz schnell mal ein paar tausend oder gar zehntausend Datensätze zusammenkommen. Und diese Datenmassen stellen besondere Anforderungen an ein ETL-Tool.

Wir sprechen hier gleich von ETL-Tools, da wir uns nicht mit selbstgebastelten Programmen aufhalten sollten. Die mögen zwar exakt auf eine spezifische Aufgabe zugeschnitten, noch einen Tick mehr Geschwindigkeit herauskitzeln, professionelle Standard-Tools haben aber so viele andere Vorteile (flexible Konfigurierbarkeit, Monitoring, schnellere Umsetzung jeder neuen Aufgabe), dass sich die Do-It-Yourself-Methode einfach nicht rechnet. Das gilt, nebenbei bemerkt, natürlich auch für die anderen Konzepte EDI, EAI usw.

Worauf kommt es bei ETL an?

Zuerst mal auf Geschwindigkeit, dann auf Speed und außerdem auf Performance. 😉  Na gut, ernsthaft: Natürlich gibt es noch andere wichtige Aspekte, aber vergessen Sie nicht, es geht um Massendaten. Zur Verdeutlichung bleiben wir mal bei dem Beispiel, den Artikelstamm aus der WaWi in die Datenbank des Webshops zu transferieren.

Im simpelsten Fall passiert das, indem regelmäßig die Datenbank der WaWi komplett ausgelesen und in die des Webshops geschoben wird. Allerdings dürften zumindest die Tabellen unterschiedlich aussehen, also müssen wir den Aufbau der Daten etwas verändern. Dann hat vielleicht die WaWi spezielle Codes für die verschiedenen Länder, deren Steuersätze usw., und der Webshop braucht Länderkürzel wie DE, AT, CH und direkte Prozentangaben bei den Steuern. Das sind ein paar simple Beispiele für Transformationen.

Nun stehen wir vor einem Problem: Wir wollen ja einen sauberen Datenbestand haben. Also einen Schnappschuss des Artikelstammes der WaWi, in dem alles genau zusammenpasst. Das heißt, wir können nicht einfach ein Select-Statement feuern, das ein paar zehntausend oder hunderttausend Artikel in ein paar Minuten aus der Quell-DB holt, die sich womöglich laufend ändert. Das ergäbe inkonsistente Daten. Eine einfache Lösung dafür wäre, unseren Prozess mitten in der Nacht laufen zu lassen, wenn sich nichts am Bestand ändert. Allerdings ist dann die Webshop-Datenbasis über den Tag immer weniger aktuell. Also sollten wir den Abgleich vielleicht doch lieber mehrfach am Tag machen, vielleicht alle drei Stunden. Das bedeutet aber, dass wir während des Auslesens nichts an der WaWi ändern dürfen, die Tabellen sind also gesperrt. Auch nicht schön, wenn das mehrfach am Tag für einige Minuten der Fall ist. Deshalb also das Motto: Need for speed!

Übrigens haben wir auf Zielseite dasselbe Problem: Wenn wir den Datenbestand jedes mal komplett ersetzen, werden die Tabellen immer wieder für den Abgleich leer geputzt und neu befüllt, da ist der Webshop also unbrauchbar.
Es gibt nun verschiedene Ansätze. Beispielsweise kann man anhand eines Zeitstempels der letzten Änderung nur die Datensätze aus der Quelle holen, die sich seit dem letzten Abgleich geändert haben. Das reduziert die Datenmenge, könnte aber durch den Vergleich in der Where- Klausel des Statements das Auslesen auch gleichzeitig wieder verzögern.
Oder man bringt die WaWi dazu, selbst mit zu protokollieren, was sich seit dem letzten Transfer geändert hat und diese Daten von sich aus regelmäßig bereitzustellen. Schließlich kann man, wenn die Daten beider Datenbanken ständig synchron sein sollen, jede Änderung sofort an das ETL-Tool geben, das diese dann zur Webshop-DB weiterreicht. Damit würden sich lange Sperrungen auf beiden Seiten erübrigen, dafür ist in Summe mehr
zu tun (ändert sich ein Artikel zwischen zwei kompletten Abgleichen mehrfach, wird er nur einmal übertragen, bei sofortiger Übergabe jeder Änderung entsprechend jedes Mal).

Nicht vergessen dürfen wir den T-Teil, also die Transformation. Auch hier spielt die Geschwindigkeit eine Rolle, wenn auch keine so große wie beim Lesen und Schreiben der Quell- bzw. Zieldatenbank. Immerhin blockieren wir in dieser Phase keine anderen Systeme. Trotzdem sollte die Bearbeitung auch von hunderttausenden Datensätzen nicht gerade
eine Stunde dauern, sonst sind die Daten veraltet, bis sie am Ziel ankommen.
So eine Transformation kann im simpelsten Fall, wie schon erwähnt, die Ersetzung von Länderkennzeichen oder Steuersatzcodes sein. Genau so gehört aber auch das Eliminieren von Dubletten dazu oder andere Bereinigungen und Anreicherungen von Daten. Hier muss also oft auf Dateien mit Ersetzungstabellen, weitere Datenbanken und andere Drittsysteme zugegriffen werden. Auch die Abfrage von WebServices oder sonstigen SOA-Diensten kommt in Frage. Sie sehen, es gibt auch hier Gemeinsamkeiten mit EAI-Prozessen. Damit wären wir auch schon bei einem wichtigen Punkt. Wie oben gesagt sind spezielle ELT-Tools im Allgemeinen besser als Lösungen der Marke (weitere Gründe und Beispiele für solche Software liefert Wikipedia). Da aber in einem solchen Prozess schnell mal Arbeitsschritte nötig sind, die auch in EAI- (und EDI-) Vorgängen anfallen, sollte man im Einzelfall überlegen, ob man tatsächlich eine eigene Software nur für ETL anschafft oder vielleicht lieber ein EAI-Tool, das dieselben Aufgaben erledigt. Sicher werden Sie damit nicht ganz die extremen Geschwindigkeiten der spezialisierten ETL-Tools erreichen, möglicherweise reicht die Leistung der EAI-Software aber für Ihre Anforderungen locker aus, und Sie können das System eben gleich noch für andere Zwecke nutzen.

Nicht zu vergessen, dass Sie alle wichtigen Prozesse zentral halten und auch monitoren können, statt auf zwei Systeme zu achten. Oder auf drei, falls Sie auch noch EDI machen wollen, was heute in einem Unternehmen ja kaum noch zu vermeiden ist. Ideal ist also in vielen Fällen ein System, das in allen drei Welten zu Hause ist und überall Ihre Ansprüche erfüllt, auch wenn es vielleicht in extremen Bereichen (wie eben ETL) nicht das Optimum herauskitzelt, das Spezialtools erreichen (wenn dann vielleicht auch noch SOA-artige Fähigkeiten dazukommen …).