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

Artykuł
04/18/2024

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 usługą 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 pozyskiwania.

Czy małe tabele muszą 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 czasu pozyskiwania

Korzystając z usług Delta Lake i Databricks Runtime 11.3 LTS lub nowszych, niepartycyjne tabele umożliwiają automatyczne tworzenie korzyści z klastrowania czasu pozyskiwania. Czas pozyskiwania zapewnia podobne korzyści związane z partycjonowaniem strategii opartych na polach daty/godziny bez konieczności optymalizowania ani dostrajania danych.

Uwaga

Aby zachować klastrowanie czasu pozyskiwania podczas wykonywania dużej liczby modyfikacji przy użyciu UPDATE instrukcji lub MERGE w tabeli, usługa Databricks zaleca uruchomienie OPTIMIZE polecenia z użyciem kolumny zgodnej z ZORDER BY kolejnością pozyskiwania. Na przykład może to być kolumna zawierająca sygnaturę czasową zdarzenia lub datę utworzenia.

Usługa Delta Lake używa parquet jako podstawowego formatu do przechowywania danych, a niektóre tabele delty z określonymi partycjami pokazują organizację podobną do tabel Parquet przechowywanych za pomocą platformy 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 delty.

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.

Czym różnią się partycje usługi Delta Lake od partycji w innych magazynach data lake?

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 acid za pośrednictwem dzienników transakcji, więc nie trzeba oddzielać partii danych przez partycję w celu zapewnienia odnajdywania niepodzielnego.
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 działa kolejność Z i partycje?

Indeksy zamówień Z można używać obok partycji, aby przyspieszyć zapytania dotyczące dużych zestawów 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 niepartych tabel pliki można łączyć w 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 porządkować Z dla pól 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 usługi Delta Lake z magazynów danych opartych na parquet. Instrukcja CONVERT TO DELTA umożliwia konwertowanie istniejącej tabeli opartej na parquet na tabelę delty bez ponownego zapisywania istniejących danych. W związku z tym wielu klientów ma duże tabele, 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.