Transactions

Les transactions vous permettent de coordonner les opérations entre plusieurs instructions et tables SQL. Toutes les modifications réussissent ensemble ou échouent ensemble, garantissant ainsi la cohérence des données dans vos opérations et tables. Les transactions assurent les garanties ACID : atomicité, cohérence, isolation et durabilité. Consultez En quoi consistent les garanties ACID sur Azure Databricks ?. Les transactions peuvent être utilisées avec des procédures stockées et des scripts SQL pour créer des charges de travail d’entreposage stratégiques.

L’exemple suivant montre une transaction :

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;

Les trois instructions sont effectuées ensemble. Si une instruction échoue, toutes les modifications sont annulées et Databricks termine la transaction sans effets secondaires.

Pour une pratique pratique avec des transactions, consultez Tutoriel : Coordonner les transactions entre les tables.

Exigences

Pour exécuter des transactions qui s’étendent sur plusieurs instructions ou plusieurs tables :

• Toutes les tables sur lesquelles on écrit doivent :
  • "Les tables doivent être gérées par Unity Catalog (Delta ou Iceberg)"
  • Activer les validations gérées par le catalogue
• Utilisez le calcul pris en charge :
  • Pour les transactions non interactives, utilisez n’importe quel entrepôt SQL, calcul serverless ou cluster exécutant Databricks Runtime 18.0 et versions ultérieures.
  • Pour les transactions interactives, utilisez n’importe quel entrepôt SQL.
  • Pour les transactions sur les ressources partagées via Delta Sharing, utilisez Databricks Runtime 18.1 et versions ultérieures.

Modes de transaction

Azure Databricks prend en charge deux modes de transaction :

Pour obtenir une syntaxe détaillée, des exemples et des modèles d’utilisation pour les deux modes, consultez les modes transactionnels.

Opérations prises en charge

Vous pouvez utiliser les opérations suivantes dans les transactions :

Lire les sources dans les transactions

Les transactions peuvent lire des tables du Unity Catalog (Delta et Iceberg), des tables de streaming, des vues et des vues matérialisées. Pour lire à partir de sources non transactionnelles, utilisez l’indicateur allow_nontransactional_reads .

Lecture depuis des sources non transactionnelles

Pour lire à partir de sources non transactionnelles telles que des fichiers Parquet, des fichiers Avro et des tables fédérées à l’aide de JDBC, utilisez l’indicateur allow_nontransactional_reads , comme illustré dans l’exemple suivant :

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;

Isolation des transactions

Les transactions fournissent des lectures cohérentes sur toutes les instructions. Lorsque vous accédez à une table dans une transaction, Azure Databricks capture un instantané cohérent de cette table au premier accès. Toutes les lectures suivantes de cette table utilisent cet instantané. Vos lectures restent donc cohérentes même si d’autres utilisateurs modifient simultanément les mêmes tables.

Exemple :

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;

Détection des conflits et concurrence

Azure Databricks utilise le contrôle de concurrence optimiste. Les transactions continuent sans verrouillage, et les conflits sont détectés au moment de la validation. Lorsque vous validez, Azure Databricks vérifie si d’autres transactions ont modifié les mêmes données après le début de votre transaction. Si des conflits existent, votre transaction échoue. Pour les transactions non interactives, l'annulation se produit également automatiquement. Pour les transactions interactives, vous devez exécuter ROLLBACK explicitement pour effacer l’état de la transaction avant de commencer une nouvelle transaction.

Les transactions non interactives prennent en charge la concurrence au niveau des lignes. Deux transactions peuvent modifier des lignes différentes dans le même fichier de données sans conflit lorsque la concurrence au niveau des lignes est activée sur les tables cibles.

Les transactions interactives supportent la concurrence au niveau des tables.

Scénarios de conflit

Pour plus d’informations sur les niveaux d’isolation et la résolution des conflits pour les transactions, consultez les modes de transaction. Pour plus d’informations sur les niveaux d’isolation et le comportement de conflit d’écriture pour les tables Delta Lake sur Azure Databricks, consultez les recommandations d’optimisation sur Azure Databricks.

Comment les transactions apparaissent dans le journal Delta

Chaque transaction réussie apparaît sous la forme d’une entrée unique dans le journal Delta, quel que soit le nombre d’instructions individuelles exécutées dans la transaction. Cela offre une piste d’audit claire et simplifie les opérations d’annulation.

Les opérations individuelles au sein d’une transaction sont disponibles sous forme de métadonnées JSON dans l’entrée du journal Delta pour la transaction.

Gestion des erreurs et retour arrière

Le tableau suivant décrit comment les restaurations d’erreurs se produisent pour les deux types de transactions :

Pour les transactions interactives, vous pouvez annuler explicitement à l’aide de l’instruction ROLLBACK. Cela est utile lorsque vous souhaitez ignorer les modifications en fonction de la logique de validation ou des règles métier, ou après un échec d’instruction lorsque la session reste active.

Bonnes pratiques

Suivez ces pratiques pour réduire les conflits et optimiser les performances des transactions.

Éviter les conflits

• Conserver les transactions courtes : les transactions longues augmentent la probabilité de conflit et conservent les ressources plus longtemps.
• Valider tôt : vérifiez les conditions préalables au début d’une transaction pour échouer rapidement.
• Databricks recommande des transactions non interactives pour la plupart des cas d’usage : les transactions non interactives utilisent la concurrence au niveau des lignes. Consultez les transactions non interactives.
• Réessayer en cas de conflits: en cas de conflits, retenter la transaction avec des données mises à jour.

Utiliser des transactions de différents clients

Les transactions fonctionnent sur différentes interfaces clientes :

• Éditeur SQL et notebooks : Utilisez la syntaxe BEGIN ATOMIC ... END; ou BEGIN TRANSACTION; ... COMMIT; directement dans les cellules SQL ou utilisez spark.sql() dans des notebooks Python/Scala. Consultez les modes de transaction.
• Applications JDBC : utilisez des méthodes d’API JDBC (setAutoCommit(false), commit(), rollback()) avec le pilote JDBC Databricks version 3.0.5 et ultérieure. Voir l’exemple : Utiliser des transactions. Pour obtenir la liste des opérations JDBC non prises en charge dans les transactions, consultez opérations JDBC non prises en charge.
• Applications ODBC : utilisez le pilote ODBC Databricks version 2.10.0 et ultérieure. Pour obtenir la liste des opérations ODBC non prises en charge dans les transactions, consultez les opérations ODBC non prises en charge.
• Applications Python : utilisez le connecteur SQL Databricks avec autocommit=False. Consultez Databricks SQL Connector pour Python. Pour obtenir la liste des opérations de connecteur Python non prises en charge dans les transactions, consultez opérations de connecteur Python non prises en charge.
• API d’exécution d’instruction : exécutez des transactions à l’aide de la syntaxe SQL par le biais d’appels d’API. Consultez Utilisation avec l’API d’exécution d’instructions SQL.

Limites

Les limitations suivantes s’appliquent aux transactions qui s’étendent sur plusieurs tables :

Étapes suivantes

• Modes de transaction
• Tutoriel : Coordonner les transactions entre les tables
• Commits gérés par le catalogue
• Niveaux d’isolation et conflits d’écriture

Référence SQL associée

• ATOMIC instruction composée (transactions non interactives)
• BEGIN TRANSACTION (transactions interactives)
• COMMIT
• ROLLBACK