Partilhar via

Concorrência ao nível das linhas

A concorrência ao nível das linhas reduz conflitos entre operações de escrita concorrentes ao detetar alterações ao nível da linha e ao resolver automaticamente conflitos que ocorrem quando escritas concorrentes atualizam ou eliminam diferentes linhas no mesmo ficheiro de dados.

Requisitos para concorrência ao nível de linha

As tabelas não suportam concorrência ao nível das linhas se tiverem partições definidas ou não tiverem vetores de eliminação ativados. A concorrência ao nível das linhas requer Databricks Runtime 14.2 ou superior.

Tabelas com partições não suportam concorrência ao nível das linhas, mas ainda assim podem evitar conflitos entre OPTIMIZE e todas as outras operações de escrita quando os vetores de eliminação estão ativados. Consulte Limitações para simultaneidade em nível de linha.

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

Observação

MERGE INTO O suporte para a simultaneidade a nível de linha requer o Photon no Databricks Runtime 14.2. No Databricks Runtime 14.3 LTS e superior, o Photon não é necessário.

Matriz de conflito com concorrência ao nível das linhas

A tabela seguinte mostra quais pares de operações de escrita podem entrar em conflito em cada nível de isolamento com a concorrência ao nível da linha ativada:

INSERT (1) UPDATE, EXCLUIR, MERGE INTO OPTIMIZE
INSERT Não pode entrar em conflito
UPDATE, EXCLUIR, MERGE INTO Não pode haver conflito em WriteSerializable. Pode entrar em conflito em Serializable ao modificar a mesma linha. Pode entrar em conflito ao modificar a mesma linha de dados.
OPTIMIZE Não pode entrar em conflito Pode entrar em conflito quando ZORDER BY é usado. Não pode haver conflito de outra forma. Pode entrar em 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 adição que não leem quaisquer dados da mesma tabela antes de serem confirmadas. INSERT operações que contêm subconsultas lendo a mesma tabela oferecem o mesmo nível de simultaneidade que MERGE.

Observação

  • As tabelas com colunas de identidade não suportam transações simultâneas. Veja Utilizar colunas de identidade no Delta Lake.
  • REORG As operações têm a mesma semântica de isolamento que OPTIMIZE quando reescrevem ficheiros de dados. Quando você usa REORG para aplicar uma atualização, os protocolos de tabela são alterados, o que entra em conflito com todas as operações em andamento.

Escrever conflitos sem simultaneidade em nível de linha

As tabelas não suportam simultaneidade em nível de linha se tiverem partições definidas ou não tiverem vetores de exclusão habilitados. O Databricks Runtime 14.2 ou superior é necessário para simultaneidade em nível de linha.

Matriz de conflito sem concorrência ao nível das linhas

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

INSERT (1) UPDATE, EXCLUIR, MERGE INTO OPTIMIZE
INSERT Não pode entrar em conflito
UPDATE, EXCLUIR, MERGE INTO Não pode haver conflito em WriteSerializable. Pode entrar em conflito em Serializable. Veja Evitar conflitos usando particionamento. Pode entrar em conflito em Serializable e WriteSerializable. Veja Evitar conflitos usando particionamento.
OPTIMIZE Não pode entrar em conflito Não pode entrar em conflito em tabelas com vetores de eliminação ativados, a menos que ZORDER BY seja utilizado. Pode entrar em conflito de outra forma. Não pode entrar em conflito em tabelas com vetores de eliminação ativados, a menos que ZORDER BY seja utilizado. Pode entrar em conflito de outra forma.

(1) Todas as INSERT operações nesta tabela descrevem operações de adição que não leem quaisquer dados da mesma tabela antes de serem confirmadas. INSERT operações que contêm subconsultas lendo a mesma tabela oferecem o mesmo nível de simultaneidade que MERGE.

Observação

  • As tabelas com colunas de identidade não suportam transações simultâneas. Veja Utilizar colunas de identidade no Delta Lake.
  • REORG As operações têm uma semântica de isolamento idêntica a OPTIMIZE quando se reescrevem ficheiros de dados. Quando você usa REORG para aplicar uma atualização, os protocolos de tabela são alterados, o que entra em conflito com todas as operações em andamento.

Limitações para simultaneidade em nível de linha

