Freigeben über

Transaktionen

Von Bedeutung

Transaktionen, die in verwaltete Delta-Tabellen im Unity-Katalog schreiben, befinden sich in der öffentlichen Vorschau.

Transaktionen, die in verwaltete Iceberg-Tabellen im Unity-Katalog schreiben, befinden sich in der privaten Vorschau. Um dieser Vorschau beizutreten, übermitteln Sie das Vorschauformular für verwaltete Iceberg-Tabellen.

Mit Transaktionen können Sie Vorgänge über mehrere SQL-Anweisungen und Tabellen hinweg koordinieren. Alle Änderungen werden entweder gemeinsam erfolgreich durchgeführt oder gemeinsam rückgängig gemacht, wodurch die Konsistenz der Daten über Ihre Vorgänge und Tabellen hinweg gewährleistet wird. Transaktionen bieten ACID-Garantien: Atomität, Konsistenz, Isolation und Haltbarkeit. Weitere Informationen finden Sie unter Was sind ACID-Garantien in Azure Databricks?. Transaktionen können mit gespeicherten Prozeduren und SQL Scripting verwendet werden, um unternehmenskritische Lagerarbeitslasten zu erstellen.

Das folgende Beispiel zeigt eine Transaktion:

BEGIN ATOMIC
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
  INSERT INTO audit_log VALUES (1, 2, 100, current_timestamp());
END;

Alle drei Anweisungen werden gemeinsam ausgeführt. Wenn eine Anweisung fehlschlägt, werden alle Änderungen rückgängig gemacht und Databricks beendet die Transaktion ohne unerwünschte Effekte.

Praktische Übungen mit Transaktionen finden Sie im Lernprogramm: Koordinieren von Transaktionen über Tabellen hinweg.

Anforderungen

So führen Sie Transaktionen aus, die mehrere Anweisungen oder mehrere Tabellen umfassen:

  • Alle Tabellen, in die geschrieben werden muss:
  • Verwenden Sie unterstützte Rechenleistung.
    • Verwenden Sie für nicht interaktive Transaktionen jedes SQL Warehouse, serverloses Compute oder Cluster mit Databricks Runtime 18.0 und höher.
    • Verwenden Sie für interaktive Transaktionen ein beliebiges SQL Warehouse.
    • Verwenden Sie für Transaktionen mit Delta Sharing freigegebenen Vermögenswerten Databricks Runtime 18.1 und höher.

Transaktionsmodi

Azure Databricks unterstützt zwei Transaktionsmodi:

Modus Syntax Commit Rollback Am besten geeignet für:
Nicht interaktiv ATOMIC Compound-Anweisung Automatisch bei Erfolg Automatisch bei Fehler Feste Sequenzen, geplante Aufträge
Interaktiv BEGIN TRANSACTION; COMMIT; Manuell Manuell Bedingte Logik, Validierung und Debugging, CSV, ODBC, PyDBC

Ausführliche Syntax, Beispiele und Verwendungsmuster für beide Modi finden Sie unter Transaktionsmodi.

Unterstützte Operationen

Sie können die folgenden Vorgänge innerhalb von Transaktionen verwenden:

Vorgang Beschreibung
SELECT Abfragen von Daten und Überprüfen von Ergebnissen
VALUES Klausel Generieren von Testdaten oder Konstantenwerten
INSERT (einschließlich aller Varianten) Hinzufügen neuer Zeilen
UPDATE Vorhandene Zeilen ändern
COPY INTO Laden von Daten aus einer Datei in eine Delta-Tabelle
DELETE FROM Zeilen entfernen
MERGE INTO Upsert-Muster zur Kombination von Einfüge-, Aktualisierungs- und Löschoperationen

Quellen in Transaktionen lesen

Transaktionen können aus Unity-Katalogtabellen (Delta und Iceberg), Streamingtabellen, Ansichten und materialisierten Ansichten lesen. Verwenden Sie den allow_nontransactional_reads Hinweis, um aus nicht transaktionalen Quellen zu lesen.

