Performance-Faktoren von IBM DataStage

Ein Blick in die Architektur und Performance von IBM DataStage

uml ibm datastage

Das Extrahieren, Transformieren und Laden von Daten gehört für viele Unternehmen, zur alltäglichen Routine. Um diesen Prozess abzubilden, gibt es eine Fülle von verschiedenen ETL-Tools am Markt. Eines davon ist IBM DataStage, welches Bestandteil des IBM InfoSphere Softwareangebots ist. Schlagwörter wie „Cluster Computing“ und „horizontale Skalierbarkeit“ scheinen in den letzten Jahren vor allem durch Big-Data-Technologien ein neuer Trend geworden zu sein. Schon davor hat das etablierte und als Marktführer bezeichnete ETL-Tool IBM DataStage einige derartige parallele Konzepte vereinigt und für die breite ETL-Kundschaft im Angebot.

IBM DataStage

IBM DataStage ist Bestandteil von IBMs InfoSphere-Information-Server-Softwareangebots. Das Portfolio umfasst verschiedene informationsverarbeitende Applikationen mit der Zielsetzung, dem Kunden eine zentrale, agile End-2-End-Infrastruktur für die Verarbeitung und Erzeugung von präzisen, konsistenten, aktuellen und kohärenten Informationen zu bieten. Seit mehreren Jahren gilt IBM DataStage als einer der etablierten Marktführer im Bereich ETL. Ein großer Vorteil der Software-Suite sind die „Parallel Processing“-Möglichkeiten und die daraus resultierende Performance. Der Ursprung der parallelen Funktionen geht auf die Firma Ascential Software zurück. Diese kaufte zu damaliger Zeit die Rechte an Orchestrate, einem ETL-Werkzeug mit gleichnamigem Framework für parallele Shell-Ausführungen, und integrierte diese in DataStage. Dies erlaubt DataStage eine hohe parallele Skalierbarkeit [2-4].

Der nachfolgende Artikel gibt einen Einblick in die Architektur der Software und erörtert einige Performance-Aspekte von IBM DataStage. Für einen gelungenen Einstieg zu dem Thema ETL und insbesondere DataStage bietet sich die dreiteilige ORDIX® news Reihe „ETL im Data Warehouse am Beispiel IBM DataStage“ an.

Architektur

DataStage kann grob in drei Komponenten aufgeteilt werden, die anhand der Abbildung 1 im Folgenden beschrieben werden.

  • DataStage-Repository: Bezeichnet den Speicherort der Metadaten von IBM DataStage und insbesondere der jeweiligen ETL-Strecken. Das Repository liegt in einer relationalen Datenbank und ist nicht beschränkt auf IBM DB2. Die parallele Job-Engine, auf denen ein paralleler DataStage-Job aufbaut, basiert auf einer proprietären Skriptsprache namens OSH (Orchestrate). Datastage-Jobs werden in OSH-Skripte übersetzt und ebenfalls im Repository neben weiteren Informationen wie beispielsweise Datenbankverbindungen, selbstdefinierten Parametern, Routinen und software-spezfischen Informationen abgelegt.
  • DataStage-Client-Applikationen: Bestehen aus mehreren grafischen Benutzeroberflächen, die das Konfigurieren, Überwachen, Designen und Verwalten von ETL-Strecken und Metadaten erlauben. Die Client-Applikationen müssen sich über einen DataStage-Server mit einem Repository verbinden, da dies der Speicherort aller Informationen und Metadaten ist. Innerhalb des DataStage-Designers werden die Schnittstellen über eine grafische Oberfläche erstellt und anschließend in die Skriptsprache OSH kompiliert.
  • DataStage-Engine: Bezeichnet die Server-Applikation, die auf einem oder mehreren Servern als Single- oder Multiserver-Cluster-Konfiguration installiert ist. Zur Laufzeit eines parallelen Jobs wird auf jedem konfigurierten Serverknoten das Kompilat der Schnittstelle verteilt und ausgeführt. Abhängig von der jeweilige Schnittstelle verbinden sich dann die Knoten mit den verschiedenen Datenquellen und Zielsystemen und extrahieren, transformieren und laden Daten gemäß der definierten Datentransformationen.

Datenpartitionierung & Parallele Verarbeitung

