Data Integration
Steffen Schramm Produkte ERP, Business Intelligence

Data Integration

In jeder Systemlandschaft werden Daten zwischen verschiedensten Datenquellen ausgetauscht. Beispiele solcher Datenquellen sind: Dateien (CSV, XLS, XML, …), Datenbanken (Oracle, MSSQL, Access, …), FTP-Server, Webservices, Emails, aber auch Schnittstellen zu Softwareprodukten wie Google, einem OLAP- oder LDAP-Server.

Wer schon einmal Daten zwischen zwei unterschiedlichen Systemen ausgetauscht hat kennt die damit verbundenen Probleme.

Hier einige Beispiele:

  • verschiedenes Text-Encoding (Cp1242, UTF8, ISO…)
  • unterschiedliche Datumsformate (dd.MM.yyyy, yyyy/MM/dd)
  • unterschiedliche Zahlengenauigkeit, Dezimaltrenner, …
  • interne vs. externe Schlüssel
  • verschiedenste Protokolle für die Kommunikation (http, https, ftp, file, …)
  • Massendatenverarbeitung (Performance)
  • Anpassbarkeit bei Änderung der Schnittstelle

Optimiert auf solche Austauschprozesse gibt es eine Reihe von ETL (Extract-Transform-Load)-Tools. Im Folgenden möchte ich das Tool Pentaho Kettle (Data-Integration) vorstellen, welches wir in der godesys AG einsetzen und Ihnen die Möglichkeiten aber auch Grenzen aufzeigen.

Kettle ist ein in Java geschriebenes ETL-Tool welches mittels grafischer Oberfläche Skripte erzeugt, die zur Laufzeit interpretiert und in der Java-VM ausgeführt werden. Neben dem Designer („Spoon“) werden auch Kommandozeilentools („Pan“/“Kitchen“) bereitgestellt. Alle Funktionen sind plattformunabhängig und können sowohl unter Windows als auch unter Linux eingesetzt werden.

Kettle kann zwei verschiedene Skripttypen erzeugen und ausführen:

KJB – Kettle-Job

Ein Job hat einen definierten Startpunkt und durchläuft die einzelnen Schritte sequenziell.

Kettle-Job

Das dargestellte Beispiel zeigt einen einfachen Kettle-Job, welcher nach dem Start die Transformation „read Properties“ aufruft. Nach erfolgreicher Ausführung dieses Schrittes wird ein Job ausgeführt welcher im Anschluss die Transformation erfolgreich beendet. Bei einem Fehler wird ein Email-Schritt aufgerufen, der den aufgetretenen Fehler kommuniziert. An diesem Beispiel kann man gut erkennen, dass ein Kettle-Job sowohl Kettle-Transformationen, als auch weitere Kettle-Jobs geschachtelt aufrufen kann.

KTR – Kettle-Transformation

Im Gegensatz zu einem Job kann eine Transformation mehrere Start-Schritte besitzen. Jeder Schritt ohne hereinkommende Kante ist ein Start-Schritt. Eine Kettle-Transformation nutzt das sogenannte Pipeline-Prinzip. Beim Start der Transformation werden alle Schritte parallel initialisiert. Die Start-Schritte beginnen Daten einzulesen und diese an den entsprechenden Folgeschritt weiter zu geben.

Kettle-Transformation

In dieser Abbildung sollen z.B. 100.000 Datensätze aus einer CSV-Datei gelesen werden („Read file“). Der entsprechende Schritt liest nicht alle 100.000 Datensätze auf einmal sondern erst einmal „nur“ 10.000* Datensätze. Diese werden an den Folgeschritt „Filter rows“ weitergeleitet, welcher sofort die Verarbeitung beginnt. Gleichzeitig kann der Schritt „Read file“ weitere 10.000 Datensätze einlesen. Somit befinden sich 20.000 Datensätze in der Pipeline. Idealisiert betrachtet können bis zu 50.000 Datensätze parallel durch das Skript verarbeitet werden (jeweils 10.000 pro Schritt). Ohne alle Schritte weiter im Detail zu beschreiben sei hier exemplarisch noch der Schritt „Filter rows“ kurz erwähnt. Dieser filtert, wie der Name schon sagt, die ihm übergebenen Datensätze entsprechend einer festgelegten Bedingung. Alle Datensätze die diese Bedingung erfüllen verlassen den Schritt Richtung „Calculator“ und alle übrigen Datensätze in Richtung „Java Script“.

