Che cosa sono le garanzie ACID in Azure Databricks?

Azure Databricks usa Delta Lake per impostazione predefinita per tutte le operazioni di lettura e scrittura e si basa sulle garanzie ACID fornite dal protocollo Delta Lake open source. ACID è l'acronimo di atomicità, coerenza, isolamento e durabilità.

• Atomicità significa che tutte le transazioni hanno esito positivo o negativo completamente.
• Le garanzie di coerenza riguardano il modo in cui uno stato specifico dei dati viene osservato dalle operazioni simultanee.
• L'isolamento si riferisce al modo in cui le operazioni simultanee sono potenzialmente in conflitto tra loro.
• La durabilità significa che le modifiche di cui è stato eseguito il commit sono permanenti.

Sebbene molte tecnologie di elaborazione dei dati e di warehousing descrivono la presenza di transazioni ACID, garanzie specifiche variano in base al sistema e le transazioni in Azure Databricks potrebbero differire dagli altri sistemi usati.

Nota

Questa pagina descrive le garanzie per le tabelle supportate da Delta Lake. Altri formati di dati e sistemi integrati potrebbero non fornire garanzie transazionali per letture e scritture.

Tutte le scritture di Azure Databricks nell'archiviazione oggetti cloud usano commit transazionali, che creano file di metadati che iniziano con _started_<id> e _committed_<id> insieme ai file di dati. Non è necessario interagire con questi file, perché Azure Databricks pulisce regolarmente i file di metadati di commit non aggiornati.

Come vengono definiti gli ambiti delle transazioni in Azure Databricks?

Azure Databricks gestisce le transazioni a livello di tabella. Le transazioni si applicano sempre a una tabella alla volta. Per la gestione delle transazioni simultanee, Azure Databricks usa il controllo della concorrenza ottimistica. Ciò significa che non esistono blocchi per la lettura o la scrittura su una tabella e il deadlock non è una possibilità.

Per impostazione predefinita, Azure Databricks fornisce l'isolamento dello snapshot sulle letture e l'isolamento serializzabile in scrittura nelle scritture. L'isolamento serializzabile in scrittura offre garanzie più avanzate rispetto all'isolamento dello snapshot, ma applica tale isolamento più forte solo per le scritture.

Le operazioni di lettura che fanno riferimento a più tabelle restituiscono la versione corrente di ogni tabella al momento dell'accesso, ma non interrompono transazioni simultanee che potrebbero modificare le tabelle a cui si fa riferimento.

Azure Databricks non dispone BEGIN/END di costrutti che consentono di raggruppare più operazioni come singola transazione. Le applicazioni che modificano più tabelle eseguono il commit delle transazioni in ogni tabella in modo seriale. È possibile combinare inserimenti, aggiornamenti ed eliminazioni in una tabella in una singola transazione di scrittura usando MERGE INTO.

In che modo Azure Databricks implementa l'atomicità?

Il log delle transazioni controlla l'atomicità del commit. Durante una transazione, i file di dati vengono scritti nella directory di file che esegue il backup della tabella. Al termine della transazione, viene eseguito il commit di una nuova voce nel log delle transazioni che include i percorsi di tutti i file scritti durante la transazione. Ogni commit incrementa la versione della tabella e rende visibili i nuovi file di dati per le operazioni di lettura. Lo stato corrente della tabella comprende tutti i file di dati contrassegnati come validi nei log delle transazioni.

I file di dati non vengono rilevati a meno che il log delle transazioni non registri una nuova versione. Se una transazione non riesce dopo la scrittura di file di dati in una tabella, questi file di dati non danneggiano lo stato della tabella, ma i file non diventeranno parte della tabella. L'operazione VACUUM elimina tutti i file di dati non registrati in una directory di tabella, inclusi i file rimanenti di cui non è stato eseguito il commit dalle transazioni non riuscite.

In che modo Azure Databricks implementa la durabilità?

Azure Databricks usa l'archiviazione di oggetti cloud per archiviare tutti i file di dati e i log delle transazioni. L'archiviazione di oggetti cloud ha disponibilità elevata e durabilità. Poiché le transazioni hanno esito positivo o negativo completamente e il log delle transazioni si trova insieme ai file di dati nell'archiviazione di oggetti cloud, le tabelle in Azure Databricks ereditano le garanzie di durabilità dell'archiviazione di oggetti cloud in cui sono archiviate.

In che modo Azure Databricks implementa la coerenza?

Delta Lake usa il controllo di concorrenza ottimistica per fornire garanzie transazionali tra scritture. In questo meccanismo le scritture operano in tre fasi:

1. Lettura: legge (se necessario) la versione più recente disponibile della tabella per identificare quali file devono essere modificati (ovvero riscritti).
   • Le scritture che sono di sola accodamento non leggono lo stato della tabella corrente prima della scrittura. La convalida dello schema sfrutta i metadati del log delle transazioni.
2. Scrittura: scrive i file di dati nella directory usata per definire la tabella.
3. Convalidare ed eseguire il commit:
   • Controlla se le modifiche proposte sono in conflitto con eventuali altre modifiche che potrebbero essere state eseguite contemporaneamente dopo la lettura dello snapshot.
   • Se non sono presenti conflitti, tutte le modifiche in fasi vengono eseguite come nuovo snapshot con versione e l'operazione di scrittura ha esito positivo.
   • In caso di conflitti, l'operazione di scrittura non riesce con un'eccezione di modifica simultanea. Questo errore impedisce il danneggiamento dei dati.

La concorrenza ottimistica presuppone che la maggior parte delle transazioni simultanee sui dati non sia in conflitto tra loro, ma possono verificarsi conflitti. Vedere Livelli di isolamento e conflitti di scrittura in Azure Databricks.

In che modo Azure Databricks implementa l'isolamento?

Azure Databricks usa l'isolamento serializzabile in scrittura per impostazione predefinita per tutte le scritture e gli aggiornamenti delle tabelle. L'isolamento dello snapshot viene usato per tutte le letture di tabella.

La serializzabilità di scrittura e il controllo della concorrenza ottimistica interagiscono per garantire una velocità effettiva elevata per le scritture. Lo stato valido corrente di una tabella è sempre disponibile e una scrittura può essere avviata in una tabella in qualsiasi momento. Le letture simultanee sono limitate solo dalla velocità effettiva del metastore e delle risorse cloud.

Vedere Livelli di isolamento e conflitti di scrittura in Azure Databricks.

Delta Lake supporta le transazioni che coinvolgono più tabelle?

Delta Lake non supporta transazioni a più tabelle. Delta Lake supporta le transazioni a livello di tabella .

Le relazioni chiave primaria e di chiave esterna in Azure Databricks sono informative e non applicate. Vedere Dichiarare le relazioni tra chiave primaria e chiave esterna.

Cosa significa che Delta Lake supporta le scritture multi-cluster?

Delta Lake impedisce il danneggiamento dei dati quando più cluster scrivono nella stessa tabella contemporaneamente. Alcune operazioni di scrittura possono essere in conflitto durante l'esecuzione simultanea, ma non danneggiano la tabella. Vedere Livelli di isolamento e conflitti di scrittura in Azure Databricks.

È possibile modificare una tabella Delta da diverse aree di lavoro?

Sì, è possibile modificare simultaneamente la stessa tabella Delta da aree di lavoro diverse. Inoltre, se un processo sta scrivendo da un'area di lavoro, i lettori in altre aree di lavoro vedranno una visualizzazione coerente.