Sdílet prostřednictvím

Transakce

Důležité

Transakce, které se zapisují do spravovaných tabulek Delta katalogu Unity, jsou ve verzi Public Preview.

Transakce, které zapisují do katalogu Unity spravované tabulky Iceberg, jsou ve verzi Private Preview. Pokud se chcete připojit k této verzi Preview, odešlete formulář pro registraci spravovaných tabulek Iceberg ve verzi Preview.

Transakce umožňují koordinovat operace napříč několika příkazy a tabulkami SQL. Všechny změny buď společně uspějí nebo se společně vrátí, což zajišťuje konzistenci dat napříč vašimi operacemi a tabulkami. Transakce poskytují záruky ACID: atomicita, konzistence, izolace a stálost. Podívejte se, co jsou záruky ACID v Azure Databricks? Transakce se dají použít s uloženými procedurami a skriptováním SQL k sestavení důležitých úloh skladových zásob.

Následující příklad ukazuje transakci:

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;

Všechny tři příkazy se společně potvrdí. Pokud některý příkaz selže, všechny změny se vrátí zpět a Databricks ukončí transakci bez vedlejších účinků.

Praktické cvičení s transakcemi najdete v kurzu: Koordinace transakcí napříč tabulkami.

Požadavky

Spuštění transakcí, které zahrnují více příkazů nebo více tabulek:

  • Všechny tabulky, do kterých se zapisuje, musí splňovat:
  • Použití podporovaných výpočetních prostředků:
    • V případě neinteraktivních transakcí použijte libovolný SQL Warehouse, bezserverové výpočetní prostředky nebo cluster se spuštěným Modulem Databricks Runtime 18.0 a novějším.
    • Pro interaktivní transakce použijte libovolný SQL Warehouse.
    • Pro transakce u sdílených zdrojů systému Delta Sharing použijte Databricks Runtime 18.1 a vyšší.

Režimy transakcí

Azure Databricks podporuje dva režimy transakcí:

Mode Syntaxe Závazek Vrácení zpět Nejvhodnější pro
Neinteraktivní ATOMIC složený příkaz Automatické při úspěchu Automatické při chybě Pevné sekvence, naplánované úlohy
Interaktivní ZAHÁJIT TRANSAKCI; POTVRZENÍ; Příručka Příručka Podmíněná logika, ověřování a ladění, JDBC, ODBC, PyDBC

Podrobné syntaxe, příklady a vzory použití pro oba režimy naleznete v tématu Režimy transakcí.

Podporované operace

V rámci transakcí můžete použít následující operace:

Operace Description
SELECT Dotazování na data a ověření výsledků
VALUES klauzule Generování testovacích dat nebo konstantních hodnot
INSERT (včetně všech variant) Přidání nových řádků
UPDATE Úprava existujících řádků
COPY INTO Načtení dat ze souboru do tabulky Delta
DELETE FROM Odeberte řádky
MERGE INTO Vzorce upsertu kombinující vložení, aktualizaci a odstranění

Čtení zdrojů v transakcích

Transakce můžou číst z tabulek katalogu Unity (Delta a Iceberg), streamovaných tabulek, zobrazení a materializovaných zobrazení. Pokud chcete číst z jiných než transakčních zdrojů, použijte nápovědu allow_nontransactional_reads .

Čtení z ne-transakčních zdrojů

Pokud chcete číst z ne-transakčních zdrojů, jako jsou soubory Parquet, soubory Avro a federované tabulky pomocí JDBC, použijte radu allow_nontransactional_reads, jak je ukázáno v následujícím příkladu:

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;

Výstraha

Netransakční čtení nelze opakovat. Souběžné změny zdrojových dat během transakce můžou vést k nekonzistentním čtením.

Izolace transakcí

Transakce poskytují opakované čtení napříč všemi výrazy. Když přistupujete k tabulce v transakci, Azure Databricks zachytí konzistentní snímek této tabulky při prvním přístupu. Všechna následná čtení této tabulky používají tento snímek, takže čtení zůstávají konzistentní i v případě, že ostatní uživatelé současně upravují stejné tabulky.

Příklad:

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;

Detekce konfliktů a souběžnost

