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 d’entrepôt de données disposent de transactions ACID, les garanties spécifiques varient selon le système. Les transactions sur Azure Databricks peuvent différer des autres systèmes que vous avez utilisés.

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’aucun verrou n’est appliqué pour la lecture ni l’écriture sur une table, et que l’interblocage n’est pas possible.

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 elles 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 dans chaque table en série. Vous pouvez combiner des insertions, des mises à jour et des suppressions sur une table en 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 contient 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 comme 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 corrompent pas l’état de la table, mais les fichiers ne sont pas inclus dans la table. L’opération VACUUM supprime tous les fichiers de données non suivis dans un répertoire de table, notamment les fichiers non validés restants de transactions non réussies.

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 se trouve avec des 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 dans lequel 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 qui doivent être modifiés (c’est-à-dire réécrits).
   • Les écritures qui sont en ajout uniquement ne lisent pas l’état actuel de la table avant l’écriture. La validation du schéma tire profit 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.

La concurrence optimiste suppose que la plupart des transactions simultanées sur vos données ne peuvent pas entrer en conflit, mais que des conflits sont possibles. 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 en écriture par défaut pour toutes les écritures et mises à jour des tables. L’isolation de capture instantanée est utilisée pour toutes les lectures de table.

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 multitables ?

Delta Lake ne prend pas en charge les transactions multitables. Delta Lake prend en charge 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 quand plusieurs clusters écrivent simultanément dans la même table. Certaines opérations d’écriture peuvent entrer en conflit pendant l’exécution simultanée, mais elles n’endommagent pas la table. Consultez Niveaux d’isolation et conflits d’écriture sur Azure Databricks.

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

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.