Pular para o conteúdo principal
Última atualização em

Concorrência em nível de linha

A concorrência em nível de linha reduz conflitos entre operações de escrita concorrentes, detectando alterações em nível de linha e resolvendo automaticamente conflitos que ocorrem quando escritas concorrentes atualizam ou excluem linhas diferentes no mesmo arquivo de dados.

Requisitos para concorrência em nível de linha​

A simultaneidade em nível de linha é ativada automaticamente quando todos os requisitos a seguir são atendidos:

  • Utilizando Databricks Runtime 14.3 LTS e acima.
  • A tabela de origem não utiliza partições.
  • A tabela de origem tem vetores de exclusão ativados. Consulte Vetores de exclusão no Databricks.

Tabelas particionadas não permitem simultaneidade em nível de linha. No entanto, quando os vetores de exclusão estão ativados, tabelas particionadas ainda podem evitar conflitos entre OPTIMIZE e operações de gravação. Consulte Limitações para simultaneidade em nível de linha.

Para versões do Databricks Runtime anteriores a 14.3 LTS, consulte Comportamento Herdado de Simultaneidade em Nível de Linha.

Matriz de conflitos com concorrência em nível de linha​

Para tabelas de origem com simultaneidade em nível de linha, a tabela a seguir mostra quais pares de operações de gravação podem entrar em conflito em cada nível de isolamento:

Operação

INSERIR (1)

UPDATE, EXCLUIR, MERGE INTO

OPTIMIZE

INSERT

Não pode haver conflito

UPDATE, EXCLUIR, MERGE INTO

Não pode haver conflito em WriteSerializable. Pode haver conflito em objetos Serializable ao modificar a mesma linha.

Pode haver conflito ao modificar a mesma linha.

OPTIMIZE

Não pode haver conflito

Pode haver conflito quando ZORDER BY é usado. Não pode haver conflito de outra forma.

Pode haver conflito quando ZORDER BY é usado. Não pode haver conflito de outra forma.

(1) Todas as INSERT operações nesta tabela descrevem operações de anexação que não contêm subconsultas que leem dados da mesma tabela. INSERT operações que contêm subconsultas que leem da mesma tabela suportam a mesma concorrência que MERGE.

nota
  • Tabelas com colunas de identidade não oferecem suporte para transações concorrentes. Consulte Usar colunas de identidade no Delta Lake.
  • REORG As operações têm semântica de isolamento idêntica a OPTIMIZE ao reescrever arquivos de dados. Quando você usa REORG para aplicar uma atualização, os protocolos da tabela mudam, o que entra em conflito com todas as operações em andamento.

Conflitos de gravação sem simultaneidade em nível de linha​

Para tabelas de origem sem simultaneidade em nível de linha, a tabela a seguir mostra quais pares de operações de gravação podem entrar em conflito em cada nível de isolamento:

Operação

INSERIR (1)

UPDATE, EXCLUIR, MERGE INTO

OPTIMIZE

INSERT

Não pode haver conflito

UPDATE, EXCLUIR, MERGE INTO

Não pode haver conflito em WriteSerializable. Pode haver conflito em Serializable. Consulte Evitar conflitos usando particionamento.

Pode haver conflito entre Serializable e WriteSerializable. Consulte Evitar conflitos usando particionamento.

OPTIMIZE

Não pode haver conflito

Não pode haver conflito em tabelas com vetores de exclusão ativados, a menos que ZORDER BY seja usado. Caso contrário, pode haver conflito.

Não pode haver conflito em tabelas com vetores de exclusão ativados, a menos que ZORDER BY seja usado. Caso contrário, pode haver conflito.

(1) Todas as INSERT operações nesta tabela descrevem operações de anexação que não contêm subconsultas que leem dados da mesma tabela. INSERT operações que contêm subconsultas que leem da mesma tabela suportam a mesma concorrência que MERGE.

nota
  • Tabelas com colunas de identidade não oferecem suporte para transações concorrentes. Consulte Usar colunas de identidade no Delta Lake.
  • REORG operações têm semântica de isolamento idêntica a OPTIMIZE ao reescrever arquivos de dados. Quando você usa REORG para aplicar uma atualização, os protocolos da tabela mudam e entram em conflito com todas as operações em andamento.

Limitações para concorrência em nível de linha​

Existem limitações para a concorrência em nível de linha. Para as operações a seguir, a resolução de conflitos segue a concorrência normal para conflitos de escrita. Consulte Conflitos de escrita sem concorrência em nível de linha.

Limitação

Descrição

Cláusulas condicionais complexas

