Tutorial: Coordenar transações entre tabelas

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.

Este tutorial demonstra como usar transações para coordenar atualizações entre múltiplos extratos e tabelas. Aprendes ambos os modos de transação: transações não interativas, que se comprometem automaticamente, e transações interativas, que te dão controlo explícito. O tutorial também demonstra a utilização de transações com procedimentos armazenados e script SQL para construir cargas de trabalho de armazenamento de dados essenciais para a missão no Azure Databricks.

Requisitos

Ambiente: Acesso a um espaço de trabalho Azure Databricks.
Computação: Os tipos de computação suportados variam consoante o modo de transação:
- Um SQL warehouse clássico ou serverless suporta ambos os modos de transação.
- A computação serverless suporta apenas transações não interativas.
- Clusters clássicos executando Databricks Runtime 18.0 ou superior suportam apenas transações não interativas.
Privilégios: CREATE TABLE num esquema do Unity Catalog .

Configurar tabelas de exemplo

Todas as tabelas escritas numa transação com múltiplas instruções e múltiplas tabelas devem:

Tabelas geridas por catálogo Be Unity (Delta ou Iceberg)
Ter commits geridos pelo catálogo ativados

Crie duas tabelas de exemplo no Editor SQL ou num notebook:

-- Create a table for account data
CREATE TABLE IF NOT EXISTS sample_accounts (
  id INT,
  account_name STRING,
  balance DECIMAL(10,2)
) USING DELTA
TBLPROPERTIES (
  'delta.feature.catalogManaged' = 'supported'
);

-- Create a table for transaction records
CREATE TABLE IF NOT EXISTS sample_transactions (
  id INT,
  account_id INT,
  transaction_type STRING,
  amount DECIMAL(10,2)
) USING DELTA
TBLPROPERTIES (
  'delta.feature.catalogManaged' = 'supported'
);

-- To upgrade an existing table, use:
-- ALTER TABLE <table_name> SET TBLPROPERTIES ('delta.feature.catalogManaged' = 'supported');

-- Insert sample data
INSERT INTO sample_accounts VALUES
  (1, 'Alice', 1000.00),
  (2, 'Bob', 500.00);

INSERT INTO sample_transactions VALUES
  (1, 1, 'deposit', 100.00);

Verifique a configuração:

SELECT * FROM sample_accounts;
SELECT * FROM sample_transactions;

Output:

sample_accounts:
id	account_name	balance
1	  Alice	        1000.00
2	  Bob	          500.00

sample_transactions:
id	account_id	transaction_type	amount
1	           1	         deposit	100.00

Transações não interativas

Transações não interativas utilizam BEGIN ATOMIC ... END; sintaxe. Todas as declarações funcionam como uma única unidade atómica. Se cada instrução tiver sucesso, o Azure Databricks faz o commit automaticamente. Se alguma instrução falhar, o Azure Databricks reverte automaticamente todas as alterações. Para sintaxe detalhada e padrões de utilização, veja transações não interativas.

Execute uma transação bem-sucedida

Atualize ambas as tabelas de forma atómica:

BEGIN ATOMIC
  -- Update Alice's account balance
  UPDATE sample_accounts
  SET balance = balance + 100.00
  WHERE id = 1;

  -- Record the deposit transaction
  INSERT INTO sample_transactions
  VALUES (2, 1, 'deposit', 100.00);
END;

Verifique o sucesso de ambas as operações:

-- Alice's balance should now be 1100.00
SELECT * FROM sample_accounts WHERE id = 1;

-- Should show two transaction records
SELECT * FROM sample_transactions;

Tanto a atualização do saldo como o registo da transação foram criados em conjunto. Se qualquer uma das instruções tivesse falhado, nenhuma alteração teria sido efetivada, e a transação teria sido terminada pela Databricks sem efeitos colaterais.

Use o SIGNAL para falhar uma transação sob uma condição

Pode usar SIGNAL dentro de um BEGIN ATOMIC ... END; bloco para falhar a transação quando uma condição definida pelo utilizador não é cumprida. Isto é útil para validação de dados antes da confirmação:

BEGIN ATOMIC
  -- Insert new account
  INSERT INTO sample_accounts VALUES (3, 'Charlie', -50.00);

  -- Fail the transaction if balance is negative
  IF (SELECT balance FROM sample_accounts WHERE id = 3) < 0 THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Account balance cannot be negative';
  END IF;
END;

SIGNAL gera um erro, o que faz com que toda a transação seja revertida automaticamente. Verifique se o inserto foi revertido:

-- Should return 0 rows (the transaction was rolled back by SIGNAL)
SELECT * FROM sample_accounts WHERE id = 3;

Ver recuo automático em caso de falha

Execute uma transação com um extrato inválido:

BEGIN ATOMIC
  -- This statement is valid
  INSERT INTO sample_accounts VALUES (4, 'David', 300.00);

  -- This statement will fail (table does not exist)
  INSERT INTO non_existent_table VALUES (1, 2, 3);
END;

