Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les niveaux d’isolation et le comportement de conflit d’écriture déterminent ce qui se passe lorsque des opérations concurrentes lisent et écrivent la même table Delta Lake sur Azure Databricks.
Lorsque plusieurs jobs ou utilisateurs écrivent sur la même table en même temps, certaines de ces écritures peuvent échouer avec une exception de conflit. Utilisez les pages de cette section pour :
- Résoudre ou réduire les défaillances dues aux écritures concurrentes, telles que
ConcurrentAppendException. Voir exceptions de conflit. - Déterminez si une table nécessite un niveau d’isolation supérieur à celui par défaut. Consultez les niveaux d’isolation (WriteSerializable et Serializable).
Delta Lake garantit les transactions ACID entre lectures et écritures :
- Enregistreurs : plusieurs enregistreurs sur plusieurs clusters peuvent modifier simultanément une partition de table. Les auteurs voient une vue instantanée cohérente de la table et les opérations d’écriture sont effectuées dans un ordre séquentiel.
- Lecteurs : Les lecteurs continuent de voir une vue d’instantané cohérente de la table avec laquelle le travail Azure Databricks a démarré, même lorsqu’une table est modifiée pendant un travail.
Consultez En quoi consistent les garanties ACID sur Azure Databricks ?.
Note
Azure Databricks utilise Delta Lake pour toutes les tables par défaut.
Sujets d’isolation
| Sujet | Description |
|---|---|
| Niveaux d’isolation (WriteSerializable et Serializable) | Comment les deux niveaux d’isolation affectent les opérations simultanées et comment les configurer. |
| Concurrence au niveau des lignes | La façon dont la détection des conflits au niveau des lignes réduit les conflits d’écriture pour les opérations simultanées sur les mêmes fichiers de données. |
Pour plus d’informations sur l’isolation des transactions, le comportement d’instantané et la gestion des conflits, consultez l’isolation des transactions.
Conflits de changements de métadonnées
Les modifications des métadonnées peuvent entraîner l’échec de toutes les opérations d’écriture simultanées. Ces opérations comprennent la modification du protocole de la table, des propriétés de la table ou du schéma de données.
Les lectures en flux échouent lorsqu’elles rencontrent un commit qui modifie les métadonnées d’une table. Si vous souhaitez que le flux continue, vous devez le redémarrer. Pour connaître les méthodes recommandées, consultez Considérations relatives à la production pour Structured Streaming.
Exemples de requêtes modifiant les métadonnées :
-- Set a table property
ALTER TABLE table_name SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')
-- Enable a feature using a table property and update the table protocol
ALTER TABLE table_name SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);
-- Drop a table feature
ALTER TABLE table_name DROP FEATURE deletionVectors;
-- Upgrade to UniForm
REORG TABLE table_name APPLY (UPGRADE UNIFORM(ICEBERG_COMPAT_VERSION=2));
-- Update the table schema
ALTER TABLE table_name ADD COLUMNS (col_name STRING);