Was sind ACID-Garantien in Azure Databricks?

Azure Databricks verwendet standardmäßig Delta Lake für alle Lese- und Schreibvorgänge und basiert auf den ACID-Garantien, die vom Open-Source-Protokoll von Delta Lake bereitgestellt werden. ACID steht für „Atomicity, Consistency, Isolation, Durability“ (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit).

• Atomarität bedeutet, dass alle Transaktionen entweder erfolgreich sind oder vollständig fehlschlagen.
• Konsistenzgarantien beziehen sich darauf, wie ein bestimmter Zustand der Daten durch gleichzeitige Vorgänge wahrgenommen wird.
• Isolation bezieht sich darauf, wie gleichzeitige Vorgänge möglicherweise miteinander in Konflikt geraten.
• Dauerhaftigkeit bedeutet, dass Änderungen nach dem Commit dauerhaft sind.

Auch wenn viele Datenverarbeitungs- und Warehousingtechnologien vorgeblich ACID-Transaktionen umfassen, variieren bestimmte Garantien je nach System, und Transaktionen in Azure Databricks können sich von anderen Systemen, mit denen Sie gearbeitet haben, unterscheiden.

Hinweis

Auf dieser Seite werden Garantien für Tabellen beschrieben, die von Delta Lake unterstützt werden. Andere Datenformate und integrierte Systeme bieten möglicherweise keine Transaktionsgarantien für Lese- und Schreibvorgänge.

Alle Azure Databricks-Schreibvorgänge in den Cloudobjektspeicher verwenden Transaktionscommits, die neben Datendateien auch Metadatendateien beginnend mit _started_<id> und _committed_<id> erstellen. Sie müssen mit diesen Dateien nicht interagieren, da Azure Databricks routinemäßig veraltete Commit-Metadatendateien bereinigt.

Wie wird der Bereich für Transaktionen in Azure Databricks festgelegt?

Azure Databricks verwaltet Transaktionen auf Tabellenebene. Transaktionen gelten immer für jeweils eine Tabelle. Für die Verwaltung gleichzeitiger Transaktionen verwendet Azure Databricks die Steuerung der optimistischen Nebenläufigkeit. Dies bedeutet, dass es keine Sperren für das Lesen oder Schreiben für eine Tabelle gibt, und ein Deadlock ist nicht möglich.

Standardmäßig bietet Azure Databricks eine Momentaufnahmeisolation für Lesevorgänge und eine serialisierbare Schreibisolation für Schreibvorgänge. Die serialisierbare Schreibisolation bietet höhere Garantien als die Momentaufnahmeisolation, wendet aber diese stärkere Isolation nur auf Schreibvorgänge an.

Lesevorgänge, die auf mehrere Tabellen verweisen, geben zum Zeitpunkt des Zugriffs die aktuelle Version der einzelnen Tabellen zurück, unterbrechen jedoch keine gleichzeitigen Transaktionen, durch die referenzierte Tabellen möglicherweise geändert werden.

Azure Databricks verfügt nicht über BEGIN/END-Konstrukte, mit denen mehrere Vorgänge zu einer einzigen Transaktion gruppiert werden können. Anwendungen, die mehrere Tabellen ändern, committen Transaktionen in den einzelnen Tabellen auf serielle Weise. Mithilfe von MERGE INTO können Sie Einfügungen, Aktualisierungen und Löschungen für eine Tabelle in einer einzigen Schreibtransaktion kombinieren.

Wie wird die Atomarität in Azure Databricks implementiert?

Das Transaktionsprotokoll steuert die Atomarität von Commits. Während einer Transaktion werden Datendateien in das Dateiverzeichnis geschrieben, das der Tabelle zugrunde liegt. Wenn die Transaktion abgeschlossen ist, wird ein neuer Eintrag in das Transaktionsprotokoll committet. Dieser enthält die Pfade zu allen Dateien, die während der Transaktion geschrieben wurden. Jeder Commit erhöht die Tabellenversion und macht neue Datendateien für Lesevorgänge sichtbar. Der aktuelle Zustand der Tabelle umfasst alle Datendateien, die in den Transaktionsprotokollen als gültig markiert sind.

Datendateien werden nicht nachverfolgt, es sei denn, das Transaktionsprotokoll zeichnet eine neue Version auf. Wenn eine Transaktion nach dem Schreiben von Datendateien in eine Tabelle fehlschlägt, wird der Tabellenzustand durch diese Datendateien nicht beschädigt, aber die Dateien werden nicht Teil der Tabelle. Der VACUUM-Vorgang löscht alle nicht nachverfolgten Datendateien in einem Tabellenverzeichnis, einschließlich der verbleibenden, nicht committeten Dateien aus fehlgeschlagenen Transaktionen.

