Partycjonowanie tabel Delta

Partycjonowanie w stylu Hive dzieli tabelę Delta na fizyczne podkatalogi na podstawie wartości jednej lub większej liczby kolumn partycji. Każda unikatowa kombinacja wartości kolumn partycji tworzy oddzielny katalog. Ten układ umożliwia oczyszczanie partycji: aparat pomija całe katalogi, gdy zapytanie filtruje kolumnę partycji.

Kiedy należy używać partycjonowania

Podstawowy przypadek użycia partycjonowania w usłudze Delta Lake polega na włączeniu współbieżnych operacji zapisu, które nie powodują konfliktu. Usługa Delta Lake używa optymistycznej kontrolki współbieżności, a dwie operacje, które dotykają tych samych plików, mogą powodować konflikt. Partycjonowanie umożliwia wykonywanie współbieżnych operacji na zestawach rozłącznych plików przez działanie na oddzielnych partycjach.

Stosuj partycjonowanie, gdy:

• Masz współbieżne procesy zapisu, które muszą aktualizować, usuwać lub scalać dane w tej samej tabeli bez powodowania konfliktów — na przykład wiele potoków przetwarzających jednocześnie różne jednostki biznesowe lub regiony.
• Kolumna partycji ma niską lub umiarkowaną kardynalność (dziesiątki do setek odrębnych wartości, a nie tysięcy). Uwaga: większe tabele mogą pomieścić więcej partycji. Docelowy co najmniej 1 GB danych w każdej partycji.
• Wartości partycji są dopasowane do Twoich wzorców zapisu — każdy zapisujący proces naturalnie kieruje zapis do określonej partycji.

Tworzenie tabeli partycjonowanej

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

Partycjonowanie i współbieżne zapisy

Partycjonowanie jest podstawowym mechanizmem w Delta Lake, pozwalającym uniknąć konfliktów między współbieżnymi operacjami zapisu. Gdy tabela jest podzielona na partycje, operacje przeznaczone dla różnych partycji działają na rozłącznych zestawach plików i nie powodują konfliktu ze sobą.

Na przykład dwie współbieżne operacje MERGE INTO na tabeli podzielonej na partycje według region nie kolidują ze sobą, o ile każda z nich jest skierowana do innego regionu — pod warunkiem, że kolumna partycjonowania jest jawnie uwzględniona w warunku scalania:

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

Bez partycjonowania — lub bez uwzględnienia kolumny partycjonowania w warunku operacji — te same operacje mogą wchodzić ze sobą w konflikt, nawet jeśli logicznie modyfikują różne wiersze. Kolumna partycji musi być wyświetlana w samym warunku scalania, a nie tylko w danych źródłowych. Bez niego usługa Delta Lake nie może określić w czasie weryfikacji, że dwie operacje dotknąły rozłącznych zestawów plików.

Pełny przewodnik po typach konfliktów i strategiach rozwiązywania problemów można znaleźć w temacie Kontrola współbieżności.

Typowe pułapki

• Kolumny partycji o wysokiej kardynalności (na przykład user_id z milionami wartości) tworzą tysiące małych katalogów i plików, co obniża wydajność zapisu i odczytu.
  • Kolumny dat należy wybrać ostrożnie. W przypadku wielu tabel partycjonowanie według kolumny dat powoduje zbyt wiele małych partycji. Docelowy co najmniej 1 GB danych w każdej partycji.
• Nie można zmienić kolumn partycji po utworzeniu tabeli bez ponownego zapisywania całej tabeli.
• Mały problem z plikiem występuje często w przypadku przesyłania strumieniowego lub częste dołączania do wielu partycji, ponieważ każdy zapis tworzy co najmniej jeden plik na partycję.
• Partycjonowanie i klastrowanie płynne są niezgodne w tej samej tabeli. Musisz wybrać jedną strategię.

Porównanie partycjonowania i klastrowania cieczy

Treści powiązane

• Kontrola współbieżności
• Klastrowanie cieczy
• Porządek Z
• Kompaktowanie tabeli
• Pomijanie plików
• Rząd V
• Utrzymanie tabeli Delta