Adaptacyjne wykonywanie zapytań

Artykuł
03/01/2024

Adaptacyjne wykonywanie zapytań (AQE) to ponowna optymalizacja zapytań wykonywana podczas wykonywania zapytania.

Motywacją do ponownej optymalizacji środowiska uruchomieniowego jest to, że usługa Azure Databricks ma najbardziej aktualne dokładne statystyki na końcu wymiany shuffle i emisji (określane jako etap zapytania w AQE). W związku z tym usługa Azure Databricks może zdecydować się na lepszą strategię fizyczną, wybrać optymalny rozmiar partycji i liczbę po przetasowaniach lub przeprowadzić optymalizacje, które były używane do wymagania wskazówek, na przykład obsługi niesymetryczności sprzężenia.

Może to być bardzo przydatne, gdy zbieranie statystyk nie jest włączone lub gdy statystyki są nieaktualne. Jest to również przydatne w miejscach, w których statycznie pochodne statystyki są niedokładne, takie jak w środku skomplikowanego zapytania lub po wystąpieniu niesymetryczności danych.

Funkcje

Usługa AQE jest domyślnie włączona. Ma 4 główne funkcje:

Dynamicznie zmienia sortowanie scalania sprzężenia w sprzężenia skrótu emisji.
Dynamicznie łączy partycje (połącz małe partycje w odpowiednio duże partycje) po zmianie rozmiaru. Bardzo małe zadania mają gorszą przepływność operacji we/wy i mają tendencję do większego obciążenia związanego z planowaniem i konfiguracją zadań. Łączenie małych zadań pozwala zaoszczędzić zasoby i zwiększyć przepływność klastra.
Dynamicznie obsługuje niesymetryczne sprzężenie scalania sortowania i sprzężenie skrótu shuffle przez podzielenie (i replikowanie w razie potrzeby) niesymetrycznych zadań w mniej więcej zadania o równomiernym rozmiarze.
Dynamicznie wykrywa i propaguje puste relacje.

Aplikacja

Usługa AQE ma zastosowanie do wszystkich zapytań, które są następujące:

Brak przesyłania strumieniowego
Zawiera co najmniej jedną wymianę (zwykle w przypadku sprzężenia, agregacji lub okna), jednego zapytania podrzędnego lub obu tych elementów.

Nie wszystkie zapytania stosowane w usłudze AQE muszą zostać ponownie zoptymalizowane. Ponowna optymalizacja może lub nie może wymyślić innego planu zapytania niż statycznie skompilowany. Aby określić, czy plan zapytania został zmieniony przez usługę AQE, zobacz poniższą sekcję Plany zapytań.

Plany zapytań

W tej sekcji omówiono sposób analizowania planów zapytań na różne sposoby.

Interfejs użytkownika platformy Spark

Węzeł `AdaptiveSparkPlan`

Zapytania zastosowane w usłudze AQE zawierają co najmniej jeden AdaptiveSparkPlan węzeł główny każdego zapytania głównego lub zapytania podrzędnego. Przed uruchomieniem zapytania lub jego uruchomieniu isFinalPlan flaga odpowiedniego AdaptiveSparkPlan węzła będzie wyświetlana jako false; po zakończeniu wykonywania zapytania flaga isFinalPlan zmieni się na true.

Ewoluujący plan

Diagram planu zapytania ewoluuje wraz z postępem wykonywania i odzwierciedla najbardziej bieżący plan, który jest wykonywany. Węzły, które zostały już wykonane (w których metryki są dostępne), nie zostaną zmienione, ale te, które nie mogły się zmieniać w czasie w wyniku ponownej optymalizacji.

Poniżej przedstawiono przykład diagramu planu zapytania:

Query plan diagram

`DataFrame.explain()`

Węzeł `AdaptiveSparkPlan`

Zapytania zastosowane w usłudze AQE zawierają co najmniej jeden AdaptiveSparkPlan węzeł główny każdego zapytania głównego lub zapytania podrzędnego. Zanim zapytanie zostanie uruchomione lub gdy jest uruchomione, isFinalPlan flaga odpowiedniego AdaptiveSparkPlan węzła będzie wyświetlana jako false; po zakończeniu wykonywania zapytania flaga isFinalPlan zmieni się na true.

Bieżący i początkowy plan

W każdym AdaptiveSparkPlan węźle będzie dostępny zarówno początkowy plan (plan przed zastosowaniem optymalizacji AQE), jak i bieżący lub końcowy plan, w zależności od tego, czy wykonanie zostało ukończone. Bieżący plan będzie ewoluował w miarę postępu wykonywania.

Statystyki środowiska uruchomieniowego

Każdy etap mieszania i emisji zawiera statystyki danych.

Przed uruchomieniem etapu lub po uruchomieniu etapu statystyki są szacowane w czasie kompilacji, a flaga isRuntime to false, na przykład: Statistics(sizeInBytes=1024.0 KiB, rowCount=4, isRuntime=false);

Po zakończeniu wykonywania etapu statystyki są zbierane w czasie wykonywania, a flaga isRuntime stanie się true, na przykład: Statistics(sizeInBytes=658.1 KiB, rowCount=2.81E+4, isRuntime=true)

DataFrame.explain Oto przykład:

Przed wykonaniem
Podczas wykonywania
Po wykonaniu

`SQL EXPLAIN`

Węzeł `AdaptiveSparkPlan`

Zapytania zastosowane w usłudze AQE zawierają co najmniej jeden węzeł AdaptiveSparkPlan, zwykle jako węzeł główny każdego zapytania głównego lub podrzędnego zapytania.

Brak bieżącego planu

Ponieważ SQL EXPLAIN nie wykonuje zapytania, bieżący plan jest zawsze taki sam jak plan początkowy i nie odzwierciedla tego, co ostatecznie zostanie wykonane przez usługę AQE.

Poniżej przedstawiono przykład objaśnienia sql:

SQL explain

Skuteczności

Plan zapytania zmieni się, jeśli co najmniej jedna optymalizacja AQE zacznie obowiązywać. Efekt tych optymalizacji AQE jest przedstawiony przez różnicę między bieżącymi i końcowymi planami oraz początkowym planem i określonymi węzłami planu w bieżących i końcowych planach.

Dynamicznie zmieniaj sprzężenia scalania sortowania w sprzężenia skrótów emisji: różne fizyczne węzły sprzężenia między bieżącym/końcowym planem a planem początkowym
Dynamiczne łączenie partycji: węzeł CustomShuffleReader z właściwością Coalesced
Dynamiczne obsługa sprzężenia niesymetrycznego: węzeł SortMergeJoin z polem isSkew ma wartość true.
Dynamiczne wykrywanie i propagowanie pustych relacji: część (lub cała) planu jest zastępowana przez węzeł LocalTableScan z polem relacji jako puste.