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!

Popular posts from this blog

SQL Server In-Memory OLTP – Isolation Level Beispiele

-
Image
Wie schon mal von mir erwähnt, erlebe ich bei den Teilnehmern meiner SQL Server In-Memory OLTP Workshops die meisten Schwierigkeiten bei der Verwendung der “neuen” Isolation Level. Zwar klingen für viele Entwickler die Level SNAPSHOT, REPEATABLE READ und SERIALIZABLE vertraut, nur schon bei den SQL Server “disk-based” Tabellen haben die wenigsten diese aktiv genutzt. Standard ist häufig READ COMMITED und das ist auch gut so. Die Tatsache, dass In-Memory OLTP aber ohne Sperren auskommt, fühlt sich für die meisten Entwickler erstmal befremdlich an. Zwar haben wohl die meisten Interessierten schon mal die Microsoft PowerPoints mit einer Erklärung des Version Stores gesehen und sich gefreut, wie schön da Versionen von Zeilen nebeneinander koexistieren können. Nur wie sieht das in der Praxis für den Entwickler aus? Der deutsche Begriff für die Technologie In-Memory OLTP “Arbeitsspeicheroptimierung” trifft es irgendwie nicht ganz. Zwar wird der Arbeitsspeicher wesentlich optimierter gen
Read more

MERGE in T-SQL – Der unbekannte Befehl im BI Projekt für ELT

-
Image
Wenn ich Diskussionen über die Entscheidung für eine ETL oder ELT Architektur führe oder auch nur moderiere, dann bringe ich als ein mögliches Beispiel für eine ELT Architektur gerne die Verwendung des MERGE Befehls. Nur wenige scheinen diesen Befehl bisher aktiv zu nutzen, dabei ist er schon seit SQL Server 2008 dabei und gehört auch zum SQL:2008 Standard! Was macht nun der Befehl MERGE? Laut den BOL das hier: “Führt Einfüge-, Aktualisierungs- oder Löschvorgänge in einer Zieltabelle anhand der Ergebnisse eines Joins mit einer Quelltabelle aus. Sie können z. B. zwei Tabellen synchronisieren, indem Sie Zeilen in einer Tabelle anhand von Unterschieden, die in der anderen Tabelle gefunden wurden, einfügen, aktualisieren oder löschen.” Und damit ist er perfekt geeignet für den Ladeprozess von Dimensionen in Data Warehouse/BI Projekten. Denn dort benötigen wir ja sowohl ein INSERT als auch ein UPDATE für unsere Geschäftsobjekte in den Dimensionen. Ok, und ganz selten mal ein DELETE,
Read more

PSG Performance Driven Development für den SQL Server

-
In den letzten Monaten wurde ich häufig danach gefragt, was denn dieses Performance Driven Development (PSG PDD) eigentlich sei? Und welche Technologien wir damit meinen? In erster Linie verstehen wir unter der Performance Driven Development Methode weniger einen Technologie Ansatz, als vielmehr einen Rahmen an Maßnahmen, damit das Thema Performance im Laufe einer Software Entwicklung den Stellenwert er- und behält, welcher bei Projektstart als notwendig erachtet wurde. Entstanden ist die Idee zu der Methode u.a. aus dem Feedback unserer Schulungskunden. Es wurde uns zwar attestiert, dass die Teilnehmer unserer Workshops und Schulungen einen deutlichen Knowhow Fortschritt machen würden, dennoch wäre es für den einzelnen Entwickler immer wieder schwierig sei neues Wissen auch so einzusetzen, dass die Projekte bzw. Produkte davon wirklich partizipieren. Der Alltag von Entwicklern sei ja stark getrieben durch ein agiles geprägtes Umfeld und Stakeholder, für die diese grundlegenden t
Read more