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 concurrence au niveau des lignes, le tableau suivant montre comment chaque paire d’opérations d’écriture concurrentes se comporte à chaque niveau d’isolement.

Les modifications concurrentes des métadonnées sont une exception à chaque résultat du tableau. Un changement de métadonnées, tel qu’une ALTER TABLE commande ou une écriture qui met à jour le schéma de la table, peut provoquer l’échec de toutes les opérations d’écriture simultanées, y compris INSERT. Voir Conflits de changements de métadonnées.

(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. Les opérations INSERT contenant des sous-requêtes qui lisent la même table prennent en charge 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 montre comment chaque paire d’opérations d’écriture concurrentes se comporte à chaque niveau d’isolement.

Les modifications concurrentes des métadonnées sont une exception à chaque résultat du tableau. Un changement de métadonnées, tel qu’une ALTER TABLE commande ou une écriture qui met à jour le schéma de la table, peut provoquer l’échec de toutes les opérations d’écriture simultanées, y compris INSERT. Voir Conflits de changements de métadonnées.

(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. Les opérations INSERT contenant des sous-requêtes qui lisent la même table prennent en charge 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 comportement standard des conflits d’écriture. Consultez Conflits d’écriture sans concurrence au niveau des lignes.

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 concurrente met à jour les métadonnées d’une table Delta Lake. Les causes courantes incluent des opérations ALTER TABLE ou des écritures qui modifient le schéma de la table.

ConcurrentTransactionException

Cette exception se produit si une requête en streaming utilisant le même point de contrôle est lancée plusieurs fois simultanément et tente d’écrire simultanément sur la table Delta Lake. 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 enregistreurs créent ou remplacent une table au même moment
• Plusieurs enregistreurs écrivent en même temps dans un chemin d’accès vide

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