Staging-Area: Potentiale gegenüber Quellsystemen

In Zeiten der Digitalisierung ist es besonders wichtig, auf verlässliche Datenbanken zurückgreifen zu können, um Fehlerquellen auszuschließen und zielstrebiges und exaktes Arbeiten zu ermöglichen. Die Staging-Area stellt für diese Art von Anforderungen in der heutigen Zeit eine Lösung bereit.

Designer und Architekten unterschätzen häufig die Notwendigkeit einer Staging-Area in der Datenbanklandschaft, da sie dies für eine Verschwendung von Platz, Leistung und Entwicklungszeit halten. Sicher ist für den Aufbau von Staging Platz und Anstrengung erforderlich, doch diese zahlt sich über den gesamten Lebenszyklus der Datenbank aus.

Die Staging Area definiert sich über die klassische Gestaltung einer Datenbank, die einen Zwischenbereich (Staging-Area) umfasst, der aus 1-zu-1-Kopien von Tabellen aus den Quellsystemen besteht, wie die untenstehende Abbildung veranschaulicht. In der Staging-Area werden Daten temporär zwischengespeichert, um sie dort zu bereinigen und zu transformieren. Nach der Durchführung dieses Prozesses werden die aufbereiteten Daten in die entsprechende Zieldatenbank transferiert, um anschließend entsprechend Anwendung zu finden.

In diesem Artikel werden die Vorteile einer Staging-Integration und Argumente erläutert, warum Staging immer in die Architektur eines Data Warehouses integriert werden sollte.

1. Erleichterung bei der Analyse von Fehlerquellen

Oftmals fallen Fehler im Präsentationsbereich erst durch den Hinweis von gewerblichen Nutzern auf. Fehlerquellen können hier unterschiedlicher Natur sein. Entweder liegt der Fehler im ETL-Prozess (Extract, Transform, Load) oder es handelt sich beispielsweise um fehlerhafte Daten im Quellsystem, um Missverständnisse oder falsche Anforderungen.

Um diese Frage zu beantworten, sollte ein Analyst oder eine verantwortliche Person Zahlen aus dem Präsentationsbereich mit den Quellsystemen vergleichen. Dies stellt jedoch eine umfangreiche Aufgabe dar, da eine Zahl im Präsentationsbereich aus vielen Tabellen der unterschiedlichen Quellsysteme hergeleitet werden kann. Ob zum Beispiel die Höhe des Umsatzes richtig berechnet wurde, kann nicht gesagt werden, wenn sich Daten aus den Offlinegeschäften in der Oracle-Datenbank und die Onlineverkäufe in verschiedenen MySQL-Datenbanken befinden. Um dies abzugleichen, muss beispielsweise eine Excel-Tabelle erstellt werden, die Daten aus den Quellsystemen extrahiert, kombiniert und sie mit dem Präsentationsbereich vergleicht. Dies scheint aufwendig und fehleranfällig.

Durch eine Staging-Area wird diese Vorgehensweise umgangen und eine einzige SQL-Abfrage reicht aus, um alle Quelltabellen zu verbinden, da sich alle in einer einzigen Datenbank befinden. Sie lassen sich vollautomatisch mit dem Präsentationsbereich abgleichen und der Mangel kann behoben werden. Die Wahrscheinlichkeit, dass Fehler bei einfachen 1-zu-1-Transformationen vom Quellsystem in die Staging Area auftreten, liegt bei 0,1 %. Das Risiko, Fehler in weiteren Transformationen zu machen, liegt dagegen bei 99,9 %. So kann ein Analyst relativ einfach sagen, ob ein ETL-Prozess korrekt durchgeführt worden ist, und dementsprechend fehlerhafte Zeilen aufzeigen.

2. Testphase der Staging-Area und Überprüfung bei Ausnahmefällen

Während der Testphase ist es wichtig, über einen stabilen Datensatz zu verfügen, um verschiedene Versionen von ETL zu testen. Die Staging-Area bietet hier den klaren Vorteil, diesen einzufrieren und weitere ETL-Prozesse und Tests auszuführen. Zudem können kompliziertere Testschemata, wie beispielsweise das Load-Staging, implementiert und die gespeicherten Kopien anschließend für ETL verwendet werden, um die gesamte wöchentliche Verarbeitung schnell zu simulieren.
Bei Daten in Quellsystemen ist dieser Prozess nicht möglich, da diese auch für andere Zwecke verwendet werden.

Oftmals werden auch Ausnahmefälle überprüft, beispielsweise, wie der ETL-Prozess Situationen verarbeitet, die gegenwärtig noch nicht in den Quelldaten existieren. Dies betrifft zum Beispiel Verkäufe, die mit einem nicht bestehenden Kunden verbunden sind. Kann der ETL-Prozess diese Situation wie geplant verarbeiten? Wenn die Datenbank über eine Staging-Area verfügt, können diese in Staging-Daten modelliert und durch das ETL geprüft werden.

3. Leistungsaspekte eines Staging-Bereichs

