Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Delta Lake auf Azure Databricks unterstützt zwei Isolationsstufen, die steuern, wie gleichzeitige Vorgänge in einer bestimmten Tabelle interagieren:
| Isolationsstufe | Beschreibung |
|---|---|
| Serialisierbar | Die stärkste Isolationsstufe. Stellt sicher, dass zugesicherte Schreibvorgänge und alle Lesevorgänge serialisierbar sind. Vorgänge sind zulässig, solange eine serielle Sequenz vorhanden ist, die bei gleichzeitiger Ausführung dasselbe Ergebnis generiert wie in der Tabelle. Bei Schreibvorgängen ist diese serielle Sequenz identisch mit der Reihenfolge, die in der Historie der Tabelle zu sehen ist. |
| WriteSerializable (Standard) | Eine schwächere Isolationsstufe als die Serialisierbare. Stellt sicher, dass nur Schreibvorgänge (nicht gelesen) serialisierbar sind. Dies ist immer noch stärker als snapshot isolation. Bietet eine gute Balance zwischen Datenkonsistenz und Verfügbarkeit für die häufigsten Vorgänge. |
Auswirkungen der Isolationsebenen auf Lesevorgänge
Für Lesevorgänge gilt stets die Momentaufnahmenisolation. Die Schreibisolationsstufe bestimmt, ob ein Leser eine Momentaufnahme einer Tabelle sehen kann, die gemäß dem Verlauf "nie existierte".
- Serialisierbar: Ein Leser sieht immer nur Tabellen, die dem Verlauf entsprechen
- WriteSerializable: Ein Leser kann einen Tabellenstatus sehen, der im Delta-Protokoll nicht vorhanden ist.
Beispiel: Gleichzeitiges Löschen und Einfügen
Betrachten Sie ein Szenario, in dem eine lange Löschtransaktion und eine Insert-Transaktion gleichzeitig beginnen, und die Version v0 lesen. Die Einfügetransaktion wird zuerst abgeschlossen und erstellt die Version v1. Danach versucht die Löschtransaktion, einen Commit durchzuführen v2:
t0: deleteTxn_START
t1: insertTxn_START
t2: insertTxn_COMMIT(v1)
t3: deleteTxn_COMMIT(v2)
In diesem Szenario deleteTxn hat die von insertTxn eingefügten Daten nicht gesehen und nicht gelöscht:
-
Serialisierbar:
deleteTxnEs ist nicht zulässig, einen Commit auszuführen, ein Konflikt tritt auf -
WriteSerializable: Das Commit ist zulässig, da die Transaktionen sortiert werden können. Der resultierende Tabellenstatus ist so, als sei
insertTxnnachdeleteTxnaufgetreten, sodass die eingefügten Zeilen Teil der Tabelle sind. Der Delta-Verlauf zeigt jedoch die physische Commitreihenfolge (insertTxnbei v1 vordeleteTxnbei v2).
Festlegen der Isolationsstufe
Legen Sie die Isolationsstufe mithilfe des ALTER TABLE Befehls fest:
ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)
Wo <level-name> ist Serializable oder WriteSerializable.
Example:
-- Change from default WriteSerializable to Serializable
ALTER TABLE my_table SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')
Wann führt Delta Lake ein Commit aus, ohne die Tabelle zu lesen?
Bei INSERT- oder Anfügevorgängen in Delta Lake wird der Tabellenstatus vor dem Commit nicht gelesen, wenn die folgenden Bedingungen erfüllt sind:
- Logik wird mithilfe der
INSERTSQL-Logik oder des Anfügemodus ausgedrückt. - Logik enthält keine Unterabfragen oder Bedingungen, die auf die Tabelle verweisen, auf die der Schreibvorgang abzielt.
Wie bei anderen Commits verwendet Delta Lake Transaktionsprotokollmetadaten, um Tabellenversionen beim Commit zu überprüfen und aufzulösen, aber keine Version der Tabelle wird tatsächlich gelesen.
Hinweis
Viele gängige Muster verwenden MERGE-Vorgänge zum Einfügen von Daten basierend auf Tabellenbedingungen. Obwohl es möglich sein kann, diese Logik mit INSERT-Anweisungen neu zu schreiben, wenn ein bedingter Ausdruck auf eine Spalte in der Zieltabelle verweist, weisen diese Anweisungen die gleichen Parallelitätseinschränkungen wie MERGE auf.