Condividi tramite

Concorrenza a livello di riga

La concorrenza a livello di riga riduce i conflitti tra le operazioni di scrittura simultanee rilevando le modifiche a livello di riga e risolvendo automaticamente i conflitti che si verificano quando si scrive simultaneamente l'aggiornamento o si eliminano righe diverse nello stesso file di dati.

Requisiti per la concorrenza a livello di riga

Le tabelle non supportano la concorrenza a livello di riga se hanno partizioni definite o non dispongono di vettori di eliminazione abilitati. La concorrenza a livello di riga richiede Databricks Runtime 14.2 e versioni successive.

Le tabelle con partizioni non supportano la concorrenza a livello di riga, ma possono comunque evitare conflitti tra OPTIMIZE e tutte le altre operazioni di scrittura quando i vettori di eliminazione sono abilitati. Vedere Limitazioni per la concorrenza a livello di riga.

Per le versioni di Databricks Runtime precedenti alla 14.2, vedere Comportamento di anteprima della concorrenza a livello di riga (legacy).

Annotazioni

MERGE INTO il supporto per la concorrenza a livello di riga richiede Photon in Databricks Runtime 14.2. In Databricks Runtime 14.3 LTS e versioni successive, Photon non è obbligatorio.

Matrice di conflitti con concorrenza a livello di riga

La tabella seguente illustra le coppie di operazioni di scrittura in conflitto in ogni livello di isolamento con la concorrenza a livello di riga abilitata:

INSERT (1) UPDATE, ELIMINA, MERGE INTO OPTIMIZE
INSERT Non può esserci conflitto
UPDATE, ELIMINA, MERGE INTO Impossibile avere conflitti in WriteSerializable. Può essere in conflitto in Serializable durante la modifica della stessa riga. Può entrare in conflitto durante la modifica della stessa riga.
OPTIMIZE Non può esserci conflitto Può essere in conflitto quando ZORDER BY viene usato. Non può essere in conflitto in caso contrario. Può essere in conflitto quando ZORDER BY viene usato. Non può essere in conflitto in caso contrario.

(1) Tutte le INSERT operazioni in questa tabella descrivono le operazioni di accodamento che non leggono dati dalla stessa tabella prima di eseguire il commit. INSERT le operazioni che contengono sottoquery che leggono la stessa tabella sostengono la stessa concorrenza di MERGE.

Annotazioni

  • Le tabelle con colonne Identity non supportano transazioni simultanee. Vedi Usa colonne identità in Delta Lake.
  • REORG le operazioni hanno una semantica di isolamento identica a quando OPTIMIZE si riscriveno i file di dati. Quando si usa REORG per applicare un aggiornamento, i protocolli di tabella cambiano, che sono in conflitto con tutte le operazioni in corso.

Scrivi conflitti senza concorrenza simultanea a livello di riga

Le tabelle non supportano la concorrenza a livello di riga se hanno partizioni definite o non dispongono di vettori di eliminazione abilitati. Databricks Runtime 14.2 o versione successiva è necessario per la concorrenza a livello di riga.

Matrice di conflitti senza concorrenza a livello di riga

La tabella seguente illustra le coppie di operazioni di scrittura in conflitto in ogni livello di isolamento:

INSERT (1) UPDATE, ELIMINA, MERGE INTO OPTIMIZE
INSERT Non può esserci conflitto
UPDATE, ELIMINA, MERGE INTO Impossibile avere conflitti in WriteSerializable. Può entrare in conflitto in Serializable. Vedere Evitare conflitti con il partizionamento. Può esserci un conflitto tra Serializable e WriteSerializable. Vedere Evitare conflitti con il partizionamento.
OPTIMIZE Non può esserci conflitto Impossibile avere conflitti nelle tabelle in cui i vettori di eliminazione siano abilitati, a meno che non ZORDER BY venga usato. In caso contrario, può essere in conflitto. Non è possibile creare conflitti nelle tabelle con vettori di eliminazione abilitati, a meno che non si usi ZORDER BY. In caso contrario, può essere in conflitto.

(1) Tutte le INSERT operazioni in questa tabella descrivono le operazioni di accodamento che non leggono dati dalla stessa tabella prima di eseguire il commit. INSERT le operazioni che contengono sottoquery che leggono la stessa tabella sostengono la stessa concorrenza di MERGE.

Annotazioni

  • Le tabelle con colonne Identity non supportano transazioni simultanee. Vedi Usa colonne identità in Delta Lake.
  • REORG le operazioni hanno una semantica di isolamento identica a quando OPTIMIZE si riscriveno i file di dati. Quando si usa REORG per applicare un aggiornamento, i protocolli di tabella cambiano, che sono in conflitto con tutte le operazioni in corso.

Limitazioni per la concorrenza a livello di riga

Le limitazioni si applicano per la concorrenza a livello di riga. Per le operazioni seguenti, la risoluzione dei conflitti segue la normale concorrenza per i conflitti di scrittura. Consultare Conflitti di scrittura senza concorrenza a livello di riga.