Gegner des Systems behaupten, dass bei der Auffüllung des Staging-Bereichs eine zusätzliche Verarbeitung erforderlich ist und dies im Endeffekt negative Auswirkungen auf die ETL-Leistung hat. Auch wenn für das Auffüllen von Staging-Tabellen einige Ressourcen erforderlich sind, kann dies zu einem späteren Zeitpunkt auch Leistungsvorteile mit sich bringen. Dies geschieht besonders dann, wenn eine Quelltabelle während des Auffüllens des Kernbereichs mehr als einmal berührt wird. So erhält man durch das Kopieren in die Staging-Area einen spürbaren Leistungsvorteil. Dies gilt nicht nur für die Datenbank, auch die Arbeitsbelastung, die eine Datenbank an das Quellsystem gibt, muss optimiert werden. Eine Architektur mit einer Staging-Area ermöglicht die Ausführung einfacher Abfragen der Quellsysteme, wobei jede Tabelle nur einmal berührt wird, so dass eine minimale Arbeitsbelastung an die Quellsysteme weitergegeben wird.

Zudem können ETL-Tools effektivere Techniken verwenden, um den Prozess durchzuführen, wenn sich alle Quellen in der gleichen Datenbank befinden. Beispiele dafür sind Informatica, das die Push-down-Optimierung nutzt, oder ODI (Oracle Data Integrator), das kein LKM (Load Knowledge Module) für die weitere Verarbeitung benötigt.
Damit das ETL-Tool eine Verbindung herstellen kann, ist die Konvertierung von Tabellen in dieselbe Datenbank erforderlich. Ist diese Voraussetzung nicht gegeben, haben ETL-Tools keine andere Wahl, als diese in die gleiche Instanz zu kopieren. Durch die Einführung einer Staging-Area macht ein Architekt das Gleiche, jedoch auf kontrollierbarere Art und Weise.

Da die Staging-Area von einem Datenbankteam kontrolliert wird, kann das Team Datenbankstatistiken erfassen, die für die ETL-Optimierung notwendig sind, und kann jederzeit darauf zurückgreifen. Es gibt keine Garantie dafür, dass das Quellsystem alle für die SQLs der Datenbank erforderlichen Statistiken enthält. Aus diesem Grund können Abfragen, die auf die Quellsysteme zugreifen, möglicherweise nicht optimal funktionieren.

Ein weiterer Vorteil einer Staging-Area ist die Erstellung eines Index, der zum Tragen kommt, sobald eine Staging-Tabelle bei Transformationen mehr als einmal verwendet wird. Dies ist eine leicht zu bewältigende Aufgabe und fordert nicht die Unterstützung eines Datenbankadministrators, dessen Hauptaufgabe darin besteht, OLTP-Aktivitäten (Echtzeit-Transaktionsverarbeitung) zu unterstützen.

Wenn im Data Warehouse eine Staging-Area genutzt wird, besteht die verteilte Umgebung aus sehr einfachen 1-zu-1-Kopieraufträgen aus Quellsystemen und die gesamte anschließende Verarbeitung erfolgt in einer einheitlichen Datenbank. Die meisten Leistungsprobleme entstehen in einer einheitlichen Datenbankumgebung. Um dies zu umgehen, wird nach einiger Zeit eine Leistungsoptimierung vorgenommen.
Umfasst die Architektur jedoch keine Staging-Area, gibt es viele komplexe Aufträge, die auf verschiedene Umgebungen zugreifen. Ist dies der Fall, handelt es sich bei der Optimierung eines verteilten Systems um eine wesentlich komplexere Aufgabe und es sind Menschen vonnöten, die Erfahrung mit unterschiedlichen Technologien haben. Schließlich besteht die Möglichkeit, dass das Datenbankteam keine ausreichenden Berechtigungen zur Lösung von Leistungsproblemen auf der Seite der Quellsysteme hat, und es kann möglicherweise nicht die Ausführungspläne, die Tabellenstruktur, die Hardwarekonfiguration etc. einsehen.

4. Vorgehensweise, Ablaufprozess und die Umsetzung von Anforderungen durch einen Analysten

Nachdem alle Daten aus den unterschiedlichen Quellsystemen in die Datenbank integriert worden sind, stellen die gewerblichen Nutzer Anforderungen an den Analysten, der sich mit ihrer Analyse eingehend befasst. Um die Anforderungen der Nutzer erfüllen zu können, sollten folgende Bedingungen gegeben sein:

Zugriff auf alle Quellsysteme
Vereinbarung eines Fensters zur Ausführung von Abfragen
Erfahrung mit allen gängigen Source-Technologien
Umfassende technische Fähigkeiten, um Quelldaten zusammenzufügen

Eine einheitliche Staging-Umgebung erleichtert die Arbeit und verringert den Zeitaufwand zur Bearbeitung der Anforderungen ungemein, insbesondere wenn Staging-Tabellen auch Spalten enthalten, die in der Datenbank noch nicht verwendet werden.
Um diese Art von vermeidbaren Problemen zu umgehen, sollte der Staging Area besondere Aufmerksamkeit gelten. Sie hilft, Ihr Projekt flexibler zu erstellen und zu unterstützen, und führt sogar zu einer Verbesserung der Leistung.