Compartilhar via

Transactions

Importante

As transações que gravam em tabelas Delta gerenciadas pelo Catálogo Unity estão em Visualização Pública.

As transações que gravam em tabelas Iceberg gerenciadas pelo Unity Catalog estão em Versão Prévia Privada. Para ingressar nesta prévia, envie o formulário de inscrição para prévia das tabelas Iceberg gerenciadas.

As transações permitem coordenar operações em várias instruções SQL e tabelas. Todas as alterações são bem-sucedidas juntas ou revertidas juntas, garantindo a consistência dos dados em suas operações e tabelas. As transações fornecem garantias ACID (acrônimo de atomicidade, consistência, isolamento e durabilidade). Confira O que são garantias ACID no Azure Databricks?. As transações podem ser usadas com procedimentos armazenados e scripts SQL para criar cargas de trabalho de armazenagem críticas.

O exemplo a seguir mostra uma transação:

BEGIN ATOMIC
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
  INSERT INTO audit_log VALUES (1, 2, 100, current_timestamp());
END;

Todas as três instruções são aplicadas simultaneamente. Se qualquer instrução falhar, todas as alterações serão revertidas e o Databricks encerrará a transação sem efeitos colaterais.

Para prática prática com transações, consulte Tutorial: Coordenar transações entre tabelas.

Requisitos

Para executar transações que abrangem várias instruções ou várias tabelas:

  • Todas as tabelas gravadas devem:
  • Utilize recursos computacionais com suporte
    • Para transações não interativas, use qualquer Armazenamento de Dados SQL, Computação Sem Servidor ou cluster executando o Databricks Runtime 18.0 ou superior.
    • Para transações interativas, use qualquer SQL Warehouse.
    • Para transações em ativos compartilhados do Delta Sharing, use o Databricks Runtime 18.1 ou versões posteriores.

Modos de transação

O Azure Databricks dá suporte a dois modos de transação:

Modo Sintaxe Confirmar Reversão Mais adequado para
Não interativo Instrução composta ATOMIC Automático após o sucesso Automático em caso de erro Sequências fixas, trabalhos agendados
Interativo BEGIN TRANSACTION; COMMIT; Manual Manual Lógica condicional, validação e depuração, JDBC, ODBC, PyDBC

Para obter sintaxe detalhada, exemplos e padrões de uso para ambos os modos, consulte os modos de transação.

Operações com suporte

Você pode usar as seguintes operações em transações:

Operação Descrição
SELECT Consultar dados e validar resultados
Cláusula VALUES Gerar dados de teste ou valores constantes
INSERT (incluindo todas as variantes) Adicionar novas linhas
UPDATE Modificar linhas existentes
COPY INTO Carregar dados de um arquivo em uma tabela Delta
DELETE FROM Remover linhas
MERGE INTO Padrões de upsert combinando inserir, atualizar e excluir

Ler fontes em transações

As transações podem ser lidas a partir de tabelas do Catálogo do Unity (Delta e Iceberg), tabelas de streaming, exibições e exibições materializadas. Para ler de fontes não transacionais, use a allow_nontransactional_reads indicação.

Ler de fontes não transacionais

Para ler de fontes não transacionais, como arquivos Parquet, arquivos Avro e tabelas federadas usando JDBC, use a allow_nontransactional_reads dica, conforme mostrado no exemplo a seguir:

BEGIN TRANSACTION;

-- Read from a non-transactional Parquet source
INSERT INTO transactional_table
SELECT col1, col2
FROM parquet.`/path/to/data`
WITH (allow_nontransactional_reads = true);

-- Read from a managed Delta table (no hint needed)
INSERT INTO another_table
SELECT * FROM managed_delta_table;

COMMIT;

Aviso

Leituras não transacionais não são repetíveis. Alterações simultâneas nos dados de origem durante a transação podem resultar em leituras inconsistentes.

Isolamento de transações

