Controlo de concorrência para tabelas Delta

Quando vários notebooks do Fabric, pipelines ou trabalhos do Spark escrevem na mesma tabela Delta ao mesmo tempo, o Delta Lake utiliza controlo de concorrência otimista (OCC) para manter a tabela consistente. Cada transação lê uma captura instantânea, escreve novos ficheiros e depois verifica se não ocorreu nenhum commit em conflito entretanto. Se for detetado um conflito, a transação falha com uma exceção em vez de corromper os dados.

Este artigo aborda padrões práticos para gerir escritas simultâneas no Fabric. Para uma especificação completa do protocolo OCC, veja controlo de concorrência Delta Lake (documentação open-source).

Níveis de isolamento

Todas as tabelas Delta utilizam o nível de isolamento Serializable. Serializable é o nível mais rigoroso e o único suportado. Garante que o resultado das transações concorrentes é idêntico a uma ordem de execução sequencial.

O Delta Lake também utiliza um nível interno de SnapshotIsolation para operações que não alteram dados a nível lógico (como OPTIMIZE). O SnapshotIsolation ignora a verificação de anexação concorrente, permitindo que a compactação prossiga sem conflito com inserções concorrentes. Não se configura o SnapshotIsolation diretamente — o Delta Lake aplica-o automaticamente quando apropriado.

Com isolamento Serializable, uma anexação cega concorrente (INSERT INTO) pode entrar em conflito com um MERGE ou UPDATE que lê a mesma partição.

Que operações entram em conflito

Nem todas as operações de escrita concorrentes entram em conflito. O fator chave é se duas operações tocam nos mesmos ficheiros subjacentes.

Isolar escritores com particionamento

A forma mais comum de executar DML concorrente contra a mesma tabela sem conflitos é particionar a tabela pela coluna que separa os seus escritores, e depois incluir essa coluna em todas as condições de operação. Quando cada escritor tem como alvo uma partição diferente, as operações tocam conjuntos de ficheiros desjuntos e não entram em conflito.

Um cenário típico: vários pipelines processam, cada um, dados para diferentes unidades de negócio ou tenants. Particione por essa dimensão e afixe o MERGE de cada canalização à 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 mais detalhes sobre estratégias de particionamento, veja Particionamento para tabelas Delta.

Retentativa de confirmação integrada

O Delta Lake repete automaticamente a tentativa de efetuar um commit quando deteta que outra transação efetuou primeiro o commit. Em cada nova tentativa, lê o commit vencedor, executa o verificador de conflito e — se não existir conflito lógico — tenta novamente o commit na próxima versão disponível. Este processo repete-se de forma transparente, sem qualquer ação do seu código.

Um conflito lógico (por exemplo, duas operações a reescrever o mesmo ficheiro) não pode ser resolvido automaticamente. A nova tentativa gera uma das exceções listadas em Exceções comuns de conflito. No entanto, muitas colisões transitórias de versões, como dois acrescentos sem verificação prévia a disputar a mesma posição de versão, são resolvidas automaticamente e nem sequer chegam à sua aplicação.

Exceções de conflito comum

Quando é detetado um conflito, Delta Lake levanta uma exceção específica. Compreender qual a exceção que se vê ajuda a identificar a causa raiz.

Estratégias comuns para evitar conflitos de escrita

Ativar a compactação automática

A autocompactação corre de forma síncrona como parte das operações de escrita. A compactação síncrona impede que tarefas de compactação agendadas separadamente coincidam com operações de modificação de dados e, consequentemente, causem exceções de escrita simultânea.

Agendar manutenção fora das janelas de escrita

OPTIMIZE e VACUUM podem entrar em conflito com operações simultâneas de modificação de dados. No Fabric, agende trabalhos de notebook ou atividades do 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 a mesma.

Use padrões de anexação e fusão

Para a ingestão com elevada concorrência, grave os dados brutos com operações de escrita só de acréscimo numa tabela de preparação (sem possibilidade de conflitos) e, em seguida, execute uma única tarefa MERGE para reconciliar os dados na tabela de destino. O padrão serializa a operação suscetível a conflitos, mantendo a ingestão totalmente paralela.

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

A nova tentativa de commit integrada trata automaticamente conflitos transitórios de versão, mas os conflitos lógicos — quando duas operações se sobrepõem efetivamente — geram uma exceção. Como o Delta Lake nunca produz escritas parciais, uma transação falhada é segura para tentar novamente ao nível da aplicação. Para pipelines em que são esperados conflitos lógicos ocasionais, envolva a operação de escrita numa lógica de nova tentativa:

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 esquema adequada

O agrupamento de líquidos e o particionamento resolvem diferentes problemas. O agrupamento de líquidos otimiza o layout dos ficheiros para o desempenho de leitura. A partição cria limites físicos que evitam conflitos concorrentes entre escritores. Se a sua carga de trabalho precisar de ambos, particione pela coluna de isolamento de escrita e utilize Z-Order dentro de cada partição para melhorar o desempenho de leitura.

Conteúdo relacionado

• Partitioning
• Agrupamento de líquidos
• Fusão de Baixa Reorganização
• Compactação de tabelas
• Z-Order
• Manutenção da tabela Delta
• Interoperabilidade do Delta Lake
• Controlo de concorrência Delta Lake (documentação open-source)