Nutzung eines Jobpools in Business Intelligence Umgebungen
Da ich vor ein paar Tagen ja über Repositories in Data Warehouse Umgebungen geschrieben habe, hier noch ein paar weitere Gedanken dazu. Im Rahmen der European PASS Conference 2009 habe ich zwei Vorträge gehalten. In dem einen ging es primär um dynamisch erstellte SSIS Pakete. Eine äußerst leistungsfähige Technologie, wenn in umfangreicheren Projekten eine größere Menge an SSIS Tasks und Paketen benötigt wird, welche auf Basis von Metadaten erzeugt werden sollen. Ein sekundärer Aspekt dieser Session, welcher ein wenig unterging, war die Nutzung eines Jobpools innerhalb eines Repositorys.
Damit sind wir wieder beim Thema. Es geht mir dabei um die Arbeit mit einer großen Menge an einzelnen Paketen und Jobs, welche zum Beispiel im Rahmen einer Datenbewirtschaftung eines Data Warehouses verarbeitet werden müssen. Natürlich gibt es eine ganze Reihe von Abhängigkeiten, welche bei der Abarbeitung berücksichtigt werden müssen! Als Lösung für eine solche Herausforderung wird gerne die Ablaufsteuerung von SSIS verwendet. Mit dieser lassen sich Abhängigkeiten zwischen einzelnen Paketen sehr leicht visuell modellieren. Dabei werden Jobs in immer der identischen sequentiellen Reihenfolge bzw. parallel abgearbeitet.
Ein Nachteil dieser Vorgehensweise ist aber die Handhabung in sehr großen Umgebungen, welche auch noch zum Teil dynamisch sind. Wenn dann noch der Wunsch nach automatischer Lastverteilung, Skalierbarkeit und Ausfallsicherheit an die Umgebung gestellt wird, dann kann es schon äußerst komplex werden!
Als eine mögliche Lösung für dieses Szenario setze ich gerne auf einen sogenannten Jobpool. Dabei werden die einzelnen Aufgaben bzw. Jobs zentral in einem Pool abgelegt. Von “außen” greifen nun sogenannte Agents auf diesen Pool zu und “suchen” sich die Pakete, welche sie verarbeitet werden dürfen.
Ob ein Paket aus dem Pool genommen werden darf und verarbeitet werden kann, wird auf Basis von Regeln entschieden. Zum Beispiel kann eine sehr einfache Regel sein, dass erst alle Pakete der Gruppe “ExtraktionCRM” fertig sein müssen, bevor mit der Verarbeitung der “Dimension Kunde” begonnen werden kann. Dabei ist es aber nicht entscheidend, in welchen Reihenfolge die Pakete der Gruppen “ExtraktionCRM” ausgeführt werden.
Wenn nun ein neuer Job dem Pool hinzugefügt wird, dann muss dieser nicht mit anderen Jobs “verdrahtet” werden, sondern er wird einem Regelsatz zugewiesen. Die Agents, welche die Pakete bzw. Jobs verarbeiten, können für unterschiedliche Aufgaben zur Verfügung stehen. Zum Beispiel dem einfachen Ausführen von SSIS Paketen oder dem Verarbeiten von AMO Anweisungen für den Aufbau von Cubes. Die Agents können über mehrere Server verteilt werden. Dadurch ist eine Lastverteilung und Skalierbarkeit gegeben, ohne, dass eine Ablaufsteuerung manuell an die neue Hardware (welche auch gern virtuell sein kann) angepasst werden muss. Der Ausfall eines Server ist zwar bedauerlich, da seine Leistung fehlt, aber führt nicht mehr zum Abbruch der gesamten Verarbeitung!
Wichtig ist mir die Abgrenzung, dass ein Jobpool erst in größeren Umgebungen Sinn macht! In einer überschaubaren Umgebung ist die SSIS Ablaufsteuerung mit ihren Möglichkeiten wesentlich sinnvoller. Der Moment über einen Jobpool nachzudenken ist gekommen, wenn der Verantwortliche für die Datenbewirtschaftung erst ein paar Minuten braucht, um die vermeintlich richtige Stelle in einem Paket zu finden, um einen neuen Job hinzuzufügen. Auch Anforderungen wie Skalierbarkeit, Lastverteilung und Ausfallsicherheit können Treiber für diesen Ansatz sein.