Stärken von Kettle

  • plattformunabhängig auf Windows und Linux (Designer und Kommandozeile)
  • sehr viele standardmäßig ausgelieferte Schritte für Lesen, Schreiben und Transformieren von Daten
  • grafischer Designer mit Debugging-Funktion
  • Pipeline-Prinzip für eine sehr hohe Verarbeitungsgeschwindigkeit von Massendaten
  • viele Schritte besitzen eine Caching-Funktionalität welche die Verarbeitungsgeschwindigkeit deutlich verbessern kann (z.B. Ergebnisse gleicher DB-Selects in Arbeitsspeicher puffern und wiederverwenden)
  • hoch spezialisierte Schritte, welche die Komplexität kapseln und nur per Konfiguration gesteuert werden
  • keine Programmierkenntnisse notwendig (Ausnahme: Schritte wie „Java Script“; muss man aber nicht verwenden)

Aus diesen Stärken lassen sich z.B. folgende Einsatzgebiete benennen, in denen Kettle einen sehr hohen Nutzen bringen kann:

  • Export großer Datenbestände aus einer Datenbank in ein Textfile(z.B. CSV); ohne Probleme könnten mehr als 1.000.000 Datensätze (z.B. Artikelstamm, Kundenstamm, Buchungssätze) incl. Anpassung der Formatierung in wenigen Minuten exportiert werden
  • Export von Daten als XLS zur Weiterverarbeitung in Excel
  • Import großer Datenmengen in eine Zieltabelle
  • Befüllen eines DWH(Data-Warehouse) auf Basis unterschiedlichster Daten und Datenquellen

Beispiele für Grenzen des universellen Einsatzes

In diesem Abschnitt geht es nicht darum Kettle als Tool schlecht zu reden, vielmehr möchte ich Szenarien aufzeigen, welche mit Kettle nur schwierig, gar nicht oder ohne wirklichen Nutzen umsetzbar sind. Ich hoffe, dass diese Grenzen die optimalen Einsatzgebiete verdeutlichen und Projektfehler verhindern.

Anlage von Daten ohne Geschäftslogik der primären Anwendung

Beispiel: Import von Artikeln aus einem CSV-File in ein ERP-System

Grundsätzlich klingt dies nach einem Paradebeispiel für den Einsatz von Kettle. Vergessen sollte man hier aber nicht, dass das Ziel zwar eine Datenbank ist (die Struktur ist evtl. sogar bekannt), deren Geschäftslogik aber außerhalb der Datenbank programmiert ist. Um einen gültigen Artikel anzulegen müssten die gesamte Geschäftslogik in Kettle nachgebaut werden (evtl. hoher Aufwand!). Auch besteht die Möglichkeit, dass man mit der Geschäftslogik der primären Anwendung in Konflikt gerät (ERP und Kettle laufen parallel und schreiben gleichzeitig in die DB). Aber auch wenn man die Logik in Kettle nachstellt, so besteht stets die Gefahr, dass sich die Geschäftslogik des ERP-System ändert und Kettle nicht automatisch diese Änderung übernimmt.

Verarbeitung sehr kleiner Datenmengen in sehr kurzen Intervallen

Beispiel: Jede Sekunde soll auf neue Datensätze in einer Datenbank geprüft werden, um diese Daten anschließend weiter zu verarbeiten.

Das Problem dieses Szenarios ist, dass Kettle für den Start jedes Jobs und jeder Transformation eine Initialisierungszeit von wenigen Sekunden benötigt. Folglich überschreitet die Initialisierungszeit bereits das gesetzte Intervall ohne dass auch nur ein Datensatz gelesen wurde. Hat man eine einzelne Transformation, welche 100.000 liest und verarbeitet, so verliert sich die Initialisierungszeit in der Menge der verarbeiteten Daten, da die Transformation nur einmal initialisiert wird.

Reihenfolge gelesener Daten

Bleiben wir bei dem Beispiel aus der 2. Abbildung und gehen davon aus, dass die Daten im CSV-File eine Ordnung haben und auch genauso in das Zielsystem zu überführen sind. Der „Read file“ Schritt liest die Daten in der korrekten Reihenfolge sequenziell ein und übergibt diese auch in der korrekten Reihenfolge an den nachfolgenden Schritt („Filter rows“). Genau an dieser Stelle wird auf Grund der Aufteilung des Datenstromes die vorhandene Sortierung aufgehoben. Da der „Java Script“-Schritt langsamer bei der Verarbeitung eines Datensatzes ist als der „Calculator“-Schritt, können Datensätze von weiter hinten, die Datensätze, welche über den „Java Script“-Schritt laufen, überholen und folglich die Sortierung aufheben. Zwar gibt es für dieses Problem z.B. den „Sort rows“-Schritt, jedoch ist dieser mit Vorsicht zu verwenden. Eine Sortierung auf 100.000 Datensätzen bedingt, dass auch alle 100.000 Datensätze im Sortierschritt vorhanden sind, d.h. an dieser Stelle wird das Pipeline-Prinzip ausgehoben. Zusätzlich wird hier viel Arbeitsspeicher verwendet (Puffer für die Sortierung) und mit einem Datei-basierten Temp-File gearbeitet (schlechte Performance).

