Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
I livelli di isolamento e il comportamento dei conflitti di scrittura determinano cosa succede quando operazioni concorrenti leggono e scrivono la stessa tabella Delta Lake su Azure Databricks.
Quando più job o utenti scrivono contemporaneamente sulla stessa tabella, alcune di queste scritture possono fallire con un'eccezione di conflitto. Usa le pagine di questa sezione quando hai bisogno:
- Risolvere o ridurre i fallimenti dovuti a scritture concorrenti, come
ConcurrentAppendException. Vedi Eccezioni di conflitto. - Decidi se una tabella ha bisogno di un isolamento più forte rispetto al valore predefinito. Vedere Livelli di isolamento (WriteSerializable e Serializable).
Delta Lake garantisce transazioni ACID tra letture e scritture:
- Scrittori: più scrittori in più cluster possono modificare simultaneamente una partizione di tabella. Gli scrittori visualizzano un'istantanea coerente della tabella e le operazioni di scrittura vengono eseguite in ordine seriale.
- Lettori: i lettori continuano a visualizzare una visualizzazione snapshot coerente della tabella con cui è stato avviato il processo di Azure Databricks, anche quando una tabella viene modificata durante un processo.
Vedere Che cosa sono le garanzie ACID in Azure Databricks?.
Annotazioni
Azure Databricks usa Delta Lake per tutte le tabelle per impostazione predefinita.
Argomenti relativi all'isolamento
| Argomento | Descrizione |
|---|---|
| Livelli di isolamento (WriteSerializable e Serializable) | Come i due livelli di isolamento influiscono sulle operazioni simultanee e su come configurarle. |
| Concorrenza a livello di riga | In che modo il rilevamento dei conflitti a livello di riga riduce i conflitti di scrittura per le operazioni simultanee sugli stessi file di dati. |
Per informazioni sull'isolamento delle transazioni, sul comportamento dello snapshot e sulla gestione dei conflitti, vedere Isolamento delle transazioni.
Conflitti di cambiamento dei metadati
I cambiamenti ai metadati potrebbero causare il fallimento di tutte le operazioni di scrittura concorrenti. Queste operazioni includono modifiche al protocollo di tabella, alle proprietà della tabella o allo schema dei dati.
Le letture di streaming hanno esito negativo quando rilevano un commit che modifica i metadati della tabella. Se si vuole che il flusso continui, è necessario riavviarlo. Per i metodi consigliati, vedere Considerazioni sulla produzione per Structured Streaming.
Esempi di query che modificano i metadati includono:
-- Set a table property
ALTER TABLE table_name SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')
-- Enable a feature using a table property and update the table protocol
ALTER TABLE table_name SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);
-- Drop a table feature
ALTER TABLE table_name DROP FEATURE deletionVectors;
-- Upgrade to UniForm
REORG TABLE table_name APPLY (UPGRADE UNIFORM(ICEBERG_COMPAT_VERSION=2));
-- Update the table schema
ALTER TABLE table_name ADD COLUMNS (col_name STRING);