Projektowanie i implementowanie schematu partycjonowania danych

Partycjonowanie danych ma bezpośredni wpływ na sposób wydajnego uruchamiania zapytań i ilości używanych zasobów obliczeniowych. Podczas partycjonowania tabeli dane są dzielone na odrębne segmenty na podstawie wartości kolumn, co umożliwia aparatowi zapytań odczytywanie tylko odpowiednich części zestawu danych. Takie podejście, nazywane oczyszczaniem partycji, może znacznie zmniejszyć skanowanie danych, gdy filtry są zgodne z granicami partycji.

Rozważmy, że firma detaliczna przetwarza miliony codziennych transakcji sprzedaży. Analitycy często wysyłają zapytania o dane według zakresów dat, aby generować cotygodniowe raporty, porównywać trendy miesięczne i analizować wzorce sezonowe. Bez partycjonowania każde zapytanie skanuje całą historię transakcji. Przy odpowiednim partycjonowaniu według daty zapytania dotyczące określonego tygodnia dotykają tylko części przechowywanych plików.

Określanie, kiedy ma zastosowanie partycjonowanie

Usługa Databricks zaleca, aby tabele partycji nie zawierały mniej niż 1 TB danych. W przypadku mniejszych tabel obciążenie związane z zarządzaniem metadanymi partycji i możliwością tworzenia wielu małych plików przewyższa wszelkie korzyści z wydajności zapytań. Niepartycyjne tabele delty w ostatnich wersjach środowiska Databricks Runtime automatycznie korzystają z klastrowania czasu pozyskiwania, co zapewnia podobne zalety zapytania bez jawnej konfiguracji.

Gdy tabele przekraczają 1 TB, partycjonowanie staje się cenną techniką optymalizacji. Na tej skali korzyści wynikające z odczytywania tylko odpowiednich segmentów danych znacznie zrównoważą koszty zarządzania partycjami. Partycjonowanie umożliwia również przetwarzanie równoległe, ponieważ platforma Spark może dystrybuować różne partycje między węzłami klastra na potrzeby współbieżnego wykonywania.

W przypadku bardzo dużych tabel w zakresie setek terabajtów partycjonowanie zapewnia jeszcze większe korzyści. W tej skali oczyszczanie partycji znacznie zmniejsza ilość danych, które aparat zapytań potrzebuje do przetworzenia, zwiększając wydajność i wydajność kosztu.

Wybieranie obowiązujących kluczy partycji

Wybór klucza partycji wymaga zrozumienia cech danych i wzorców zapytań. Efektywne klucze partycji mają wspólne cechy, które maksymalizują korzyści z wydajności, unikając typowych pułapek.

Kolumny o niskiej kardynalności działają najlepiej

Wybierz kolumny z ograniczoną liczbą unikatowych wartości. Kolumny dat, regiony geograficzne, kategorie produktów i pola stanu stanowią doskonałe klucze partycji, ponieważ tworzą zarządzalną liczbę partycji. Kolumna zawierająca tysiące lub miliony unikatowych wartości, takich jak identyfikator klienta lub identyfikator transakcji, prowadzi do nadmiernego partycjonowania i niskiej wydajności.

Na przykład partycjonowanie tabeli sprzedaży na poziomie dziennym z sale_date może prowadzić do utworzenia 365 partycji rocznie. Jeśli każdy dzień zawiera wystarczającą ilość danych, stopień szczegółowości działa prawidłowo. Jednak partycjonowanie na sale_timestamp drugim poziomie spowodowałoby utworzenie milionów partycji, z których każda zawiera minimalne dane.

Dopasowywanie do wzorców zapytań

Klucz partycji powinien być zgodny z kolumnami, które użytkownicy filtrują najczęściej. Jeśli analitycy stale wysyłają zapytania dotyczące danych sprzedaży według zakresów dat, partycjonowanie według daty umożliwia wydajne oczyszczanie. Jeśli zapytania są filtrowane głównie według regionów, należy rozważyć region jako klucz partycji.

Jeśli istnieje wiele wzorców filtrów, należy określić priorytety najczęściej używanych lub najbardziej krytycznych dla wydajności zapytań. Można zdefiniować jeden schemat partycjonowania na tabelę, więc wybierz kolumny, które przynoszą największe korzyści dla większości obciążeń. W przypadku znacznie różnych wzorców zapytań rozważ utworzenie oddzielnych zoptymalizowanych zmaterializowanych widoków lub tabel podsumowań dla określonych przypadków użycia.

Rozważ wzrost danych w czasie

Wybierz schemat partycji, który jest odpowiednio skalowany w miarę zwiększania się danych. Partycjonowanie według roku działa dobrze początkowo, ale może tworzyć partycje, które z biegiem czasu stają się zbyt duże. Z drugiej strony partycjonowanie według godziny może działać w przypadku danych o dużej ilości, ale tworzy zbyt wiele małych partycji dla umiarkowanych woluminów.

Oceń oczekiwany współczynnik wzrostu danych podczas wybierania stopnia szczegółowości partycji. Równowaga między rozmiarem partycji a liczbą partycji pomaga zachować spójną wydajność zapytań w miarę rozszerzania zestawu danych.

Rozważ również dystrybucję danych między partycjami. Poważnie nierówne rozmiary partycji mogą tworzyć wąskie gardła przetwarzania, ponieważ węzły obsługujące większe partycje zajmują więcej czasu, podczas gdy inne pozostają bezczynne.

Implementowanie partycji w usłudze Azure Databricks

Partycje są definiowane podczas tworzenia tabeli przy użyciu klauzuli PARTITIONED BY w SQL lub metody partitionBy w PySpark. Po ustanowieniu partycji usługa Azure Databricks automatycznie kieruje dane przychodzące do odpowiednich katalogów partycji na podstawie wartości kolumn.