Condições em tipos de dados complexos (estruturas, arrays, mapas), expressões não determinísticas, subconsultas e subconsultas correlacionadas.

MERGE requisito de predicado

No Databricks Runtime 14.2, o comando MERGE deve usar um predicado explícito na tabela de destino para filtrar as linhas que correspondem à tabela de origem.

Compensação de desempenho

A detecção de conflitos em nível de linha pode aumentar o tempo total de execução. Com muitas transações simultâneas, o escritor prioriza a latência em detrimento da resolução de conflitos.

Todas as limitações para vetores de deleção também se aplicam. Consulte as limitações.

Evite conflitos usando particionamento.​

Em todos os casos marcados como "pode haver conflito" nas matrizes de conflito, um conflito ocorre somente se as duas operações afetarem o mesmo conjunto de arquivos. Para tornar dois conjuntos de arquivos disjuntos, particione a tabela pelas mesmas colunas usadas nas condições das operações.

Exemplo:

Os comandos UPDATE table WHERE date > '2010-01-01' ... e DELETE table WHERE date < '2010-01-01' entram em conflito se a tabela não estiver particionada por data, porque ambos podem tentar modificar os mesmos arquivos. Particionar a tabela por date evita o conflito.

nota

Particionar uma tabela por uma coluna com alta cardinalidade pode causar problemas de desempenho devido ao grande número de subdiretórios.

Evite conflitos com filtros de partição explícitos​

Esta exceção é frequentemente gerada durante operações concorrentes DELETE, UPDATE ou MERGE que podem ler a mesma partição, mesmo ao atualizar partições diferentes. Tornar a separação explícita na condição da operação:

Scala
// 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()

Exceções de conflito​

Quando ocorre um conflito de transação, você observa uma das seguintes exceções:

Exceção de Aplicação Concorrente​

Essa exceção ocorre quando uma operação concorrente adiciona arquivos na mesma partição (ou em qualquer lugar em uma tabela não particionada) que sua operação está lendo. As adições de arquivos podem ser causadas por operações INSERT, DELETE, UPDATE ou MERGE .

Com o nível de isolamento default WriteSerializable, arquivos adicionados por INSERT operações que anexam dados sem ler nenhum dado não entram em conflito com nenhuma operação. Se o nível de isolamento for serializável, quaisquer anexações podem entrar em conflito.

importante

INSERT Operações podem entrar em conflito no modo WriteSerializable se múltiplas operações concorrentes DELETE, UPDATE ou MERGE puderem referenciar valores anexados pela operação INSERT. Para evitar isso:

  • Garanta que as operações concorrentes DELETE, UPDATE ou MERGE não leiam os dados anexados.
  • Tenha no máximo uma DELETE, UPDATE ou MERGE operações que podem ler os dados anexados.

Exceção Concorrente de Exclusão de Leitura​

Esta exceção ocorre quando uma operação concorrente exclui um arquivo que sua operação leu. As causas comuns são operações DELETE, UPDATE ou MERGE que reescrevem arquivos.

Exceção Concorrente de Exclusão​

Esta exceção ocorre quando uma operação concorrente exclui um arquivo que sua operação também exclui. Isso pode ser causado por duas operações de compactação simultâneas que reescrevem os mesmos arquivos.

Exceção MetadataChangedException​

Essa exceção ocorre quando uma transação concorrente atualiza os metadados de uma tabela Delta . As causas comuns são operações ALTER TABLE ou gravações que atualizam o esquema da tabela.

Exceção de transação simultânea​

Essa exceção ocorre se uma consulta de transmissão que utiliza o mesmo local de ponto de verificação for iniciada várias vezes simultaneamente e tentar gravar na tabela Delta ao mesmo tempo. Nunca execute duas consultas de transmissão com a mesma localização de checkpoint simultaneamente.

Exceção ProtocolChangedException​

Essa exceção pode ocorrer quando:

  • Sua tabela Delta Lake é atualizada para uma nova versão de protocolo (talvez seja necessário atualizar seu Databricks Runtime)
  • Vários escritores estão criando ou substituindo uma tabela ao mesmo tempo.
  • Vários escritores estão escrevendo em um caminho vazio ao mesmo tempo.

Consulte a compatibilidade e os protocolos de recursosDelta Lake.

Comportamento legado de simultaneidade em nível de linha​

No Databricks Runtime 13.3 LTS, a simultaneidade em nível de linha usa o comportamento herdado:

  • Requer vetores de exclusão. Consulte Vetores de exclusão no Databricks.
  • Tabelas com clustering líquido habilitam automaticamente a simultaneidade em nível de linha.

Próximos passos​

Nesta página