As transações fornecem leituras repetíveis em todas as instruções. Quando você acessa uma tabela em uma transação, o Azure Databricks captura um instantâneo consistente dessa tabela no primeiro acesso. Todas as leituras subsequentes dessa tabela usam esse instantâneo, de modo que suas leituras permaneçam consistentes mesmo que outros usuários modifiquem simultaneamente essas mesmas tabelas.

Exemplo:

BEGIN TRANSACTION;

-- First access to products table captures snapshot
SELECT * FROM products WHERE product_id = 1001;

-- Another user updates product 1001

-- Still reads the same snapshot (repeatable read)
SELECT * FROM products WHERE product_id = 1001;

COMMIT;

Detecção de conflitos e concorrência

O Azure Databricks usa controle de simultaneidade otimista. As transações prossseguem sem bloqueio e os conflitos são detectados no momento da confirmação. Quando você confirma, o Azure Databricks verifica se outras transações modificaram os mesmos dados após o início da transação. Se houver conflitos, a transação falhará. Para transações não interativas, a reversão também ocorre automaticamente. Para transações interativas, você deve executar ROLLBACK explicitamente para limpar o estado da transação antes de iniciar uma nova transação.

Transações não interativas dão suporte à concorrência de nível de linha. Duas transações podem modificar linhas diferentes no mesmo arquivo de dados sem conflitos quando a simultaneidade no nível de linha está habilitada nas tabelas de destino.

As transações interativas oferecem suporte à concorrência no nível da tabela.

Cenários de conflito

Scenario Descrição
Conflitos simultâneos de escrita Duas transações atualizam ou excluem as mesmas linhas.
Conflitos de leitura e escrita Outra transação modificou linhas que sua transação leu. Aplica-se somente ao isolamento serializável.
Conflitos de leitura fantasma Outra transação adicionou novas linhas que correspondem a um predicado que a sua transação leu. Aplica-se ao isolamento WriteSerializable e Serializable.
Conflitos de metadados Outra transação alterou o esquema ou as propriedades da tabela.

Para obter mais detalhes sobre os níveis de isolamento e a resolução de conflitos para transações, consulte os modos de transação. Para obter informações sobre níveis de isolamento e comportamento de conflito de gravação para tabelas Delta Lake no Azure Databricks, consulte Recomendações de Otimização no Azure Databricks.

Como as transações aparecem no log Delta

Cada transação bem-sucedida aparece como uma única entrada no log Delta da tabela, independentemente de quantas instruções individuais foram executadas na transação. Isso fornece uma trilha de auditoria limpa e simplifica as operações de reversão.

As operações individuais dentro de uma transação estão disponíveis como metadados JSON na entrada de log Delta para a transação.

Tratamento e reversão de erros

A tabela a seguir descreve como ocorrem reversões de erro para ambos os tipos de transação:

Scenario Comportamento para transações não interativas Comportamento para transações interativas
Falha na declaração Qualquer instrução que gera um erro causa reversão automática imediata. Você deve executar explicitamente ROLLBACK para descartar alterações se a sessão ainda estiver ativa.
Lógica de validação com falha ou regras de negócios Use SIGNAL para lançar uma exceção e disparar a reversão automática. Execute ROLLBACK para descartar alterações.
Desconexão de sessão A transação é revertda automaticamente. A transação é revertda automaticamente.
Intervalo Reverte automaticamente após 48 horas de duração total. Reverte automaticamente após 10 minutos de inatividade ou 48 horas de duração total (consulte Limitações). A transação é encerrada sem efeitos colaterais, mas você deve executar explicitamente ROLLBACK para limpar o estado da transação se a sessão ainda estiver ativa.

Para transações interativas, você pode reverter explicitamente usando a instrução ROLLBACK . Isso é útil quando você deseja descartar alterações com base na lógica de validação ou nas regras de negócios, ou após uma falha em uma declaração, quando a sessão permanece ativa.

Práticas recomendadas

Siga estas práticas para reduzir conflitos e otimizar o desempenho da transação.