Lesen aus nicht transaktionsfreien Quellen

Verwenden Sie den Hinweis allow_nontransactional_reads, wie im folgenden Beispiel gezeigt, um mit JDBC aus nicht-transaktionellen Quellen wie Parquet-Dateien, Avro-Dateien und Verbundtabellen zu lesen.

BEGIN TRANSACTION;

-- Read from a non-transactional Parquet source
INSERT INTO transactional_table
SELECT col1, col2
FROM parquet.`/path/to/data`
WITH (allow_nontransactional_reads = true);

-- Read from a managed Delta table (no hint needed)
INSERT INTO another_table
SELECT * FROM managed_delta_table;

COMMIT;

Warnung

Nicht transaktionsbezogene Lesevorgänge können nicht wiederholt werden. Gleichzeitige Änderungen an den Quelldaten während der Transaktion können zu inkonsistenten Lesevorgängen führen.

Transaktionsisolation

Transaktionen bieten wiederholbare Lesevorgänge für alle Abfragen. Wenn Sie auf eine Tabelle in einer Transaktion zugreifen, erfasst Azure Databricks beim ersten Zugriff eine konsistente Momentaufnahme dieser Tabelle. Alle nachfolgenden Lesevorgänge dieser Tabelle verwenden diese Momentaufnahme, sodass Ihre Lesevorgänge konsistent bleiben, auch wenn andere Benutzer gleichzeitig dieselben Tabellen ändern.

Beispiel:

BEGIN TRANSACTION;

-- First access to products table captures snapshot
SELECT * FROM products WHERE product_id = 1001;

-- Another user updates product 1001

-- Still reads the same snapshot (repeatable read)
SELECT * FROM products WHERE product_id = 1001;

COMMIT;

Konflikterkennung und Parallelität

Azure Databricks verwendet optimistische Parallelitätssteuerelemente. Transaktionen werden ohne Sperrung fortgesetzt, und Konflikte werden beim Commit erkannt. Wenn Sie einen Commit ausführen, überprüft Azure Databricks, ob andere Transaktionen dieselben Daten geändert haben, nachdem Ihre Transaktion begonnen hat. Wenn Konflikte bestehen, schlägt ihre Transaktion fehl. Bei nicht interaktiven Transaktionen erfolgt auch das Rollback automatisch. Für interaktive Transaktionen müssen Sie ROLLBACK explizit ausführen, um den Transaktionsstatus zu löschen, bevor Sie eine neue Transaktion beginnen.

Nicht interaktive Transaktionen unterstützen Zeilenebenenkonkurrenz. Zwei Transaktionen können unterschiedliche Zeilen in derselben Datendatei ändern, ohne dass Konflikte auftreten, wenn die Parallelität auf Zeilenebene in den Zieltabellen aktiviert ist.

Interaktive Transaktionen unterstützen Parallelität auf Tabellenebene.

Konfliktszenarien

Szenario Beschreibung
Schreibkonflikte Zwei Transaktionen aktualisieren oder löschen dieselben Zeilen.
Schreib-Lese-Konflikte Eine andere Transaktion hat die Zeilen geändert, die Ihre Transaktion gelesen hat. Gilt nur für serialisierbare Isolation.
Phantomlesekonflikte Eine andere Transaktion hat neue Zeilen hinzugefügt, die mit einer Bedingung Ihrer Transaktion übereinstimmen. Gilt sowohl für WriteSerializable als auch für Serialisierbare Isolation.
Metadatenkonflikte Eine andere Transaktion hat das Tabellenschema oder die Eigenschaften geändert.

Weitere Informationen zu Isolationsstufen und Konfliktauflösung für Transaktionen finden Sie unter Transaktionsmodi. Informationen zu Isolationsstufen und Schreiben von Konfliktverhalten für Delta Lake-Tabellen in Azure Databricks finden Sie unter Optimierungsempfehlungen für Azure Databricks.

Darstellung von Transaktionen im Delta-Protokoll

