Partager via

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

Les tables ne prennent pas en charge la concurrence au niveau des lignes si elles ont des partitions définies ou n’ont pas de vecteurs de suppression activés. La concurrence au niveau des lignes nécessite Databricks Runtime 14.2 et versions ultérieures.

Les tables avec partitions ne prennent pas en charge la concurrence au niveau des lignes, mais peuvent toujours éviter les conflits entre OPTIMIZE et toutes les autres opérations d’écriture lorsque les vecteurs de suppression sont activés. Consultez Limitations pour la concurrence au niveau de ligne.

Pour les versions de Databricks Runtime antérieures à la version 14.2, consultez le comportement d’aperçu de la concurrence au niveau des lignes (hérité).

Note

La prise en charge de MERGE INTO pour la concurrence au niveau des lignes nécessite Photon dans Databricks Runtime 14.2. Photon n’est pas nécessaire dans Databricks Runtime 14.3 LTS et les versions ultérieures.

Matrice de conflit avec 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 avec la concurrence au niveau des lignes activée :

INSERT (1) UPDATESUPPRIMER MERGE INTO OPTIMIZE
INSERT Ne peut pas entrer en conflit
UPDATESUPPRIMER MERGE INTO Conflit impossible avec WriteSerializable. Conflit possible en mode Serializable lors de la modification de la même ligne. Peut entrer en conflit lors de la modification de la même ligne.
OPTIMIZE Ne peut pas entrer en conflit Peut entrer en conflit lorsque vous utilisez ZORDER BY. Ne peut pas entrer en conflit dans le cas contraire. Peut entrer en conflit lorsque vous utilisez ZORDER BY. Ne peut pas entrer en conflit dans le cas contraire.

(1) Toutes les opérations de cette table décrivent les INSERT opérations d’ajout qui ne lisent aucune donnée de la même table avant la validation. Les opérations INSERT qui contiennent des sous-requêtes lisant la même table prennent en charge la même concurrence que MERGE.

Note

  • Les tables avec colonnes d’identité ne prennent pas en charge les transactions simultanées. Consultez Utiliser des colonnes d’identité dans Delta Lake.
  • REORG les opérations ont une sémantique d’isolation identique à OPTIMIZE lors de la réécriture des fichiers de données. Lorsque vous utilisez REORG pour appliquer une mise à niveau, les protocoles de table changent, ce qui crée un conflit avec toutes les opérations en cours.

Conflits d’écriture sans concurrence au niveau des lignes

Les tables ne prennent pas en charge l’accès concurrentiel au niveau des lignes si elles ont des partitions définies et n’ont aucun vecteur de suppression activé. Databricks Runtime 14.2 ou au-delà est requise pour l'accès simultané au niveau des lignes.

Matrice de conflit 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 :

INSERT (1) UPDATESUPPRIMER MERGE INTO OPTIMIZE
INSERT Ne peut pas entrer en conflit
UPDATESUPPRIMER MERGE INTO Conflit impossible avec WriteSerializable. Peut entrer en conflit avec Serializable. Consultez Éviter les conflits à l’aide du partitionnement. Conflit possible dans Serializable et WriteSerializable. Consultez Éviter les conflits à l’aide du partitionnement.
OPTIMIZE Ne peut pas entrer en conflit Impossible d'entrer en conflit dans les tables avec des vecteurs de suppression activés, à moins que ZORDER BY ne soit utilisé. Un conflit pourrait sinon survenir. Impossible d'entrer en conflit dans les tables avec des vecteurs de suppression activés, à moins que ZORDER BY soit utilisé. Un conflit pourrait sinon survenir.

(1) Toutes les opérations de cette table décrivent les INSERT opérations d’ajout qui ne lisent aucune donnée de la même table avant la validation. Les opérations INSERT qui contiennent des sous-requêtes lisant la même table prennent en charge la même concurrence que MERGE.

Note

  • Les tables avec colonnes d’identité ne prennent pas en charge les transactions simultanées. Consultez Utiliser des colonnes d’identité dans Delta Lake.
  • REORG les opérations ont une sémantique d’isolation identique à OPTIMIZE lors de la réécriture des fichiers de données. Lorsque vous utilisez REORG pour appliquer une mise à niveau, les protocoles de table changent, ce qui crée un conflit avec toutes les opérations en cours.

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.

Limitation Description
Clauses conditionnelles complexes Conditions sur les types de données complexes (structs, tableaux, cartes), expressions non déterministes, sous-requêtes et sous-requêtes corrélées
MERGE exigence de prédicat Dans Databricks Runtime 14.2, MERGE les commandes doivent utiliser un prédicat explicite sur la table cible pour filtrer les lignes correspondant à la table source
Compromis de performance La détection des conflits au niveau des lignes peut augmenter le temps d’exécution total. Avec de nombreuses transactions simultanées, le processeur privilégie la latence par rapport à la résolution des conflits.

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.

Note

Le partitionnement d’une table par une colonne avec une cardinalité élevée peut entraîner des problèmes de performances en raison du grand nombre de sous-répertoires.

Exemple : Éviter les conflits avec les filtres de partition explicites

Cette exception est souvent levée pendant les opérations simultanées DELETE, UPDATEou MERGE qui peuvent lire la même partition même lors de la mise à jour de différentes partitions. 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 des opérations aveugles INSERT (opérations qui ajoutent des données sans lire de données) ne sont pas en conflit avec une opération. Si le niveau d’isolation est Serializable, des insertions aveugles peuvent entrer en conflit.

Important

Les ajouts aveugles peuvent entrer en conflit en mode WriteSerializable si plusieurs opérations simultanées DELETE, UPDATE ou MERGE peuvent référencer des valeurs insérées par des ajouts aveugles. Pour éviter cela :

  • Veillez à ce que les opérations simultanées DELETE, UPDATE, ou MERGE ne lisent pas les données ajoutées
  • Avoir au plus un DELETE, UPDATEou MERGE opération qui peut lire les données ajoutées

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 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 de prévisualisation de la concurrence au niveau des lignes (hérité)

Cette section décrit des comportements de préversion pour l’accès concurrentiel au niveau des lignes dans Databricks Runtime 14.1 et versions ultérieures.

Version de Databricks Runtime Comportement
Databricks Runtime 13.3 LTS et versions ultérieures Les tables avec le « liquid clustering » activent automatiquement la concurrence au niveau des lignes
Databricks Runtime 14.0 et 14.1 Activer la concurrence au niveau des lignes pour les tables avec des vecteurs de suppression à l’aide de la configuration ci-dessous
Databricks Runtime 14.1 et versions ultérieures Le calcul non Photon prend en charge uniquement la concurrence au niveau des lignes pour les opérations DELETE

Pour activer la concurrence au niveau des lignes dans Databricks Runtime 14.0 et 14.1 :

spark.databricks.delta.rowLevelConcurrencyPreview = true

L’accès concurrentiel au niveau des lignes nécessite toujours des vecteurs de suppression.

Étapes suivantes

  • Last updated on