Partilhar via

Transações

Importante

As transações que escrevem em tabelas Delta administradas pelo Unity Catalog encontram-se em Prévia Pública.

As transações que escrevem em tabelas Iceberg geridas pelo Catálogo Unity encontram-se em Prévia Privada. Para aderir a esta pré-visualização, submeta o formulário de inscrição de pré-visualização gerida das tabelas Iceberg.

As transações permitem-lhe coordenar operações entre múltiplas instruções e tabelas SQL. Todas as alterações são bem-sucedidas em conjunto ou revertem em conjunto, garantindo a consistência dos dados entre as suas operações e tabelas. As transações oferecem garantias ACID: atomicidade, consistência, isolamento e durabilidade. Consulte Quais são as garantias ACID no Azure Databricks? As transações podem ser usadas com procedimentos armazenados e SQL Scripting para construir cargas de trabalho de armazenamento críticas para a missão.

O exemplo seguinte 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;

As três declarações são confirmadas em conjunto. Se qualquer instrução falhar, todas as alterações serão revertidas e o Databricks finalizará a transação sem causar efeitos colaterais.

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

Requisitos

Para executar transações que abrangem múltiplos extratos ou múltiplas tabelas:

  • Todas as tabelas escritas para devem:
  • Use computação suportada:
    • Para transações não interativas, utilize qualquer SQL warehouse, computação sem servidor ou cluster que execute Databricks Runtime 18.0 ou superior.
    • Para transações interativas, use qualquer armazém SQL.
    • Para transações em ativos compartilhados na Delta Sharing, utilize o Databricks Runtime 18.1 e acima.

Modos de transação

O Azure Databricks suporta dois modos de transação:

Mode Sintaxe Compromisso Reversão Melhor para
Não interativo Enunciado do composto ATOMIC Automático ao ter sucesso Automático em caso de erro Sequências fixas, trabalhos agendados
Interativo INICIAR TRANSAÇÃO; COMPROMETER-SE; Manual Manual Lógica condicional, validação e depuração, JDBC, ODBC, PyDBC

Para sintaxe detalhada, exemplos e padrões de utilização para ambos os modos, veja Modos de transação.

Operações suportadas

Pode usar as seguintes operações dentro das transações:

Funcionamento Descrição
SELECT Consultar dados e validar resultados
VALUES cláusula 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 ficheiro numa tabela Delta
DELETE FROM Remover linhas
MERGE INTO Padrões de upsert (combinação de inserção, atualização e eliminação)

Leia as fontes nas transações

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

Lido de fontes não transacionais

Para ler de fontes não transacionais, como ficheiros Parquet, ficheiros Avro e tabelas federadas usando JDBC, use a allow_nontransactional_reads indicação, como se mostra no exemplo abaixo.

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;

Advertência

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

Isolamento de transações

As transações proporcionam leituras repetíveis em todas as declarações. Quando acede a uma tabela numa transação, o Azure Databricks capta um instantâneo consistente dessa tabela no primeiro acesso. Todas as leituras subsequentes dessa tabela usam esta captura instantânea, assim as suas leituras são consistentes mesmo que outros utilizadores modifiquem concomitantemente as 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;

Deteção de conflitos e concorrência

O Azure Databricks utiliza controlo de concorrência otimista. As transações decorrem sem bloqueios, e os conflitos são detetados no momento do compromisso. Quando faz o commit, o Azure Databricks verifica se outras transações modificaram os mesmos dados após o início da transação. Se existirem conflitos, a sua transação falha. Para transações não interativas, o rollback também ocorre automaticamente. Para transações interativas, deve executar ROLLBACK explicitamente para limpar o estado da transação antes de iniciar uma nova transação.

Transações não interativas suportam concorrência ao nível das linhas. Duas transações podem modificar linhas diferentes no mesmo ficheiro de dados sem conflito quando a concorrência ao nível das linhas está ativada nas tabelas de destino.

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

Cenários de conflito

Scenario Descrição
Conflitos de escrita Duas transações atualizam ou eliminam as mesmas linhas.
Conflitos de leitura-escrita Outra transação modificou linhas que a sua transação leu. Aplica-se apenas 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 tanto ao isolamento WriteSerializable como ao Serializable.
Conflitos de metadados Outra transação alterou o esquema ou propriedades da tabela.

Para mais detalhes sobre níveis de isolamento e resolução de conflitos para transações, consulte Modos de transação. Para informações sobre níveis de isolamento e comportamento em caso de conflito de escrita para tabelas Delta Lake no Azure Databricks, consulte Recomendações de Otimização no Azure Databricks.

Como aparecem as transações no registo Delta

Cada transação bem-sucedida aparece como uma única entrada no log Delta da tabela, independentemente do número de declarações individuais executadas dentro da transação. Isto proporciona um registo de auditoria limpo e simplifica as operações de reversão.

Operações individuais dentro de uma transação estão disponíveis como metadados JSON na entrada do registo Delta para a transação.

Tratamento de erros e rollback

