Présentation des garanties ACID sur Azure Databricks

Azure Databricks utilise Delta Lake par défaut pour toutes les lectures et écritures, et s’appuie sur les garanties ACID fournies par le protocole Delta Lake open source. ACID signifie Atomicité, Cohérence, Isolation et Durabilité.

• Atomicité signifie que toutes les transactions réussissent ou échouent complètement.
• Les garanties de Cohérence concernent la façon dont un état spécifique des données est observé en cas d’opérations simultanées.
• Isolation fait référence à la façon dont les opérations simultanées sont potentiellement en conflit.
• Durabilité signifie que les modifications validées sont permanentes.

Bien que de nombreuses technologies de traitement et de stockage de données revendiquent la prise en charge des transactions ACID, les garanties spécifiques varient d'un système à l'autre, et les transactions sur Azure Databricks peuvent différer de celles des autres systèmes que vous avez utilisés.

Notes

Cette page décrit les garanties pour les tables sauvegardées par Delta Lake. Il est possible que d’autres formats de données et systèmes intégrés ne fournissent pas de garanties transactionnelles pour les lectures et les écritures.

Toutes les écritures Azure Databricks dans le stockage d’objets cloud utilisent des validations transactionnelles, qui créent des fichiers de métadonnées commençant par _started_<id> et _committed_<id> avec les fichiers de données. Vous n’avez pas besoin d’interagir avec ces fichiers, car Azure Databricks nettoie régulièrement les fichiers de métadonnées de validation obsolètes.

Comment les transactions sont-elles délimitées sur Azure Databricks ?

Azure Databricks gère les transactions au niveau de la table. Les transactions s’appliquent toujours à une table à la fois. Pour la gestion des transactions simultanées, Azure Databricks utilise le contrôle d’accès concurrentiel optimiste. Cela signifie qu’il n’y a pas de verrous sur la lecture ou l’écriture sur une table, et que le blocage n’est pas une possibilité.

Par défaut, Azure Databricks fournit une isolation de capture instantanée sur les lectures et l’isolation sérialisable en écriture sur les écritures. L’isolation sérialisable en écriture offre de meilleures garanties que l’isolation de capture instantanée. Toutefois, cette meilleure isolation s’applique uniquement aux écritures.

Les opérations de lecture référençant plusieurs tables retournent la version actuelle de chaque table au moment de l’accès, mais n’interrompent pas les transactions simultanées susceptibles de modifier les tables référencées.

Azure Databricks n’a pas de constructions BEGIN/END permettant de regrouper plusieurs opérations en une transaction unique. Les applications qui modifient plusieurs tables valident les transactions sur chaque table de manière série. Vous pouvez combiner des insertions, des mises à jour et des suppressions sur une table dans une transaction d'écriture unique à l'aide de MERGE INTO.

Comment Azure Databricks implémente-t-il l’atomicité ?

Le journal des transactions contrôle l’atomicité de validation. Pendant une transaction, les fichiers de données sont écrits dans le répertoire de fichiers qui sauvegarde la table. Une fois la transaction terminée, une nouvelle entrée est validée dans le journal des transactions qui inclut les chemins d’accès à tous les fichiers écrits pendant la transaction. Chaque validation incrémente la version de la table et rend les nouveaux fichiers de données visibles pour les opérations de lecture. L’état actuel de la table comprend tous les fichiers de données marqués valides dans les journaux des transactions.

Les fichiers de données ne sont pas suivis, sauf si le journal des transactions enregistre une nouvelle version. Si une transaction échoue après l’écriture de fichiers de données dans une table, ces fichiers de données ne endommagent pas l’état de la table, mais les fichiers ne font pas partie de la table. L’opération VACUUM supprime tous les fichiers de données non suivis dans un répertoire de table, y compris les fichiers non validés restants des transactions ayant échoué.

Comment Azure Databricks implémente-t-il la durabilité ?

Azure Databricks utilise le stockage d’objets cloud pour stocker l’ensemble des fichiers de données et des journaux des transactions. Le stockage d’objets cloud offre une haute disponibilité et une durabilité. Étant donné que les transactions réussissent ou échouent complètement et que le journal des transactions réside en même temps que les fichiers de données dans le stockage d’objets cloud, les tables sur Azure Databricks héritent des garanties de durabilité du stockage d’objets cloud sur lesquelles elles sont stockées.

Comment Azure Databricks implémente-t-il la cohérence ?

Delta Lake utilise le contrôle d’accès concurrentiel optimiste pour fournir des garanties transactionnelles entre les écritures. Dans le cadre de ce mécanisme, les écritures s’effectuent en trois étapes :

1. Lecture : lit (si nécessaire) la dernière version disponible de la table pour identifier les fichiers à modifier (autrement dit, réécrits).
   • Les écritures qui s'ajoutent uniquement ne lisent pas l'état actuel de la table avant d'écrire. La validation de schéma tire parti des métadonnées du journal des transactions.
2. Écriture : écrit des fichiers de données dans le répertoire utilisé pour définir la table.
3. Valider et commiter :
   • Vérifie si les modifications proposées sont en conflit avec d’autres modifications qui ont pu être validées simultanément depuis la lecture de l’instantané.
   • S’il n’y a aucun conflit, tous les changements indexés sont validés comme un nouvel instantané avec version, et l’opération d’écriture réussit.
   • En cas de conflit, l’opération d’écriture échoue avec une exception de modification simultanée. Cette défaillance empêche la corruption des données.

L'accès concurrentiel optimiste suppose que la plupart des transactions simultanées sur vos données ne devraient pas entrer en conflit les unes avec les autres, mais des conflits peuvent néanmoins se produire. Consultez Niveaux d’isolation et conflits d’écriture sur Azure Databricks.

Comment Azure Databricks implémente-t-il l’isolation ?

Azure Databricks utilise l’isolation sérialisable pour l'écriture par défaut pour toutes les opérations d'écriture et de mise à jour de table. L’isolation d’instantané est utilisée pour la lecture de toutes les tables.

La sérialisabilité des écritures et le contrôle d’accès concurrentiel optimiste sont combinés pour fournir un débit élevé pour les écritures. L’état valide actuel d’une table est toujours disponible et une écriture peut être démarrée sur une table à tout moment. Les lectures simultanées sont limitées uniquement par le débit du metastore et les ressources cloud.

Consultez Niveaux d’isolation et conflits d’écriture sur Azure Databricks.

Delta Lake prend-il en charge les transactions multi-tables ?

Delta Lake ne prend pas en charge les transactions à plusieurs tables. Delta Lake supporte les transactions au niveau de la table .

Les relations de clé primaire et de clé étrangère sur Azure Databricks sont purement informatives et ne sont pas appliquées. Consultez Déclarer des relations de clé primaire et de clé étrangère.

Que signifie le fait que Delta Lake prend en charge les écritures multiclusters ?

Delta Lake empêche l’altération des données lorsque plusieurs clusters écrivent dans la même table simultanément. Certaines opérations d’écriture peuvent entrer en conflit pendant l’exécution simultanée, mais ne endommagent pas la table. Consultez Niveaux d’isolation et conflits d’écriture sur Azure Databricks.

Puis-je modifier une table Delta à partir de différents espaces de travail ?

Oui, vous pouvez modifier simultanément la même table Delta à partir de différents espaces de travail. En outre, si un processus écrit à partir d’un espace de travail, les lecteurs dans d’autres espaces de travail voient une vue cohérente.