Controle de concorrência para tabelas Delta

Quando vários notebooks do Fabric, pipelines ou trabalhos do Spark gravam na mesma tabela Delta ao mesmo tempo, o Delta Lake usa o controle de concorrência otimista (OCC) para manter a tabela consistente. Cada transação lê um snapshot, grava novos arquivos e valida se nenhum commit conflitante tenha ocorrido nesse intervalo. Se um conflito for detectado, a transação falhará com uma exceção em vez de corromper dados.

Este artigo aborda padrões práticos para gerenciar operações de gravação simultâneas no Fabric. Para obter uma especificação completa do protocolo OCC, consulte o controle de simultaneidade do Delta Lake (documentação de software livre).

Níveis de isolamento

Todas as tabelas Delta usam o nível de isolamento serializável . Serializável é o nível mais estrito e o único com suporte. Ele garante que o resultado de transações simultâneas seja idêntico a alguma ordem de execução sequencial.

O Delta Lake também usa um nível de SnapshotIsolation interno para operações que não alteram dados lógicos (como OPTIMIZE). SnapshotIsolation ignora a verificação de acréscimo simultâneo, permitindo que a compactação prossiga sem entrar em conflito com inserções simultâneas. Você não configura o SnapshotIsolation diretamente – o Delta Lake aplica-o automaticamente quando apropriado.

Com Serializable o isolamento, um acréscimo cego simultâneo (INSERT INTO) pode entrar em conflito com um MERGE ou UPDATE que lê a mesma partição.

Quais operações entram em conflito

Nem todas as gravações simultâneas entram em conflito. O fator chave é se duas operações tocam nos mesmos arquivos subjacentes.

Isolar gravadores com particionamento

A maneira mais comum de executar DML simultâneo na mesma tabela sem conflitos é particionar a tabela pela coluna que separa seus gravadores e, em seguida, incluir essa coluna em cada condição de operação. Quando cada gravador tem como destino uma partição diferente, as operações tocam conjuntos de arquivos desarticulados e não entram em conflito.

Um cenário típico: vários pipelines cada um processa dados para uma unidade de negócios ou locatário diferente. Particione por essa dimensão e fixe o MERGE de cada pipeline na sua partição.

-- Each pipeline targets its own partition, so concurrent runs don't conflict
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

# Pin the merge to a single partition to avoid conflicts with other pipelines
spark.sql("""
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

// Pin the merge to a single partition to avoid conflicts with other pipelines
spark.sql("""
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

Para obter mais detalhes sobre estratégias de particionamento, consulte Particionamento para tabelas Delta.

Nova tentativa de commit integrada

O Delta Lake tenta automaticamente uma confirmação quando detecta que outra transação foi confirmada primeiro. Em cada repetição, ele lê a confirmação vencedora, executa o verificador de conflitos e, se não houver nenhum conflito lógico, reattempta a confirmação na próxima versão disponível. Esse processo é repetido de forma transparente sem nenhuma ação do código.

Um conflito lógico (por exemplo, duas operações reescrevendo o mesmo arquivo) não pode ser resolvido automaticamente. A repetição gera uma das exceções listadas em exceções de conflito comuns. No entanto, muitos conflitos transitórios de versão — como dois acréscimos sem verificação prévia disputando a mesma posição de versão — são resolvidos automaticamente e nunca chegam à sua aplicação.

Exceções de conflito comuns

Quando um conflito é detectado, o Delta Lake gera uma exceção específica. Entender qual exceção você vê ajuda a identificar a causa raiz.

Estratégias comuns para evitar conflitos de gravação

Habilitar a compactação automática

A compactação automática é executada de forma síncrona como parte das operações de gravação. A compactação síncrona impede que tarefas de compactação agendadas separadamente coincidam com operações de modificação de dados, evitando, assim, exceções de gravadores concorrentes.

Agendar manutenção fora das janelas de gravação

OPTIMIZE e VACUUM pode entrar em conflito com operações simultâneas de modificação de dados. No Fabric, agende tarefas de notebook ou atividades de pipeline para compactação de tabelas e VACUUM durante janelas de baixa atividade, por exemplo, após a conclusão da ingestão noturna, em vez de durante ela.

Usar padrões de acréscimo + mesclagem

Para ingestão com alta simultaneidade, grave os dados brutos com gravações somente de acréscimo em uma tabela de staging (sem possibilidade de conflitos) e, em seguida, execute um único trabalho MERGE para reconciliar os dados na tabela de destino. O padrão serializa a operação propensa a conflitos, mantendo a ingestão totalmente paralela.

Adicionar lógica de repetição para conflitos lógicos

A nova tentativa de commit integrada lida automaticamente com conflitos transitórios de versão, mas conflitos lógicos — quando duas operações realmente se sobrepõem — resultam em uma exceção. Como o Delta Lake nunca produz gravações parciais, uma transação com falha pode ser repetida com segurança no nível da aplicação. Para pipelines em que conflitos lógicos ocasionais são esperados, encapsule a gravação na lógica de repetição:

from delta.exceptions import ConcurrentAppendException
import time

# Retry with backoff on transient concurrent write conflicts
max_retries = 3
for attempt in range(max_retries):
    try:
        spark.sql("MERGE INTO target USING source ON ...")
        break
    except ConcurrentAppendException:
        if attempt < max_retries - 1:
            time.sleep(2 ** attempt)
        else:
            raise

Escolha a estratégia de layout certa

O clustering e o particionamento líquidos resolvem problemas diferentes. O clustering líquido otimiza o layout do arquivo para o desempenho de leitura. O particionamento cria limites físicos que impedem conflitos entre operações de gravação simultâneas. Se sua carga de trabalho precisar de ambos, particione pela coluna de isolamento do gravador e use Z-Order em cada partição para desempenho de leitura.

Conteúdo relacionado

• Particionamento
• Agrupamento líquido
• Mesclagem Low-Shuffle
• Compactação de tabela
• Ordem Z
• Manutenção de tabela delta
• Interoperabilidade do Delta Lake
• Controle de simultaneidade do Delta Lake (documentação de software livre)