--- title: "Delta Lake: wenn das Unternehmen auf Microsoft steht" url: "https://hurukan.com/de/blog/delta-lake-wenn-das-unternehmen-auf-microsoft-steht" description: "OneLake speichert Tabellen als Delta Parquet. Was das Delta-Log der Aufzeichnung gibt, was Microsoft Fabric für Sie verwaltet und was Ihre Entscheidung bleibt." --- # Delta Lake: wenn das Unternehmen auf Microsoft steht 1\. Oktober 2026·4 Min. Lesezeit·Redaktion Ein Finanzcontroller von der Seite an einem Stehpult in einem offenen Büro, ein breiter Monitor zeigt ein abstraktes blau-graues Hauptbuch mit einer Spalte von Versionsnummern, ein zweiter Bildschirm mit einem Kalender, graue Wände und ein dünner blauer LED-Streifen unter dem Tisch Ein Unternehmen läuft seit fünfzehn Jahren auf Microsoft. E-Mail, Dokumente und Besprechungen in Microsoft 365, Berichte in Power BI und seit Kurzem ein Fabric-Arbeitsbereich, in dem das Datenteam Auszüge aus dem ERP ablegt. Wenn ein solches Unternehmen ein Betriebssystem für das ganze Geschäft erwägt, ist die erste Frage der IT vernünftig: Landet die Aufzeichnung an einem Ort, den unsere Werkzeuge noch lesen können? Für ein Unternehmen in dieser Lage führt die Antwort über Delta Lake. OneLake, der Speicher unter Fabric, hält seine Tabellen laut [Microsofts Dokumentation](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview) als Delta Parquet, also ist eine Aufzeichnung in Delta eine, die Fabric ohne Kopie lesen kann. Hurukans Integration mit Microsoft 365 Copilot ist geplant, nicht live, und die Datenschicht ist im Aufbau; dieser Text handelt davon, was Delta Lake der Aufzeichnung in diesem Umfeld gibt und was dem Unternehmen zu entscheiden bleibt. Warum es die Aufzeichnung überhaupt gibt, steht in [Laufender Zustand und Aufzeichnung](https://hurukan.com/de/blog/laufender-zustand-und-aufzeichnung-zwei-gedaechtnisse). ## Was das Log tut Delta Lake fügt einem Verzeichnis von Parquet-Dateien eine Sache hinzu: ein Transaktionslog. `_delta_log/` hält eine JSON-Datei je Commit, nach Version benannt, die jeweils auflistet, welche Dateien hinzugefügt oder entfernt wurden und wie Schema und Protokoll lauten. Periodische Parquet-Checkpoints fassen das Log zusammen, damit ein Leser es nicht von Anfang an abspielt. Das [Protokolldokument](https://github.com/delta-io/delta/blob/master/PROTOCOL.md) definiert das; Version [4.4.0](https://github.com/delta-io/delta/releases) ist aktuell (geprüft am 21. Oktober 2026). Aus diesem einen Mechanismus folgt alles, was die Aufzeichnung braucht. Ein Schreibvorgang ist atomar, weil die Commit-Datei entweder existiert oder nicht. Leser sehen eine ganze Version, weil sie einen nummerierten Commit lesen, keine Verzeichnisliste. Zwei Schreiber beschädigen einander nicht, weil optimistische Nebenläufigkeit den Konflikt beim Commit erkennt. Und „die Tabelle, wie sie war, als der Agent dies vorschlug” ist eine Versionsnummer — das macht die Prüffrage beantwortbar. ## Die Funktionen, die für eine Aufzeichnung zählen Deltas Tabellenfunktionen werden je Tabelle eingeschaltet und im Protokoll geführt, sodass ein Leser weiß, ob er lesen kann, was er vor sich hat. Die [Versionsseite](https://docs.delta.io/latest/versioning.html) listet sie mit den Leser- und Schreiberversionen, die sie verlangen (geprüft am 21. Oktober 2026). Vier davon prägen eine Unternehmensaufzeichnung. **Löschvektoren** markieren Zeilen als entfernt, ohne die Datei neu zu schreiben, sodass ein Löschersuchen für eine Person nicht ein Jahr an Rechnungen neu schreibt. Die Entfernung wird endgültig, wenn die alten Dateien per Vacuum bereinigt werden — eine Aufbewahrungseinstellung, kein automatischer Effekt. **Change Data Feed** legt offen, was sich zwischen zwei Versionen geändert hat; so erfahren nachgelagerte Tabellen und Agenten von einer Änderung, ohne alles neu zu lesen. **Liquid Clustering** ersetzt feste Partitionen durch Clustering-Schlüssel, die sich später ändern können, sodass der Aufbau dem folgen kann, wie die Aufzeichnung tatsächlich abgefragt wird. **UniForm** schreibt Iceberg-Metadaten neben das Delta-Log, sodass Engines, die Iceberg lesen, dieselbe Tabelle sehen. Es verlangt Column Mapping, ist von der Iceberg-Seite nur lesbar und hat dokumentierte Grenzen bei Löschvektoren und Änderungsdaten, beschrieben unter [Delta UniForm](https://docs.delta.io/latest/delta-uniform.html). Der Text dieser Reihe zu [XTable und UniForm](https://hurukan.com/de/blog/eine-aufzeichnung-fuer-vorhandene-werkzeuge-xtable-uniform) geht darauf ein, was das bringt. ## Was Fabric verwaltet, und was nicht Eine verwaltete Plattform nimmt dem Unternehmen echte Arbeit ab: Speicher, Rechenleistung, die Engines, die Power-BI-Anbindung und zunehmend die Wartungsjobs. Sie ist ein vernünftiger Ort für eine Aufzeichnung, wenn das Unternehmen bereits entschieden hat, auf Microsoft zu stehen. Vier Dinge bleiben beim Unternehmen, ob es das bemerkt oder nicht. **Der Katalog.** OneLake entscheidet, wie eine Tabelle heißt, wer sie lesen darf und wo die aktuelle Version erklärt wird. Die Dateien sind offen; das Verzeichnis der Dateien gehört der Plattform. Ein Ausstiegsplan, der sagt „wir haben Parquet in einem Lake”, hat dieses Verzeichnis nicht berücksichtigt. **Aufbewahrung und Löschung.** Log-Aufbewahrung und Vacuum-Schwellen sind Tabelleneinstellungen. Sie bestimmen, wie weit die Zeitreise reicht und wann eine gelöschte Person tatsächlich weg ist. Niemand bei der Plattform setzt sie für Sie, und ein Agent in Hurukan darf sie vorschlagen, aber nicht freigeben. **Einschalten von Funktionen.** Eine neuere Funktion einzuschalten hebt die Protokollversion an und kann einen älteren Leser anderswo im Unternehmen aussperren. Der Gewinn ist real; der Leser, der stehen bleibt, auch. Ein Mensch entscheidet, je Tabelle, mit der Liste der Leser vor sich. **Der Schreibpfad.** Delta kann von vielen Engines geschrieben werden, aber die Engine, die eine bestimmte Tabelle schreibt, ist eine Entwurfsentscheidung, weil dort die Eigentümerschaft der Daten sitzt. In Hurukan schreiben die Module über den eigenen Pfad der Aufzeichnung und die Plattform liest; das Umgekehrte ist eine andere Architektur. Welche davon das Unternehmen besitzt, ist genau die Frage unter [Sicherheit und Souveränität](https://hurukan.com/de/system/sicherheit-und-souveraenitaet): Infrastruktur, die das Unternehmen wählt, Daten und Modelle, die beim Unternehmen bleiben, ein Ausstieg, der in der Praxis möglich ist. ## Wo Agenten helfen, und wo sie aufhören Die Wartung einer Delta-Aufzeichnung ist mechanisch und dauerhaft: Verdichtung, Vacuum, Statistiken, Clustering. Agenten entwerfen diese Jobs gut, und sie erklären eine langsame Abfrage besser als ein Dashboard. In Hurukan ist jeder solche Job ein Vorschlag im Freigabe-Posteingang mit beigefügter Begründung, von einem Menschen freigegeben und wie jede andere Änderung aufgezeichnet. Was Agenten nicht tun, ist über Aufbewahrung entscheiden, eine Protokollanhebung freigeben oder den Schreibpfad wählen. Diese drei Entscheidungen legen fest, was die Aufzeichnung später beweisen kann, und ein Unternehmen muss sagen können, wer sie getroffen hat. ## Ein Test, den Sie heute machen können Öffnen Sie eine Tabelle, die Ihr Fabric-Arbeitsbereich bereits hält, und suchen Sie drei Einstellungen: ihre Log-Aufbewahrung, ihre Vacuum-Schwelle und die Protokollversion, die sie von einem Leser verlangt. Stehen alle drei dort, wo die Plattform sie gelassen hat, hat noch niemand entschieden, wie weit Ihre Aufzeichnung zurückreicht oder welche Ihrer Werkzeuge sie nächstes Jahr lesen können. Das ist die erste Entscheidung, die eine Unternehmensaufzeichnung braucht, und sie kostet nichts. - Delta Lake - Microsoft Fabric - OneLake - Transaktionslog - Souveränität ## Weiterlesen - [Eine Identität für Menschen und Agenten: wer was tun darf](https://hurukan.com/de/blog/eine-identitaet-fuer-menschen-und-agenten) - [Laufender Zustand und Aufzeichnung: die zwei Gedächtnisse eines Unternehmensbetriebssystems](https://hurukan.com/de/blog/laufender-zustand-und-aufzeichnung-zwei-gedaechtnisse)