Partizionamento per le tabelle Delta

Il partizionamento in stile Hive divide una tabella Delta in sottodirectory fisiche in base ai valori di una o più colonne di partizione. Ogni combinazione univoca di valori di colonna di partizione crea una directory separata. Questo layout consente la potatura delle partizioni: il motore salta intere directory quando una query applica un filtro alla colonna di partizione.

Quando usare il partizionamento

Il caso d'uso principale per il partizionamento in Delta Lake consiste nell'abilitare operazioni di scrittura simultanee che non sono in conflitto. Delta Lake usa il controllo della concorrenza ottimistica e due operazioni che toccano gli stessi file possono essere in conflitto. Il partizionamento rende possibile che le operazioni simultanee facciano riferimento a set di file non contigui operando su partizioni separate.

Usare il partizionamento quando:

• Ci sono writer concorrenti che devono aggiornare, eliminare o eseguire il merge nella stessa tabella senza entrare in conflitto, ad esempio più pipeline che elaborano simultaneamente unità aziendali o aree geografiche diverse.
• La colonna della partizione ha una cardinalità da bassa a moderata (decine a centinaia di valori distinti, non migliaia). Nota: le tabelle più grandi possono contenere più partizioni. Specificare almeno 1 GB di dati in ogni partizione.
• I valori delle partizioni sono allineati ai tuoi schemi di scrittura: ogni writer punta naturalmente a una partizione specifica.

Creare una tabella partizionata

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

Partizionamento e scritture simultanee

Il partizionamento è il meccanismo principale in Delta Lake per evitare conflitti tra le operazioni di scrittura simultanee. Quando una tabella è partizionata, le operazioni destinate a partizioni diverse operano su set di file non contigui e non sono in conflitto tra loro.

Ad esempio, due operazioni simultanee MERGE INTO su una tabella partizionata da region non sono in conflitto, purché ogni destinazione sia un'area diversa, purché la colonna di partizione sia inclusa in modo esplicito nella condizione di merge:

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

Senza partizionamento, o senza includere la colonna di partizione nella condizione dell'operazione, queste stesse operazioni potrebbero entrare in conflitto anche se modificano logicamente righe diverse. La colonna di partizione deve essere visualizzata nella condizione di unione stessa, non solo nei dati di origine. Senza di esso, Delta Lake non è in grado di determinare in fase di convalida che le due operazioni hanno toccato set di file non contigui.

Per una guida completa ai tipi di conflitto e alle strategie di risoluzione, vedere Controllo della concorrenza.

Insidie comuni

• Le colonne di partizione con cardinalità elevata(ad esempio, user_id con milioni di valori) creano migliaia di piccole directory e file, con prestazioni di scrittura e lettura ridotte.
  • Le colonne di data devono essere scelte con cautela. Per molte tabelle, il partizionamento in base a una colonna di data comporta un numero eccessivo di partizioni di piccole dimensioni. Specificare almeno 1 GB di dati in ogni partizione.
• Le colonne di partizione non possono essere modificate dopo la creazione della tabella senza riscrivere l'intera tabella.
• Un problema di file di piccole dimensioni è comune con lo streaming o le accodamenti frequenti in molte partizioni, perché ogni scrittura crea almeno un file per partizione.
• Il partizionamento e il clustering liquido non sono compatibili nella stessa tabella. È necessario scegliere una strategia.

Confrontare il partizionamento e il clustering liquido

Contenuti correlati

• Controllo della concorrenza
• Clustering liquido
• Ordine Z
• La compattazione della tabella
• Esclusione dei file
• V-Order
• Manutenzione delle tabelle Delta