Transaktioner

Viktigt!

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 har ACID-egenskaper: atomicitet, konsistens, isolering och varaktighet. 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:

Icke-interaktiv

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;

Interactive

BEGIN TRANSACTION;
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());
COMMIT;

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å OpenSharing-delade tillgångar 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 Villkorlig logik, validering och felsökning, JDBC, ODBC, PyODBC

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 (delselektera) 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
USE CATALOG och USE SCHEMA Ställ in den aktuella katalogen eller det aktuella schemat för satser i transaktionen
EXECUTE IMMEDIATE Kör en SQL-instruktion som du skapar dynamiskt vid körning
DESCRIBE TABLE Returnera metadata om en tabell, till exempel dess kolumner och egenskaper
SHOW COLUMNS Visa en lista över kolumnerna i en tabell
GET DIAGNOSTICS-instruktion Hämta diagnostikinformation, till exempel status för den aktiva transaktionen eller antalet rader som påverkats av den senaste satsen

Läskällor och skrivmottagare som stöds

Med transaktioner kan du läsa från Unity Catalog-tabeller (Delta Lake och Iceberg), strömmande tabeller, vyer och materialiserade vyer.

På grund av ACID-garantier stöds öppna tabellformat, till exempel Delta Lake och Iceberg, i transaktioner som både läskällor och skrivmottagare. Om du vill läsa från icke-transaktionskällor använder du tipset allow_nontransactional_read . Se Läsa från icke-transaktionskällor och Exempel: icke-transaktionell läsning.

Läsa från icke-transaktionskällor

Varning

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

Transaktioner gör att du kan läsa från källor som inte är transaktionella. Icke-transaktionskällor inkluderar externa tabeller med hjälp av Parquet-, Avro-, CSV- och JSON-filformat och federerade tabeller med JDBC. Om du vill läsa icke-transaktionskällor refererar du till källan efter namn och använder tipset allow_nontransactional_read .

I en transaktion kan du även fråga information_schema.

Du kan läsa filer direkt med den read_files tabellvärderade funktionen.

Sökvägsbaserad åtkomst stöds inte. Om du refererar till en fil direkt efter sökväg i stället, till exempel FROM parquet.`/path/to/data`, misslyckas transaktionen med ett PATH_BASED_ACCESS fel.

I följande kodexempel visas hur du använder tipset i en extern tabell med JSON:

BEGIN TRANSACTION;
-- Non-transactional source, hint required
INSERT INTO transactional_table
SELECT col1, col2
FROM external_json_table
WITH (allow_nontransactional_read = true);

COMMIT;

Exempel: icke-transaktionell läsoperation

Följande exempel visar en icke-transaktionell läsning från en extern tabell med Parquet. Det här exemplet kräver att du har en befintlig extern plats med läs- och skrivåtkomst.

Se Anslut till en extern plats för Azure Data Lake Storage Gen2 (ADLS Gen2).

Om du vill registrera Parquet-källan som en namngiven extern tabell kör du följande:

CREATE TABLE main.default.external_parquet_table
USING PARQUET
LOCATION 'abfss://my-container@my-storage-account.dfs.core.windows.net/path/to/data'; -- existing external location

Om du vill läsa både en icke-transaktionell Parquet-källa och en hanterad tabell med Delta Lake i en transaktion kör du följande:

BEGIN ATOMIC
-- Non-transactional source, hint required
INSERT INTO transactional_table
SELECT col1, col2
FROM external_parquet_table
WITH (allow_nontransactional_read = true);

-- Managed table source, no hint is required
INSERT INTO another_table
SELECT * FROM managed_delta_table;
END;

Transaktionsisolering

Transaktioner möjliggör upprepade läsningar i alla satser. 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.

I följande exempel fångar den första frågan till products i transaktionen en konsistent ögonblicksbild:

Icke-interaktiv

BEGIN ATOMIC
  SELECT * FROM products WHERE product_id = 1001;
  SELECT * FROM products WHERE product_id = 1001;
END;

Interactive

BEGIN TRANSACTION;
SELECT * FROM products WHERE product_id = 1001;
SELECT * FROM products WHERE product_id = 1001;
COMMIT;

Anta sedan att en annan användare samtidigt uppdaterar raden för product_id = 1001 innan den andra frågan börjar:

UPDATE products SET price = 29.99 WHERE product_id = 1001;

Eftersom ögonblicksbilden togs vid första åtkomsten returnerar den andra frågan products den ursprungliga raden, inte den uppdaterade.

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 bekräftar kontrollerar Azure Databricks huruvida andra transaktioner har ändrat samma data efter att din transaktion har påbörjats. 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 på Azure Databricks finns i Optimization recommendations on 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 möjliggör 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 . På så sätt kan du 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.
  • Används BEGIN ATOMIC för samtidighet på radnivå: Icke-interaktiva transaktioner (BEGIN ATOMIC ... END;) identifierar konflikter på radnivå, vilket minskar konflikter jämfört med den tabellnivåidentifiering som interaktiva transaktioner använder. Se Icke-interaktiva transaktioner.
  • Skapa logik för återförsök: En transaktion kan misslyckas när som helst på grund av en konflikt. Skapa logik för återförsök i ditt program och försök igen misslyckade transaktioner med nya data.
  • Starta varje interaktiv session med en återställning: Kör ROLLBACK i början av en interaktiv session för att rensa alla befintliga transaktionstillstånd.

Använda transaktioner från olika klienter

Transaktioner fungerar i olika klientgränssnitt:

Begränsningar

Följande begränsningar gäller för transaktioner:

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 Katalogincheckningar.
DDL-åtgärder stöds inte Kör DDL-åtgärder, till exempel CREATE TABLE, ALTER TABLEeller DROP TABLE, utanför transaktioner. De åtgärder som transaktioner stöder finns i Åtgärder som stöds.
Vissa metadataåtgärder stöds inte Vissa 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 som räknar upp objekt (till exempel SHOW TABLES och SHOW DATABASES) och SELECT frågor mot systemtabeller. Kör dessa 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.
Samtidighet på radnivå för MERGE Samtidighet på radnivå för MERGE åtgärder stöds inte i AWS GovCloud eller på kluster med en enda användare (dedikerade). På dessa plattformar använder MERGE åtgärder samtidighet på tabellnivå. Se konkurrens på radnivå.
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ärstamning Transaktioner genererar spårbarhet när varje läsning och skrivning sker. Linjehändelser kvarstår även om transaktionen ångras.
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 OpenSharing-delade tabeller OpenSharing-leverantö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 OpenSharing-mottagare Azure Databricks-mottagare kan bara köra transaktioner på delade vyer, materialiserade vyer, strömmande tabeller och icke-Iceberg externa tabeller. Mottagare i samma Azure Databricks-konto som deras leverantör måste använda delad eller serverlös beräkning. Mottagare i ett annat konto måste använda serverlös beräkning.
OpenSharing-källtabellkonflikt OpenSharing-mottagare kan inte referera till en delad vy och en delad tabell som refererar till samma källtabell i en enda transaktion.

Ytterligare resurser

  • Last updated on