Kiedy należy partycjonować tabele w usłudze Azure Databricks

Uwaga

W zarządzanych tabelach Apache Iceberg, Unity Catalog obsługuje tylko klastrowanie płynne i interpretuje partycje określone w klauzuli PARTITION BY jako klucze klastrowania dla klastrowania płynnego.

Databricks zaleca wykorzystanie liquid clustering dla wszystkich nowych tabel Delta oraz zarządzanych tabel Iceberg. Zobacz Tabele zarządzane przez Katalog Unity w usłudze Azure Databricks dla Delta Lake i Apache Iceberg oraz Używanie płynnego klastrowania dla tabel.

Klastry cieczy są czasami nazywane również "partycjami cieczy". W tym artykule odnosi się tylko do starszego partycjonowania Delta, a nie płynnego klastrowania.

Ten artykuł zawiera omówienie sposobu partycjonowania tabel w usłudze Azure Databricks i konkretnych zaleceń dotyczących tego, kiedy należy używać partycjonowania dla tabel wspieranych przez usługę Delta Lake. Ze względu na wbudowane funkcje i optymalizacje większość tabel z mniej niż 1 TB danych nie wymaga partycji.

Usługa Azure Databricks domyślnie używa usługi Delta Lake dla wszystkich tabel. W poniższych zaleceniach założono, że pracujesz z Delta Lake dla wszystkich tabel.

W środowisku Databricks Runtime 11.3 LTS i nowszym usługa Azure Databricks automatycznie klasteruje dane w tabelach bezpartyjnych według czasu pozyskiwania. Zobacz Używanie klastrowania czasu ładowania danych.

Czy małe tabele powinny być partycjonowane?

Usługa Databricks zaleca, aby nie partycjonować tabel zawierających mniej niż terabajt danych.

Co to jest minimalny rozmiar każdej partycji w tabeli?

Usługa Databricks zaleca, aby wszystkie partycje zawierały co najmniej gigabajt danych. Tabele z mniejszą liczbą większych partycji zwykle przewyższają wyniki tabel z wieloma mniejszymi partycjami.

Używanie klastrowania według czasu pobierania

Korzystając z Delta Lake i Databricks Runtime 11.3 LTS lub nowszych, tabele niepartycyjne automatycznie zyskują dzięki klastrowaniu według czasu załadunku. Czas pozyskiwania zapewnia podobne korzyści do strategii partycjonowania opartych na polach daty i godziny, bez potrzeby optymalizowania i dostrajania danych.

Uwaga

Aby zachować klastrowanie według czasu pozyskiwania podczas dokonywania dużej liczby modyfikacji za pomocą instrukcji UPDATE lub MERGE na tabeli, usługa Databricks zaleca stosowanie klastrowania strumieniowego w kolumnie dopasowanej do kolejności pozyskiwania, na przykład według sygnatury czasowej zdarzenia lub daty utworzenia. Zobacz Używaj płynnego grupowania dla tabel.

Czy Delta Lake i Parquet współdzielą strategie partycjonowania?

Usługa Delta Lake używa Parquet jako podstawowego formatu do przechowywania danych, a niektóre tabele Delta z określonymi partycjami pokazują organizację podobną do tabel Parquet przechowywanych w Apache Spark. Platforma Apache Spark używa partycjonowania w stylu hive podczas zapisywania danych w formacie Parquet. Partycjonowanie w stylu Hive nie jest częścią protokołu Delta Lake, a obciążenia nie powinny polegać na tej strategii partycjonowania w celu interakcji z tabelami Delta.

Wiele funkcji usługi Delta Lake przerywa założenia dotyczące układu danych, które mogły zostać przeniesione z wersji protokołu Parquet, Hive lub nawet wcześniejszych wersji protokołu Delta Lake. Zawsze należy korzystać z danych przechowywanych w usłudze Delta Lake przy użyciu oficjalnie obsługiwanych klientów i interfejsów API.

Uwaga

Po włączeniu mapowania kolumn dla tabeli Delta losowe prefiksy zastępują nazwy kolumn w katalogach partycji dla partycjonowania w stylu Hive. Zobacz Zmień nazwę i usuń kolumny za pomocą mapowania kolumn Delta Lake.

Czym różnią się partycje Delta Lake od partycji w innych jeziorach danych?

