Projektowanie i implementowanie strategii klastrowania

Ukończone

Wskazówka

Aby uzyskać więcej szczegółów, zobacz kartę Tekst i obrazy .

Optymalizacja sposobu, w jaki dane są fizycznie zorganizowane na dysku, bezpośrednio wpływa na wydajność zapytań i wydajność magazynowania. Podczas projektowania strategii klastrowania dla tabel usługi Delta Lake określasz, jak aparat zapytań lokalizuje i pobiera odpowiednie dane. Właściwe podejście może znacznie zmniejszyć ilość danych skanowanych podczas zapytań, obniżając czasy odpowiedzi i koszty obliczeń.

Usługa Azure Databricks udostępnia kilka uzupełniających technik organizacji danych. Zrozumienie, kiedy należy stosować klastrowanie płynne, porządkowanie Z lub wektory usuwania , pomaga podejmować decyzje, które równoważą wydajność, nakład pracy konserwacyjne i zgodność z istniejącymi tabelami.

Omówienie podstaw pomijania danych

Przed zbadaniem określonych technik klastrowania ważne jest, aby zrozumieć podstawowy mechanizm, którego używają: pomijanie danych. Delta Lake automatycznie zbiera statystyki dla każdego pliku danych, w tym minimalne i maksymalne wartości, liczby wartości null i liczby rekordów dla każdej kolumny. Podczas wykonywania zapytania z warunkami filtrowania aparat zapytań najpierw sprawdza te statystyki i pomija pliki, które nie mogą zawierać pasujących rekordów.

Jeśli na przykład wykonasz zapytanie dotyczące danych sprzedaży w styczniu 2026 r., a statystyki określonego pliku pokazują, że zawiera tylko rekordy z marca 2026 r., aparat pomija ten plik całkowicie bez odczytywania jego zawartości. Ta optymalizacja odbywa się automatycznie, ale jej skuteczność zależy od tego, jak dobrze są zorganizowane dane.

Diagram wyjaśniający podstawy pomijania danych.

Pomijanie danych staje się skuteczne, gdy powiązane rekordy są przechowywane razem w tych samych plikach. Jeśli rekordy dla każdego miesiąca są losowo rozmieszczone we wszystkich plikach, aparat nie może pominąć żadnych plików, ponieważ każdy plik zawiera rekordy z każdego miesiąca. Istnieją techniki klastrowania, aby rozwiązać dokładnie ten problem.

Zaimplementuj klastrowanie liquid dla nowych tabel

Klastrowanie liquid jest zalecanym podejściem do organizowania danych w nowych tabelach Delta Lake i jest również dostępne w publicznej wersji zapoznawczej dla zarządzanych tabel Apache Iceberg w katalogu Unity (Databricks Runtime 16.4 LTS i nowszych). W przeciwieństwie do tradycyjnego partycjonowania, klastrowanie płynne umożliwia zmianę strategii klastrowania bez ponownego zapisywania istniejących danych. Ta elastyczność jest cenna, gdy wzorce zapytań ewoluują lub gdy nie masz pewności, które kolumny będą najczęściej filtrowane.

Uwaga / Notatka

W przypadku zarządzanych tabel Iceberg w Unity Catalog, określenie PARTITION BY klauzula jest interpretowane jako klucze klastrowania — a nie tradycyjne partycje w stylu Hive. Nie ma oddzielnego zachowania partycji specyficznego dla góry lodowej; cała optymalizacja układu przechodzi przez klastrowanie płynne.

Aby włączyć klastrowanie liquid, użyj klauzuli CLUSTER BY podczas tworzenia tabeli:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_category STRING,
    region STRING,
    transaction_date DATE,
    amount DECIMAL(12,2)
)
CLUSTER BY (region, transaction_date);

Można określić maksymalnie cztery klucze klastrowania. Wybierz kolumny, które są często wyświetlane w filtrach zapytań. Kolejność kluczy klastra ma mniejsze znaczenie niż wybór odpowiednich kolumn, ponieważ liquid clustering optymalizuje jednocześnie wszystkie określone klucze.

Po utworzeniu tabeli klastrowanej uruchom OPTIMIZE polecenie , aby zastosować klastrowanie do danych:

OPTIMIZE sales.transactions;

Klastrowanie płynne jest przyrostowe. Każde uruchomienie OPTIMIZE grupuje tylko te dane, które wymagają reorganizacji, co sprawia, że regularna konserwacja jest wydajna. Databricks zaleca planowanie OPTIMIZE zadań co jedną lub dwie godziny dla tabel, do których często wstawiane są nowe dane lub które są często aktualizowane.

Wskazówka

W przypadku tabel zarządzanych przez Unity Catalog włącz optymalizację predykcyjną w celu zautomatyzowania OPTIMIZE operacji. Usługa Azure Databricks analizuje wzorce obciążeń i automatycznie uruchamia operacje konserwacji.

Zmiana kluczy klastrowania w razie potrzeby

Jedną z znaczących zalet klastrowania cieczy w przypadku partycjonowania jest możliwość modyfikowania strategii klastrowania. Jeśli wzorce zapytań ulegają zmianie, zaktualizuj klucze klastrowania za pomocą instrukcji ALTER TABLE :