Jede erfolgreiche Transaktion wird als einzelner Eintrag im Delta-Protokoll der Tabelle angezeigt, unabhängig davon, wie viele einzelne Anweisungen innerhalb der Transaktion ausgeführt wurden. Dies bietet einen sauberen Überwachungspfad und vereinfacht Rollbackvorgänge.

Einzelne Vorgänge innerhalb einer Transaktion sind als JSON-Metadaten im Delta-Protokolleintrag für die Transaktion verfügbar.

Fehlerbehandlung und Rollback

In der folgenden Tabelle wird beschrieben, wie Fehlerrollbacks für beide Arten von Transaktionen durchgeführt werden.

Szenario Verhalten für nicht interaktive Transaktionen Verhalten für interaktive Transaktionen
Anweisungsfehler Jede Anweisung, die einen Fehler auslöst, führt zu einem sofortigen automatischen Rollback. Sie müssen ROLLBACK explizit ausführen, um Änderungen zu verwerfen, wenn die Sitzung noch aktiv ist.
Fehlgeschlagene Überprüfungslogik oder Geschäftsregeln Verwenden Sie SIGNAL, um eine Ausnahme zu werfen und ein automatisches Rollback zu veranlassen. Führen Sie ROLLBACK aus, um Änderungen zu verwerfen.
Sitzungsverbindung trennen Die Transaktion wird automatisch zurückgesetzt. Die Transaktion wird automatisch zurückgesetzt.
Zeitlimit Automatisches Zurücksetzen nach 48 Stunden Gesamtdauer. Automatisches Zurücksetzen nach 10 Minuten Inaktivität oder 48 Stunden Gesamtdauer (siehe Einschränkungen). Die Transaktion wird ohne Nebenwirkungen beendet, aber Sie müssen ROLLBACK explizit ausführen, um den Transaktionsstatus zu löschen, wenn die Sitzung noch aktiv ist.

Bei interaktiven Transaktionen können Sie ein Rollback mithilfe der ROLLBACK-Anweisung explizit durchführen. Dies ist nützlich, wenn Sie Änderungen basierend auf Validierungslogik oder Geschäftsregeln verwerfen möchten oder nach einem Anweisungsfehler, wenn die Sitzung aktiv bleibt.

Bewährte Methoden

Befolgen Sie diese Methoden, um Konflikte zu reduzieren und die Transaktionsleistung zu optimieren.

Vermeiden von Konflikten

  • Halten Sie Transaktionen kurz: Lange laufende Transaktionen erhöhen die Konfliktwahrscheinlichkeit und halten Ressourcen länger.
  • Frühzeitig validieren: Überprüfen Sie die Vorbedingungen zu Beginn einer Transaktion, um Fehler frühzeitig zu erkennen.
  • Databricks empfiehlt nicht interaktive Transaktionen für die meisten Anwendungsfälle: Nicht interaktive Transaktionen verwenden Parallelität auf Zeilenebene. Siehe nicht interaktive Transaktionen.
  • Erneuter Versuch bei Konflikten: Wenn Konflikte auftreten, versuchen Sie die Transaktion erneut mit frischen Daten.

Verwenden von Transaktionen aus verschiedenen Clients

Transaktionen funktionieren über verschiedene Clientschnittstellen hinweg:

Einschränkungen

Die folgenden Einschränkungen gelten für Transaktionen, die sich über mehrere Tabellen erstrecken:

