Dela via

Transaktioner

Viktigt!

Transaktioner som skriver till hanterade Delta-tabeller i Unity Catalog finns i offentlig förhandsversion.

Transaktioner som skriver till hanterade Iceberg-tabeller i Unity Catalog finns i privat förhandsversion. Om du vill ansluta till den här förhandsversionen skickar du registreringsformuläret för förhandsversionen av hanterade Iceberg-tabeller.

Med transaktioner kan du samordna åtgärder i flera SQL-instruktioner och tabeller. Alla ändringar lyckas tillsammans eller rullas ihop igen, vilket säkerställer datakonsekvens i dina åtgärder och tabeller. Transaktioner ger ACID-garantier: atomicitet, konsistens, isolering och hållbarhet. Se Vad är ACID-garantier på Azure Databricks?. Transaktioner kan användas med lagrade procedurer och SQL-skript för att skapa verksamhetskritiska lagerarbetsbelastningar.

I följande exempel visas en 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;

Alla tre uttalanden genomförs tillsammans. Om någon instruktion misslyckas återställs alla ändringar och Databricks avslutar transaktionen utan biverkningar.

Praktiska metoder för transaktioner finns i Självstudie: Samordna transaktioner mellan tabeller.

Requirements

Så här kör du transaktioner som sträcker sig över flera uttryck eller flera tabeller:

  • Alla tabeller som skrivs till måste:
  • Använd beräkning som stöds:
    • För icke-interaktiva transaktioner använder du alla SQL-lager, serverlös beräkning eller kluster som kör Databricks Runtime 18.0 och senare.
    • För interaktiva transaktioner använder du alla SQL-lager.
    • För transaktioner på tillgångar som delas via Delta Sharing använder du Databricks Runtime 18.1 och senare.

Transaktionslägen

Azure Databricks stöder två transaktionslägen:

Läge Syntax Commit Tillbakagång Bäst för
Icke-interaktiv ATOMISK sammansatt sats Automatiskt vid framgång Automatiskt vid fel Fasta sekvenser, schemalagda jobb
Interactive BEGIN TRANSACTION; COMMIT; Manuell Manuell Villkorslogik, validering och felsökning, JDBC, ODBC, PyDBC

Detaljerad syntax, exempel och användningsmönster för båda lägena finns i Transaktionslägen.

Åtgärder som stöds

Du kan använda följande åtgärder inom transaktioner:

Verksamhet Beskrivning
SELECT Fråga efter data och validera resultat
VALUES-klausul Generera testdata eller konstanta värden
INSERT (inklusive alla varianter) Lägga till nya rader
UPDATE Ändra befintliga rader
COPY INTO Läsa in data från en fil i en Delta-tabell
DELETE FROM Ta bort rader
MERGE INTO Upsert-mönster som kombinerar infoga, uppdatera och ta bort

Läs källor i transaktioner

Transaktioner kan läsa från Unity Catalog-tabeller (Delta och Iceberg), strömmande tabeller, vyer och materialiserade vyer. Om du vill läsa från icke-transaktionskällor använder du tipset allow_nontransactional_reads .

Läsa från icke-transaktionskällor

Om du vill läsa från icke-transaktionskällor som Parquet-filer, Avro-filer och federerade tabeller med JDBC använder du tipset allow_nontransactional_reads , som du ser i följande exempel:

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;

Varning

Icke-transaktionella läsningar kan inte upprepas. Samtidiga ändringar av källdata under transaktionen kan resultera i inkonsekventa läsningar.

Transaktionsisolering

Transaktioner ger upprepningsbara läsningar över alla sats. När du kommer åt en tabell i en transaktion samlar Azure Databricks in en konsekvent ögonblicksbild av tabellen vid första åtkomsten. Alla efterföljande läsningar av tabellen använder den här ögonblicksbilden, så dina läsningar förblir konsekventa även om andra användare samtidigt ändrar samma tabeller.

Exempel:

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;

Konfliktidentifiering och samtidighet