Tworzenie tabeli podzielonej na partycje przy użyciu języka SQL

Poniższy przykład tworzy tabelę transakcji sprzedaży podzieloną na partycje według daty transakcji:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_id STRING,
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    transaction_date DATE
)
PARTITIONED BY (transaction_date);

Podczas wykonywania zapytań względem tej tabeli z filtrem daty aparat zapytań odczytuje tylko partycje zgodne z kryteriami filtrowania:

SELECT product_id, SUM(total_amount) AS revenue
FROM sales.transactions
WHERE transaction_date BETWEEN '2024-01-01' AND '2024-01-31'
GROUP BY product_id;

Tworzenie tabeli partycjonowanej za pomocą narzędzia PySpark

W przypadku korzystania z narzędzia PySpark określ partycjonowanie podczas operacji zapisu:

df.write.format("delta") \
    .partitionBy("transaction_date") \
    .saveAsTable("sales.transactions")

W przypadku kolejnych zapisów zachowaj spójność, uwzględniając tę samą specyfikację partycji:

new_transactions_df.write.format("delta") \
    .mode("append") \
    .partitionBy("transaction_date") \
    .saveAsTable("sales.transactions")

Używanie wygenerowanych kolumn w celu zapewnienia elastyczności partycji

Wygenerowane kolumny umożliwiają uzyskiwanie wartości partycji z istniejących kolumn bez przechowywania nadmiarowych danych. Takie podejście jest przydatne, gdy dane źródłowe zawierają znaczniki czasu, ale chcesz partycjonować według daty:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_id STRING,
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    transaction_timestamp TIMESTAMP,
    transaction_date DATE GENERATED ALWAYS AS (CAST(transaction_timestamp AS DATE))
)
PARTITIONED BY (transaction_date);

Unikanie typowych błędów partycjonowania

Zrozumienie, czego należy unikać, jest równie ważne, jak wiedza o tym, co należy zrobić. Kilka typowych błędów może znacznie obniżyć wydajność i komplikować zarządzanie danymi.

Nadmierne partycjonowanie powoduje problemy z małymi plikami

Utworzenie zbyt wielu partycji, z których każda zawiera niewystarczające dane, prowadzi do problemów z małymi plikami. Gdy partycje zawierają pliki mniejsze niż docelowy rozmiar pliku, wydajność zapytań cierpi na nadmierne operacje metadanych i zmniejsza wydajność odczytu. Celuj w partycje z co najmniej 1 GB danych.

Oznaki nadmiernego partycjonowania obejmują niską wydajność zapytań pomimo oczyszczania partycji, dużej liczby małych plików w katalogach partycji i długich czasów optymalizacji tabeli. Jeśli zaobserwujesz te objawy, rozważ wybranie stopnia szczegółowości partycji grubszej.

Podział na partycje dla kolumn o wysokiej kardynalności kończy się niepowodzeniem

Kolumny z wieloma unikatowymi wartościami to złe klucze partycji. Partycjonowanie według identyfikatora klienta, identyfikatora transakcji lub innych kolumn o wysokiej kardynalności powoduje utworzenie milionów partycji, które obniżają wydajność, a nie zwiększają wydajności. Przeznacz optymalizację kolumn o wysokiej kardynalności dla innych technik zaprojektowanych do tego celu.

Zmiana partycji wymaga ponownego zapisywania danych

Kolumny partycji są częścią struktury tabeli. Zmiana strategii partycjonowania wymaga ponownego zapisania całej tabeli w nowej lokalizacji z różnymi granicami partycji. Ta operacja zużywa znaczne zasoby obliczeniowe i czas dla dużych tabel.

Starannie zaplanuj strategię partycjonowania przed załadowaniem danych na dużą skalę. Rozważ przyszłe wzorce zapytań i wzrost danych, aby uniknąć kosztownej restrukturyzacji później.

Decyzje dotyczące partycjonowania dokumentów

Zapisz wybrane opcje klucza partycji i ich przyczynę. Ta dokumentacja ułatwia członkom zespołu zrozumienie możliwości optymalizacji zapytań i zapobieganie przypadkowym zmianom, które mogą mieć wpływ na wydajność. Uwzględnij informacje o oczekiwanych rozmiarach partycji, wzorcach zapytań, które korzystają ze schematu i wszelkich ograniczeniach mających wpływ na decyzje.

Rozważ klastrowanie płynne jako alternatywę

W przypadku napotkania wyzwań związanych z partycjonowaniem — szczególnie w przypadku kolumn o wysokiej kardynalności , takich jak znaczniki czasu lub gdy wzorce zapytań są niepewne — klastrowanie płynne zapewnia nowoczesną alternatywę. W przeciwieństwie do tradycyjnego partycjonowania, klasteryzacja płynna oferuje:

• Elastyczność dostosowywania strategii optymalizacji bez ponownego zapisywania danych
• Automatyczna konserwacja w miarę zwiększania się tabel
• Mniejsze obciążenie związane z zarządzaniem partycjami

Klastrowanie liquid jest zalecanym podejściem dla nowych tabel, w których ograniczenia partycjonowania zmniejszałyby wydajność lub powodowałyby nadmierne obciążenie związane z konserwacją. Jest to szczególnie skuteczne w przypadku tabel, które przekraczają 1 TB i wymagają filtrowania kolumn, które tworzą zbyt wiele partycji przy użyciu tradycyjnych metod.

Aby uzyskać szczegółowe informacje na temat implementacji, składni i strategii optymalizacji, zapoznaj się z modułem Projektowanie i implementowanie strategii klastrowania w dalszej części tego modułu.