Wgląd w wydajność zapytań

Ważne

Ta funkcja jest dostępna w wersji beta. Administratorzy obszaru roboczego mogą kontrolować dostęp do tej funkcji ze strony Podglądy . Zobacz Zarządzanie wersjami zapoznawczami usługi Azure Databricks.

Na tej stronie opisano szczegółowe informacje o wydajności, które Azure Databricks zwracane w historii zapytań i sposób ich działania.

Podczas uruchamiania zapytań Azure Databricks może zwracać informacje wskazujące możliwości poprawy wydajności lub raportujące już zastosowane optymalizacje.

Znajdowanie szczegółowych informacji i zaleceń dotyczących zapytania

Szczegółowe informacje są wyświetlane w historii zapytań i w profilu zapytania. Panel szczegółów zapytania zawiera podsumowanie szczegółowych informacji sklasyfikowanych według szacowanego wpływu na łączny czas trwania zadania. Karta Szczegółowe informacje o wydajności w profilu zapytania zawiera pełne szczegóły dla poszczególnych szczegółowych informacji.

Optymalizowanie za pomocą kodu Genie

Gdy zapytanie zawiera szczegółowe informacje z możliwością działania, wybierz pozycję Optymalizuj , aby otworzyć kod Genie. Aby uzyskać szczegółowe informacje, które wymagają zmiany zapytania, kod Genie ponownie zapisuje zapytanie i przedstawia zmiany do zatwierdzenia. W przypadku szczegółowych informacji obejmujących zmiany tabeli lub obliczeń kod Genie podsumowuje zalecane akcje jako zwykły tekst.

Aby dowiedzieć się więcej na temat pracy z programem Genie Code, zobacz Genie Code (Kod genie).

Szczegółowe informacje o optymalizacji zapytań

COVERAGE_FILTER_KEYS_CLUSTERING

Tabela jest klasterowana przez co najmniej jeden klucz, który nie jest używany w filtrach podczas skanowania tabeli.

Zalecenie: Dodaj filtry w kluczach klastrowania, aby zmniejszyć odczyt bajtów.

COVERAGE_FILTER_KEYS_PARTITIONING

Tabela jest partycjonowana przez co najmniej jeden klucz, który nie jest używany w filtrach podczas skanowania tabeli.

Zalecenie: Dodaj filtry dla kluczy partycjonowania, aby zmniejszyć odczyt bajtów.

COVERAGE_PHOTON

Photon nie może przyspieszyć tej operacji, więc zapytanie używa standardowego aparatu środowiska uruchomieniowego.

Zalecenie: Przejrzyj ograniczenia aplikacji Photon i dostosuj zapytanie, aby użyć obsługiwanej ścieżki wykonywania.

EXPLODING_JOIN

Sprzężenia generuje znacznie więcej wierszy, niż odczytuje.

Zalecenie: Określ potrzebny podzestaw wyników, a następnie zaktualizuj warunek sprzężenia lub zmniejsz liczbę wierszy wejściowych z obu relacji.

FLOW_FULL_RECOMPUTE

Przepływ jest uruchamiany jako pełna ponowna kompilacja.

Zalecenie: Zastąp ponownie zapytanie dotyczące obsługi przyrostowej, aby zmniejszyć odczyt bajtów.

REDUNDANT_AGGREGATION

Operacja agregacji nie zmieniła wyniku zapytania.

Zalecenie: Usuń ograniczenia agregacji lub zastosuj ograniczenia klucza podstawowego i obcego.

REDUNDANT_JOIN

Zewnętrzne łączenie nie zmieniało liczby wierszy na zewnętrznej stronie i nie używa się kolumn z połączonej tabeli.

Rekomendacja: Usuń połączenie lub zastosuj klucz główny lub unikalne ograniczenia.

SELECTIVE_JOIN

Sprzężenia generuje znacznie mniej wierszy, niż odczytuje.

Zalecenie: Określ potrzebny podzestaw wyników, a następnie dodaj filtry przed sprzężenia, aby zmniejszyć liczbę wierszy wejściowych.

WIDE_PROJECTION

Zapytanie projektuje wszystkie kolumny z tabeli.

Zalecenie: Project tylko kolumny potrzebne do zmniejszenia liczby bajtów do odczytu.

Szczegółowe informacje o układzie danych

RÓWNOCZESNE_PISANIE

Współbieżne zapisy w tabeli powodują konflikty , które są automatycznie rozwiązywane lub kończą się niepowodzeniem.