Azure Databricks používá optimistické řízení souběžnosti. Transakce probíhají bez uzamčení a konflikty se detekují v době potvrzení. Když potvrdíte, Azure Databricks zkontroluje, jestli jiné transakce změnily stejná data po zahájení transakce. Pokud existují konflikty, vaše transakce selže. U neinteraktivních transakcí probíhá vrácení zpět také automaticky. U interaktivních transakcí je nutné explicitně spustit ROLLBACK , aby se před zahájením nové transakce vymaže stav transakce.

Neinteraktivní transakce podporují souběžnost na úrovni řádků. Dvě transakce mohou upravovat různé řádky ve stejném datovém souboru, aniž by došlo ke konfliktu, když je v cílových tabulkách povolena souběžnost na úrovni řádků .

Interaktivní transakce podporují souběžnost na úrovni tabulky.

Konfliktní scénáře

Scénář Description
Konflikty zápisů Dvě transakce aktualizují nebo odstraní ty samé řádky.
Konflikty mezi čtením a zápisem Další transakce upravila řádky, které vaše transakce přečetla. Platí pouze pro serializovatelnou izolaci.
Konflikty při fantomovém čtení Další transakce přidala nové řádky odpovídající predikátu, který vaše transakce četla. Platí jak pro writeSerializable, tak serializovatelnou izolaci.
Konflikty metadat Jiná transakce změnila schéma tabulky nebo vlastnosti.

Další podrobnosti o úrovních izolace a řešení konfliktů pro transakce naleznete v tématu Režimy transakcí. Pro informace o úrovních izolace a chování konfliktů při zápisu pro tabulky Delta Lake v Azure Databricks, viz Doporučení optimalizace pro Azure Databricks.

Jak se transakce zobrazují v protokolu Delta

Každá úspěšná transakce se zobrazí jako jedna položka v tabulkovém protokolu Delta bez ohledu na to, kolik jednotlivých příkazů se spustilo v rámci transakce. Poskytuje čistý záznam auditu a zjednodušuje operace vrácení zpět.

Jednotlivé operace v rámci transakce jsou k dispozici jako metadata JSON v položce protokolu Delta pro transakci.

Zpracování chyb a zpětné převinutí

Následující tabulka popisuje, jak dochází ke zpětnému vrácení chyb u obou typů transakcí:

Scénář Chování pro neinteraktivní transakce Chování interaktivních transakcí
Selhání výroků Jakýkoli příkaz, který vyvolá chybu, způsobí okamžité automatické vrácení zpět. Pokud je relace stále aktivní, musíte explicitně spustit ROLLBACK, abyste odstranili provedené změny.
Neúspěšná logika ověření nebo pravidla obchodního jednání Použijte SIGNAL k vyvolání výjimky a spuštění automatického vrácení zpět. Spuštěním příkazu ROLLBACK zahoďte změny.
Odpojení relace Transakce se automaticky vrátí zpět. Transakce se automaticky vrátí zpět.
Přerušení zápasu Automaticky se vrátí zpět po celkové době trvání 48 hodin. Automaticky se vrátí zpět po 10 minutách nečinnosti nebo celkové době trvání 48 hodin (viz Omezení). Transakce je ukončena bez vedlejších účinků, ale musíte explicitně spustit ROLLBACK vymazat stav transakce, pokud relace je stále aktivní.

Pro interaktivní transakce můžete explicitně vrátit zpět pomocí příkazu ROLLBACK . To je užitečné, když chcete zahodit změny na základě logiky ověření nebo obchodních pravidel nebo po selhání příkazu, když relace zůstane aktivní.

Osvědčené postupy

Pokud chcete omezit konflikty a optimalizovat výkon transakcí, postupujte podle těchto postupů.

Vyhněte se konfliktům

  • Udržujte transakce krátké: Dlouhotrvající transakce zvyšují pravděpodobnost konfliktů a uchovávají prostředky déle.
  • Ověřte brzy: Zkontrolujte předběžné podmínky na začátku transakce, aby transakce rychle selhala v případě chyby.
  • Databricks doporučuje neinteraktivní transakce pro většinu případů použití: Neinteraktivní transakce používají souběžnost na úrovni řádků. Viz Neinteraktivní transakce.
  • Opakování při konfliktech: Pokud dojde ke konfliktům, zkuste transakci znovu s čerstvými daty.