Der mit unter größte Performance-Faktor wird durch die Anzahl der bereitgestellten Knoten in Verbindung mit den darunter liegenden Servern bestimmt. In der Praxis verwendet man mehrere Server mit der DataStage-Installationsinstanz, auf denen wiederum ein oder mehrere Knoten konfiguriert sind. Jeder Knoten verarbeitet zu der Laufzeit einer Schnittstelle die jeweiligen Daten. Entscheidend ist dabei die Aufteilung der Daten auf die verschiedenen Knoten. Dies kann über sogenannte „Partitioners“ innerhalb der Schnittelle definiert werden. Die zu verarbeitenden Daten werden partitioniert und über das Netzwerk auf die verschiedenen Knoten aufgeteilt. Auf jedem Knoten wird anschließend die Verarbeitung unabhängig voneinander parallel ausgeführt. Die Art der Partitionierung wird über den Partitioner festgelegt. Es wird unterschieden zwischen schlüsselbasierten Partitionierungen und nicht schlüsselbasierten Partitionierungen. Bei nicht-schlüsselbasierten Partitionierungen können die Datensätze unabhängig der jeweiligen Spaltenwerte erteilt werden. Hierunter zählen Partitionierungsfunktionen wie „Round Robin“, „Random“, „Entire“ und „Same“. Bei der schlüsselbasierten Partitionierung werden einzelne Spaltenwerte berücksichtigt. Beispielsweise kann die Datenverteilung anhand der Hash-Werte bestimmter Spalten erfolgen oder durch eine Modulus-Berechnung auf Integer-basierten-Spalten.

Einige Verarbeitungsschritte, wie beispielsweise das Bilden einer Summe oder das Joinen verschiedener Datenströme, setzen eine korrekte Aufteilung der Daten voraus. Nur Daten, die gemeinsam auf einem Knoten liegen, werden gemeinsam verarbeitet. Wir nehmen an, dass einzelne Umsätze von jeweils verschiedenen Produktkategorien vorliegen. Möchte man beispielsweise die Umsatzsummen von den jeweiligen Produktkategorien ermitteln, so müssen die jeweiligen Umsatzzahlen einer Produktkategorie in der gleichen Partition liegen.

Ziel der Partitionierung für eine performante Verarbeitung ist eine gleichmäßige Verteilung der Daten auf den verschiedenen Knoten unter der Maßgabe, die Anzahl an Repartitionierungen gering zu halten. Abbildung 2 zeigt die Partitionierung von fünf Datensätzen auf zwei verschiedenen Knoten. Die Partitionierung erfolgt nicht-schlüsselbasiert anhand einer Round-Robin-Funktion. Diese teilt die Datensätze, wie bei der Verteilung von Karten bei einem Kartenspiel, gleichmäßig auf. Jeder Knoten führt anschließend unabhängig von einander die anstehenden Verarbeitungsschritte aus.

Neben den Partitioners existieren sogenannte „Collectors“. Diese sind dafür zuständig, die Daten von mehreren Partitionen für eine sequenzielle Verarbeitung wieder zu vereinen. Zum Beispiel erfolgt das Schreiben von Daten in eine Datei (Sequential-File) sequenziell. Sind die Daten vorher über mehrere Knoten partitioniert, so vereinigt ein Collector zunächst die Daten auf einem Knoten, bevor die Daten in die Datei geschrieben werden. Eine detaillierte Auflistung der möglichen Partitionierungsarten können in den kostenfreien erhältlichen IBM Redbooks [1] entnommen werden.

Parallele DataSets

Die Notwendigkeit, Daten zwischenzuspeichern, ist vielfältig. Beispielsweise benötigt man ein Set von Daten in mehreren Verarbeitungen und möchte ähnliche oder gleiche Vortransformationen nur einmal ausführen. Oder man möchte Jobabschnitte definieren mit Restart-Points, wodurch das Speichern von Zwischenergebnissen notwendig ist. Für dieses Speichern eignet sich die Verwendung von „DataSets“ mit der namensgleichen DataSet-Stage. Während in sequenziellen Jobs die Daten in sequenziellen oder Hash-basierten Dateien zwischengespeichert werden, so werden im Parallel Framework DataSets verwendet. Diese ermöglichen das parallele Speichern und Lesen von Daten auf den jeweils konfigurierten Knoten. Dabei wird die vorherige Datenpartitionierung und Datensortierung beibehalten. Zudem werden die Daten in einem DataStage-spezifischen binären Datenformat gespeichert, welches ein performanteres Lesen und Schreiben ermöglicht, da die Daten nicht erst gesondert interpretiert werden müssen.

Beispiel-Job Umsatzsummierung

Eine typische DataStage-Verarbeitung besteht aus mehreren von einander abhängigen Stages. Eine Beispielverarbeitung ist in Abbildung 3 dargestellt. Es wird angenommen, dass ein DataSet mit Umsätzen für einzelne Produktverkäufe existiert. Ein anderes DataSet beinhaltet zu verschiedenen Produkten die Produktkategorie. Ziel ist es, die Umsatzzahlen je Produktkategorie zu ermitteln. In einem ersten Schritt werden die Daten über die DataSet-Stages DS_Umsatzzahlen und DS_Produktdaten ausgelesen und die Umsatzzahlen mit Produktdaten angereichert (LookUp-Stage LKP_Produktdaten). Zuvor werden für den Reference-Stream get_produktdaten alle nicht benötigten Felder gelöscht, um die Datenmengegering zu halten (Modify-Stage DROP_Unused_columns). In einem zweiten Schritt werden die Umsatzzahlen in das richtige Format transformiert (Transformer-Stage TR_Umsatz_Produktdaten). In einem dritten Schritt werden die Umsätze aggregiert zum Bilden einer Umsatzsumme(Aggregator-Stage AGG_Umsatzsumme). Schlussendlich werden die Daten in die Datenbank geschrieben (Oracle-Stage OC_Write_T_UMSATZSUMME).

