arrow arrow--cut calendar callback check chevron chevron--large cross cross--large download filter kununu linkedin magnifier mail marker media-audio media-blog media-video menu minus Flieger phone play plus quote share youtube

Data Lake auf Azure

Was Sie wissen sollten

Im Oktober haben wir in unserem Blogpost unter mit dem Titel „Whitepaper: Einrichten eines Data Lakes auf AWS“ bereits berichtet, wie wir eine Data Lake Infrastruktur auf AWS aufgebaut haben und die Vor- und Nachteile aufgezeigt. Heute gehen wir auf unseren Blueprint für einen Data Lake ein. Von Azure werden verschiedene Dienste zur Verfügung gestellt – mittlerweile auch in einer zweiten Generation. Für unseren Blueprint verwenden wir folgende Dienste: Azure Data Lake Storage Gen2, Azure Data Factory V2, Databricks und SQL Azure Database.

Prozess datacatolog datafactory datatransform

Zusammenstellung der Infrastruktur auf Azure Data Lake

Die Abbildung 1 zeigt die komplette Infrastruktur mit Netzwerkzugehörigkeit und Netzwerkverbindung auf. Der Aufbau des Data Lakes ist für Enterprise Architekturen konzipiert, sodass on-premises Cluster eingebunden werden können. Es ist zu empfehlen, die Dienste in einem separaten Subnetz zu deployen, damit der Zugang zu einem Data Lake auch innerhalb einer Organisation regelbar ist.

Einige Dienste besitzen noch keine Netzwerkschnittstelle und müssen deshalb außerhalb eines VNET bereitgestellt werden;  zurzeit betrifft das die Data Factory und den Data Catalog. Die Integration Runtime wird notwendig, wenn on-premises gehostete Quellsysteme mit der Cloud verbunden werden sollen. Je nach Netzwerkverbindung mit der Azure-Cloud muss diese auf einer VM im Subnetz oder auf dem Cluster on-premises installiert werden.

In unserem Konzept teilen wir den Data Lake Storage in zwei verschiedenen Ressourcen auf: die Landing-Zone und die Standardization-Calculation-Zone. Das soll die Auswirkung von Fehlern eingrenzen. Der Databricks-Cluster (dbstranform) befindet sich ebenfalls außerhalb des Subnetzes, da sich eine Integration in ein Subnetz derzeit nicht umsetzen lässt. Bei dem Data Warehouse handelt es sich um eine Light-Weight-Variante, in der nur aggregierte Daten vorgehalten werden, was zu einer Minimierung des Datenbankspeichers und somit zu einer Reduktion der Kosten führt. In dem Azure Data Vault (kee-dl) werden verschlüsselt User, Passwörter und Token vorgehalten, die für eine Authentifizierung gegenüber den Azure Diensten erforderlich sind.

Foto von Giovanni Maccaferri
Giovanni Maccaferri

Ehemaliger

Netzwerkkonfiguration für Azure Data Factory und Databricks

Nicht alle Dienste, wie zum Beispiel Data Factory und Databricks, sind von Azure als Trusted Service zertifiziert. Somit sind einige Workarounds notwendig, um einen Zugriff dieser Dienste auf Ressourcen innerhalb eines Subnetzes zu realisieren. Bei einer Data Factory ist eine Virtuellen Maschine mit installierter Data Factory Integration Runtime notwendig. Der Zugriff für Databricks auf den Data Lake Storage wird über einen App-Service konfiguriert, für alle zertifizierten Dienste werden Service Endpoints installiert. Nichtsdestotrotz muss darauf geachtet werden, wie die Firewall in der entsprechenden Enterprise-Umgebungen konfiguriert ist. Manche Firewallhersteller verfügen über ein Azure-Konfigurations-Modul, welches die bekannten Data Centers IP-Adressliste abgreift. Microsoft ist wohl dabei, verschiedene Dienste zu zertifizieren; bei Databricks ist man da schon ein gutes Stück weiter. Bei Data Factory wird die Realisierung einer Netzwerkkomponente schwieriger werden.