ALTER TABLE sales.transactions
CLUSTER BY (customer_id, transaction_date);

Kolejne OPTIMIZE operacje korzystają z nowego podejścia do klastrowania. Wcześniej zapisane dane nie są automatycznie zapisywane ponownie. Aby zastosować nowe klastrowanie do wszystkich istniejących danych, uruchom polecenie:

OPTIMIZE sales.transactions FULL;

Włączanie automatycznego wyboru klucza klastrowania

Usługa Azure Databricks może inteligentnie wybierać klucze klastrowania na podstawie rzeczywistych wzorców zapytań. Automatyczne klastrowanie danych analizuje historię obciążeń i wybiera kolumny, które zapewniają największe korzyści z pomijania danych.

CREATE TABLE sales.orders CLUSTER BY AUTO;

Automatyczne klastrowanie można włączyć w istniejących tabelach:

ALTER TABLE sales.transactions CLUSTER BY AUTO;

Automatyczne klastrowanie cieczy wymaga włączenia optymalizacji predykcyjnej. Usługa Azure Databricks okresowo ocenia, czy różne klucze klastrowania poprawiłyby wydajność i odpowiednio dostosują strategię.

Migrowanie z porządkowania Z do klastrowania płynnego

Porządkowanie Z to starsza technika, która organizuje dane w celu kolokowania powiązanych informacji w tych samych plikach. Podczas gdy klastrowanie liquid jest zalecane dla nowych tabel, napotkasz istniejące tabele, które używają porządkowania Z i będziesz musiał zrozumieć obie metody.

Porządkowanie Z używa polecenia OPTIMIZE z klauzulą ZORDER BY:

OPTIMIZE sales.legacy_transactions
ZORDER BY (region, transaction_date);

Porządkowanie Z różni się od klastrowania cieczy na kilka ważnych sposobów:

Aspekt Klasteryzacja cieczy Uporządkowanie według osi Z
Kluczowa elastyczność Zmienianie kluczy bez ponownego zapisywania danych Zmiana kluczy wymaga pełnego ponownego zapisywania
Wydajność zapisu Klastrowanie operacji zapisu na potrzeby kwalifikujących się operacji Stosowane tylko podczas optymalizacji
Współbieżne zapisy Obsługiwana współbieżność na poziomie wiersza Współbieżność na poziomie transakcji
Compatibility Wymaga środowiska Databricks Runtime 13.3 LTS lub nowszego Obsługiwane we wszystkich środowiskach uruchomieniowych

Gdy dziedziczysz tabelę uporządkowaną w modelu Z, masz dwie opcje. Kontynuuj używanie porządkowania Z w celu zapewnienia spójności lub migracji do klastra płynnego w celu zwiększenia elastyczności. Aby przeprowadzić migrację, najpierw włącz klastrowanie liquid w istniejącej niepartycyjnej tabeli:

ALTER TABLE sales.legacy_transactions
CLUSTER BY (region, transaction_date);

Następnie uruchom pełną optymalizację, aby zreorganizować wszystkie istniejące dane:

OPTIMIZE sales.legacy_transactions FULL;

Ważne

Klastrowanie cieczy nie jest zgodne z partycjonowaniem. W przypadku tabel podzielonych na partycje należy ocenić, czy zalety klastrowania płynnego uzasadniają migrację do niepartej struktury tabeli.

Zarządzanie wektorami usuwania na potrzeby wydajnych aktualizacji

Wektory usuwania dotyczą innego aspektu organizacji danych: jak usługa Delta Lake obsługuje zmodyfikowane lub usunięte rekordy. Domyślnie podczas aktualizowania lub usuwania pojedynczego wiersza w pliku Parquet usługa Delta Lake musi ponownie zapisać cały plik. W przypadku tabel z częstymi modyfikacjami powoduje to znaczne obciążenie.

Po włączeniu wektorów usuwania usługa Delta Lake oznacza zmodyfikowane wiersze jako usunięte w osobnym pliku metadanych zamiast natychmiastowego ponownego zapisywania pliku Parquet. Kolejne operacje odczytu stosują te usunięcia na bieżąco, łącząc oryginalny plik z wektorem usunięć, aby zwrócić dokładne wyniki.

Wektory usuwania są domyślnie włączone dla nowych tabel utworzonych za pomocą środowiska Databricks Runtime 14.1 lub nowszego. Można je jawnie włączyć w istniejących tabelach:

ALTER TABLE sales.transactions
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

Wektory usuwania są stosowane fizycznie po ponownym zapisie plików danych podczas wykonywania następujących operacji:

  • Polecenie OPTIMIZE
  • Wyzwalacze automatycznego kompaktowania
  • REORG TABLE ... APPLY (PURGE) Operacja

W przypadku scenariuszy zgodności, w których należy upewnić się, że usunięte dane zostały fizycznie usunięte, uruchom operację REORG , po której następuje VACUUM:

REORG TABLE sales.transactions APPLY (PURGE);
VACUUM sales.transactions;

Wektory usuwania umożliwiają również współbieżność na poziomie wiersza, umożliwiając wielu współbieżnych transakcji modyfikowanie różnych wierszy w tej samej tabeli bez konfliktów. Ta funkcja jest szczególnie cenna w przypadku tabel z dużymi woluminami aktualizacji.