A tabela seguinte descreve como ocorrem as 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 da declaração Qualquer declaração que gera um erro causa uma imediata reversão automática. Tens de executar explicitamente o ROLLBACK para descartar alterações se a sessão ainda estiver ativa.
Lógica de validação falhada ou regras de negócio Use SIGNAL para lançar uma exceção e ativar o rollback automático. Executa o ROLLBACK para descartar alterações.
Desconexão da sessão A transação retrocede automaticamente. A transação anula-se automaticamente.
Timeout Recua automaticamente após 48 horas de duração total. Reverte automaticamente após 10 minutos de inatividade ou 48 horas no total (ver Limitações). A transação é terminada sem efeitos secundários, mas deve executar explicitamente o ROLLBACK para limpar o estado da transação se a sessão ainda estiver ativa.

Para transações interativas, pode reverter explicitamente usando a instrução ROLLBACK . Isto é útil quando deseja descartar alterações com base na lógica de validação ou regras de negócio, ou após uma falha de instrução SQL com a sessão ainda ativa.

Melhores práticas

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

Evitar conflitos

  • Mantenha as transações curtas: Transações de longa duração aumentam a probabilidade de conflito e mantêm os recursos por mais tempo.
  • Validar cedo: Verifique as pré-condições no início de uma transação para falharem rapidamente.
  • A Databricks recomenda transações não interativas para a maioria dos casos de uso: Transações não interativas utilizam concorrência ao nível da linha. Ver Transações não interativas.
  • Repetir na ocorrência de conflitos: Quando ocorrerem conflitos, reexecute a transação com dados frescos.

Utilizar transações de diferentes clientes

As transações funcionam através de várias interfaces de cliente:

Limitações

As seguintes limitações aplicam-se a transações que abrangem múltiplas tabelas:

Limitação Descrição
Conflitos de transações interativas Transações interativas (INICIAR TRANSAÇÃO; ... CONFIRMAR;) usam uma deteção de conflitos mais conservadora do que transações não interativas e podem entrar em conflito ao nível da tabela, exceto para INSERT operações que não leem a tabela de destino. Use transações não interativas (instrução composta ATOM) quando a deteção de conflitos ao nível da linha for importante. Ver Transações não interativas.
Objetivos de escrita Só podes escrever em tabelas Delta ou Iceberg geridas pelo Unity Catalog que tenham a catalogManaged funcionalidade de tabela ativada. Ver Commits geridos por catálogo.
Apenas operações DML As transações suportam SELECT, INSERT, UPDATE, DELETE, COPY INTO, e MERGE. Executar operações DDL, como CREATE TABLE, ALTER TABLE, ou DROP TABLE, fora das transações.
Operações de metadados não suportadas As operações de metadados não funcionam dentro das transações, independentemente do protocolo. Isto 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), consultas SELECT às tabelas information_schema ou tabelas de sistema. Executar operações de metadados fora das transações.
COPY INTO Concorrência Uma transação que executa um COPY INTO comando falha se outro COPY INTO comando for executado ao mesmo tempo para escrever na mesma tabela e confirmar primeiro.
Operações de escrita em streaming não são suportadas Escritas transacionais em tabelas de streaming não são suportadas.
Tabelas RLS e CLM não suportadas Tabelas com filtros de linhas e máscaras de coluna não podem participar nas transações.
Limites de tabela e visualização Uma transação pode ler ou escrever até 100 tabelas no total, e pode ler até 100 visualizações. Cada tabela pode ter até 100 commits intermédios numa transação.
Viagem no tempo não suportada Não pode usar viagem no tempo dentro de uma transação.
Tempo limite de inatividade As transações interativas revertem após 10 minutos de inatividade. A transação é terminada sem efeitos secundários, mas deve executar explicitamente o ROLLBACK para limpar o estado da transação se a sessão ainda estiver ativa.
Duração máxima Todas as transações anulam-se automaticamente após uma duração total de 48 horas. Para transações interativas, a transação é terminada sem efeitos secundários, mas deve executar explicitamente o ROLLBACK para limpar o estado da transação se a sessão ainda estiver ativa.
Requisito de tabelas partilhadas do Delta Sharing Os fornecedores de Delta Sharing devem partilhar uma tabela WITH HISTORY para permitir que os destinatários realizem transações nela. Os destinatários podem executar transações usando qualquer tipo de computação.
Restrições de cálculo do destinatário com Delta Sharing Os destinatários do Azure Databricks só podem executar transações em vistas partilhadas, vistas materializadas, tabelas de streaming e tabelas estrangeiras que não sejam Iceberg. Os destinatários na mesma conta do Azure Databricks que a do fornecedor devem usar computação partilhada ou *serverless*. Os destinatários numa conta diferente devem usar computação sem servidor.
Conflito com a tabela de origem do Delta Sharing Os destinatários do Delta Sharing não podem referenciar uma vista partilhada e uma tabela partilhada que referenciam a mesma tabela de origem dentro de uma única transação.

Passos seguintes

  • Last updated on