Landing Area (Zone) im SQL Server Data Warehouse
Noch ein wenig was zum Thema Data Warehouse Design.
Diese Woche hatte ich u. a. ein Meeting, bei dem erwähnt wurde, dass der Begriff Landing Zone bzw. Landing Area im Zusammenhang mit Data Warehouse Architekturen bisher den Teilnehmern nicht bekannt war. Für mich ist die Nutzung einer Landing Area in einer Data Warehouse Umgebung ein wesentliches Element, um eine beherrschbare Lösung zu erstellen. Ihr erinnert Euch vielleicht, dass für mich die spätere “Beherrschung” der Business Intelligence Lösung ein elementarer Punkt ist und mir meist wichtiger ist, als irgendwelche technischen Spielereien auf der “Bit-Ebene…”. Und daher hier kurz eine Erläuterung meiner Sicht auf eine Landing Zone, welche gerne auch mal Landing Area heißt.
Die Aufteilung eines ETL Prozesses in sogenannte Stages ist mittlerweile relativ bekannt. Also die Daten, welche für das Data Warehouse benötigt werden, durchlaufen im Datenbewirtschaftungsprozess diverse Schritte (Stages) zur Überprüfung und Verarbeitung, bevor sie im finalen Load-Prozess ins DWH geladen werden.
Die Landing Zone setzt nun auf der gegenüberliegenden Seite an! Hier fängt der ETL Prozess an. Wichtig ist die Erkenntnis, dass der ETL Prozess eigentlich aus diversen voneinander getrennten Prozessen/Jobs/Paketen/What-ever besteht. Es gibt u.a. diverse Extract-Prozesse (das E in ETL), welche die Daten aus den Vorsystemen “einsammeln”. Nun gibt es aber auch noch den häufigen Fall, dass die Vorsysteme die Daten von sich aus automatisch liefern. Wohin also mit diesen gepushten Daten? Das ist die ursprüngliche Idee hinter der Landing Zone. Hier laden die Vorsysteme Ihre Daten ab. Entweder Deltas, Transaktionslog, Backups, Flats usw. Meist ist die Landing Area aus technischer Sicht eine Ordnerfreigabe auf einem Server. Aus dieser holen sich dann die Prozesse des ETL Jobs die dort “gelandeten” Daten ab und verarbeiten diese weiter. Natürlich kann es auch vorkommen, dass Datenpakete abgewiesen werden, weil die Datenqualität nicht die Geschäftsregeln erfüllen oder einfach was fehlerhaft ist im Format.
Meine Nutzung der Landing Zone geht noch ein wenig weiter, da ich einfach (ich mag einfache Lösungen bei komplexen Herausforderungen) alle Extract Prozesse ihre Ergebnisse in die Landing Zone ablegen lasse. Auch die Jobs, welche klassisch exportieren. Dazu nutze ich i. d. R. beim SQL Server die Integration Services (SSIS) und lasse die Daten im Rohdatenformat (RAW Format) in der Freigabe ablegen. Die weiteren Prozesse nehmen dann diese Dateien als Quelle auf und verarbeiten sie entsprechend weiter.
Der Vorteil einer Landing Area ist u.a., dass der ETL Prozess nicht direkt an den Vorsystemen hängt, sondern von diesen losgelöst ist. Eine asynchrone Verarbeitung zahlt sich auch hier aus, wenn das Ganze ein wenig unübersichtlicher von der Anzahl der Quellen und Prozesse wird. Des Weiteren kann der Inhalt der Landing Area, welcher im übrigen immer nur temporär dort liegt, ganz hervorragend mit einem Komprimierungstool in Paketform historisiert werden. Die Historisierung führe ich gerade bei ganz frischen Data Warehouse Umgebungen gerne durch, um noch evtl. Fehler in der Verarbeitung durch einen “Reset” des DWHs zu kompensieren ohne eine Datenverlust in der Historisierung zu haben. Daher gehört für mich eine Landing Area zu jedem komplexeren Data Warehouse!