Chociaż usługi Azure Databricks i Delta Lake bazują na technologiach typu open source, takich jak Apache Spark, Parquet, Hive i Hadoop, motywacje partycjonowania i strategie przydatne w tych technologiach zwykle nie są prawdziwe w przypadku usługi Azure Databricks. Jeśli zdecydujesz się podzielić tabelę na partycje, przed wybraniem strategii należy wziąć pod uwagę następujące fakty:

• Transakcje nie są definiowane przez granice partycji. Usługa Delta Lake zapewnia właściwości ACID za pośrednictwem dzienników transakcji, więc nie trzeba oddzielać partii danych przez partycję, aby zapewnić atomowe odkrywanie.
• Klastry obliczeniowe usługi Azure Databricks nie mają lokalizacji danych powiązanych z nośnikami fizycznymi. Dane pozyskane do usługi Lakehouse są przechowywane w magazynie obiektów w chmurze. Chociaż dane są buforowane do magazynu na dysku lokalnym podczas przetwarzania danych, usługa Azure Databricks używa statystyk opartych na plikach w celu zidentyfikowania minimalnej ilości danych na potrzeby ładowania równoległego.

Jak kolejność Z współpracuje z partycjami?

Uwaga

Databricks zaleca stosowanie klastrowania płynnego zamiast Z-ordering dla wszystkich nowych tabel. Zobacz Używaj płynnego grupowania dla tabel.

Indeksy porządkowe Z można używać wraz z partycjami, aby przyspieszyć wykonywanie zapytań na dużych zestawach danych.

Uwaga

Większość tabel może korzystać z klastrowania czasu pozyskiwania, aby uniknąć konieczności martwienia się o kolejność Z i dostrajanie partycji.

Podczas planowania strategii optymalizacji zapytań na podstawie granic partycji i kolejności Z należy pamiętać o następujących regułach:

• Kolejność Z działa razem z poleceniem OPTIMIZE . Nie można łączyć plików w granicach partycji, dlatego klastrowanie kolejności Z może odbywać się tylko w ramach partycji. W przypadku niepodzielonych tabel pliki można łączyć dla całej tabeli.
• Partycjonowanie działa dobrze tylko w przypadku pól o niskiej lub znanej kardynalności (na przykład pól daty lub lokalizacji fizycznych), ale nie w przypadku pól o wysokiej kardynalności, takich jak znaczniki czasu. Kolejność Z działa dla wszystkich pól, w tym pól o wysokiej kardynalności i polach, które mogą rosnąć nieskończonie (na przykład znaczniki czasu lub identyfikator klienta w tabeli transakcji lub zamówień).
• Nie można stosować Z-porządkowania na polach używanych do partycjonowania.

Jeśli partycje są tak złe, dlaczego niektóre funkcje usługi Azure Databricks używają ich?

Partycje mogą być korzystne, zwłaszcza w przypadku bardzo dużych tabel. Wiele ulepszeń wydajności dotyczących partycjonowania koncentruje się na bardzo dużych tabelach (setki terabajtów lub większych).

Wielu klientów migruje do Delta Lake z jezior danych opartych na formacie Parquet. Instrukcja CONVERT TO DELTA pozwala na konwertowanie istniejącej tabeli w formacie Parquet na tabelę w formacie Delta bez ponownego zapisywania istniejących danych. W związku z tym wielu klientów ma duże zbiory danych w tabelach, które dziedziczą poprzednie strategie partycjonowania. Niektóre optymalizacje opracowane przez usługę Databricks starają się wykorzystać te partycje, jeśli to możliwe, ograniczając pewne potencjalne wady strategii partycjonowania, które nie są zoptymalizowane pod kątem usługi Delta Lake.

Usługi Delta Lake i Apache Spark to technologie typu open source. Chociaż usługa Databricks nadal wprowadza funkcje, które zmniejszają zależność od partycjonowania, społeczność open source może nadal tworzyć nowe funkcje, które dodają złożoność.

Czy można przewyższać wbudowane optymalizacje usługi Azure Databricks przy użyciu partycjonowania niestandardowego?

Niektórzy doświadczeni użytkownicy platform Apache Spark i Delta Lake mogą projektować i implementować wzorzec zapewniający lepszą wydajność niż klastrowanie czasu pozyskiwania. Implementacja złego stanu partycjonowania może mieć bardzo negatywne konsekwencje dotyczące wydajności podrzędnej i może wymagać pełnego ponownego zapisywania danych w celu naprawienia. Usługa Databricks zaleca, aby większość użytkowników używała ustawień domyślnych, aby uniknąć wprowadzania kosztownych nieefektywności.