Condividi tramite

Transactions

Importante

Le transazioni che scrivono nelle tabelle Delta gestite del catalogo Unity sono in anteprima pubblica.

Le transazioni che scrivono nelle tabelle Iceberg gestite dal catalogo Unity sono in anteprima privata. Per partecipare a questa anteprima, inviare il modulo di iscrizione per l'anteprima delle tabelle Iceberg gestite.

Le transazioni consentono di coordinare le operazioni tra più istruzioni e tabelle SQL. Tutte le modifiche riescono insieme o eseguono il rollback insieme, garantendo la consistenza dei dati tra le operazioni e le tabelle. Le transazioni offrono garanzie ACID: atomicità, coerenza, isolamento e durabilità. Vedere Che cosa sono le garanzie ACID in Azure Databricks?. Le transazioni possono essere usate con stored procedure e script SQL per creare carichi di lavoro di warehousing cruciali.

L'esempio seguente mostra una transazione:

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;

Tutte le tre le dichiarazioni vengono consolidate insieme. Se una qualsiasi istruzione fallisce, tutte le modifiche vengono revocate e Databricks termina la transazione senza conseguenze.

Per una pratica pratica con le transazioni, vedere Esercitazione: Coordinare le transazioni tra tabelle.

Requisiti

Per eseguire transazioni attraverso più dichiarazioni o più tabelle:

  • Tutte le tabelle scritte in devono:
  • Usare il calcolo supportato:
    • Per le transazioni non interattive, usare qualsiasi SQL Warehouse, calcolo serverless o cluster che esegue Databricks Runtime 18.0 e versioni successive.
    • Per le transazioni interattive, usare qualsiasi sql warehouse.
    • Per le transazioni sugli asset condivisi di Delta Sharing, utilizzare Databricks Runtime 18.1 e versioni successive.

Modalità di transazione

Azure Databricks supporta due modalità di transazione:

Modalità Sintassi Commettere Ripristino Ideale per
Non interattivo Istruzione composta ATOMIC Automatico in caso di esito positivo Automatico in caso di errore Sequenze fisse, processi pianificati
Interattivo BEGIN TRANSACTION; COMMIT; Manuale Manuale Logica condizionale, convalida e debug, JDBC, ODBC, PyDBC

Per una sintassi dettagliata, esempi e modelli di utilizzo per entrambe le modalità, vedere Modalità di transazione.

Operazioni supportate

È possibile usare le operazioni seguenti all'interno delle transazioni:

Operation Descrizione
SELECT Eseguire query sui dati e convalidare i risultati
VALUES clausola Generare dati di test o valori costanti
INSERT (incluse tutte le varianti) Aggiungere nuove righe
UPDATE Modificare le righe esistenti
COPY INTO Caricare dati da un file in una tabella Delta
DELETE FROM Rimuovi righe
MERGE INTO Modelli di upsert che combinano inserimento, aggiornamento ed eliminazione

Leggere le fonti delle transazioni

Le transazioni possono leggere da tabelle del catalogo Unity (Delta e Iceberg), tabelle di streaming, viste e viste materializzate. Per leggere da origini non transazionali, utilizzare il suggerimento allow_nontransactional_reads .

Lettura da origini non transazionali

Per leggere da origini non transazionali, ad esempio file Parquet, file Avro e tabelle federate tramite JDBC, usare l'hint allow_nontransactional_reads , come illustrato nell'esempio seguente:

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;

Avviso

Le operazioni di lettura non transazionali non sono ripetibili. Le modifiche simultanee ai dati di origine durante la transazione potrebbero causare letture incoerenti.

Isolamento delle transazioni

Le transazioni consentono letture ripetibili per tutte le istruzioni. Quando si accede a una tabella in una transazione, Azure Databricks acquisisce uno snapshot coerente di tale tabella al primo accesso. Tutte le letture successive di tale tabella usano questo snapshot, pertanto le letture rimangono coerenti anche se gli altri utenti modificano contemporaneamente le stesse tabelle.

Esempio:

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;

Rilevamento dei conflitti e concorrenza