Limitation Descrizione
Clausole condizionali complesse Condizioni sui tipi di dati complessi (strutture, matrici, map), espressioni non deterministiche, sottoquery e sottoquery correlate
MERGE requisito del predicato In Databricks Runtime 14.2 MERGE i comandi devono usare un predicato esplicito nella tabella di destinazione per filtrare le righe corrispondenti alla tabella di origine
Compromesso sulle prestazioni Il rilevamento dei conflitti a livello di riga può aumentare il tempo di esecuzione totale. Con molte transazioni simultanee, il processo di scrittura assegna la priorità alla latenza rispetto alla risoluzione dei conflitti.

Si applicano anche tutte le limitazioni per i vettori di eliminazione. Vedere Limitazioni.

Evitare conflitti usando il partizionamento

Per tutti i casi contrassegnati come "possono essere in conflitto" nelle matrici di conflitti, si verifica un conflitto solo se le due operazioni influiscono sullo stesso set di file. Per rendere disgiunti due set di file, partizionare la tabella in base alle stesse colonne utilizzate nelle condizioni operative.

Esempio:

I comandi UPDATE table WHERE date > '2010-01-01' ... e DELETE table WHERE date < '2010-01-01' confliggono se la tabella non è partizionata per data, perché entrambi possono tentare di modificare gli stessi file. Il partizionamento della tabella mediante date evita il conflitto.

Annotazioni

Il partizionamento di una tabella in base a una colonna con cardinalità elevata può causare problemi di prestazioni a causa del numero elevato di sottodirectory.

Esempio: evitare conflitti con filtri di partizione espliciti

Questa eccezione viene spesso generata durante operazioni simultanee DELETE, UPDATEo MERGE che potrebbero leggere la stessa partizione anche quando si aggiornano partizioni diverse. Rendere esplicita la separazione nella condizione dell'operazione:

// Problem: Condition can scan the entire table
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

// Solution: Add explicit partition filters
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country AND t.date = '" + date + "' AND t.country = '" + country + "'")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

Eccezioni di conflitto

Quando si verifica un conflitto di transazioni, si osserva una delle eccezioni seguenti:

ConcurrentAppendException

Questa eccezione si verifica quando un'operazione simultanea aggiunge file nella stessa partizione (o in qualsiasi punto di una tabella non partizionata) letti dall'operazione. Le aggiunte di file possono essere causate da INSERT, DELETE, UPDATE o MERGE operazioni.

Con il livello di isolamento WriteSerializable predefinito, i file aggiunti da operazioni non vedenti INSERT (operazioni che aggiungono dati senza leggere dati) non sono in conflitto con alcuna operazione. Se il livello di isolamento è Serializable, le aggiunte non controllate potrebbero entrare in conflitto.

Importante

Gli accodamenti ciechi possono essere in conflitto in modalità "WriteSerializable" se più operazioni simultanee DELETE, UPDATE, o MERGE possono riferirsi a valori inseriti da accodamenti ciechi. Per evitare questo problema:

  • Verificare che le operazioni simultanee DELETE, UPDATEo MERGE non leggano i dati accodati
  • Disporre al massimo di un'operazione DELETE, UPDATEo MERGE in grado di leggere i dati accodati

ConcurrentDeleteReadException

Questa eccezione si verifica quando un'operazione simultanea elimina un file letto dall'operazione. Le cause comuni sono DELETE, UPDATE o MERGE, operazioni che riscrivono i file.

ConcurrentDeleteDeleteException

Questa eccezione si verifica quando un'operazione simultanea elimina un file eliminato anche dall'operazione. Ciò potrebbe essere causato da due operazioni di compattazione simultanee che riscrivono gli stessi file.

MetadataChangedException

Questa eccezione si verifica quando una transazione simultanea aggiorna i metadati di una tabella Delta. Le cause comuni sono ALTER TABLE operazioni o scritture che aggiornano lo schema della tabella.

EccezioneDiTransazioneConcorrenziale

Questa eccezione si verifica se una query di streaming che usa la stessa posizione del checkpoint viene avviata più volte contemporaneamente e tenta di scrivere nella tabella Delta contemporaneamente. Non eseguire mai due query di streaming con la stessa posizione del checkpoint contemporaneamente.

ProtocolChangedException

Questa eccezione può verificarsi quando:

  • La tabella Delta viene aggiornata a una nuova versione del protocollo (potrebbe essere necessario aggiornare Databricks Runtime)
  • Più writer stanno creando o sostituendo una tabella contemporaneamente
  • Più scrittori stanno scrivendo in un percorso vuoto contemporaneamente

Vedere Compatibilità e protocolli delle funzionalità delta Lake.

Comportamento di anteprima della concorrenza a livello di riga (legacy)

Questa sezione descrive i comportamenti di anteprima per la concorrenza a livello di riga in Databricks Runtime 14.1 e versioni successive.

Versione di Databricks Runtime Comportamento
Databricks Runtime 13.3 LTS e versioni successive Le tabelle con clustering liquido abilitano automaticamente la concorrenza a livello di riga
Databricks Runtime 14.0 e 14.1 Abilitare la concorrenza a livello di riga per le tabelle con vettori di eliminazione usando la configurazione seguente
Databricks Runtime 14.1 e versioni precedenti Il calcolo non Photon supporta solo la concorrenza a livello di riga per operazioni DELETE

Per abilitare la concorrenza a livello di riga in Databricks Runtime 14.0 e 14.1:

spark.databricks.delta.rowLevelConcurrencyPreview = true

La concorrenza a livello di riga richiede sempre vettori di eliminazione.

Passaggi successivi

  • Last updated on