Schleifen in der Verarbeitungslogik

Beispiel: Daten eines bestimmten Datums selektieren und dieses Datum nach vollständiger Verarbeitung als „fertig“ markieren. Anschließend die Verarbeitung für den Folgetag wiederholen. (Schleife soll hier dafür sorgen, dass die Sortierung der Tage definitiv erhalten bleibt).

Designt man eine solche Schleife, in der z.B. eine Transformation ausgeführt wird, so kann es bei einer hohen Anzahl von Schleifendurchläufen zu eines Speicher-Überlauf kommen. Grund ist, dass Kettle für jeden Schleifendurchlauf eine neue Instanz der Transformation erzeugt und diese auch nach dem Schleifendurchlauf erhalten bleibt. Generell sind Schleifen in Kettle nicht vorgesehen, was seinen Grund in der Architektur und Zielstellung des Tools hat.

XML schreiben oder lesen

Kettle bietet Schritte zum Lesen und Schreiben von XML. Input (bei XML-Output) oder Output (bei XML-Input) sind aber denn noch sequenzielle Datensätze. Komplexe XML-Strukturen lassen sich nicht einfach aus sequenziellen Daten erzeugen. Auch problematisch sind dynamische XML-Strukturen, also z.B. dynamisch viele Kind-Elemente eines XML Vater-Elementes.

Transaktionshandling

Beispiel: Import von Rechnungen mit insgesamt ca. 100.000 Rechnungspositionen.

Wurde für dieses Beispiel eine Transformation erstellt, welche die 100.000 Rechnungspositionen importiert und der letzte Schritt dieser Transformation ist ein „Table output“-Schritt, so kann hier eine Commitsize z.B. auf 1.000 gesetzt werden. Hierdurch wird ein Commit erst nach 1.000 INSERT-Befehlen ausgeführt, was sich positiv auf die Performance auswirkt. Das Problem dieser Transaktionssteuerung ist, dass bei einem Fehler alle Datensätze vor einem Commit nicht persistiert werden. Aus fachlicher Sicht wäre es sinnvoll bei einem Fehler einer Rechnungsposition alle Positionen der zugehörigen Rechnung zurück zu rollen (rollback). Dies muss aber explizit in Skript designt werden, was mehr als nur einer einfachen Transformation bedarf.

Fazit

Kettle ist ein sehr gutes Tool und kann vor allem durch die Vielzahl seiner standardmäßig mitgelieferten Schritte und der hohen Performance punkten. Die Einsatzgebiete sind klar abgegrenzt und stehen nicht in Konkurrenz zu Funktionen einer ERP-Software, vielmehr ergänzen sie diese sinnvoll. Wir bei der godesys setzen Kettle unter anderem im Bereich Business Intelligence (BI) ein, da die Ausgangsbedingungen hier optimal sind:

  • einfaches DB-Schema ohne komplizierte Geschäftslogik (einfache Dimensionen- und Faktentabellen)
  • Massendaten aus dem ERP werden aus der Datenbank selektiert und ohne Schleifen oder Sortierungen in das Data Warehouse (DWH) geschrieben
  • Lookups im DWH können mittels Caching der Lookup-Schritte performant umgesetzt werden
  • Nutzung der speziellen DWH-Schritte welche standardmäßig mitgeliefert werden
  • große Vielfalt an weiteren Schritten um Daten aus verschiedensten Fremdsystemen in das DWH zu importieren
  • optimale Integration mit godesys BI und godesys extended BI

*Die Zahl 10.000 und auch alle weiteren Mengenangaben sind fiktiv und sollen nur das Pipeline-Konzept verdeutlichen. Konkrete Zahlen können nicht benannt werden, da es sich um interne Prozesse von Kettle handelt.

Weitere Informationen

    0 Kommentare

    Neuen Kommentar schreiben

    Dies ist ein Pflichtfeld!
    Keine Kommentare gefunden!