Concurrence au niveau des lignes

La concurrence au niveau des lignes réduit les conflits entre les opérations d’écriture simultanées en détectant les modifications au niveau des lignes et en résolvant automatiquement les conflits qui se produisent lorsque des écritures simultanées mettent à jour ou suppriment des lignes différentes dans le même fichier de données.

Exigences pour la concurrence au niveau des lignes

La concurrence au niveau des lignes est automatiquement activée lorsque toutes les conditions suivantes sont remplies :

• Utilisation de Databricks Runtime 14.3 LTS et versions ultérieures.
• La table source n’utilise pas de partitions.
• La table source a des vecteurs de suppression activés. Consultez les vecteurs de suppression dans Databricks.

Les tables partitionnée n’autorisent pas la concurrence au niveau des lignes. Toutefois, lorsque des vecteurs de suppression sont activés, les tables partitionnées peuvent toujours éviter les conflits entre OPTIMIZE et les opérations d’écriture. Consultez Limitations pour la concurrence au niveau de ligne.

Pour les versions de Databricks Runtime antérieures à 14.3 LTS, consultez le comportement hérité de la concurrence au niveau des lignes.

Matrice de conflit avec concurrence au niveau des lignes

Pour les tables sources avec accès concurrentiel au niveau des lignes, le tableau suivant montre quelles paires d’opérations d’écriture peuvent entrer en conflit dans chaque niveau d’isolation :

(1) Toutes les opérations de cette table décrivent les INSERT opérations d’ajout qui ne contiennent pas de sous-requêtes qui lisent les données de la même table. INSERT les opérations contenant des sous-requêtes qui lisent dans la même table offrent le même niveau de concurrence que MERGE.

Conflits d’écriture sans concurrence au niveau des lignes

Pour les tables sources sans concurrence au niveau des lignes, le tableau suivant indique quelles paires d’opérations d’écriture peuvent entrer en conflit dans chaque niveau d’isolation :

(1) Toutes les opérations de cette table décrivent les INSERT opérations d’ajout qui ne contiennent pas de sous-requêtes qui lisent les données de la même table. INSERT les opérations contenant des sous-requêtes qui lisent dans la même table offrent le même niveau de concurrence que MERGE.

Limitations pour la concurrence au niveau des lignes

Les limitations s’appliquent à la concurrence au niveau des lignes. Pour les opérations suivantes, la résolution des conflits suit le processus concurrentiel normal pour les conflits de synchronisation d'écriture. Consultez Conflits d'écriture sans concurrence au niveau ligne.

Toutes les limitations des vecteurs de suppression s’appliquent également. Consultez Limitations.

Éviter les conflits à l’aide du partitionnement

Pour tous les cas marqués « peut conflit » dans les matrices de conflit, un conflit se produit uniquement si les deux opérations affectent le même ensemble de fichiers. Pour rendre disjoints deux ensembles de fichiers, partitionnez la table avec les mêmes colonnes utilisées dans les conditions d'opération.

Exemple :

Les commandes UPDATE table WHERE date > '2010-01-01' ... et DELETE table WHERE date < '2010-01-01' sont en conflit si la table n’est pas partitionnée par date, puisque les deux peuvent tenter de modifier les mêmes fichiers. Le partitionnement de la table par date permet d'éviter le conflit.

Éviter les conflits avec les filtres de partition explicites

Cette exception est souvent déclenchée lors d’opérations simultanées DELETE, UPDATE ou MERGE susceptibles de lire la même partition, même lorsqu’elles mettent à jour des partitions différentes. Rendez la séparation explicite dans la condition d’opération :

// Problem: Condition can scan the entire table
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

// Solution: Add explicit partition filters
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country AND t.date = '" + date + "' AND t.country = '" + country + "'")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

Exceptions de conflit

Lorsqu’un conflit de transaction se produit, vous observez l’une des exceptions suivantes :

Exception d'ajout simultané (ConcurrentAppendException)

Cette exception se produit lorsqu’une opération simultanée ajoute des fichiers dans la même partition (ou n’importe où dans une table non partitionnée) que celle que votre opération lit. Les ajouts de fichiers peuvent être causés par des opérations INSERT, DELETE, UPDATE ou MERGE.

Avec le niveau d’isolation WriteSerializable par défaut, les fichiers ajoutés par les opérations INSERT qui ajoutent des données sans en lire n’entrent en conflit avec aucune opération. Si le niveau d’isolation est sérialisable, les opérations d’ajout peuvent entrer en conflit.

ConcurrentDeleteReadException

Cette exception se produit lorsqu’une opération simultanée supprime un fichier lu par votre opération. Les causes courantes sont DELETE, UPDATEou MERGE les opérations qui réécrire des fichiers.

ConcurrentDeleteDeleteException

Cette exception se produit lorsqu’une opération simultanée supprime un fichier que votre opération supprime également. Cela peut être dû au fait que deux opérations de compression simultanées réécrivent les mêmes fichiers.

MetadataChangedException

Cette exception se produit lorsqu’une transaction simultanée met à jour les métadonnées d’une table Delta. Les causes courantes sont ALTER TABLE des opérations ou des écritures qui mettent à jour le schéma de table.

ConcurrentTransactionException

Cette exception se produit si une requête de streaming utilisant le même emplacement de point de contrôle est démarrée plusieurs fois simultanément et tente d’écrire dans la table Delta en même temps. N’exécutez jamais deux requêtes de streaming avec le même emplacement de point de contrôle simultanément.

ProtocolChangedException (Exception de changement de protocole)

Cette exception peut se produire lorsque :

• Votre table Delta Lake est mise à niveau vers une nouvelle version de protocole (vous devrez peut-être mettre à niveau votre Databricks Runtime)
• Plusieurs rédacteurs créent ou remplacent une table en même temps
• Plusieurs écrivains écrivent dans un chemin vide en même temps

Consultez les protocoles et la compatibilité des fonctionnalités Delta Lake.

Comportement hérité de la concurrence au niveau des lignes

Dans Databricks Runtime 13.3 LTS, la concurrence au niveau des lignes utilise le comportement hérité :

• Nécessite des vecteurs de suppression. Consultez les vecteurs de suppression dans Databricks.
• Les tables avec clustering liquide activent automatiquement la concurrence au niveau des lignes.

Ressources supplémentaires

• Niveaux d’isolation (WriteSerializable et Serializable)
• Transactions
• Vecteurs de suppression dans Databricks
• Compatibilité et protocoles des fonctionnalités Delta Lake