Transações

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 incluem propriedades ÁCIDAS: atomicidade, consistência, isolamento e durabilidade. Veja Quais são as garantias ACID em 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:

Não interativo

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;

Interativo

BEGIN TRANSACTION;
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());
COMMIT;

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:
  • Tabelas geridas por catálogo Be Unity (Delta Lake ou Iceberg)
  • Ter os commits do Catálogo ativados
• 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 partilhados OpenSharing, utilize Databricks Runtime 18.1 e superiores.

Modos de transação

Azure Databricks suporta dois modos de transação:

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:

Fontes de leitura suportadas e destinos de escrita suportados

As transações permitem-lhe ler tabelas do Unity Catalog (Delta Lake e Iceberg), tabelas de streaming, vistas e vistas materializadas.

Devido às garantias ACID, formatos de tabela aberta, como Delta Lake e Iceberg, são suportados em transações tanto como fontes de leitura como sumidouros de escrita. Para ler de fontes não transacionais, use a allow_nontransactional_read dica. Veja Ler de fontes não transacionais e Exemplo: leitura não transacional.

Lido de fontes não transacionais

As transações permitem-lhe ler de fontes não transacionais. Fontes não transacionais incluem tabelas externas usando formatos de ficheiro Parquet, Avro, CSV e JSON, e tabelas federadas usando JDBC. Para ler fontes não transacionais, faça referência à fonte pelo nome e use a allow_nontransactional_read dica.

O acesso baseado em caminhos não é suportado. Se, em vez disso, referenciar um ficheiro diretamente através do caminho, como FROM parquet.`/path/to/data`, a transação falha com o erro PATH_BASED_ACCESS.

O seguinte exemplo de código mostra como usar a dica numa tabela externa usando JSON:

BEGIN TRANSACTION;
-- Non-transactional source, hint required
INSERT INTO transactional_table
SELECT col1, col2
FROM external_json_table
WITH (allow_nontransactional_read = true);

COMMIT;

Exemplo: leitura não transacional

O exemplo seguinte mostra uma leitura não transacional de uma tabela externa usando Parquet. Este exemplo exige que tenhas uma localização externa existente com acesso de leitura e escrita.

Veja Estabelecer ligação a uma localização externa do Azure Data Lake Storage Gen2 (ADLS Gen2).

Para registar a fonte Parquet como uma tabela externa nomeada, execute o seguinte:

CREATE TABLE main.default.external_parquet_table
USING PARQUET
LOCATION 'abfss://my-container@my-storage-account.dfs.core.windows.net/path/to/data'; -- existing external location

Para ler tanto uma fonte Parquet não transacional como uma tabela gerida usando Delta Lake numa transação, execute o seguinte:

BEGIN ATOMIC
-- Non-transactional source, hint required
INSERT INTO transactional_table
SELECT col1, col2
FROM external_parquet_table
WITH (allow_nontransactional_read = true);

-- Managed table source, no hint is required
INSERT INTO another_table
SELECT * FROM managed_delta_table;
END;

Isolamento de transações

As transações permitem leituras repetidas em todas as instruções. Quando acede a uma tabela numa transação, o Azure Databricks captura 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.

No exemplo seguinte, a primeira consulta para products na transação captura um instantâneo consistente:

Não interativo

BEGIN ATOMIC
  SELECT * FROM products WHERE product_id = 1001;
  SELECT * FROM products WHERE product_id = 1001;
END;

Interativo

BEGIN TRANSACTION;
SELECT * FROM products WHERE product_id = 1001;
SELECT * FROM products WHERE product_id = 1001;
COMMIT;

Depois, suponha que outro utilizador atualiza em simultâneo a linha de product_id = 1001 antes de a segunda consulta começar:

UPDATE products SET price = 29.99 WHERE product_id = 1001;

Como o instantâneo foi capturado no acesso inicial, a segunda consulta a products devolve a linha original, e não a linha atualizada.

Deteção de conflitos e concorrência

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 sua 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

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 de conflito de escrita para tabelas do 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 permite 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.

Para transações interativas, pode reverter explicitamente usando a instrução ROLLBACK . Isto permite-lhe descartar alterações com base em lógica de validação ou em regras de negócio, ou após a falha de uma instrução, quando a sessão permanece 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:

• SQL Editor e notebooks: Use a sintaxe BEGIN ATOMIC ... END; ou BEGIN TRANSACTION; ... COMMIT; diretamente nas células SQL ou use spark.sql() nos notebooks Python/Scala. Veja Modos de transação.
• Aplicações JDBC: Utilize métodos API JDBC (setAutoCommit(false), commit(), rollback()) com o driver JDBC Databricks versão 3.0.5 e superior. Consulte Exemplo: Usar transações. Para uma lista de operações JDBC não suportadas dentro das transações, veja Operações JDBC não suportadas.
• Aplicações ODBC: Utilize o Databricks ODBC Driver versão 2.10.0 e superior. Para uma lista de operações ODBC não suportadas dentro das transações, veja Operações ODBC não suportadas.
• Aplicações Python: Use o Databricks SQL Connector com autocommit=False. Consulte o Conector SQL Databricks para Python. Para uma lista de operações de conectores de Python não suportadas dentro das transações, veja Operações de conectores de Python não suportadas.
• API de Execução de Instruções: Executar transações usando sintaxe SQL através de chamadas API. Consulte Utilização com API de Execução de Instruções.

Limitações

As seguintes limitações aplicam-se às transações:

Recursos adicionais

• Modos de transação
• Tutorial: Coordenar transações entre tabelas
• Catálogo de commits
• Níveis de isolamento e conflitos de escrita
• ATOMIC Declaração composta (transações não interativas)
• INICIAR TRANSAÇÃO (transações interativas)
• COMMITAR
• ROLLBACK