Použijte transakce z různých klientů

Transakce fungují napříč různými klientskými rozhraními:

Omezení

Následující omezení platí pro transakce, které zahrnují více tabulek:

Omezení Description
Konflikty interaktivních transakcí Interaktivní transakce (BEGIN TRANSACTION; ... COMMIT;) používají konzervativnější detekci konfliktů než neinteraktivní transakce a mohou kolidovat na úrovni tabulky s výjimkou INSERT operací, které nečtou z cílové tabulky. Pokud je důležité zjišťování konfliktů na úrovni řádků, používejte neinteraktivní transakce (atomic složený příkaz). Viz Neinteraktivní transakce.
Stanovení cílů Zapisovat můžete pouze do tabulek Delta nebo Iceberg spravovaných službou Unity Catalog s povolenou příslušnou funkcí tabulky. Viz commity spravované katalogem.
Pouze operace DML Transakce podporují SELECT, INSERT, UPDATE, DELETE, COPY INTO a MERGE. Spusťte operace DDL, například CREATE TABLE, ALTER TABLEnebo DROP TABLE, mimo transakce.
Nepodporovaná operace s metadaty Operace metadat nefungují uvnitř transakcí bez ohledu na protokol. To zahrnuje volání metadat založená na RPC pomocí Thriftu (jako jsou metody JDBC DatabaseMetaData a funkce katalogu ODBC), příkazy založené na SQL (SHOW TABLES, SHOW DATABASES, DESCRIBE TABLE) a SELECT dotazy proti information_schema tabulkám nebo systémovým tabulkám. Spouštění operací metadat mimo transakce
COPY INTO Souběžnost Transakce, která spouští příkaz, COPY INTO selže, pokud se jiný COPY INTO příkaz spustí souběžně pro zápis do stejné tabulky a potvrzení jako první.
Streamované zápisy nejsou podporovány. Transakční zápisy do streamovaných tabulek se nepodporují.
Tabulky RLS a CLM nejsou podporovány. Tabulky s filtry řádků a maskami sloupců se nemohou účastnit transakcí.
Omezení tabulek a zobrazení Transakce může číst nebo zapisovat až do 100 tabulek dohromady a může číst až ze 100 zobrazení. Každá tabulka může mít v rámci transakce až 100 mezilehlých commitů.
Časová cesta není podporována. V rámci transakce nelze použít cestování časem.
Časový limit nečinnosti Interaktivní transakce se vrátí zpět po 10 minutách nečinnosti. Transakce je ukončena bez vedlejších účinků, ale musíte explicitně spustit ROLLBACK vymazat stav transakce, pokud relace je stále aktivní.
Maximální doba trvání Všechny transakce se automaticky vrátí zpět po celkové době trvání 48 hodin. U interaktivních transakcí je transakce ukončena bez vedlejších účinků, ale pokud je relace stále aktivní, musíte explicitně spustit rollback vymazat stav transakce.
Požadavek na sdílení sdílených tabulek Delta Poskytovatelé rozdílového sdílení musí sdílet tabulku WITH HISTORY , aby příjemci mohli spouštět transakce. Příjemci mohou spouštět transakce pomocí libovolného typu výpočetních prostředků.
Omezení výpočetní kapacity příjemce Delta Sharing Příjemci Azure Databricks můžou spouštět transakce pouze ve sdílených zobrazeních, materializovaných zobrazeních, streamovaných tabulkách a cizích tabulkách mimo Iceberg. Příjemci ve stejném účtu Azure Databricks jako poskytovatel musí používat sdílené výpočetní prostředky nebo výpočetní prostředky bez serveru. Příjemci v jiném účtu musí používat bezserverové výpočetní prostředky.
Delta Sharing zdrojová tabulka konflikt Příjemci Delta Sharingu nemohou v rámci jedné transakce souběžně odkazovat na sdílené zobrazení a sdílenou tabulku, pokud oba odkazují na stejnou zdrojovou tabulku.

Další kroky

  • Last updated on