Azure Databricks använder optimistisk samtidighetskontroll. Transaktioner genomförs omgående utan låsning och konflikter upptäcks vid commit-tidpunkt. När du infogar kontrollerar Azure Databricks om andra transaktioner har ändrat samma data efter att din transaktion började. Om det finns konflikter misslyckas transaktionen. För icke-interaktiva transaktioner sker återställningen också automatiskt. För interaktiva transaktioner måste du uttryckligen köra ROLLBACK för att rensa transaktionstillståndet innan du påbörjar en ny transaktion.

Icke-interaktiva transaktioner stöder samtidighet på radnivå. Två transaktioner kan ändra olika rader i samma datafil utan konflikt när samtidighet på radnivå är aktiverat i måltabellerna.

Interaktiva transaktioner stöder samtidighet på tabellnivå.

Konfliktscenarier

Scenario Beskrivning
Skrivkonflikter Två transaktioner uppdaterar eller tar bort samma rader.
Skrivläsningskonflikter En annan transaktion ändrade rader som din transaktion hade läst. Gäller endast serialiserbar isolering.
Fiktiva läskonflikter En annan transaktion har lagt till nya rader som matchar ett predikat som din transaktion läste. Gäller för både WriteSerializable och Serializable isolation.
Metadatakonflikter En annan transaktion har ändrat tabellschemat eller egenskaperna.

Mer information om isoleringsnivåer och konfliktlösning för transaktioner finns i Transaktionslägen. Information om isoleringsnivåer och skrivkonflikter för Delta Lake-tabeller i Azure Databricks finns i Optimeringsrekommendationer för Azure Databricks.

Så här visas transaktioner i Delta-loggen

Varje lyckad transaktion visas som en enda post i tabellens Delta-logg, oavsett hur många enskilda instruktioner som kördes i transaktionen. Detta ger en ren spårningslogg och förenklar återställningsåtgärder.

Enskilda åtgärder i en transaktion är tillgängliga som JSON-metadata i deltaloggposten för transaktionen.

Felhantering och återställning

I följande tabell beskrivs hur återställningar av fel inträffar för båda transaktionstyperna:

Scenario Beteende för icke-interaktiva transaktioner Beteende för interaktiva transaktioner
Uttalande fel Alla påståenden som genererar ett fel orsakar omedelbar automatisk återgång. Du måste uttryckligen köra ROLLBACK för att ignorera ändringar om sessionen fortfarande är aktiv.
Valideringslogik eller affärsregler misslyckades Använd SIGNAL för att utlösa ett undantag och automatisk återställning. Kör ROLLBACK för att ignorera ändringar.
Frånkoppling av session Transaktionen återställs automatiskt. Transaktionen återställs automatiskt.
Tidsavbrott Återställs automatiskt efter 48 timmars samlad varaktighet. Återställs automatiskt efter 10 minuters inaktivitet eller 48 timmars total varaktighet (se Begränsningar). Transaktionen avslutas utan biverkningar, men du måste uttryckligen köra ÅTERSTÄLLNING för att rensa transaktionstillståndet om sessionen fortfarande är aktiv.

För interaktiva transaktioner kan du uttryckligen återställa med hjälp av ROLLBACK-instruktionen . Detta är användbart när du vill ignorera ändringar baserat på valideringslogik eller affärsregler, eller efter ett instruktionsfel när sessionen förblir aktiv.

Metodtips

Följ dessa metoder för att minska konflikter och optimera transaktionsprestanda.

Undvik konflikter

  • Håll transaktionerna korta: Långvariga transaktioner ökar sannolikheten för konflikter och håller resurserna längre.
  • Verifiera tidigt: Kontrollera förhandsvillkoren i början av en transaktion för att misslyckas snabbt.
  • Databricks rekommenderar icke-interaktiva transaktioner för de flesta användningsfall: Icke-interaktiva transaktioner använder samtidighet på radnivå. Se Icke-interaktiva transaktioner.
  • Försök igen vid konflikter: När konflikter inträffar kan du försöka utföra transaktionen igen med nya data.

