Transações atômicas em tabelas Delta Lake e Apache Iceberg no Databricks

O Databricks liberou em disponibilidade geral (GA) o suporte a transações SQL em tabelas gerenciadas Delta Lake e Apache Iceberg via Unity Catalog. Com esse recurso, comandos executados em múltiplas tabelas são agrupados em uma única transação atômica, garantindo que todas as alterações sejam confirmadas juntas ou revertidas em caso de falha.

Para que serve

Imagine que você precisa atualizar o estoque em uma tabela e registrar a venda em outra tabela na mesma operação. Se uma das etapas falhar, os dados ficam inconsistentes. Com as transações atômicas, você pode:

• Agrupar múltiplos comandos SQL de leitura e escrita em uma transação única.
• Garantir integridade de dados (ACID) entre tabelas distintas gerenciadas pelo Unity Catalog.
• Operar conjuntamente tabelas nos formatos Delta Lake e Apache Iceberg.

Como usar

Para participar de transações, as tabelas precisam ter o recurso de Catalog Commits habilitado via propriedade delta.feature.catalogManaged.

Primeiro, crie uma tabela nova com o recurso ou altere uma tabela existente:

-- Criando uma nova tabela gerenciada
CREATE TABLE meu_catalogo.vendas.pedidos (
  pedido_id BIGINT,
  valor DECIMAL(10,2),
  data_pedido DATE
)
TBLPROPERTIES ('delta.feature.catalogManaged' = 'supported');

-- Habilitando em tabela gerenciada existente
ALTER TABLE meu_catalogo.vendas.estoque 
SET TBLPROPERTIES ('delta.feature.catalogManaged' = 'supported');

O que acontece nesse código:

1. A primeira instrução cria a tabela pedidos com commits coordenados diretamente no catálogo.
2. A segunda instrução altera a tabela estoque já existente para habilitar o gerenciamento de commits pelo Unity Catalog.

Com o recurso habilitado nas tabelas participantes, execute a transação atômica usando BEGIN TRANSACTION ou BEGIN ATOMIC:

BEGIN TRANSACTION;

INSERT INTO meu_catalogo.vendas.pedidos VALUES (101, 150.00, current_date());
UPDATE meu_catalogo.vendas.estoque SET quantidade = quantidade - 1 WHERE produto_id = 42;

COMMIT;

O que acontece nesse código:

1. O comando BEGIN TRANSACTION inicia o bloco transacional.
2. O INSERT e o UPDATE são executados de forma isolada.
3. O comando COMMIT aplica as mudanças em ambas as tabelas de maneira atômica; se houver erro, nada é gravado.

Para conferir se o recurso está ativo em uma tabela:

DESCRIBE DETAIL meu_catalogo.vendas.pedidos;

Limitações e requisitos

• As transações estão em GA, mas o recurso subjacente de Catalog Commits está listado em Beta.
• Requer tabelas gerenciadas pelo Unity Catalog (Delta ou Apache Iceberg), streaming tables ou materialized views.
• Para ler, gravar ou criar tabelas gerenciadas com catalog commits, exige Databricks Runtime 16.4 ou superior.
• Para habilitar ou desabilitar o recurso em tabelas gerenciadas existentes, é necessário Databricks Runtime 18.0 ou superior.
• Em streaming tables e materialized views, a leitura e escrita exigem Databricks Runtime 17.3 ou superior (ou compute serverless no Spark Declarative Pipelines), e desabilitar exige Databricks Runtime 18 LTS ou superior.
• Não é possível ativar ou desativar o recurso em tabelas existentes usando CREATE OR REPLACE TABLE ou REPLACE TABLE; use ALTER TABLE.
• Streaming tables com catalog commits não podem ser acessadas por clusters single-user.

Como aplicar num pipeline

Em pipelines de ingestão ou conciliação financeira na camada Silver ou Gold, use os blocos transacionais para atualizar tabelas de fatos e dimensões correlacionadas no mesmo commit, evitando leituras intermediárias inconsistentes por dashboards ou relatórios.