Prozess DF Management ELT-Pipelines VNET
Abbildung 2 Datenmigration

Datenmigration innerhalb des Data Lakes

Abbildung 2 stellt einen Datenfluss und die daran beteiligten Dienste dar. Der Datenfluss ist von links nach rechts zu betrachten.

Schritt 1: Pipelinekonfiguration

Die Data Factory (links) beinhaltet alle ELT-Pipelines, Linked Services, Integration Runtimes und Notebooks. Wir zentralisieren die Pipelines über Data Factory, sodass das Scheduling, das Triggern und das Monitoring über eine Managementoberfläche realisiert werden kann. Die Linked Services werden so konfiguriert, dass diese über die selbst gehostete Integration Runtime geroutet werden. Das führt dazu, dass die Pipelines auf der Virtuellen Maschine ausgeführt werden, sodass die Daten direkt in den Data Lake Storage (Landing-Zone) fließen können.

Schritt 2: Datenintegration

In der Landing-Zone werden diese nach folgendem Muster abgelegt:

[Quellsystem][Jahr][Monat][Tag][Stunde]

Die Segmentierung kann man beliebig herunterbrechen, um so auch Anforderungen aus dem Streamingbereich zu erfüllen. Zwischen der Landing-Zone und Standardization-Zone können für die Standardisierung der Daten zwei Dienste verwendet werden: Zum einen die Data Flow Funktionalität innerhalb der Data Factory – diese ist mit SSIS vergleichbar –  oder direkt ein Notebook aus Databricks. Ein Data Flow kann per Drag- and Drop erstellt werden. Der im Hintergrund erzeugte Code wird als Job auf Databricks ausgeführt. Diese Funktion wird derzeit nicht von einer self-hosted Integration Runtime unterstützt. Bei der Wahl eines Notebooks geht die Übersicht durch den Code verloren, diese kann aber mit einer ordentlichen Formatierung wiedergewonnen werden.

Schritt 3: Transformation der Daten

Im letzten Schritt werden die standardisierten Daten transformiert und in das Data Warehouse geladen. Bei der Konfiguration der Datenbank gibt es seit kurzer Zeit die Möglichkeit, einen serverlosen Datenbankbetrieb zu wählen. Bei diesem lässt sich ein Inaktivitäts-Treshhold bestimmen, nach dem die Datenbank heruntergefahren werden soll. Dies ist eine gute Option, da die Daten in der Regel nicht 24/7 abgerufen werden.

Schritt 4: Visualisierung mit Power BI

In unserem Szenario greift Power BI direkt auf die Datenbank zu. Beim Zugriff gibt es ebenfalls mehrere Optionen: Entweder kann die Verbindung über ein Power BI- Gateway gekapselt werden, oder man verwendet Dataflows mit Power BI-Pro, um direkt auf den Data Lake Storage zuzugreifen. Alle Szenarien haben Ihre Vor- und Nachteile und es muss individuell entschieden werden, ob der Fokus auf Security, Kosten oder Zeit gelegt werden soll. Einen tieferen Einblick in Power BI gibt

Bewertung der Azure-Cloud für einen Data Lake

Wie dem oberen Beitrag zu entnehmen ist, bietet Azure viele Möglichkeiten, seine Data Lake Infrastruktur an die entsprechenden Bedürfnisse anzupassen. An einigen Stellen ist Azure noch in einer Preview-Aufbauphase, dies wird an einigen Diensten wie Data Factory und Databricks deutlich. Azure selbst merkt das auch in seiner Dokumentation an und weist auf mögliche Workarounds hin. Es werden nicht nur Azure-Komponenten unterstützt, sondern auch eine große Bandbreite an Drittanbieter-Tools. Ein Beispiel: beim Erstellen/Deployment von IaC-Skripten, werden verschiedene Tools wie Azure CLI, Azure RM oder Terraform bereitgestellt. Unser Rat: suchen Sie sich das Tool aus, mit dem Sie sich am besten auskennen. Die Cloudumgebung Azure macht einen robusten Eindruck mit guter Perspektive für den zukünftigen Aufbau einer Data Lake Umgebung.