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

Transações

info

Visualização

Transações que gravam no Unity Catalog gerenciam tabelas Delta e estão em Pré-visualização Pública.

Transações que gravam em tabelas Iceberg gerenciadas Unity Catalog estão em Pré-visualização Privada. Para join desta pré-visualização, envie o formulário de inscrição para a pré-visualização das mesas Iceberg.

As transações permitem coordenar operações em várias instruções SQL e tabelas. Todas as alterações são aplicadas simultaneamente ou revertidas em conjunto, garantindo a consistência dos dados em todas as suas operações e tabelas. As transações fornecem garantias ACID: atomicidade, consistência, isolamento e durabilidade. Consulte O que são garantias ACID no Databricks?. Transações podem ser usadas com procedimentos armazenados e scripts SQL para criar cargas de trabalho de armazenamento de dados de missão crítica.

O exemplo a seguir mostra uma transação:

SQL
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;

As três declarações commit em conjunto. Se alguma instrução falhar, todas as alterações são revertidas e o Databricks encerra a transação sem efeitos colaterais.

Para praticar transações, consulte o tutorial: Coordenar transações entre tabelas.

Requisitos​

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

  • Todas as tabelas escritas devem:

  • Utilizar compute suportados:

    • Para transações não interativas , utilize qualquer SQL warehouse, computeserverless ou cluster executando Databricks Runtime 18.0 ou superior.
    • Para transações interativas , utilize qualquer SQL warehouse.
    • Para transações em ativos compartilhados Delta Sharing , utilize Databricks Runtime 18.1 ou superior.

Modos de transação​

O Databricks suporta dois modos de transação:

Mode

Sintaxe

Commit

Reverter

Melhor para

Não interativo

declaração composta ATÔMICA

Automático em caso de sucesso

Automático em caso de erro

Sequências fixas, trabalho agendado

Interativo

INICIAR TRANSAÇÃO; confirmar;

Manual

Manual

Lógica condicional, validação e depuração, JDBC, ODBC, PyDBC

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

Operações apoiadas​

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

Operação

Descrição

Selecionar

Consultar dados e validar resultados

Cláusula de VALORES

Gere dados de teste ou valores constantes.

INSERIR (incluindo todas as variantes)

Adicionar novas linhas

UPDATE

Modificar linhas existentes

COPY INTO

Carregar dados de um arquivo para uma tabela Delta

DELETE FROM

Remover linhas

MERGE INTO

Padrões Upsert que combinam inserção, atualização e exclusão.

Leia as fontes nas transações.​

As transações podem ler tabelas do Unity Catalog (Delta e Iceberg), tabelas de transmissão, visualizações e visualizações materializadas. Para ler de fontes não transacionais, use a dica allow_nontransactional_reads .

Leia a partir de fontes não transacionais​

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

SQL
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;
atenção

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ção​

As transações fornecem leituras repetíveis em todas as declarações. Ao acessar uma tabela em uma transação, Databricks captura um Snapshot consistente dessa tabela no primeiro acesso. Todas as leituras subsequentes dessa tabela usam esse Snapshot, portanto suas leituras permanecem consistentes mesmo que outros usuários modifiquem as mesmas tabelas simultaneamente.

Exemplo:

SQL
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 Databricks utiliza controle de concorrência otimista. As transações são processadas sem bloqueio, e os conflitos são detectados no momento da confirmação (commit). Ao efetuar o commit, o Databricks verifica se outras transações modificaram os mesmos dados após o início da sua transação. Se houver conflitos, sua transação falhará. Para transações não interativas, o rollback também ocorre automaticamente. Para transações interativas, você deve executar explicitamente ROLLBACK para limpar o estado da transação antes de iniciar uma nova transação.

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

Transações interativas suportam concorrência em nível de tabela.

cenários de conflito​

Cenário

Descrição

Conflitos de escrita

Duas transações atualizam ou excluem as mesmas linhas.

Conflitos de escrita e leitura

Outra transação modificou as 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 lido pela sua transação. Aplica-se tanto ao isolamento WriteSerializable quanto ao 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 Modos de transação. Para obter informações sobre níveis de isolamento e comportamento de conflitos de gravação para tabelas Delta Lake no Databricks, consulte Recomendações de otimização no 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 do número de instruções individuais executadas dentro da transação. Isso proporciona um histórico de auditoria limpo 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 do log Delta da transação.

