Contrôle de la simultanéité pour les tables Delta

Lorsque plusieurs blocs-notes Fabric, pipelines ou travaux Spark écrivent dans la même table Delta en même temps, Delta Lake utilise le contrôle d’accès concurrentiel optimiste (OCC) pour maintenir la cohérence de la table. Chaque transaction lit un instantané, écrit de nouveaux fichiers, puis valide qu’aucune validation en conflit n’a eu lieu entre elles. Si un conflit est détecté, la transaction échoue en générant une exception plutôt qu’en corrompant les données.

Cet article présente des modèles pratiques pour la gestion des écritures simultanées dans Fabric. Pour obtenir une spécification complète du protocole OCC, consultez le contrôle d’accès concurrentiel Delta Lake (documentation open source).

Niveaux d’isolation

Toutes les tables Delta utilisent le niveau d’isolation Serializable. Serializable est le niveau le plus strict et le seul pris en charge. Il garantit que le résultat des transactions simultanées est identique à un ordre d’exécution séquentiel.

Delta Lake utilise également un niveau SnapshotIsolation interne pour les opérations qui ne modifient pas les données logiques (par OPTIMIZEexemple). SnapshotIsolation ignore la vérification de l’ajout simultané, ce qui permet de poursuivre le compactage sans conflit avec les insertions simultanées. Vous ne configurez pas SnapshotIsolation directement : Delta Lake l’applique automatiquement, le cas échéant.

Avec l’isolation Serializable, un ajout aveugle concurrent (INSERT INTO) peut être en conflit avec un MERGE ou UPDATE qui lit la même partition.

Quelles opérations sont en conflit

Toutes les écritures simultanées n’entrent pas en conflit. Le facteur clé est de savoir si deux opérations touchent les mêmes fichiers sous-jacents.

Isoler les processus d’écriture grâce au partitionnement

La façon la plus courante d’exécuter simultanément DML sur la même table sans conflit consiste à partitionner la table par la colonne qui sépare vos enregistreurs, puis à inclure cette colonne dans chaque condition d’opération. Lorsque chaque enregistreur cible une partition différente, les opérations touchent les jeux de fichiers disjoints et ne sont pas en conflit.

Un scénario typique : plusieurs pipelines traitent chacun des données pour une unité commerciale ou un locataire différent. Partitionnez selon cette dimension et épinglez le MERGE de chaque pipeline à sa partition.

-- Each pipeline targets its own partition, so concurrent runs don't conflict
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

# Pin the merge to a single partition to avoid conflicts with other pipelines
spark.sql("""
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

// Pin the merge to a single partition to avoid conflicts with other pipelines
spark.sql("""
MERGE INTO events AS target
USING staged AS source
ON target.event_id = source.event_id
    AND target.business_unit = 'EMEA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

Pour plus d’informations sur les stratégies de partitionnement, consultez Partitionnement pour les tables Delta.

Nouvelle tentative de commit intégrée

Delta Lake retente automatiquement une validation lorsqu’elle détecte qu’une autre transaction a été validée en premier. Sur chaque nouvelle tentative, elle lit la validation gagnante, exécute le vérificateur de conflit et, si aucun conflit logique n’existe, réattempte la validation à la prochaine version disponible. Ce processus se répète de manière transparente sans aucune action de votre code.

Un conflit logique (par exemple, deux opérations réécritant le même fichier) ne peuvent pas être résolues automatiquement. La nouvelle tentative génère l’une des exceptions répertoriées dans Exceptions de conflit courantes. Toutefois, de nombreuses collisions de version transitoires — par exemple lorsque deux ajouts sans lecture préalable entrent en concurrence pour le même emplacement de version — sont résolues automatiquement et ne remontent jamais jusqu’à votre application.

Exceptions de conflit courantes

Lorsqu’un conflit est détecté, Delta Lake déclenche une exception spécifique. Comprendre l’exception que vous voyez permet d’identifier la cause racine.

Stratégies courantes pour éviter les conflits d’écriture

Activer le compactage automatique

Le compactage automatique s’exécute de manière synchrone dans le cadre des opérations d’écriture. Le compactage synchrone empêche que des tâches de compactage planifiées séparément ne se chevauchent avec des opérations de modification des données et n’entraînent ainsi des exceptions d’écriture concurrente.

Planifier la maintenance en dehors des fenêtres d’écriture

OPTIMIZE et VACUUM peut entrer en conflit avec les opérations de modification de données simultanées. Dans Fabric, planifiez des tâches de notebook ou des activités de pipeline pour le compactage des tables et VACUUM pendant les périodes de faible activité, par exemple après la fin de l’ingestion nocturne, plutôt que pendant celle-ci.

Utiliser des modèles d’ajout + fusion

Pour l’ingestion à forte concurrence, chargez les données brutes avec des écritures en ajout seul dans une table intermédiaire (aucun conflit possible), puis exécutez une seule tâche MERGE pour réconcilier les données dans la table cible. Le modèle sérialise l’opération sujette aux conflits tout en conservant l’ingestion entièrement parallèle.

Ajouter une logique de nouvelle tentative pour les conflits logiques

Le mécanisme intégré de nouvelle tentative de validation gère automatiquement les collisions de version transitoires, mais les conflits logiques — lorsque deux opérations se chevauchent réellement — provoquent une exception. Étant donné que Delta Lake ne produit jamais d’écritures partielles, une transaction ayant échoué est sécurisée pour réessayer au niveau de l’application. Pour les pipelines dans lesquels des conflits logiques ponctuels sont à prévoir, encapsulez l’opération d’écriture dans un mécanisme de nouvelle tentative :

from delta.exceptions import ConcurrentAppendException
import time

# Retry with backoff on transient concurrent write conflicts
max_retries = 3
for attempt in range(max_retries):
    try:
        spark.sql("MERGE INTO target USING source ON ...")
        break
    except ConcurrentAppendException:
        if attempt < max_retries - 1:
            time.sleep(2 ** attempt)
        else:
            raise

Choisir la stratégie de disposition appropriée

Le clustering liquide et le partitionnement résolvent différents problèmes. Le clustering liquide optimise la disposition des fichiers pour les performances de lecture. Le partitionnement crée des frontières physiques qui empêchent les conflits entre écritures concurrentes. Si votre charge de travail nécessite les deux, partitionnez les données selon la colonne d’isolation en écriture et utilisez Z-Order dans chaque partition afin d’optimiser les performances de lecture.

Contenu connexe

• Partitionnement
• Agrégation liquide
• Fusion à faible brassage
• Compactage de table
• Z-Order
• Maintenance de la table Delta
• Interopérabilité de Delta Lake
• Contrôle d’accès concurrentiel Delta Lake (documentation open source)