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 zahrnují vlastnosti ACID: atomicity, konzistence, izolace a stálost. Viz Co jsou záruky ACID na 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:

Neinteraktivní

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;

Interaktivní

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;

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 se sdílenými aktivy OpenSharing použijte Databricks Runtime 18.1 nebo novější.

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, PyODBC

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 (dílčí výběr) 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í

Podporované zdroje čtení a jímky zápisu

Transakce umožňují číst data z tabulek Unity Catalog (Delta Lake a Iceberg), streamovacích tabulek, zobrazení a materializovaných zobrazení.

Vzhledem k zárukám ACID jsou otevřené formáty tabulek, jako je Delta Lake a Iceberg, podporovány v transakcích jako zdroje pro čtení i jímky zápisu. Pokud chcete číst z jiných než transakčních zdrojů, použijte nápovědu allow_nontransactional_read . Viz také Čtení z netransakčních zdrojů a Příklad: netransakční čtení.

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

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.

Transakce umožňují číst z jiných než transakčních zdrojů. Mezi netransakční zdroje patří externí tabulky využívající formáty souborů Parquet, Avro, CSV a JSON a federované tabulky používající JDBC. Chcete-li číst netransakční zdroje, odkažte na zdroj podle názvu a použijte nápovědu allow_nontransactional_read.

Přístup založený na cestě není podporován. Pokud místo toho odkazujete na soubor přímo podle cesty, například FROM parquet.`/path/to/data`, transakce selže s chybou PATH_BASED_ACCESS .

Následující příklad kódu ukazuje, jak použít nápovědu k externí tabulce pomocí 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;

Příklad: netransakční čtení

Následující příklad ukazuje netransakční čtení z externí tabulky pomocí formátu Parquet. Tento příklad vyžaduje, abyste měli existující externí umístění s přístupem pro čtení a zápis.

Viz Připojení k externímu umístění Azure Data Lake Storage Gen2 (ADLS Gen2).

Pokud chcete zdroj Parquet zaregistrovat jako pojmenovanou externí tabulku, spusťte následující příkaz:

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

Chcete-li v rámci transakce číst jak netransakční zdroj Parquet, tak spravovanou tabulku pomocí Delta Lake, spusťte následující příkaz:

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;

Izolace transakcí

Transakce umožňují opakovatelné čtení napříč všemi příkazy. Při přístupu k tabulce v transakci Azure Databricks při prvním přístupu zachytí konzistentní snímek této tabulky. 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.

V následujícím příkladu první dotaz na products v transakci zachytí konzistentní snímek:

Neinteraktivní

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

Interaktivní

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

Pak předpokládejme, že jiný uživatel souběžně aktualizuje řádek pro product_id = 1001 ještě předtím, než začne druhý dotaz:

UPDATE products SET price = 29.99 WHERE product_id = 1001;

Protože byl snímek zachycen při prvním přístupu, druhý dotaz na products vrátí původní řádek, nikoli aktualizovaný řádek.

Detekce konfliktů a souběžnost

Azure Databricks používá optimistickou kontrolu souběžnosti. Transakce probíhají bez uzamčení a konflikty se detekují v době potvrzení. Když provedete potvrzení, Azure Databricks kontroluje, zda jiné transakce upravily stejná data po zahájení vaší 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í. Informace o úrovních izolace a chování konfliktů zápisu pro tabulky Delta Lake v Azure Databricks najdete v tématu Optimization recommendations on 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. To umožňuje č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 vám umožňuje zrušit změny na základě validační logiky nebo obchodních pravidel anebo po neúspěšném provedení příkazu, pokud 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í

Pro transakce platí následující omezení:

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 potvrzení katalogu.
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í.
Původ Transakce generují provázanost při každém čtení a zápisu. Události rodokmenu se uchovávají i v případě, že se transakce vrátí zpět.
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 OpenSharing Zprostředkovatelé OpenSharing 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ích prostředků příjemců openSharingu Azure Databricks příjemci mohou provádět transakce pouze na 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.
Konflikt zdrojové tabulky OpenSharing Příjemci OpenSharing nemohou odkazovat na sdílené zobrazení a sdílenou tabulku, která odkazuje na stejnou zdrojovou tabulku v rámci jedné transakce.

Další zdroje informací

  • Last updated on