Rozmiar tabeli w usłudze Azure Databricks

Rozmiar tabeli zgłoszony dla tabel obsługiwanych przez usługę Delta Lake w usłudze Azure Databricks różni się od całkowitego rozmiaru odpowiednich katalogów plików w magazynie obiektów w chmurze. W tym artykule omówiono, dlaczego ta różnica istnieje i zalecenia dotyczące kontrolowania kosztów.

Dlaczego rozmiar tabeli delty nie jest zgodny z rozmiarem katalogu?

Rozmiary tabel zgłaszane w usłudze Azure Databricks za pośrednictwem interfejsów użytkownika i DESCRIBE poleceń odnoszą się do całkowitego rozmiaru plików danych na dysku dla tych plików, do których odwołuje się bieżąca wersja tabeli delty. Większość operacji zapisywanych w tabelach wymaga ponownego zapisywania bazowych plików danych, ale stare pliki danych są przechowywane przez pewien czas w celu obsługi zapytań dotyczących podróży w czasie.

Uwaga

Jeśli regularnie usuwasz lub aktualizujesz rekordy w tabelach, wektory usuwania mogą przyspieszyć wykonywanie zapytań i zmniejszyć całkowity rozmiar plików danych. Zobacz Co to są wektory usuwania?.

Obliczanie metryk przechowywania dla tabeli

Dotyczy: Databricks Runtime 18.0 lub nowsze

Aby zrozumieć, dlaczego całkowity rozmiar magazynu różni się od rozmiaru tabeli, użyj polecenia ANALYZE TABLE … COMPUTE STORAGE METRICS. To polecenie zawiera szczegółowy podział alokacji magazynu, ułatwiając:

• Identyfikowanie możliwości optymalizacji kosztów: zobacz, ile miejsca można odzyskać za pomocą VACUUM
• Analizowanie nakładu pracy związanych z podróżą w czasie: omówienie kosztów przechowywania danych historycznych
• Śledź wzorce magazynowania: Monitoruj, jak magazyn tabel ewoluuje wraz z upływem czasu, okresowo uruchamiając polecenie
• Przeprowadź inspekcję magazynu między tabelami: uruchom polecenie w pętli, aby przeanalizować całą infrastrukturę danych

Polecenie zwraca kompleksowe metryki, w tym:

• Całkowity rozmiar pamięci masowej: Pełny ślad obejmujący wszystkie dane, metadane i dzienniki
• Aktywne dane: rozmiar bieżącej wersji tabeli
• Dane, które można odzyskać poprzez ich usunięcie: przestrzeń, którą można odzyskać
• Dane podróży w czasie: dane historyczne dotyczące wycofywania

Jest to szczególnie przydatne w przypadku tabel zarządzanych przez Unity Catalog, w których usługa Azure Databricks automatycznie zarządza przechowywaniem za pomocą optymalizacji predykcyjnej.

Aby uzyskać pełną składnię i przykłady, zobacz COMPUTE STORAGE METRICS.

Używanie optymalizacji predykcyjnej do kontrolowania rozmiaru danych

Usługa Databricks zaleca używanie tabel zarządzanych Unity Catalog z włączoną optymalizacją predykcyjną. Dzięki zarządzanym tabelom i optymalizacji predykcyjnej, usługa Databricks automatycznie uruchamia polecenia OPTIMIZE i VACUUM, aby zapobiec narastaniu nieużywanych plików danych. Zawsze należy oczekiwać różnicy w rozmiarze między bieżącą wersją tabeli a całkowitym rozmiarem plików danych w magazynie obiektów w chmurze. Wynika to z faktu, że pliki danych, do których nie odwołuje się bieżąca wersja, są wymagane do obsługi zapytań dotyczących podróży czasowych. Zobacz Optymalizację predykcyjną dla tabel zarządzanych w Unity Catalog.

Jakie metryki plików raportuje VACUUM ?

Gdy wyczyścisz nieużywane pliki danych VACUUM lub użyjesz DRY RUN aby wyświetlić podgląd plików przeznaczonych do usunięcia, metryki zgłaszają liczbę plików i rozmiar usuniętych danych. Rozmiar i liczba plików usuniętych VACUUM przez program różnią się znacząco, ale nie jest rzadkością, aby rozmiar usuniętych plików przekraczał całkowity rozmiar bieżącej wersji tabeli.

Jakie metryki plików raportuje OPTIMIZE ?

Gdy OPTIMIZE jest uruchamiane w tabeli docelowej, nowe pliki danych łączą rekordy z istniejących plików danych. Zmiany zatwierdzone tylko w organizacji OPTIMIZE danych, a nie występują żadne zmiany w zawartości danych bazowych. Całkowity rozmiar plików danych skojarzonych z tabelą zwiększa się po OPTIMIZE uruchomieniu, ponieważ nowe skompaktowane pliki współistnieją w katalogu zawierającym z nieprzywoływane pliki danych.

Rozmiar tabeli zgłoszonej po OPTIMIZE jest zazwyczaj mniejszy niż rozmiar przed OPTIMIZE uruchomieniem, ponieważ całkowity rozmiar plików danych, do których odwołuje się bieżąca wersja tabeli, zmniejsza się wraz z kompaktowaniem danych. VACUUM należy uruchomić po przekroczeniu progu retencji w celu usunięcia podstawowych plików danych.

Uwaga

Możesz zobaczyć podobne metryki dla operacji, takich jak REORG TABLE lub DROP FEATURE. Wszystkie operacje wymagające ponownego zapisywania plików danych zwiększają całkowity rozmiar danych w katalogu, aż VACUUM usunie pliki danych, które nie są już odwoływane w bieżącej wersji tabeli.