Azure

Azure Data Lake Storage

Overview

Azure Data Lake Storage ist kein eigener Dienst und kein eigener Kontotyp, sondern eine Funktion von Blob Storage. Du aktivierst sie, indem Du in einem Storage Account den hierarchischen Namespace einschaltest. Der frühere Name lautet Data Lake Storage Gen2, Microsoft verwendet heute meist nur noch „Azure Data Lake Storage“.

Der hierarchische Namespace organisiert Objekte in echten Verzeichnissen. Umbenennen oder Löschen eines Verzeichnisses ist damit eine einzelne Metadatenoperation, was Analyseprozesse mit vielen Dateien deutlich beschleunigt. Analysewerkzeuge wie Azure Databricks, Azure Synapse Analytics, Microsoft Fabric oder Spark-Cluster greifen über den ABFS-Treiber auf den Endpunkt dfs.core.windows.net zu.

Die Vorgängergeneration Data Lake Storage Gen1 war ein eigener Dienst und wurde am 29. Februar 2024 eingestellt. Abgrenzung: Ein Data Lake speichert Rohdaten in beliebigen Formaten, ein Data Warehouse strukturierte, aufbereitete Daten für Abfragen.

How it works

Aufbau und Zugriff:

  1. Beim Anlegen eines GPv2- oder Premium-Block-Blob-Kontos aktivierst Du den hierarchischen Namespace. Ein nachträgliches Upgrade bestehender Konten ist möglich, aber nicht umkehrbar.
  2. Container dienen als Dateisysteme, darin legst Du Verzeichnisse etwa nach Zonen wie raw, curated und reporting an.
  3. Rechte vergibst Du grob per Azure RBAC (zum Beispiel Storage Blob Data Reader) und fein per POSIX-ACL auf Verzeichnis- und Dateiebene.
  4. Analyse-Engines verbinden sich per ABFS-URI (abfss://<container>@<konto>.dfs.core.windows.net/<pfad>), Anwendungen auch per Blob-API.
  5. Lebenszyklusregeln und Zugriffsebenen aus Blob Storage gelten weiter.

Laut Microsoft gibt es keine Grenzen für Kontogröße, Dateigröße oder Gesamtvolumen. Die Daten sind im Ruhezustand immer verschlüsselt.

Benefits

  • Verzeichnisoperationen sind atomar und schnell, was ETL-Jobs mit Millionen Dateien beschleunigt.
  • Feingranulare ACLs erlauben Rechte pro Fachbereich oder Datensatz, ohne getrennte Konten anzulegen.
  • Preise auf Blob-Storage-Niveau mit Zugriffsebenen und Lebenszyklusregeln für ältere Daten.
  • Breite Unterstützung durch Databricks, Synapse, Fabric und Hadoop-kompatible Werkzeuge über ABFS.

Practical example

Ein Hersteller von Verpackungsmaschinen mit 500 Mitarbeitenden möchte Maschinendaten, ERP-Exporte und Servicetickets gemeinsam auswerten. Die IT legt einen Storage Account mit hierarchischem Namespace an und strukturiert ihn in die Zonen raw, curated und reporting. Data-Factory-Pipelines laden die Rohdaten, Databricks bereitet sie auf und Power BI greift auf die Reporting-Zone zu. ACLs sorgen dafür, dass der Vertrieb nur aggregierte Daten sieht, während Data Engineers Zugriff auf alle Zonen haben.

Things to keep in mind

  • Aktiviere den hierarchischen Namespace bewusst: Die Umstellung lässt sich nicht rückgängig machen und einige Blob-Funktionen verhalten sich danach anders.
  • Kombiniere RBAC und ACLs gezielt. RBAC-Rollen auf Datenebene überstimmen ACLs, deshalb grob per RBAC, fein per ACL.
  • Lege die Verzeichnisstruktur und Namenskonventionen vor dem ersten Ladeprozess fest.
  • Viele kleine Dateien erhöhen Transaktionskosten und verlangsamen Analysen. Fasse Daten in größere Parquet-Dateien zusammen.
  • Prüfe, ob Microsoft Fabric mit OneLake für Dein Szenario sinnvoller ist, bevor Du eine eigene Data-Lake-Plattform aufbaust.

Licensing & availability

Abrechnung wie Blob Storage über das Azure-Abonnement nach Datenmenge, Zugriffsebene, Redundanz und Transaktionen. Für Konten mit hierarchischem Namespace gelten eigene Transaktions- und Metadatenpreise. Data Lake Storage Gen1 ist seit 29. Februar 2024 eingestellt. Stand: Oktober 2026.

Conclusion

Azure Data Lake Storage ist die Speichergrundlage für Datenplattformen auf Azure. Plane Struktur, Rechte und Dateiformate, bevor die ersten Pipelines laufen.

Further reading

Related articles