Tratamento de erros e reversão​

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

Cenário

Comportamento para transações não interativas

Comportamento para transações interativas

Falha na declaração

Qualquer instrução que gere um erro causa um rollback automático imediato.

Você deve executar explicitamente o comando ROLLBACK para descartar as alterações caso a sessão ainda esteja ativa.

Falha na lógica de validação ou nas regras de negócio

Use SIGNAL para lançar uma exceção e acionar o rollback automático.

execução ROLLBACK para descartar alterações.

Desconexão da sessão

A transação é revertida automaticamente.

A transação é revertida automaticamente.

Tempo esgotado

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 o comando ROLLBACK para limpar o estado da transação caso a sessão ainda esteja ativa.

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

Melhores práticas​

Siga estas práticas para reduzir conflitos e otimizar o desempenho das transações.

Evite conflitos​

  • Mantenha as transações curtas : Transações de longa duração aumentam a probabilidade de conflitos e retêm recursos por mais tempo.
  • Valide antecipadamente : verifique as pré-condições no início de uma transação para detectar falhas rapidamente.
  • A Databricks recomenda transações não interativas para a maioria dos casos de uso : transações não interativas utilizam concorrência em nível de linha. Consulte Transações não interativas.
  • Repetir em caso de conflitos : Quando ocorrerem conflitos, a transação será repetida com dados atualizados.

Utilize transações de diferentes clientes.​

As transações funcionam em diversas interfaces de cliente:

Limitações​

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

Limitação

Descrição

Conflitos de transações interativas

Transações interativas (BEGIN TRANSACTION; ... commit;) usam uma detecção de conflitos mais conservadora do que transações não interativas e podem entrar em conflito no nível da tabela, exceto para operações INSERT que não leem da tabela de destino. Utilize transações não interativas (instrução composta ATOMIC) quando a detecção de conflitos em nível de linha for importante. Consulte Transações não interativas.

Escrever metas

Você só pode escrever em tabelas Delta ou Iceberg gerenciadas Unity Catalog que tenham o recurso de tabela catalogManaged habilitado. Consulte commit gerenciado por catálogo.

Somente operações DML

As transações suportam SELECT, INSERT, UPDATE, DELETE, COPY INTO e MERGE. execução de operações DDL, como CREATE TABLE, ALTER TABLE ou DROP TABLE, fora das transações.

Operações de metadados não suportadas

Operações com metadados não funcionam dentro de transações, independentemente do protocolo. Isso inclui chamadas de metadados baseadas em Thrift RPC (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 tabelas do sistema. execução de operações de metadados fora das transações.

COPY INTO concorrência

Uma transação que executa um comando COPY INTO falha se outra execução de comando COPY INTO simultânea for escrita na mesma tabela e confirmada primeiro.

transmissões escreve não suportado

Não há suporte para escritas transacionais em tabelas de transmissão.

Tabelas RLS e CLM não são suportadas.

Tabelas com filtros de linha e máscaras de coluna não podem participar de transações.

Limites de tabela e view

Uma transação pode ler ou gravar em até 100 tabelas combinadas e pode ler de até 100 visualizações. Cada tabela pode ter até 100 confirmações intermediárias dentro de uma transação.

Viagem do tempo não suportada

Não é possível usar "viagem do tempo" dentro de uma transação.

tempo limite do paradigma

Transações interativas são revertidas após 10 minutos de inatividade. A transação é encerrada sem efeitos colaterais, mas você deve executar explicitamente o comando ROLLBACK para limpar o estado da transação caso a sessão ainda esteja ativa.

Máximo

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 o comando ROLLBACK para limpar o estado da transação se a sessão ainda estiver ativa.

Requisito de tabelas compartilhadas Delta Sharing

Os provedores Delta Sharing 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 compute.

Restrições compute do destinatário Delta Sharing

Os destinatários Databricks só podem executar transações em visões compartilhadas, visões materializadas, tabelas de transmissão e tabelas estrangeiras que não sejam Iceberg. Os destinatários que compartilham a mesma account Databricks que seu provedor devem usar compute compartilhada ou serverless . Os destinatários em uma account diferente devem usar compute serverless .

Conflito na tabela de origem Delta Sharing

Os destinatários Delta Sharing não podem referenciar uma view compartilhada e uma tabela compartilhada que façam referência à mesma tabela de origem dentro de uma única transação.

Próximos passos​

Referência SQL relacionada​