Samtidighetskontroll for delta-tabeller

Når flere Fabric-notatbøker, pipelines eller Spark-jobber skriver til samme Delta-tabell samtidig, bruker Delta Lake optimistisk samtidighetskontroll (OCC) for å holde tabellen konsistent. Hver transaksjon leser et øyeblikksbilde, skriver nye filer, og validerer deretter at ingen konfliktfylt commit har skjedd imellom. Hvis en konflikt oppdages, mislykkes transaksjonen med et unntak i stedet for å korrumpere data.

Denne artikkelen dekker praktiske mønstre for å håndtere samtidige skrivinger i Fabric. For en fullstendig spesifikasjon av OCC-protokollen, se Delta Lake samtidighetskontroll (åpen kildekode-dokumentasjon).

Isolasjonsnivåer

Alle Delta-tabeller bruker det serialiserbare isolasjonsnivået. Serializable er det strengeste nivået og det eneste som støttes. Den sikrer at resultatet av samtidige transaksjoner er identisk med en sekvensiell utførelsesrekkefølge.

Delta Lake bruker også et internt SnapshotIsolation-nivå for operasjoner som ikke endrer logiske data (som OPTIMIZE). SnapshotIsolation hopper over sjekken av samtidige appender, slik at komprimering kan fortsette uten å kollidere med samtidige innsettinger. Du konfigurerer ikke SnapshotIsolation direkte – Delta Lake bruker det automatisk når det er hensiktsmessig.

Med Serializable isolasjon kan et samtidig blindt tillegg (INSERT INTO) komme i konflikt med a MERGE eller UPDATE som leser samme partisjon.

Hvilke operasjoner er konflikt

Ikke alle samtidige skrivinger er i konflikt. Den viktigste faktoren er om to operasjoner berører de samme underliggende filene.

Isoler skribenter med partisjonering

Den vanligste måten å kjøre samtidig DML mot samme tabell uten konflikter på, er å dele tabellen etter kolonnen som skiller forfatterne dine, og deretter inkludere den kolonnen i hver operasjonsbetingelse. Når hver forfatter retter seg mot en forskjellig partisjon, berører operasjonene disjunkte filsett og kommer ikke i konflikt.

Et typisk scenario: flere pipelines behandler hver data for en annen forretningsenhet eller leietaker. Partisjoner etter den dimensjonen og fest hver rørledning MERGE til sin partisjon.

-- 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 *
""")

For mer detaljer om partisjoneringsstrategier, se Partitionering for Delta-tabeller.

Innebygd commit retry

Delta Lake prøver automatisk en commit på nytt når den oppdager at en annen transaksjon er gjort først. Ved hvert forsøk leser den vinnende commit, kjører konfliktsjekkeren, og – hvis det ikke finnes noen logisk konflikt – prøver den commit på nytt ved neste tilgjengelige versjon. Denne prosessen gjentas transparent uten noen handling fra koden din.

En logisk konflikt (for eksempel to operasjoner som skriver om samme fil) kan ikke løses automatisk. Gjenprøvingen reiser ett av unntakene listet i Common conflict-unntakene. Mange kollisjoner med forbigående versjoner – som to blinde tillegg som konkurrerer om samme versjonsplass – løses imidlertid automatisk og vises aldri i applikasjonen din.

Vanlige unntak for konflikt

Når en konflikt oppdages, oppretter Delta Lake et spesifikt unntak. Å forstå hvilket unntak du ser hjelper deg å identifisere den egentlige årsaken.

Vanlige strategier for å unngå skrivekonflikter

Aktiver automatisk komprimering

Automatisk komprimering kjører synkront som en del av skriveoperasjoner. Synkron komprimering forhindrer at separat planlagte komprimeringsjobber overlapper med dataendringsoperasjoner og dermed forårsaker samtidige skriverunntak.

Planlegg vedlikehold utenfor skrivevinduer

OPTIMIZE og VACUUM kan komme i konflikt med samtidige dataendringsoperasjoner. I Fabric, planlegg notatbokjobber eller pipeline-aktiviteter for tabellkompaktering og VACUUM under lavaktivitetsvinduer – for eksempel etter at nattlig inntak er fullført, ikke underveis.

Bruk append + merge-mønstre

For høy-samtidig-inntak, land rådata med kun append-skriving inn i en staging-tabell (ingen konflikter mulig), og kjør deretter en enkelt MERGE jobb for å avstemme til måltabellen. Mønsteret serialiserer den konfliktutsatte operasjonen samtidig som inntaket holdes helt parallelt.

Legg til retry-logikk for logiske konflikter

Den innebygde commit retry håndterer transiente versjonskollisjoner automatisk, men logiske konflikter – der to operasjoner faktisk overlapper hverandre – utløser et unntak. Fordi Delta Lake aldri produserer delvise skrivinger, er en mislykket transaksjon trygg å prøve på nytt på applikasjonsnivå. For pipelines hvor det er forventet sporadiske logiske konflikter, pakk inn skrivelogikken i retry:

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

Velg riktig layoutstrategi

Væskeklynging og partisjonering løser ulike problemer. Liquid clustering optimaliserer filoppsettet for leseytelse. Oppdeling skaper fysiske grenser som forhindrer samtidige konflikter mellom forfattere. Hvis arbeidsmengden din trenger begge deler, partisjoner du etter writer-isolation-kolonnen og bruker Z-Order innenfor hver partisjon for leseytelse.

Relatert innhold

• Partisjonering
• Væskeklynging
• Low-Shuffle Sammenslåing
• Komprimering av tabell
• Z-orden
• Vedlikehold av delta-bord
• Delta Lake-interoperabilitet
• Delta Lake samtidighetskontroll (åpen kildekode-dokumentasjon)