Zalecenie: Przejrzyj historię delty , aby zidentyfikować współbieżne zapisy i dostosować planowanie, aby uniknąć konfliktów.

COVERAGE_STATS_DELTA

Statystyki dotyczące pomijania danych delta są nieobecne lub niekompletne dla filtrów plików skanowania tabeli, w związku z czym zapytanie używa filtrowania wewnątrz pliku.

Stan statystyk dla każdego filtru może być jednym z następujących elementów:

• Pełne: Statystyki są dostępne dla wszystkich filtrów.
• Częściowe: Statystyki są dostępne dla podzbioru filtrów.
• Niedostępne: Statystyki nie są dostępne dla żadnego filtru.
• Nieużywane: Nie można użyć statystyk, ponieważ filtr konwertuje typ danych.

Zalecenie:Zbierz statystyki różnicowe , aby zmniejszyć odczyt bajtów.

COVERAGE_STATS_OPTIMIZER

Brak lub niekompletne statystyki optymalizatora opartego na kosztach, więc plan zapytania używa standardowych heurystyki.

Zalecenie:Zbierz statystyki , aby umożliwić optymalizatorowi tworzenie lepszego planu.

DATA_SKEW

Dane są dystrybuowane nierównomiernie między zasobami obliczeniowymi.

Zalecenie: Przejrzyj dystrybucję danych, a następnie zrównoważ obciążenie przy użyciu łączenia kluczy lub wstępnego agregacji.

MANUAL_DATA_LAYOUT

Stół jest ręcznie zoptymalizowany i może korzystać z automatycznego klasteryzowania cieczy.

Recommendations:

• Przekonwertuj tabelę z zewnętrznej na zarządzaną , aby uzyskać lepszą wydajność i automatyczną konserwację.
• Włącz optymalizację predykcyjną w tabeli na potrzeby automatycznych operacji konserwacji.
• Włącz automatyczne klastrowanie w tabeli, aby zmniejszyć odczyt bajtów.

Szczegółowe informacje o obliczeniach i zasobach

DATA_SPILL

Dane rozlały się na dysk podczas wykonywania zapytania, ponieważ dane nie mieściły się w pamięci.

Zalecenie: Zwiększ rozmiar magazynu, aby dodać pamięć. Zmniejsz liczbę wierszy, kolumn lub rozmiar dużych kolumn (ciągów, tablic, map, struktur), aby zmniejszyć użycie pamięci.

EXCESSIVE_QUEUE_TIME

Zapytanie czekało w kolejce magazynu .

Zalecenie: Zwiększ maksymalną liczbę klastrów w magazynie, aby skrócić czas kolejki.

IO_THROTTLING

Żądanie magazynu w chmurze zostało ograniczone przez dostawcę usług w chmurze.

Zalecenie: Skontaktuj się z administratorem, aby poprosić o zwiększenie limitów żądań magazynu od dostawcy usług w chmurze.

Przyspieszenia stosowane

Te wnioski opisują optymalizacje, które Azure Databricks już zastosował podczas wykonywania zapytań. Pojawiają się one w zakładce Performance insights z etykietą Przyspieszone i nie wymagają działania.

AUTO_LIQUID_CLUSTERING

To zapytanie odczytuje mniej danych, ponieważ jego tabele wykorzystują automatyczne klasteryzowanie cieczy. Azure Databricks nieustannie klastruje każdą tabelę według kluczy, których nauczy się z Twojego obciążenia, więc skanowanie pomija pliki, które nie mogą pasować do filtrów. Nie jest wymagane strojenie ani ręczne podziały.

HISTORY_BASED_JOIN_STRATEGY

Azure Databricks zoptymalizował łączenie tego zapytania, wykorzystując pomiary z wcześniejszych przeprowadzeń podobnych zapytań. Wybrał broadcast join zamiast przesuwania danych po klastrze, na podstawie historii obciążeń. Nie jest wymagana zmiana zapytania.

SHORT_QUERY_PRIORITIZATION

Mimo że klaster był na pełnej mocy, Azure Databricks przewidział, że to zapytanie będzie krótkotrwałe i natychmiast przeszedł je przez szybką ścieżkę, zamiast trzymać je w kolejce za cięższymi zapytaniami. Dzięki temu interaktywne obciążenia są responsywne pod obciążeniem.

Dodatkowe zasoby

Aby zapoznać się z szerszym omówieniem najlepszych rozwiązań dotyczących wydajności, zobacz Kompleksowy przewodnik dotyczący optymalizowania obciążeń usługi Databricks, Spark i Delta Lake.