Wie wird die Dauerhaftigkeit in Azure Databricks implementiert?

Azure Databricks verwendet Cloudobjektspeicher zum Speichern aller Datendateien und Transaktionsprotokolle. Cloudobjektspeicher verfügt über Hochverfügbarkeit und Dauerhaftigkeit. Da Transaktionen entweder erfolgreich sind oder vollständig fehlschlagen und sich das Transaktionsprotokoll neben den Datendateien im Cloudobjektspeicher befindet, erben Tabellen in Azure Databricks die Dauerhaftigkeitsgarantien des Cloudobjektspeichers, in dem sie gespeichert sind.

Wie wird die Konsistenz in Azure Databricks implementiert?

Delta Lake verwendet die Steuerung für optimistische Parallelität, um Transaktionsgarantien zwischen Schreibvorgängen bereitzustellen. Durch diesen Mechanismus werden Schreibvorgänge in drei Phasen ausgeführt:

1. Lesen: Liest (falls erforderlich) die neueste verfügbare Version der Tabelle, um zu ermitteln, welche Dateien geändert (umgeschrieben) werden müssen.
   • Bei Schreibvorgängen, die nur anfügen, wird vor dem Schreiben nicht der aktuelle Tabellenzustand gelesen. Bei der Schemaüberprüfung werden Metadaten aus dem Transaktionsprotokoll genutzt.
2. Schreiben: Schreibt Datendateien in das Verzeichnis, das zum Definieren der Tabelle verwendet wird.
3. Überprüfen und committen:
   • Überprüft, ob die vorgeschlagenen Änderungen mit anderen Änderungen in Konflikt stehen, für die seit dem Lesen der Momentaufnahme möglicherweise gleichzeitig ein Commit ausgeführt wurde.
   • Wenn keine Konflikte vorliegen, wird für alle vorbereiteten Änderungen ein Commit als neue Momentaufnahme der geänderten Version ausgeführt und der Schreibvorgang erfolgreich abgeschlossen.
   • Wenn Konflikte auftreten, schlägt der Schreibvorgang mit einer gleichzeitigen Änderungsausnahme fehl. Dieser Fehler verhindert die Beschädigung von Daten.

Bei der optimistischen Nebenläufigkeit wird davon ausgegangen, dass die meisten gleichzeitigen Transaktionen für Ihre Daten nicht miteinander in Konflikt treten können. Konflikte können jedoch auftreten. Siehe Isolationsstufen und Schreibkonflikte in Azure Databricks.

Wie wird die Isolation in Azure Databricks implementiert?

Azure Databricks verwendet standardmäßig die serialisierbare Schreibisolation für alle Tabellenschreibvorgänge und -aktualisierungen. Die Momentaufnahmeisolation wird für alle Tabellenlesevorgänge verwendet.

Schreibserialisierbarkeit und die Steuerung der optimistischen Nebenläufigkeit arbeiten zusammen, um einen hohen Durchsatz für Schreibvorgänge bereitzustellen. Der aktuelle gültige Zustand einer Tabelle ist immer verfügbar, und ein Schreibvorgang für eine Tabelle kann jederzeit gestartet werden. Gleichzeitige Lesevorgänge werden nur durch den Durchsatz des Metastores und der Cloudressourcen eingeschränkt.

Siehe Isolationsstufen und Schreibkonflikte in Azure Databricks.

Werden Transaktionen mit mehreren Tabellen von Delta Lake unterstützt?

Delta Lake unterstützt keine Transaktionen für mehrere Tabellen. Delta Lake unterstützt Transaktionen auf Tabellenebene.

Primärschlüssel- und Fremdschlüsselbeziehungen in Azure Databricks dienen nur zur Information und werden nicht erzwungen. Siehe Deklarieren von Primärschlüssel- und Fremdschlüsselbeziehungen.

Was bedeutet es, dass Delta Lake Schreibvorgänge in mehreren Clustern unterstützt?

Delta Lake verhindert Datenbeschädigungen, wenn mehrere Cluster gleichzeitig in die gleiche Tabelle schreiben. Bei der gleichzeitigen Ausführung kann es zwar zu Konflikten zwischen einigen Schreibvorgänge kommen, die Tabelle wird jedoch nicht beschädigt. Siehe Isolationsstufen und Schreibkonflikte in Azure Databricks.

Kann ich eine Delta-Tabelle aus verschiedenen Arbeitsbereichen ändern?

Ja, Sie können dieselbe Delta-Tabelle gleichzeitig aus verschiedenen Arbeitsbereichen ändern. Wenn ein Prozess aus einem Arbeitsbereich schreibt, erhalten Leser in anderen Arbeitsbereichen darüber hinaus eine konsistente Ansicht.