Transactions
Aperçu
Les transactions qui écrivent dans les tables Iceberg gérées par Unity Catalog sont en préversion privée. Pour rejoindre cette préversion, soumettez le formulaire d'inscription à la préversion des tables Iceberg gérées.
Les transactions vous permettent de coordonner les opérations sur plusieurs instructions SQL et tables. Tous les changements réussissent ensemble ou sont annulés ensemble, garantissant ainsi la cohérence des données de vos Opérations et de vos tables. Les transactions incluent les propriétés ACID : atomicité, cohérence, isolement et durabilité. Consultez Que sont les garanties ACID sur Databricks ?.
Les transactions peuvent être utilisées avec les procédures stockées et le scripting SQL pour créer des charges de travail d'entreposage critiques.
L’exemple suivant montre une transaction :
- Non-interactive
- Interactive
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;
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;
Les trois instructions effectuent un commit ensemble. Si une instruction échoue, toutes les modifications sont annulées et Databricks met fin à la transaction sans effets secondaires.
Pour une pratique concrète des transactions, consultez le Tutoriel : Coordonner les transactions entre les tables.
Exigences
Pour exécuter des transactions qui couvrent plusieurs instructions ou plusieurs tables :
-
Toutes les tables écrites dans doivent :
- Être des tables gérées par Unity Catalog (Delta Lake ou Iceberg)
- Activer les commits du catalogue
-
Utilisez le compute pris en charge :
- Pour les **transactions non interactives**, utilisez n’importe quel SQL Warehouse, uncompute serverless ou un cluster exécutant Databricks Runtime 18,0 et versions ultérieures.
- Pour les transactions interactives , utilisez n'importe quel SQL warehouse.
- Pour les transactions sur les assets partagés OpenSharing , utilisez Databricks Runtime 18,1 et versions ultérieures.
Modes de transaction
Databricks prend en charge deux modes de transaction :
Mode | Syntaxe | commit | Restauration | Idéal pour |
|---|---|---|---|---|
Non-interactif | Automatique en cas de succès | Automatique en cas d'erreur | Séquences fixes, jobs planifiés | |
Un workspace | Manuel | Manuel | Logique conditionnelle, validation et debugging, JDBC, ODBC, PyODBC |
Pour connaître la syntaxe détaillée, les exemples et les modèles d'utilisation pour les deux modes, consultez Modes de transaction.
Opérations prises en charge
Vous pouvez utiliser les Opérations suivantes dans les transactions :
Opérations | Description |
|---|---|
Query les données et valider les résultats | |
Générer des données de test ou des valeurs constantes | |
| Ajouter de nouvelles lignes |
Modifier les lignes existantes | |
Charger des données à partir d'un fichier dans une table Delta | |
Supprimer les lignes | |
Modèles d'upsert combinant l'insertion, la mise à jour et la suppression | |
Définissez le catalogue ou le schéma actuel pour les instructions de la transaction. | |
Exécutez une instruction SQL que vous construisez dynamiquement au moment de l’exécution | |
Renvoie les métadonnées d'une table, telles que ses colonnes et ses propriétés. | |
Répertoriez les colonnes dans une table | |
Récupérez les informations de diagnostic, telles que l'état de la transaction active ou le nombre de lignes affectées par la dernière instruction |
Sources de lecture et récepteurs d'écriture pris en charge
Les transactions vous permettent de lire à partir des tables Unity Catalog (Delta Lake et Iceberg), des tables de streaming, des vues et des vues matérialisées.
Grâce aux garanties {ACID}, les formats de table ouverts, tels que {Delta Lake} et {Iceberg}, sont pris en charge dans les transactions en tant que sources de lecture et puits d'écriture. Pour lire à partir de sources non transactionnelles, utilisez l'indicateur allow_nontransactional_read. Voir Lecture à partir de sources non transactionnelles et Exemple : lecture non transactionnelle.
Lire à partir de sources non transactionnelles
Les lectures non transactionnelles ne sont pas reproductibles. Les modifications simultanées apportées aux données sources pendant la transaction peuvent entraîner des lectures incohérentes.
Les transactions vous permettent de lire à partir de sources non transactionnelles. Les sources non transactionnelles comprennent les tables externes utilisant les formats de fichier Parquet, Avro, CSV et JSON, ainsi que les tables fédérées utilisant JDBC. Pour lire des sources non transactionnelles, référencez la source par son nom et utilisez l'indice allow_nontransactional_read.
Au sein d'une transaction, vous pouvez également query le information_schema.
Vous pouvez lire les fichiers directement avec la fonction table read_files.
L'accès basé sur le chemin n'est pas pris en charge. Si vous référencez un fichier directement par son chemin d'accès à la place, tel que FROM parquet.`/path/to/data`, la transaction échoue avec une erreur PATH_BASED_ACCESS.
L’exemple de code suivant montre comment utiliser l’indication sur une table externe à l’aide de 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;
Exemple : lecture non transactionnelle
L'exemple suivant montre une lecture non transactionnelle à partir d'une table externe en Parquet. Cet exemple nécessite que vous disposiez d'un emplacement externe existant avec un accès en lecture et écriture.
Consultez Connectez-vous à un emplacement externe AWS S3.
Pour enregistrer la source Parquet en tant que table externe nommée, exécutez ce qui suit :
CREATE TABLE main.default.external_parquet_table
USING PARQUET
LOCATION 's3://my-bucket/path/to/data'; -- existing external location
Pour lire à la fois une source Parquet non transactionnelle et une table gérée à l'aide de Delta Lake dans une transaction, exécutez ce qui suit :
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;
Isolation des transactions
Les transactions permettent des lectures reproductibles sur toutes les déclarations. Lorsque vous accédez à une table lors d'une transaction, Databricks capture un instantané cohérent de cette table lors du premier accès. Toutes les lectures ultérieures de cette table utilisent cet instantané, de sorte que vos lectures restent cohérentes même si d'autres utilisateurs modifient simultanément les mêmes tables.
Dans l'exemple suivant, la première query à products dans la transaction capture un instantané cohérent :
- Non-interactive
- Interactive
BEGIN ATOMIC
SELECT * FROM products WHERE product_id = 1001;
SELECT * FROM products WHERE product_id = 1001;
END;
BEGIN TRANSACTION;
SELECT * FROM products WHERE product_id = 1001;
SELECT * FROM products WHERE product_id = 1001;
COMMIT;
Alors, supposons qu'un autre utilisateur mette à jour simultanément la ligne pour product_id = 1001 avant le début de la deuxième query :
UPDATE products SET price = 29.99 WHERE product_id = 1001;
Étant donné que l'instantané a été capturé lors du premier accès, la deuxième query à products renvoie la ligne d'origine, et non celle mise à jour.
Détection des conflits et simultanéité
Databricks utilise un contrôle de concurrence optimiste. Les transactions se déroulent sans verrouillage, et les conflits sont détectés au moment du commit. Lorsque vous effectuez un commit, 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 explicitement ROLLBACK pour effacer l'état de la transaction avant de commencer une nouvelle transaction.
Les transactions non interactives prennent en charge la simultanéité au niveau des lignes. Deux transactions peuvent modifier différentes lignes dans le même fichier de données sans conflit lorsque la simultanéité au niveau des lignes est activée sur les tables cibles.
Les transactions interactives prennent en charge la concurrence au niveau de la table.
Scénarios de conflit
Scénario | Description |
|---|---|
Conflits d'écriture-écriture | Deux transactions mettent à jour ou suppriment les mêmes lignes. |
Conflits en lecture-écriture | Une autre transaction a modifié les lignes que votre transaction a lues. S'applique uniquement à l'isolation sérialisable. |
Conflits de lecture fantôme | Une autre transaction a ajouté de nouvelles lignes correspondant à un prédicat lu par votre transaction. S'applique aux isolations WriteSerializable et Serializable. |
Conflits de métadonnées | Une autre transaction a modifié le schéma ou les propriétés de la table. |
Pour plus de détails sur les niveaux d'isolation et la résolution des conflits pour les transactions, consultez Modes de transaction. Pour plus d'informations sur les niveaux d'isolation et le comportement en cas de conflit d'écriture pour les tables Delta Lake sur Databricks, consultez Recommandations d'optimisation sur Databricks.
Comment les transactions apparaissent-elles dans le Delta Log
Chaque transaction réussie apparaît comme une seule entrée dans le log Delta de la table, quel que soit le nombre d'instructions individuelles exécutées au sein de la transaction. Cela permet un suivi d'audit clair et simplifie les opérations de rollback.
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 restauration
Le tableau suivant décrit comment les annulations d'erreurs se produisent pour les deux types de transactions :
Scénario | Comportement pour les transactions non interactives | Comportement pour les transactions interactives |
|---|---|---|
Échec de l'instruction | Toute déclaration qui génère une erreur entraîne un rollback automatique immédiat. | Vous devez exécuter explicitement ROLLBACK pour annuler les modifications si la session est toujours active. |
Logique de validation ou règles métier échouées | Utilisez | Exécutez RESTAURATION pour annuler les modifications. |
Déconnexion de la session | La transaction s'annule automatiquement. | La transaction s'annule automatiquement. |
Délai d'expiration | Rétablit automatiquement après 48 heures de durée totale. | Annule automatiquement après 10 minutes d'inactivité ou 48 heures de durée totale (voir Limitations). La transaction est terminée sans effets secondaires, mais vous devez exécuter explicitement ROLLBACK pour effacer l'état de la transaction si la session est toujours active. |
Pour les transactions interactives, vous pouvez explicitement annuler l'opération en utilisant l'instruction ROLLBACK. Cela vous permet d'annuler 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.
Évitez les conflits
- Gardez les transactions courtes : les transactions de longue durée augmentent la probabilité de conflit et retiennent les Ressources plus longtemps.
- Valider en amont : vérifiez les préconditions au début d’une transaction pour échouer rapidement.
- Utilisez
BEGIN ATOMICpour la concurrence au niveau des lignes : les transactions non interactives (BEGIN ATOMIC ... END;) détectent les conflits au niveau des lignes, ce qui réduit les conflits par rapport à la détection au niveau des tables utilisée par les transactions interactives. Voir Transactions non interactives. - Définir la logique de nouvelle tentative : Une transaction peut échouer à tout moment en raison d'un conflit. Intégrez une logique de nouvelle tentative à votre application et relancez les transactions ayant échoué avec de nouvelles données.
- start each interactive session with a rollback : Exécutez ROLLBACK au début d'une session interactive pour effacer tout état de transaction préexistant.
Utiliser des transactions de différents clients
Les transactions fonctionnent sur diverses interfaces client :
- Éditeur SQL et Notebooks : Utilisez la syntaxe
BEGIN ATOMIC ... END;ouBEGIN TRANSACTION; ... COMMIT;directement dans les cellules SQL ou utilisezspark.sql()dans les Notebooks Python/Scala. Voir les modes de transaction. - Applications JDBC : Utilisez les méthodes de l'API JDBC (
setAutoCommit(false),commit(),rollback()) avec le Driver JDBC Databricks version 3.0.5 et ultérieure. Voir 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 Driver ODBC Databricks version 2.10.0 et ultérieure. Pour une liste des opérations ODBC non prises en charge dans les transactions, consultez Opérations ODBC non prises en charge.
- Applications Python : utilisez le connecteur Databricks SQL avec
autocommit=False. Consultez Databricks SQL Connector for Python. Pour une liste des Opérations du connecteur Python non prises en charge au sein des transactions, consultez Opérations du connecteur Python non prises en charge. - API d'exécution des déclarations : exécutez des transactions à l'aide de la syntaxe SQL via des appels d'API. Consultez l'utilisation avec l'API d'exécution d'instructions.
Limitations
Les limitations suivantes s'appliquent aux transactions :
Limitation | Description |
|---|---|
Conflits de transaction interactifs | Les transactions interactives (BEGIN TRANSACTION; ... COMMIT;) utilisent une détection de conflit plus conservatrice que les transactions non interactives et peuvent entrer en conflit au niveau du tableau, à l'exception des opérations INSERT qui ne lisent pas à partir de la table cible. Utilisez des transactions non interactives (instruction composée ATOMIQUE) lorsque la détection de conflit au niveau des lignes est importante. Voir Transactions non interactives |
Cibles d'écriture | Vous pouvez uniquement écrire dans les tables Unity Catalog gérées Delta ou Iceberg pour lesquelles la fonctionnalité de table |
Opérations DDL non prises en charge | Exécutez les opérations DDL, telles que |
Certaines opérations de métadonnées non prises en charge | Certaines opérations de métadonnées ne fonctionnent pas dans les transactions, quel que soit le protocole. Cela inclut les appels de métadonnées basés sur Thrift RPC (telles que les méthodes JDBC |
| Une transaction exécutant une commande |
Simultanéité au niveau des lignes pour | La simultanéité au niveau des lignes pour les |
Limites des tables et des vues | Une transaction peut lire dans ou écrire dans un total de 100 tables, et peut lire jusqu'à 100 vues. Chaque table peut avoir jusqu’à 100 commits intermédiaires au sein d’une transaction. |
Time travel non pris en charge | Vous ne pouvez pas utiliser time travel au sein d'une transaction. |
Délai d'expiration d'inactivité | Les transactions interactives sont annulées après 10 minutes d'inactivité. La transaction est terminée sans effets secondaires, mais vous devez exécuter explicitement ROLLBACK pour effacer l'état de la transaction si la session est toujours active. |
Traçabilité | Les transactions émettent de la traçabilité à chaque lecture et écriture. Les événements de traçabilité persistent même si la transaction est annulée. |
Durée maximale | Toutes les transactions sont annulées automatiquement après 48 heures de durée totale. Pour les transactions interactives, la transaction est terminée sans effets secondaires, mais vous devez exécuter explicitement ROLLBACK pour effacer l'état de la transaction si la session est toujours active. |
Exigence pour les tables partagées OpenSharing | Les fournisseurs OpenSharing doivent partager une table |
Restrictions de compute pour les destinataires OpenSharing | Les destinataires Databricks peuvent exécuter des transactions uniquement sur des vues partagées, des vues matérialisées, des tables de streaming et des tables étrangères non-Iceberg. Les destinataires dans le même compte Databricks que leur fournisseur doivent utiliser le compute partagé ou serverless. Les destinataires dans un compte différent doivent utiliser le compute serverless. |
Conflit de table source OpenSharing | Les destinataires OpenSharing ne peuvent pas référencer une vue partagée et une table partagée qui référencent la même table source au sein d'une même transaction. |