Limitações aplicam-se para concorrência a nível de linha. Para as operações seguintes, a resolução de conflitos segue a concorrência normal para conflitos de escrita. Consulte Escrever conflitos sem concorrência ao nível da linha.

Limitação Descrição
Orações condicionais complexas Condições em tipos de dados complexos (structs, arrays, maps), expressões não determinísticas, subconsultas e subconsultas correlacionadas
MERGE requisito de predicado No Databricks Runtime 14.2, MERGE os comandos devem usar um predicado explícito na tabela de destino para filtrar as linhas que correspondem à tabela de origem
Troca de desempenho A deteção de conflitos ao nível da linha pode aumentar o tempo total de execução. Com muitas transações simultâneas, o autor prioriza a latência em detrimento da resolução de conflitos

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

Evitar conflitos usando particionamento

Para todos os casos marcados como "podem entrar em conflito" nas matrizes de conflito, um conflito ocorre apenas se as duas operações afetarem o mesmo conjunto de ficheiros. Para tornar dois conjuntos de ficheiros disjuntos, particione a tabela pelas mesmas colunas usadas nas condições de operação.

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 ficheiros. Dividir a tabela por date evita o conflito.

Observação

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

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

Esta exceção é frequentemente lançada durante operações concorrentes, como 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ção:

// 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 conflitos

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

ConcurrentAppendException

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

Com o nível padrão de isolamento WriteSerializable, ficheiros adicionados por operações cegas INSERT (operações que adicionam dados sem ler qualquer dado) não entram em conflito com nenhuma operação. Se o nível de isolamento for serializável, os anexos ceguos podem entrar em conflito.

Importante

Os acréscimos cegos podem entrar em conflito no modo WriteSerializable se múltiplas operações simultâneas DELETE, UPDATE, ou MERGE poderem referenciar valores inseridos por acréscimos cegos. Para evitar isto:

  • Assegure que as operações concorrentes DELETE, UPDATE, ou MERGE não leem os dados anexados
  • Tenha no máximo uma operação DELETE, UPDATE, ou MERGE que possa ler os dados anexados

ConcurrentDeleteReadException

Esta exceção ocorre quando uma operação concorrente apaga um ficheiro que a sua operação leu. As causas comuns são DELETE, UPDATE, ou MERGE operações que reescrevem ficheiros.

ConcurrentDeleteDeleteException

Esta exceção ocorre quando uma operação concorrente apaga um ficheiro que a sua operação também elimina. Isto pode ser causado por duas operações de compactação simultâneas que reescrevem os mesmos ficheiros.

MetadataChangedException

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

Exceção de Transação Concorrente

Esta exceção ocorre se uma consulta de streaming usando a mesma localização de checkpoint for iniciada várias vezes simultaneamente e tentar escrever na tabela Delta ao mesmo tempo. Nunca execute em simultâneo duas consultas de streaming utilizando a mesma localização de checkpoint.

ProtocolChangedException

Esta exceção pode ocorrer quando:

  • A sua tabela Delta é atualizada para uma nova versão do protocolo (pode ser necessário atualizar o seu Databricks Runtime)
  • Vários escritores estão a criar ou substituir uma tabela ao mesmo tempo
  • Vários escritores estão a escrever para um diretório vazio simultaneamente.

Consulte Compatibilidade de recursos e protocolos do Delta Lake.

Comportamento de visualização de concorrência em nível de linha (legado)

Esta seção descreve comportamentos de visualização para simultaneidade em nível de linha no Databricks Runtime 14.1 e abaixo.

Versão do Databricks Runtime Comportamento
Databricks Runtime 13.3 LTS ou superior Tabelas com agrupamento líquido permitem automaticamente a concorrência ao nível das linhas
Databricks Runtime 14.0 e 14.1 Ative a concorrência ao nível da linha para tabelas com vetores de eliminação usando a configuração abaixo
Databricks Runtime versão 14.1 e inferiores A computação não-Photon suporta apenas operações de DELETE com concorrência ao nível da linha.

Para ativar a concorrência ao nível da linha no Databricks Runtime 14.0 e 14.1:

spark.databricks.delta.rowLevelConcurrencyPreview = true

A concorrência a nível de linha sempre requer vetores de eliminação.

Passos seguintes

  • Last updated on