Opdeling af delta-tabeller

Hive-stil opdeling opdeler en Delta-tabel i fysiske undermapper baseret på værdierne af en eller flere partitionskolonner. Hver unik kombination af partitionskolonneværdier skaber en separat mappe. Dette layout muliggør beskæring af partitioner: motoren springer hele mapper over, når en forespørgsel filtreres på partitionskolonnen.

Hvornår skal man bruge partitionering

Den primære anvendelse af partitionering i Delta Lake er at muliggøre samtidige skriveoperationer, der ikke konflikter. Delta Lake bruger optimistisk samtidighedskontrol, og to operationer, der berører de samme filer, kan konflikte. Partitionering gør det muligt for samtidige operationer at målrette disjunkte sæt filer ved at operere på separate partitioner.

Brug partitionering når:

• Du har samtidige forfattere , der skal opdatere, slette eller flette ind i den samme tabel uden konflikt—for eksempel flere pipelines, der behandler forskellige forretningsenheder eller regioner samtidig.
• Din partitionskolonne har lav til moderat kardinalitet (titusinder til hundreder af forskellige værdier, ikke tusinder). Bemærk: større tabeller kan rumme flere partitioner. Mål mindst 1 GB data i hver partition.
• Partitionsværdier stemmer overens med dine skrive-mønstre—hver forfatter retter naturligt sig mod en specifik partition.

Opret en partitioneret tabel

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()

Partitionering og samtidige skrivninger

Partitionering er den primære mekanisme i Delta Lake til at undgå konflikter mellem samtidige skriveoperationer. Når en tabel er opdelt, opererer operationer, der målretter forskellige partitioner, på adskilte sæt filer og konflikter ikke med hinanden.

For eksempel konflikter to samtidige MERGE INTO operationer på en tabel opdelt med region ikke i konflikt, så længe hver måler et forskelligt område—forudsat at partitionskolonnen eksplicit er inkluderet i sammenfletningsbetingelsen:

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

Uden partitionering – eller uden at inkludere partitionkolonnen i operationsbetingelsen – kan de samme operationer konflikte, selvom de logisk ændrer forskellige rækker. Partitionskolonnen skal optræde i selve sammenfletningsbetingelsen, ikke kun i kildedataene. Uden den kan Delta Lake ikke ved valideringstidspunktet afgøre, at de to operationer berørte disjunkte filsæt.

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

Almindelige faldgruber

• Kolonner med høj kardinalitet (for eksempel user_id med millioner af værdier) skaber tusindvis af små mapper og filer, hvilket forringer både skrive- og læseydelsen.
  • Datokolonner bør vælges med forsigtighed. For mange tabeller resulterer opdeling efter datokolonne i for mange små partitioner. Mål mindst 1 GB data i hver partition.
• Partitionskolonner kan ikke ændres efter tabeloprettelsen uden at omskrive hele tabellen.
• Problemet med små filer er almindeligt ved streaming eller hyppige tilføjelser til mange partitioner, fordi hver skrivning opretter mindst én fil pr. partition.
• Partitionering og væskeklyngedannelse er inkompatible på samme tabel. Du skal vælge én strategi.

Sammenlign partitionering og væskeklyngedannelse

Relateret indhold

• Samtidighedskontrol
• Væskeklyngedannelse
• Z-orden
• Komprimering af tabel
• Filspring
• V-orden
• Vedligeholdelse af delta-tabelen