Evitar conflitos

  • Mantenha as transações curtas: transações de execução longa aumentam a probabilidade de conflito e mantêm os recursos por mais tempo.
  • Validar antecipadamente: verifique as pré-condições no início de uma transação para falhar rapidamente.
  • O Databricks recomenda transações não interativas para a maioria dos casos de uso: transações não interativas usam simultaneidade de nível de linha. Consulte transações não interativas.
  • Repetir em caso de conflitos: quando ocorrerem conflitos, repita a transação com dados atualizados.

Usar transações de clientes diferentes

As transações funcionam em várias interfaces do cliente:

Limitações

As seguintes limitações se aplicam a transações que abrangem várias tabelas:

Limitation Descrição
Conflitos de transações interativas Transações interativas (BEGIN TRANSACTION; ... COMMIT;) usam uma detecção de conflito mais conservadora do que transações não interativas e podem entrar em conflito no nível da tabela, exceto para INSERT as operações que não leem da tabela de destino. Use transações não interativas (instrução composta ATOMIC) quando a detecção de conflitos no nível da linha for importante. Consulte transações não interativas.
Destinos de gravação Você só pode gravar em tabelas gerenciadas do Unity Catalog Delta ou Iceberg que têm o recurso de catalogManaged tabela habilitado. Consulte confirmações gerenciadas pelo catálogo.
Somente operações DML Suporte a transações SELECT, INSERT, UPDATE, DELETE, COPY INTO, e MERGE. Execute operações DDL, como CREATE TABLE, ALTER TABLEou DROP TABLE, fora das transações.
Não há suporte para operações de metadados As operações de metadados não funcionam dentro de transações, independentemente do protocolo. Isso inclui chamadas de metadados baseadas em RPC do Thrift (como métodos JDBC DatabaseMetaData e funções de catálogo ODBC), comandos baseados em SQL (SHOW TABLES, SHOW DATABASES, DESCRIBE TABLE) e consultas SELECT em tabelas information_schema ou do sistema. Execute operações de metadados fora das transações.
COPY INTO Concorrência Uma transação executando um COPY INTO comando falhará se outro COPY INTO comando for executado simultaneamente para gravar na mesma tabela e confirmar primeiro.
Escritas de streaming não são suportadas Não há suporte para gravações transacionais em tabelas de streaming.
Não há suporte para tabelas RLS e CLM Tabelas com filtros de linha e máscaras de coluna não podem participar de transações.
Limites de tabela e exibição Uma transação pode ler ou gravar até 100 tabelas combinadas e pode ler de até 100 exibições. Cada tabela pode ter até 100 confirmações intermediárias em uma transação.
Não há suporte para viagem no tempo Você não pode usar viagens no tempo dentro de uma transação.
Tempo limite de inatividade As transações interativas são revertidas após 10 minutos de inatividade. A transação é encerrada sem efeitos colaterais, mas você deve executar explicitamente ROLLBACK para limpar o estado da transação se a sessão ainda estiver ativa.
Duração máxima Todas as transações são revertidas automaticamente após 48 horas de duração total. Para transações interativas, a transação é encerrada sem efeitos colaterais, mas você deve executar explicitamente ROLLBACK para limpar o estado da transação se a sessão ainda estiver ativa.
Requisito de tabelas compartilhadas do Delta Sharing Os provedores de compartilhamento Delta devem compartilhar uma tabela WITH HISTORY para permitir que os destinatários executem transações nela. Os destinatários podem executar transações usando qualquer tipo de computação.
Restrições de computação para destinatários do Delta Sharing Os destinatários do Azure Databricks só podem executar transações em exibições compartilhadas, exibições materializadas, tabelas de streaming e tabelas estrangeiras não Iceberg. Os destinatários na mesma conta do Azure Databricks que seu provedor devem usar computação compartilhada ou sem servidor. Os destinatários em uma conta diferente devem usar a computação sem servidor.
Conflito na tabela de origem do Delta Sharing Os destinatários de compartilhamento Delta não podem referenciar uma exibição compartilhada e uma tabela compartilhada que referenciam a mesma tabela de origem em uma única transação.

Próximas Etapas 

  • Last updated on