Quelles sont les garanties ACID sur Databricks ?

Databricks utilise Delta Lake par default pour toutes les lectures et écritures et s'appuie sur les garanties ACID fournies par le protocole open source Delta Lake. L'acronyme ACID désigne l'atomicité, la cohérence, l'isolement et la durabilité.

• L’atomicité signifie que toutes les transactions réussissent ou échouent complètement.
• Les garanties de cohérence se rapportent à la manière dont un état donné des données est observé par des opérations simultanées.
• L'isolement fait référence à la façon dont les Opérations simultanées peuvent potentiellement entrer en conflit les unes avec les autres.
• La durabilité signifie que les modifications validées sont permanentes.

Alors que de nombreuses technologies de traitement et d’entreposage des données décrivent la présence de Transactions ACID, les garanties spécifiques varient selon les systèmes, et les transactions sur Databricks peuvent différer d’autres systèmes avec lesquels vous avez travaillé.

remarque

Cette page décrit les garanties pour les tables reposant sur Delta Lake. D’autres formats de données et systèmes intégrés pourraient ne pas offrir de garanties transactionnelles pour les lectures et les écritures.

Toutes les écritures Databricks dans le stockage d'objets cloud utilisent des commits transactionnels, qui créent des fichiers de métadonnées commençant par _started_<id> et _committed_<id> à côté des fichiers de données. Vous n'avez pas besoin d'interagir avec ces fichiers, car Databricks nettoie régulièrement les fichiers de métadonnées de commit obsolètes.

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

Par défaut, chaque instruction SQL s'exécute comme sa propre transaction atomique sur une seule table. Vous pouvez également regrouper plusieurs instructions sur plusieurs tables en une seule transaction atomique à l'aide de la syntaxe BEGIN ATOMIC ... END;. Toutes les modifications réussissent ou sont annulées simultanément. Les transactions qui s'étendent sur plusieurs tables nécessitent des catalog commits activées sur les tables participantes. Voir Transactions.

Pour gérer les transactions concurrentes, 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 d'une table, et qu'un interblocage n'est pas possible.

By default, Databricks provides snapshot isolation on reads and write-serializable isolation on writes. Bien que l'isolement sérialisable en écriture offre des garanties plus solides que l'isolement d'instantané, ces protections s'appliquent uniquement aux opérations d'écriture.

Les Opérations de lecture référençant plusieurs tables renvoient la version actuelle de chaque table au moment de l'accès, mais n'interrompent pas les transactions concurrentes qui pourraient modifier les tables référencées.

Comment Databricks implémente-t-il l'atomicité ?

Le log de transactions contrôle l'atomicité des commits. Pendant une transaction, les fichiers de données sont écrits dans le répertoire de fichiers qui soutient la table. Une fois la transaction terminée, une nouvelle entrée est commitée dans le log de transactions, qui inclut les chemins d'accès à tous les fichiers écrits pendant la transaction. Chaque commit 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 logs de transactions.

Les fichiers de données ne sont pas suivis à moins que le Logs des transactions n'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 corrompront pas l'état de la table, mais les fichiers ne feront 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 issus des transactions échouées.

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

Databricks utilise le stockage d'objets cloud pour stocker tous les fichiers de données et les logs de transaction. Le stockage d'objets cloud offre une haute disponibilité et une grande durabilité. Étant donné que les transactions réussissent ou échouent complètement et que le log de transaction réside à côté des fichiers de données dans le stockage d'objets cloud, les tables sur Databricks héritent des garanties de durabilité du stockage d'objets cloud sur lequel elles sont stockées.

Comment Databricks met-il en œuvre la cohérence ?

Delta Lake utilise le contrôle de concurrence optimiste pour fournir des garanties transactionnelles entre les écritures. Selon 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 (c’est-à-dire, à réécrire).

   • Les écritures en mode ajout uniquement ne lisent pas l'état actuel de la table avant l'écriture. La validation du schéma exploite les métadonnées du Logs de transactions.

2. Écriture : Écrit les fichiers de données dans le répertoire utilisé pour définir la table.

3. Valider et commit :

   • Vérifie si les modifications proposées entrent en conflit avec d'autres modifications qui auraient pu être validées concurremment depuis l'instantané lu.
   • S'il n'y a pas de conflits, toutes les modifications intermédiaires sont validées comme un nouveau snapshot versionné, et l'opération d'écriture réussit.
   • S'il y a des conflits, l'opération d'écriture échoue avec une exception de modification concurrente. Cette défaillance empêche la corruption des données.

La simultanéité optimiste suppose que la plupart des transactions concurrentes sur vos données ne pourraient pas entrer en conflit les unes avec les autres, mais des conflits peuvent survenir. Voir Niveaux d'isolement et conflits d'écriture.

Comment Databricks met-il en œuvre l’isolation ?

Databricks utilise l'isolation sérialisable en écriture default pour toutes les écritures et mises à jour de table. La prise d'instantanés est utilisée pour toutes les lectures de table.

La sérialisabilité des écritures et le contrôle d'accès concurrentiel optimiste fonctionnent de concert pour offrir un haut throughput pour les écritures. L'état valide actuel d'une table est toujours disponible, et une écriture peut être start sur une table à tout moment. Les lectures simultanées sont uniquement limitées par le throughput du métastore et les ressources cloud.

Voir Niveaux d'isolation et conflits d'écriture.

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

info

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.

Oui. Les tables pour lesquelles les commits du catalogue sont activés peuvent participer à des transactions couvrant plusieurs instructions et plusieurs tables. Voir Transactions.

Les relations de clé primaire et de clé étrangère sur Databricks sont informatives et non appliquées. Consultez Déclarer les contraintes de clé primaire, de clé étrangère et d'unicité.

Que signifie le fait que Delta Lake prenne en charge les écritures multi-clusters ?

Delta Lake empêche la corruption des données lorsque plusieurs clusters écrivent simultanément dans la même table. Certaines opérations d'écriture peuvent entrer en conflit lors d'une exécution simultanée, mais elles n'endommagent pas la table. Consultez Niveaux d'isolation et conflits d'écriture.

remarque

Delta Lake sur S3 présente plusieurs limites que l'on ne retrouve pas sur d'autres systèmes de stockage. Consultez les limites de Delta Lake sur S3.