Einschränkung Beschreibung
Interaktive Transaktionskonflikte Interaktive Transaktionen (BEGIN TRANSACTION; ... COMMIT;) verwenden eine konservativere Konflikterkennung als nicht interaktive Transaktionen und können auf Tabellenebene Konflikte verursachen, mit Ausnahme von INSERT Vorgängen, die nicht aus der Zieltabelle lesen. Verwenden Sie nicht interaktive Transaktionen (ATOMIC Compound Statement), wenn die Konflikterkennung auf Zeilenebene wichtig ist. Siehe nicht interaktive Transaktionen.
Schreiben von Zielen Sie können nur in verwaltete Delta- oder Iceberg-Tabellen im Unity-Katalog schreiben, für die die catalogManaged Tabellenfunktion aktiviert ist. Siehe von Katalog verwaltete Commits.
Nur DML-Vorgänge Transaktionen unterstützen SELECT, INSERT, UPDATE, DELETE, COPY INTO und MERGE. Führen Sie DDL-Vorgänge aus, z. B. CREATE TABLE, ALTER TABLE, oder DROP TABLE außerhalb von Transaktionen.
Metadatenvorgänge werden nicht unterstützt Metadatenvorgänge funktionieren unabhängig vom Protokoll nicht innerhalb von Transaktionen. Dazu gehören Thrift RPC-basierte Metadatenaufrufe (z. B. JDBC-Methoden DatabaseMetaData und ODBC-Katalogfunktionen), SQL-basierte Befehle (SHOW TABLES, SHOW DATABASES, DESCRIBE TABLE) und Abfragen SELECT gegen information_schema Tabellen oder Systemtabellen. Ausführen von Metadatenvorgängen außerhalb von Transaktionen.
COPY INTO Parallelität Eine Transaktion, bei der ein COPY INTO Befehl ausgeführt wird, schlägt fehl, wenn ein anderer COPY INTO Befehl gleichzeitig ausgeführt wird, um in dieselbe Tabelle zu schreiben und zuerst einen Commit auszuführen.
Streaming-Schreibvorgänge werden nicht unterstützt Transaktionsschreibvorgänge in Streamingtabellen werden nicht unterstützt.
RLS- und CLM-Tabellen werden nicht unterstützt Tabellen mit Zeilenfiltern und Spaltenmasken können nicht an Transaktionen teilnehmen.
Grenzwerte für Tabellen und Ansichten Eine Transaktion kann aus bis zu 100 Tabellen lesen oder in bis zu 100 Tabellen schreiben und von bis zu 100 Ansichten lesen. Jede Tabelle kann bis zu 100 Zwischen-Commits innerhalb einer Transaktion aufweisen.
Zeitreise wird nicht unterstützt Sie können keinen Zeitsprung innerhalb einer Transaktion verwenden.
Leerlaufzeitüberschreitung Interaktive Transaktionen werden nach 10 Minuten Inaktivität zurückgespielt. Die Transaktion wird ohne Nebenwirkungen beendet, aber Sie müssen ROLLBACK explizit ausführen, um den Transaktionsstatus zu löschen, wenn die Sitzung noch aktiv ist.
Maximale Dauer Alle Transaktionen werden automatisch nach einer Gesamtdauer von 48 Stunden zurückgesetzt. Bei interaktiven Transaktionen wird die Transaktion ohne Nebenwirkungen beendet, aber Sie müssen ROLLBACK explizit ausführen, um den Transaktionsstatus zu löschen, wenn die Sitzung noch aktiv ist.
Anforderung an die Delta Sharing für freigegebene Tabellen Delta-Freigabeanbieter müssen eine Tabelle WITH HISTORYfreigeben, damit Empfänger Transaktionen darauf ausführen können. Empfänger können Transaktionen mit jedem Computetyp ausführen.
Einschränkungen für die Empfänger der Delta Sharing Azure Databricks-Empfänger können nur Transaktionen für freigegebene Ansichten, materialisierte Ansichten, Streamingtabellen und Nicht-Iceberg-Fremdtabellen ausführen. Empfänger im gleichen Azure Databricks-Konto wie ihr Anbieter müssen gemeinsam genutzte oder serverlose Compute verwenden. Empfänger in einem anderen Konto müssen auf serverlose Rechenleistung zurückgreifen.
Konflikt bei der Delta-Freigabe-Quelltabelle Delta-Freigabeempfänger können auf eine freigegebene Ansicht und eine freigegebene Tabelle, die auf dieselbe Quelltabelle verweisen, nicht innerhalb derselben Transaktion gleichzeitig zugreifen.

Nächste Schritte

  • Last updated on