Azure Databricks usa il controllo della concorrenza ottimistica. Le transazioni procedono senza blocchi e i conflitti vengono rilevati al momento del commit. Quando si esegue il commit, Azure Databricks controlla se altre transazioni hanno modificato gli stessi dati dopo l'avvio della transazione. Se esistono conflitti, la transazione ha esito negativo. Per le transazioni non interattive, viene eseguito automaticamente anche il rollback. Per le transazioni interattive, è necessario eseguire ROLLBACK in modo esplicito per cancellare lo stato della transazione prima di iniziare una nuova transazione.

Le transazioni non interattive supportano la concorrenza a livello di riga. Due transazioni possono modificare righe diverse nello stesso file di dati senza conflitti quando la concorrenza a livello di riga è abilitata nelle tabelle di destinazione.

Le transazioni interattive supportano la concorrenza a livello di tabella.

Scenari di conflitto

Scenario Descrizione
Conflitti di scrittura/scrittura Due transazioni aggiornano o eliminano le stesse righe.
Conflitti di lettura-scrittura Un'altra transazione ha modificato le righe lette dalla tua transazione. Si applica esclusivamente all'isolamento serializzabile.
Conflitti di lettura fantasma Un'altra transazione ha aggiunto nuove righe corrispondenti a un predicato letto dalla transazione. Si applica sia per l'isolamento WriteSerializable che per l'isolamento Serializable.
Conflitti di metadati Un'altra transazione ha modificato lo schema o le proprietà della tabella.

Per altre informazioni sui livelli di isolamento e sulla risoluzione dei conflitti per le transazioni, vedere Modalità di transazione. Per informazioni sui livelli di isolamento e sul comportamento di scrittura dei conflitti per le tabelle Delta Lake in Azure Databricks, vedere Raccomandazioni sull'ottimizzazione in Azure Databricks.

Modalità di visualizzazione delle transazioni nel log Delta

Ogni transazione riuscita viene visualizzata come una singola voce nel log Delta della tabella, indipendentemente dal numero di singole istruzioni eseguite all'interno della transazione. In questo modo viene fornito un audit trail pulito e vengono semplificate le operazioni di rollback.

Le singole operazioni all'interno di una transazione sono disponibili come metadati JSON nella voce di log Delta per la transazione.

Gestione degli errori e rollback

Nella tabella seguente viene descritto il modo in cui si verificano i rollback degli errori per entrambi i tipi di transazione:

Scenario Comportamento per le transazioni non interattive Comportamento per le transazioni interattive
Errore di dichiarazione Qualsiasi istruzione che genera un errore comporta un immediato rollback automatico. È necessario eseguire in modo esplicito ROLLBACK per annullare le modifiche se la sessione è ancora attiva.
Logica di convalida non riuscita o regole business Usare SIGNAL per generare un'eccezione e attivare il rollback automatico. Eseguire ROLLBACK per annullare le modifiche.
Disconnessione dalla sessione La transazione viene automaticamente annullata. Il rollback della transazione avviene automaticamente.
Interruzione temporanea Esegue automaticamente il rollback dopo 48 ore di durata totale. Esegue automaticamente il rollback dopo 10 minuti di inattività o una durata totale di 48 ore (vedere Limitazioni). La transazione viene terminata senza effetti collaterali, ma è necessario eseguire in modo esplicito ROLLBACK per cancellare lo stato della transazione se la sessione è ancora attiva.

Per le transazioni interattive, è possibile eseguire il rollback in modo esplicito usando l'istruzione ROLLBACK . Ciò è utile quando si desidera eliminare le modifiche in base alla logica di convalida o alle regole business o dopo un errore di istruzione quando la sessione rimane attiva.

Procedure consigliate

Seguire queste procedure per ridurre i conflitti e ottimizzare le prestazioni delle transazioni.

Evitare conflitti

  • Mantenere le transazioni brevi: le transazioni con esecuzione prolungata aumentano la probabilità di conflitti e mantengono più a lungo le risorse.
  • Validare in anticipo: controllare le precondizioni all'inizio di una transazione per individuare rapidamente gli errori.
  • Databricks consiglia transazioni non interattive per la maggior parte dei casi d'uso: le transazioni non interattive usano la concorrenza a livello di riga. Vedere Transazioni non interattive.
  • Nuovi tentativi in caso di conflitti: quando si verificano conflitti, riprovare la transazione con dati aggiornati.

