Parallele Verarbeitung im Data Warehouse
Die Verarbeitung großer Datenmengen ist typisch für Data Warehouse Umgebungen. Abhängig von den zur Verfügung stehenden Hardwareressourcen wird früher oder später der Punkt erreicht, an dem ein Job nicht mehr auf einem einzelnen Prozessor verarbeitet, bzw. nicht mehr durch einen einzelnen Prozess dargestellt werden kann. Die Gründe dafür sind etwa:
- Zeitliche Anforderungen erfordern den Einsatz mehrerer Prozessoren
- Die Systemressourcen (Speicher, Plattenplatz, temporärer Tablespace, Rollback-Segmente, . . .) sind begrenzt.
- Wiederkehrende Fehler erfordern die Wiederholung des Prozesses.
- Parallelisierung durch RDBMS-Parallelverarbeitung
Moderne Datenbanksysteme sind in der Lage, Abfragen parallel zu verarbeiten. Abfragen und manchmal auch Änderungen an großen Datenmengen können innerhalb des Datenbankservers parallelisiert werden und mehrere Prozessoren gleichzeitig nutzen.
Die Vorteile dieser Lösung:
- Es ist kein bzw. nur geringer Entwicklungsaufwand erforderlich
- Es entsteht nur ein geringer Overhead durch diese Art der Parallelisierung
Die Nachteile:
- Die Kontrolle über den Grad der Parallelisierung ist sehr eingeschränkt
- Eine Änderung der Anzahl der parallel ausgeführten Prozesse zur Laufzeit ist in der Regel nicht möglich
- Im Falle eines Fehlers geht die gesamte bisher geleistete Arbeit verloren
- Erforderliche Datenbank Systemressourcen (Temp Tablespace, Rollback Segmente, . . .) müssen für die komplette Operation ausreichend zur Verfügung stehen
- Die Ressourcennutzung ist oft nicht deterministisch, was in Systemen mit starkem Bedarf an Ressourcenkontrolle zu Problemen führen kann
- Der Einfluss der Parallelisierung auf den Rest des Systems ist sehr unvorhersehbar bzw. nicht planbar.
Die RDBMS-Parallelverarbeitung eignet sich daher vor allem zur Beschleunigung von Operationen durch den Einsatz mehrerer Prozessoren. Sind die Systemressourcen nicht im Überfluss vorhanden, machen sich die Nachteile stärker bemerkbar, was insbesondere für trotz Parallelisierung lang laufende Prozesse gilt.
Parallelisierung auf Anwendungsebene
Alternativ zur RDBMS-internen Parallelisierung ist es in den meisten Fällen möglich, einen Prozess in mehrere Teilprozesse aufzuteilen, die parallel ausgeführt werden können.
Die Vorteile dieser Lösung:
- Volle Kontrolle über den Grad der Parallelisierung ist möglich
- Die Anzahl der aktiven Teilprozesse zu einem bestimmten Zeitpunkt ist dynamisch einstellbar
- Fehler innerhalb eines Teilprozesses machen die Arbeit der anderen erfolgreich ausgeführten parallelen Prozesse nicht (unbedingt) ungültig. Die Auswirkungen von Fehlern auf die Gesamtlaufzeit werden reduziert.
- Systemressourcen müssen nur für den Bedarf der gleichzeitig laufenden Prozesse zur Verfügung stehen. Die Ressourcennutzung ist besser planbar und der Einfluss auf das übrige System ist dynamisch einstellbar
Die Nachteile:
- Die Implementierung ist ohne die Unterstützung durch ein geeignetes Scheduling-System sehr teuer
- Der Overhead für die Zusammenführung der Ergebnisse ist in der Regel höher als bei der RDBMS-internen Parallelisierung
Die Gegenüberstellung der Vor- und Nachteile der anwendungsbasierten Parallelisierung zeigt, dass insbesondere für sehr teure und lang laufende Prozesse in Umgebungen mit begrenzter Ressourcenverfügbarkeit die anwendungsbasierte Lösung der RDBMS-internen Parallelisierung vorzuziehen ist. Gerade in Data-Warehouse-Umgebungen sind Prozesse mit diesen Eigenschaften häufig anzutreffen.
Implementierung
Die Implementierung der anwendungsbasierten Parallelisierung erfordert immer diese drei bis vier Teilaufgaben:
- Zerlegung eines Prozesses in parallel ausführbare Teilprozesse
- Implementierung der Teilprozesse
- Implementierung der Kontrollfunktion der parallelen Ausführung der Teilprozesse
- Optional die Implementierung des Merge-Prozesses der Teilergebnisse
Beispiel
In einem Data Warehouse existiert ein SQL-Skript, das eine sehr große partitionierte Datenbanktabelle aggregiert und das Ergebnis in einer Ergebnistabelle speichert. Da dieser Prozess inzwischen mehr als den verfügbaren TEMP-Speicherplatz in der Datenbank benötigt, muss er parallelisiert werden. Die Realisierung des ersten Schritts besteht im Wesentlichen darin, eine Liste von Partitionen zu erstellen und für jede Partition einen Unterprozess zu erzeugen. Für den zweiten Schritt verwenden wir das ursprüngliche SQL-Skript.
Wir ändern es so ab, dass die Aggregation nur auf eine einzelne Partition zugreift, die durch einen Parameter festgelegt ist, anstatt auf die gesamte Tabelle. Das Ergebnis wird als Zwischenaggregat gespeichert. Nach der Ausführung aller parallelen Teilprozesse müssen wir das Zwischenaggregat erneut aggregieren und das Ergebnis wird in der Ergebnistabelle gespeichert.
Das ursprüngliche SQL-Skript liefert auch für diese Aufgabe eine sehr brauchbare Vorlage. Diese Schritte können in der Regel innerhalb weniger Stunden umgesetzt werden. Das eigentliche Problem der Realisierung ist der dritte Schritt: Wenn alle Vorteile der anwendungsbasierten Parallelisierung genutzt werden sollen, ist es notwendig, einen Kontrollmechanismus zu implementieren, der mindestens die folgenden Funktionen bereitstellt:
- Ausführung und Fehlererkennung der parallelen Teilprozesse
- Kontrolle der Anzahl der gleichzeitig laufenden Teilprozesse (zur Laufzeit)
- Überwachung und Neustart nach einem Fehler von Teilprozessen
Für die Implementierung einer individuellen Lösung ist ein erhebliches Maß an Know-How erforderlich (Skripting . . .), so dass eine effiziente, stabile und wartbare Lösung mit vertretbarem Aufwand nur sehr schwer zu erreichen sein wird. Wenn die parallelen Teilprozesse nicht in das verwendete Scheduling-System integriert werden können, entziehen sie sich der effektiven Überwachung und Steuerung im Betrieb des Data-Warehouse-Systems.
Für die Realisierung der schwierigsten Aufgabe ist kein Entwicklungsaufwand notwendig
Das BICsuite Scheduling System bietet alle Funktionen zur Umsetzung des dritten Schrittes vollständig an. So ist für die Realisierung der schwierigsten Aufgabe in diesem Zusammenhang kein Entwicklungsaufwand notwendig. Die größte Barriere für die Parallelisierung von Prozessen auf Applikationsebene wird hiermit entschärft.
Implementierung im BICsuite Scheduling System mit dynamischen Submits
Das BICsuite Scheduling System erlaubt es Jobs, mit Hilfe der BICsuite API Child-Jobs mit unterschiedlichen Parametern zu starten. Diese neu erzeugten Jobs sind wie alle anderen Jobs im Scheduling-System sichtbar und alle Funktionen (Monitoring, Operating, Resource Management, . . .) des BICsuite Scheduling-Systems stehen für die Behandlung dieser dynamisch erzeugten Job-Instanzen uneingeschränkt zur Verfügung.
Zurück zum Beispiel: Abbildung 1 zeigt die Definition eines parallelisierenden Prozesses innerhalb des BICsuite Scheduling Systems.
Sobald der Batch AGGREGATE zur Ausführung übergeben wird, werden auch die beiden (statischen) Child-Jobs SUBMIT_PARTITIONS und AGGREGATE_TOTAL instanziiert und der Job SUBMIT_ARTITIONS kann ausgeführt werden. Aufgrund der Abhängigkeit (Pfeil in der Abbildung) von SUBMIT_PARTITIONS wird der Job AGGREGATE_TOTAL erst dann ausgeführt, wenn der Job SUBMIT_PARTITIONS mit all seinen Child-Jobs beendet ist.
Das Programm für SUBMIT_PARTITIONS ist im Wesentlichen die Implementierung des ersten Schritts unserer Liste. Es erkennt die Partitionen der Datenbanktabelle und erzeugt mit Hilfe der BICsuite API (z.B.: Kommandozeilenbefehl 'submit') für jede Partition einen Child-Job. Eine einfache Implementierung des Jobs SUBMIT_PARTITIONS in einer Unix-Umgebung könnte wie folgt aussehen (in diesem Beispiel sind die Partitionen hart codiert, könnten aber auch das Ergebnis einer Abfrage sein):
sh -c "for P in P1 P2 P3 P4 P5 P6 P7
do
submit --host $SDMSHOST --port $SDMSPORT --jid $JOBID \\
--key $KEY --job PARTITION --tag $P PARTITION $P
if [ $? != 0]
then
exit 1
fi
done"
Im Monitoring von BICsuite sieht ein laufender AGGREGATE-Batch wie in Abbildung 2 dargestellt
aus.
Das BICsuite Workload Automation System erlaubt es nun, dass jeder einzelne AGGREGATE_PARTITION-Job überwacht und im Falle eines Fehlers neu gestartet (rerun) werden kann. Mit geringem Aufwand kann auf Betriebssystemebene gesteuert werden, wie viele AGGREGATE_PARTITION-Jobs zu einem Zeitpunkt ausgeführt werden können. Dies geschieht einfach durch die Definition einer Ressource und einer entsprechenden Anforderung. Diese Anzahl der parallel ausgeführten Jobs kann zur Laufzeit verändert werden. Abbildung 2 zeigt den Batch mit maximal drei parallelen AGGREGATE_PARTITION-Jobs. Indem für die AGGREGATE_PARTITION-Jobs zusätzliche Anforderungen an andere Ressourcen (zur Abbildung der verfügbaren Systemressourcen) definiert werden, liegen sie auch dem restlichen Ressourcenmanagement der Data-Warehouse-Operationen zugrunde.
Das BICsuite Workload Automation System ermöglicht mit seiner dynamischen Submit-Funktionalität eine schnelle, kostengünstige, stabile und wartbare Implementierung von anwendungsbasierter Parallelisierung. Die parallelen Teilprozesse sind in den Gesamtprozess integriert und werden im Scheduling-System sichtbar. Die Übersicht und Kontrolle über jeden dieser Teilprozesse ist damit jederzeit gewährleistet.
BICsuite Highlights
Mehr erfahren
Stöbern Sie in unserer wachsenden Sammlung von Artikeln, Erklärvideos und Tutorials, um praktische Einblicke und Best Practices für die Workload-Automatisierung mit Schedulix und BICsuite zu entdecken.
Mehr erfahrenHaben Sie noch Fragen?
Bitte zögern Sie nicht, sich mit uns in Verbindung zu setzen, wenn Sie irgendwelche Fragen haben oder weitere Informationen benötigen. Unser Team steht Ihnen gerne zur Verfügung.
Kontaktieren Sie uns↑ Nach oben