Inter-Operator Transport Buffering

Die einzelnen Verarbeitungsschritte sind abhängig von dem vorherigen Verarbeitungsschritt und die Daten müssen jede Stage gemäß der Pfeile durchlaufen. In einem DataStage-Sequential-Job wird jeweils jeder Prozessschritt einzeln und sequenziell auf diese gesamte Datenmenge angewendet, bevor der zweite Prozessschritt beginnt. DataStage-Parallel verarbeitet die Daten blockweise.

Wenn ein Block in Schritt 1 erfolgreich mit Produktdaten angereichert wurde, dann wird dieser Block bereits an Prozessschritt 2 übergeben und beginnt mit der Transformierung, während Prozessschritt 1 den entsprechend nächsten Datenblock verarbeitet. Einige Stages benötigen alle Daten oder eine entsprechende Datengruppe, um mit der Verarbeitung fortfahren zu können. Beispielsweise erfordert die Summierung der Umsatzzahlen, dass alle Umsätze für eine Produktkategorie bereits fertig transformiert wurden. In dem Beispiel wird angenommen, dass die Daten bereits nach Produktkategorie vorsortiert sind. Daher werden die Daten vor Prozessschritt 3 entsprechend pro Produktkategorie gepuffert, bis eine Aggregierung stattfinden kann. Dieses Vorgehen wird als Inter-Operator Transport Buffering bezeichnet und sorgt für eine gleichmäßige Auslastung der Ressourcen, da die Daten sich jeweils auf die Prozesse verteilen können.

Operator Combination

Zur Laufzeit eines Jobs wird anhand der hinterlegten Konfigurationen und des Job-Designs ein Ausführungsplan für den Job erstellt. Dieser bestimmt die genauen Prozesse und die Ausführungstopologie für die Jobausführung. Bei dem Erstellen des Ausführungsplan wird versucht, die Logik von verschiedenen Stages zusammenzulegen, um so die Anzahl benötigter Prozesse auf jedem Knoten zu reduzieren. In der Regel würde pro Stage ein Prozess auf jedem Knoten gestartet werden. Über die Funktion Operator Combination werden so verschiedene Schritte in einem Prozess erledigt. Dadurch wird Overhead auf den einzelnen Knoten vermieden und die Gesamtperformance steigt. Während der Ausführung des unten dargestellten Jobs kann es beispielsweise passieren, dass anstelle des Auslesens des gesamten DataSets DS_Produktdaten und dem anschließenden Löschen einiger Spalten nur die benötigen Spalten ausgelesen werden.

Schlusswort

Die in den vorherigen Abschnitten besprochenen Faktoren ermöglichen DataStage eine sehr solide Performance. Dadurch kann sich das Produkt weiterhin mit an der Spitze des Gartner Magic Quadrants behaupten. Nichtsdestotrotz bilden die hier vorgestellten Eigenschaften lediglich die Grundlage für eine performante Verarbeitung. Letztendlich spielen auch weitere Faktoren eine Rolle:

  • Das Job-Design: Werden Daten transferriert, die in der Verarbeitung nicht benötigt werden? Werden die Datenströme sinnvoll und effektiv verarbeitet? Ist die Verarbeitungsreihenfolge sinnvoll oder gibt es unnötige Berechnungen? Können Repartitionierungen und Sortierungen eingespart werden?
  • Das Server Sizing/Hardware: Sind die Maschinen, auf denen die DataStage-Knoten laufen, ausreichend dimensioniert? Stimmt die Netzwerkperformance? Ist genügend RAM bzw. schneller Scratch-Speicher verfügbar?
  • Die Konfiguration: Wurde den DataStage-Knoten ausreichend RAM und Speicherplatz für ihre Berechnungen zugeordnet? Stimmen die eingestellten Puffergrößen mit den Anforderungen überein?

Spannend bleibt auch der Blick in die Zukunft. Die ETL Werkzeugauswahl ist vielfältig und besteht neben alteingesessenen Marktführern wie IBM und Informatica auch aus neuen Herausforderern wie Oracle, Talend oder Pentaho. Die Qual der Wahl wird zunehmend größer und bedarf einer präzisen Abbildung der unternehmensspezifischen Anforderungen an eine Softwarelösung. Neben erforderlichen Leistungsfähigkeiten müssen auch einzuhaltende Nebenbedingungen sorgfältig identifiziert werden. Mehr dazu, gibt es in einer der folgenden ORDIX® news.

Tobias Ummler ()