Usare transazioni da client diversi

Le transazioni funzionano tra diverse interfacce client:

Limitazioni

Le limitazioni seguenti si applicano alle transazioni che si estendono su più tabelle:

Limitation Descrizione
Conflitti di transazioni interattive Transazioni interattive (BEGIN TRANSACTION; ... COMMIT;) usano un rilevamento dei conflitti più conservativo rispetto alle transazioni non interattive e possono trovarsi in conflitto a livello di tabella, ad eccezione delle operazioni INSERT che non leggono dalla tabella di destinazione. Utilizzare transazioni non interattive (istruzione composta ATOMIC) quando è importante il rilevamento dei conflitti a livello di riga. Vedere Transazioni non interattive.
Scrivere destinazioni È possibile scrivere solo nelle tabelle Delta gestite da Unity Catalog o Iceberg con la catalogManaged funzionalità tabella abilitata. Vedere Commit gestiti dal catalogo.
Solo operazioni DML Le transazioni supportano SELECT, INSERTUPDATE, DELETE, COPY INTO, e MERGE. Eseguire operazioni DDL, ad esempio CREATE TABLE, ALTER TABLEo DROP TABLE, all'esterno delle transazioni.
Operazioni sui metadati non supportate Le operazioni sui metadati non funzionano all'interno di transazioni indipendentemente dal protocollo. Sono incluse le chiamate di metadati basate su RPC Thrift (ad esempio i metodi JDBC DatabaseMetaData e le funzioni del catalogo ODBC), i comandi basati su SQL (SHOW TABLES, SHOW DATABASES, DESCRIBE TABLE) e SELECT le query su information_schema tabelle o tabelle di sistema. Eseguire operazioni sui metadati all'esterno delle transazioni.
COPY INTO Concorrenza Una transazione che esegue un COPY INTO comando ha esito negativo se un altro COPY INTO comando viene eseguito simultaneamente per scrivere nella stessa tabella ed esegue prima il commit.
Scritture di streaming non supportate Le scritture transazionali nelle tabelle di streaming non sono supportate.
Tabelle CLM e sicurezza a livello di riga non sono supportate Le tabelle con filtri di riga e maschere di colonna non possono partecipare alle transazioni.
Limiti di tabella e visualizzazione Una transazione può leggere o scrivere fino a 100 tabelle combinate e può leggere da un massimo di 100 visualizzazioni. Ogni tabella può avere fino a 100 commit intermedi all'interno di una transazione.
Viaggio nel tempo non supportato Non è possibile utilizzare il viaggio temporale all'interno di una transazione.
Timeout di inattività Le transazioni interattive vengono annullate dopo 10 minuti di inattività. La transazione viene terminata senza effetti collaterali, ma è necessario eseguire in modo esplicito ROLLBACK per cancellare lo stato della transazione se la sessione è ancora attiva.
Durata massima Tutte le transazioni eseguono automaticamente il rollback dopo una durata totale di 48 ore. Per le transazioni interattive, la transazione viene terminata senza effetti collaterali, ma è necessario eseguire in modo esplicito ROLLBACK per cancellare lo stato della transazione se la sessione è ancora attiva.
Requisito di Delta Sharing per le tabelle condivise I provider di Delta Sharing devono condividere una tabella WITH HISTORY per consentire ai destinatari di eseguirvi transazioni. I destinatari possono eseguire transazioni usando qualsiasi tipo di calcolo.
Restrizioni del calcolo dei destinatari per la condivisione Delta I destinatari di Azure Databricks possono eseguire transazioni solo in visualizzazioni condivise, viste materializzate, tabelle di streaming e tabelle esterne non Iceberg. I destinatari nello stesso account di Azure Databricks del provider devono usare il calcolo condiviso o senza server. I destinatari in un account diverso devono usare il calcolo serverless.
Conflitto nella tabella di origine di Delta Sharing I destinatari di Delta Sharing non possono fare riferimento a una vista condivisa e a una tabella condivisa che fanno riferimento alla stessa tabella di origine all'interno di una singola transazione.

Passaggi successivi

  • Last updated on