Partisjonering for delta-tabeller

Hive-stil partisjonering deler en Delta-tabell inn i fysiske undermapper basert på verdiene til én eller flere partisjonskolonner. Hver unik kombinasjon av partisjonskolonneverdier lager en egen katalog. Dette oppsettet muliggjør partisjonsbeskjæring: motoren hopper over hele kataloger når en spørring filtreres på partisjonskolonnen.

Når man skal bruke partisjonering

Hovedbruksområdet for partisjonering i Delta Lake er å muliggjøre samtidige skriveoperasjoner som ikke kolliderer. Delta Lake bruker optimistisk samtidighetskontroll, og to operasjoner som berører de samme filene kan komme i konflikt. Partisjonering gjør det mulig for samtidige operasjoner å målrette disjunkte sett av filer ved å operere på separate partisjoner.

Bruk partisjonering når:

• Du har samtidige skrivere som må oppdatere, slette eller slå sammen i samme tabell uten konflikt—for eksempel flere pipelines som behandler ulike forretningsenheter eller regioner samtidig.
• Partisjonskolonnen din har lav til moderat kardinalitet (titalls til hundrevis av distinkte verdier, ikke tusenvis). Merk: større tabeller kan romme flere partisjoner. Sikt på minst 1 GB data i hver partisjon.
• Partisjonsverdier samsvarer med skrivemønstrene dine—hver skriver retter seg naturlig mot en spesifikk partisjon.

Lag en partisjonert tabell

CREATE TABLE sales.orders (
    order_id BIGINT,
    order_date DATE,
    region STRING,
    amount DECIMAL(10,2)
)
USING DELTA
PARTITIONED BY (region)

from delta.tables import DeltaTable

DeltaTable.create(spark) \
    .tableName("sales.orders") \
    .addColumn("order_id", "BIGINT") \
    .addColumn("order_date", "DATE") \
    .addColumn("region", "STRING") \
    .addColumn("amount", "DECIMAL(10,2)") \
    .partitionedBy("region") \
    .execute()

import io.delta.tables.DeltaTable

DeltaTable.create(spark)
    .tableName("sales.orders")
    .addColumn("order_id", "BIGINT")
    .addColumn("order_date", "DATE")
    .addColumn("region", "STRING")
    .addColumn("amount", "DECIMAL(10,2)")
    .partitionedBy("region")
    .execute()

Partisjonering og samtidige skrivinger

Partisjonering er hovedmekanismen i Delta Lake for å unngå konflikter mellom samtidige skriveoperasjoner. Når en tabell er partisjonert, opererer operasjoner som retter seg mot ulike partisjoner på disjunkte sett av filer og kolliderer ikke med hverandre.

For eksempel konflikter ikke to samtidige MERGE INTO operasjoner på en tabell delt av region så lenge hver retter seg mot et annet område—forutsatt at partisjonskolonnen eksplisitt er inkludert i sammenslåingsbetingelsen:

-- Pipeline A: processes North America only
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

spark.sql("""
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

spark.sql("""
MERGE INTO sales.orders AS target
USING staged_orders AS source
ON target.order_id = source.order_id
    AND target.region = 'NA'
    AND source.region = 'NA'
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *
""")

Uten partisjonering—eller uten å inkludere partisjonskolonnen i operasjonsbetingelsen—kan de samme operasjonene komme i konflikt selv om de logisk endrer forskjellige rader. Partisjonskolonnen må vises i selve sammenslåingsbetingelsen, ikke bare i kildedataene. Uten den kan ikke Delta Lake ved validering fastslå at de to operasjonene berørte disjunkte filsett.

For en komplett guide til konflikttyper og løsningsstrategier, se Concurrency control.

Vanlige fallgruver

• Kolonner med høy kardinalitetspartisjon (for eksempel user_id med millioner av verdier) skaper tusenvis av små mapper og filer, noe som forringer både skrive- og leseytelsen.
  • Datokolonner bør velges med forsiktighet. For mange tabeller resulterer partisjonering etter datokolonne i for mange små partisjoner. Sikt på minst 1 GB data i hver partisjon.
• Partisjonskolonner kan ikke endres etter tabellopprettelse uten å skrive hele tabellen på nytt.
• Problemet med små filer er vanlig ved strømming eller hyppige tillegg i mange partisjoner, fordi hver skriving lager minst én fil per partisjon.
• Partisjonering og væskeklynging er inkompatible på samme bord. Du må velge én strategi.

Sammenlign partisjonering og væskeklynging

Relatert innhold

• Samtidighetskontroll
• Væskeklynging
• Z-orden
• Komprimering av tabell
• Filhopp
• V-orden
• Vedlikehold av delta-bord