A transação falha com um erro. Confirme se a primeira declaração foi revertida:

-- Should return 0 rows because the transaction was rolled back
SELECT * FROM sample_accounts WHERE id = 4;

Apesar de a primeira INSERT afirmação ser válida, foi revertida porque a segunda falhou. Isto demonstra a garantia de tudo ou nada das transações.

Transações interativas

Transações interativas dão-lhe controlo explícito sobre quando confirmar ou reverter. Usa INICIAR TRANSAÇÃO para começar, depois COMMIT para guardar alterações ou REVERTER para as descartar.

Confirmar alterações

Inicie uma transação:

BEGIN TRANSACTION;

Faça alterações (ainda não comprometidas):

INSERT INTO sample_accounts VALUES (5, 'Eve', 850.00);
UPDATE sample_accounts SET balance = balance + 50.00 WHERE id = 2;

Compromete-se a tornar as mudanças permanentes:

COMMIT;

Verifique as alterações:

-- Eve's account should now be visible
SELECT * FROM sample_accounts WHERE id = 5;

-- Bob's balance should be 550.00 (500 + 50)
SELECT * FROM sample_accounts WHERE id = 2;

Reverter alterações

Inicie uma nova transação:

BEGIN TRANSACTION;

Faça uma alteração:

INSERT INTO sample_accounts VALUES (6, 'Frank', 600.00);

Verifique se a alteração é visível na sua sessão:

-- Should show Frank's account (visible in your session only)
SELECT * FROM sample_accounts WHERE id = 6;

Recuar para descartar a alteração:

ROLLBACK;

Verifique se a alteração foi descartada:

-- Should return 0 rows (the insert was rolled back)
SELECT * FROM sample_accounts WHERE id = 6;

Utilização com procedimentos armazenados e rotinas SQL

Pode combinar transações com procedimentos armazenados para criar lógica de transações reutilizável. Este padrão é útil para operações complexas que você realiza frequentemente.

Crie duas tabelas com commits geridos pelo catálogo ativados


CREATE TABLE orders (order_id STRING, item_sku STRING, quantity_ordered INT)
 TBLPROPERTIES ('delta.feature.catalogManaged' = 'supported');

CREATE TABLE inventory (item_sku STRING, quantity_in_stock INT)
 TBLPROPERTIES ('delta.feature.catalogManaged' = 'supported');

Defina o procedimento armazenado

CREATE OR REPLACE PROCEDURE main.retail.apply_order(
    IN  p_order_id      STRING,
    IN  p_customer_id   STRING,
    IN  p_order_amount  DECIMAL(18,2)
)
LANGUAGE SQL
SQL SECURITY INVOKER
MODIFIES SQL DATA
AS
BEGIN
    -- Insert the order
    INSERT INTO main.retail.orders (order_id, customer_id, amount)
    VALUES (p_order_id, p_customer_id, p_order_amount);

    -- Update total sales per customer
    MERGE INTO main.retail.total_sales AS t
    USING (
        SELECT
          p_customer_id  AS customer_id,
          p_order_amount AS order_amount
    ) s
      ON t.customer_id = s.customer_id
    WHEN MATCHED THEN
      UPDATE SET t.total_amount = t.total_amount + s.order_amount
    WHEN NOT MATCHED THEN
      INSERT (customer_id, total_amount)
      VALUES (s.customer_id, s.order_amount);
END;

Defina a transação

BEGIN ATOMIC
    -- Staging batch id for this transaction
    DECLARE new_order_id STRING DEFAULT uuid();
    DECLARE v_batch_id STRING DEFAULT uuid();

    -- 1) Stage incoming customer and order rows
    INSERT INTO main.retail.orders_staging (order_id, customer_id, amount, batch_id)
    VALUES (new_order_id, 'CUST_123', 249.99, v_batch_id);

    -- 2) Drive final writes from staging to production via stored procedure
    FOR o AS
      SELECT
        order_id,
        customer_id,
        amount
      FROM main.retail.orders_staging
      WHERE batch_id = v_batch_id
    DO
        CALL main.retail.apply_order(
          o.order_id,
          o.customer_id,
          o.amount
        );
    END FOR;

    -- 3) Clean up processed staging rows
    DELETE FROM main.retail.orders_staging
    WHERE batch_id = v_batch_id;
END; -- 4) Commit the transaction

Se alguma parte da transação falhar, o Databricks reverte automaticamente todas as alterações.

Limpar

Remover as tabelas de exemplo:

DROP TABLE IF EXISTS sample_accounts;
DROP TABLE IF EXISTS sample_transactions;


DROP TABLE IF EXISTS orders;
DROP TABLE IF EXISTS inventory;

Passos seguintes

Transações: Visão geral do suporte às transações.
Modos de transação: Sintaxe detalhada e padrões para ambos os modos.
Commits geridos pelo catálogo: Ative o suporte de transações nas suas tabelas.
Use transações de diferentes clientes: Execute transações de aplicações JDBC, ODBC e Python.

Comentários

Esta página foi útil?

Last updated on 2026-03-15