Microsoft Fabric führt OneLake-Speicherklassen und Lifecycle-Management ein

Zusammenfassung

Microsoft hat für Microsoft Fabric OneLake neue Speicherklassen (Hot, Cool, Cold) und native Richtlinien für das Lifecycle-Management eingeführt. Damit können Unternehmen ruhende Daten automatisch in kostengünstigere Tiers verschieben, um ihre Speicherkosten zu senken. Parallel dazu bietet ein neuer OneLake-Speicherbericht detaillierte Einblicke in Dateigrößen und Kostenverursacher. Die neuen Tiers bringen jedoch auch Datenabrufgebühren und Mindestspeicherfristen (30 Tage für Cool, 90 Tage für Cold) mit sich, was eine sorgfältige FinOps-Überwachung erfordert.

Was ist passiert?

Im Rahmen des Updates für Juni 2026 hat Microsoft bedeutende Änderungen an der Speicherarchitektur von OneLake bekannt gegeben. Bisher gab es in OneLake nur eine einzige, einheitliche Speicherklasse zu Standardkonditionen. Nun stehen drei Klassen zur Verfügung:

Hot Tier: Für aktiv genutzte Daten mit maximaler Abfrage-Performance ohne zusätzliche Abrufgebühren.
Cool Tier: Für selten genutzte Daten mit geringeren Speicherkosten, aber zusätzlichen Gebühren für den Datenzugriff und einer Mindestspeicherfrist von 30 Tagen.
Cold Tier: Für Archivdaten mit den niedrigsten Speicherkosten, höheren Abrufgebühren und einer Mindestspeicherfrist von 90 Tagen.

Über deklarative Lifecycle-Management-Richtlinien können Administratoren Regeln definieren, um Daten basierend auf dem Alter oder dem letzten Zugriff automatisch in kühlere Tiers zu verschieben. Zur Unterstützung der Kostenkontrolle wurde zudem ein neuer OneLake-Speicherbericht veröffentlicht, der Speicherfresser und Kostenstrukturen auf Workspace-Ebene transparent macht.

Warum es wichtig ist

Die Einführung von OneLake-Speicherklassen ist ein wichtiger Schritt für die Etablierung von Fabric in Enterprise-Szenarien:

FinOps-Optimierung: In großen Data Lakes machen historische Daten oft 80 % des Gesamtvolumens aus. Die Möglichkeit, diese automatisiert auf Cool- oder Cold-Tiers auszulagern, kann die reinen Speicherkosten drastisch senken.
Kostenkontrolle statt Flatrate: Bisher war die Budgetierung von OneLake relativ simpel. Mit den neuen Tiers und deren Nebenkosten (Retrieval Fees, Early Deletion Fees) müssen Datenarchitekten nun genaue Kosten-Nutzen-Analysen für Abfragen durchführen.
Erwachsenwerden der Plattform: Fabric schließt damit eine funktionale Lücke zu klassischen Data-Lake-Lösungen wie Azure Data Lake Storage (ADLS) Gen2 und AWS S3, die schon lange über Tiering-Optionen verfügen.

Beweise

Die Ankündigung wurde im offiziellen Microsoft Fabric Feature Summary für Juni 2026 veröffentlicht und im begleitenden Update-Video auf YouTube demonstriert. Erste tiefgehende Analysen der Community, unter anderem auf Substack (Fabric Mastery) und im Reddit-Kanal r/MicrosoftFabric, beleuchten die genauen Tarifstrukturen und warnen vor versteckten Kosten durch vorzeitiges Löschen oder häufige Abfragen auf kühlen Tiers.

Analyse

Obwohl die Speichereinsparungen verlockend klingen, ist das Lifecycle-Management ein zweischneidiges Schwert. Die Einführung von Mindestspeicherfristen (30 Tage bei Cool, 90 Tage bei Cold) bedeutet, dass Daten, die vor Ablauf dieser Frist gelöscht oder überschrieben werden (beispielsweise durch regelmäßige ETL-Prozesse, die Tabellen neu aufbauen), mit Strafgebühren belegt werden.

Zudem können häufige analytische Abfragen auf Tabellen, die im Cool- oder Cold-Tier liegen, die Einsparungen durch hohe Abrufgebühren (Retrieval Fees) schnell zunichte machen. Data Engineers müssen daher genau segmentieren, welche Delta-Tabellen partitioniert und welche historischen Partitionen tatsächlich eingefroren werden können, ohne den operativen Betrieb zu verteuern.

Praktische Erkenntnisse

Für Datenplattform-Teams ergeben sich folgende Handlungsempfehlungen:

Speicherbericht analysieren: Nutzen Sie den neuen OneLake-Speicherbericht, um die größten Tabellen und deren Zuwachsraten zu identifizieren.
Vorsicht bei ETL-Zwischenstufen: Legen Sie keine temporären Tabellen oder ETL-Zwischenschritte in Workspaces ab, für die automatische Cool/Cold-Richtlinien gelten, um Strafgebühren für vorzeitiges Löschen zu vermeiden.
Deklarative Richtlinien vorsichtig testen: Beginnen Sie mit defensiven Richtlinien (z. B. Verschiebung nach Cool erst nach 60 Tagen Inaktivität) und überwachen Sie die Abrufhäufigkeit, bevor Sie Cold-Richtlinien einführen.
Partitionierungsstrategie anpassen: Partitionieren Sie große Tabellen nach Datum, sodass ältere Partitionen gezielt in kühlere Tiers verschoben werden können, während aktuelle Daten im Hot-Tier verbleiben.

Offene Fragen

Performance-Auswirkungen: Wie stark verzögern die Abrufzeiten (Latency) bei Cool- und Cold-Tiers analytische Direct-Lake-Abfragen in Power BI?
Regionale Preisunterschiede: Wie gestalten sich die genauen Gebührenstrukturen und Retrieval Fees in den verschiedenen Azure-Regionen?
Integration in Deployment Pipelines: Können Lifecycle-Richtlinien nahtlos als Code (Infrastructure as Code) über Git-Integrationen verwaltet werden?