Pular para o conteúdo principal

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

As tabelas não suportam concorrência em nível de linha se tiverem partições definidas ou vetores de exclusão não estiverem habilitados. A concorrência em nível de linha requer Databricks Runtime 14.2 ou superior.

Tabelas com partições não suportam concorrência em nível de linha, mas ainda podem evitar conflitos entre OPTIMIZE e todas as outras operações de gravação quando os vetores de exclusão estão habilitados. Consulte Limitações para concorrência em nível de linha.

Para versões do Databricks Runtime anteriores à 14.2, consulte Comportamento de pré-visualização de concorrência em nível de linha (legado).

nota

MERGE INTO O suporte para concorrência em nível de linha requer o Photon no Databricks Runtime 14.2. No Databricks Runtime 14.3 LTS e versões superiores, Photon não é necessário.

Matriz de conflitos com concorrência 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 com a concorrência em nível de linha ativada:

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 operações INSERT nesta tabela descrevem operações de acréscimo que não leem nenhum dado da mesma tabela antes do commit. INSERT operações que contêm subconsultas que leem a mesma tabela suportam a mesma concorrência que MERGE.

nota
  • Tabelas com colunas de identidade não suportam 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.

Escreva conflitos sem concorrência em nível de linha.

As tabelas não suportam concorrência em nível de linha se tiverem partições definidas ou vetores de exclusão não estiverem habilitados. Para concorrência em nível de linha, é necessário Databricks Runtime 14.2 ou superior.

Matriz de conflitos sem concorrência em nível de linha

A tabela a seguir mostra quais pares de operações de escrita podem entrar em conflito em cada nível de isolamento:

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 operações INSERT nesta tabela descrevem operações de acréscimo que não leem nenhum dado da mesma tabela antes do commit. INSERT operações que contêm subconsultas que leem a mesma tabela suportam a mesma concorrência que MERGE.

nota
  • Tabelas com colunas de identidade não suportam 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.

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.

Exemplo: Evitando conflitos com filtros de partição explícitos

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

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 WriteSerializable default , os arquivos adicionados por operações cegas 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 Serializable, as adições cegas podem entrar em conflito.

importante

As adições cegas podem entrar em conflito no modo WriteSerializable se várias operações concorrentes DELETE, UPDATE ou MERGE puderem referenciar valores inseridos por adições cegas. Para evitar isso:

  • Certifique-se de que operações simultâneas 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 foi 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 de pré-visualização de concorrência em nível de linha (legado)

Esta seção descreve os comportamentos de pré-visualização para concorrência em nível de linha no Databricks Runtime 14.1 e versões anteriores.

Versão do Databricks Runtime

Comportamento

Databricks Runtime 13.3 LTS e versões superiores

Tabelas com clustering líquido habilitam automaticamente a concorrência em nível de linha.

Databricks Runtime 14.0 e 14.1

Habilite a concorrência em nível de linha para tabelas com vetores de exclusão usando a configuração abaixo.

Databricks Runtime 14.1 e abaixo

compute não-Photon suporta apenas concorrência em nível de linha para operações DELETE

Para habilitar a concorrência em nível de linha no Databricks Runtime 14.0 e 14.1:

ini
spark.databricks.delta.rowLevelConcurrencyPreview = true

A concorrência em nível de linha sempre requer vetores de exclusão.

Próximos passos