Använda transaktioner från olika klienter

Transaktioner fungerar i olika klientgränssnitt:

Begränsningar

Följande begränsningar gäller för transaktioner som omfattar flera tabeller:

Limitation Beskrivning
Interaktiva transaktionskonflikter Interaktiva transaktioner (BEGIN TRANSACTION; ... COMMIT;) använder mer konservativ konfliktidentifiering än icke-interaktiva transaktioner och kan komma i konflikt på tabellnivå, förutom vid INSERT operationer som inte läser från måltabellen. Använd icke-interaktiva transaktioner (ATOMIC compound statement) när konfliktidentifiering på radnivå är viktigt. Se Icke-interaktiva transaktioner.
Skriv målen Du kan bara skriva till Unity Catalog-hanterade Delta- eller Iceberg-tabeller som har catalogManaged tabellfunktionen aktiverad. Se Kataloghanterade incheckningar.
Endast DML-åtgärder Transaktioner stöder SELECT, INSERT, UPDATE, DELETE, COPY INTOoch MERGE. Kör DDL-åtgärder, till exempel CREATE TABLE, ALTER TABLEeller DROP TABLE, utanför transaktioner.
Metadataåtgärder stöds inte Metadataåtgärder fungerar inte i transaktioner oavsett protokoll. Detta inkluderar Thrift RPC-baserade metadataanrop (till exempel JDBC-metoder DatabaseMetaData och ODBC-katalogfunktioner), SQL-baserade kommandon (SHOW TABLES, SHOW DATABASES, DESCRIBE TABLE) och SELECT frågor mot information_schema tabeller eller systemtabeller. Kör metadataåtgärder utanför transaktioner.
COPY INTO Samtidighet En transaktion som kör ett COPY INTO-kommando misslyckas om ett annat COPY INTO-kommando körs samtidigt för att skriva till samma tabell och bekräftar transaktionen först.
Strömningsskrivningar stöds inte Transaktionsskrivningar till strömmande tabeller stöds inte.
RLS- och CLM-tabeller stöds inte Tabeller med radfilter och kolumnmasker kan inte delta i transaktioner.
Tabell- och visningsgränser En transaktion kan läsa från eller skriva till upp till sammanlagt 100 tabeller och kan läsa från upp till 100 vyer. Varje tabell kan ha upp till 100 intermediära ändringar i en transaktion.
Tidsresor stöds inte Du kan inte använda tidsresor inom en transaktion.
Tidsgräns för inaktivitet Interaktiva transaktioner återställs efter 10 minuters inaktivitet. Transaktionen avslutas utan biverkningar, men du måste uttryckligen köra ÅTERSTÄLLNING för att rensa transaktionstillståndet om sessionen fortfarande är aktiv.
Högsta varaktighet Alla transaktioner återställs automatiskt efter den totala varaktigheten på 48 timmar. För interaktiva transaktioner avslutas transaktionen utan biverkningar, men du måste uttryckligen köra ROLLBACK för att rensa transaktionstillståndet om sessionen fortfarande är aktiv.
Krav för Delta Sharing av tabeller Deltadelningsleverantörer måste dela en tabell WITH HISTORY så att mottagarna kan köra transaktioner på den. Mottagare kan köra transaktioner med valfri typ av beräkning.
Beräkningsbegränsningar för Delta-delningsmottagare Azure Databricks-användare kan bara köra transaktioner på delade vyer, materialiserade vyer, strömmande tabeller och icke-Iceberg utländska tabeller. Mottagare i ett Azure Databricks-konto som är samma som deras leverantörs måste använda delad eller serverlös beräkning. Mottagare i ett annat konto måste använda serverlös beräkning.
Konflikt i Delta Sharing-källtabellen Deltadelningsmottagare kan inte referera till en delad vy och en delad tabell som refererar till samma källtabell i en enda transaktion.

Nästa steg

  • Last updated on