Powolny etap platformy Spark z małą ilością operacji we/wy

Jeśli masz powolną fazę z niewielką ilością operacji wejścia/wyjścia, może to być spowodowane:

• Odczytywanie wielu małych plików
• Pisanie wielu małych plików
• Powolne funkcje UDF (zdefiniowane przez użytkownika)
• Złączenie kartezjańskie
• Łączenie wybuchowe

Prawie wszystkie te problemy można zidentyfikować przy użyciu grupy DAG SQL.

Otwórz DAG SQL

Aby otworzyć DAG SQL, przewiń na górę strony zadania i kliknij pozycję Związane zapytanie SQL:

Powinieneś teraz zobaczyć DAG. Jeśli nie, przewiń nieco i powinieneś to zobaczyć.

Zanim przejdziesz dalej, zapoznaj się z grafem DAG i określ, gdzie jest czas inwestowany. Niektóre węzły w grupie DAG mają przydatne informacje o czasie, a inne nie. Na przykład ten blok trwał 2,1 minuty, a nawet udostępnia identyfikator etapu:

Ten węzeł wymaga otwarcia go, aby zobaczyć, że zajęło to 1,4 minuty:

Te czasy są skumulowane, więc jest to łączny czas spędzony na wszystkich zadaniach, a nie czas zegara. Ale nadal jest to bardzo przydatne, ponieważ są one skorelowane z czasem zegarowym i kosztami.

Warto zapoznać się z tym, gdzie w DAG jest poświęcany czas.

Odczytywanie wielu małych plików

Jeśli widzisz, że jeden z operatorów skanowania zajmuje dużo czasu, otwórz go i poszukaj liczby odczytanych plików:

Jeśli czytasz dziesiątki tysięcy plików lub więcej, być może masz mały problem z plikiem. Pliki nie powinny być mniejsze niż 8 MB. Problem z małym plikiem jest najczęściej spowodowany partycjonowaniem zbyt wielu kolumn lub kolumną o wysokiej kardynalności.

Jeśli masz szczęście, być może wystarczy uruchomić OPTIMIZE. Usługa Databricks zaleca również włączenie optymalizacji predykcyjnej i ponowne rozważenie układu pliku.

Pisanie wielu małych plików

Jeśli widzisz, że zapis trwa długo, otwórz go i poszukaj liczby plików oraz ilości zapisanych danych:

Jeśli piszesz dziesiątki tysięcy plików lub więcej, być może masz mały problem z plikiem. Pliki nie powinny być mniejsze niż 8 MB. Problem z małym plikiem jest najczęściej spowodowany partycjonowaniem zbyt wielu kolumn lub kolumną o wysokiej kardynalności. Należy włączyć optymalizację predykcyjną, ponownie rozważyć układ plików lub włączyć zoptymalizowane zapisy.

Powolne funkcje zdefiniowane przez użytkownika

Jeśli wiesz, że masz funkcji zdefiniowanych przez użytkownikalub zauważysz coś takiego w swoim DAG-u, możesz cierpieć na powolne funkcje zdefiniowane przez użytkownika:

Jeśli uważasz, że cierpisz na ten problem, spróbuj dodać komentarz do funkcji zdefiniowanej przez użytkownika, aby zobaczyć, jak ma to wpływ na szybkość potoku. Jeśli UDF jest naprawdę miejscem, gdzie spędza się czas, najlepszym rozwiązaniem jest przepisanie tej funkcji przy użyciu funkcji natywnych. Jeśli nie jest to możliwe, rozważ liczbę zadań na etapie wykonywania funkcji zdefiniowanej przez użytkownika. Jeśli jest ich mniej niż liczba rdzeni w twoim klastrze, repartition() przekształć ramkę danych przed użyciem funkcji zdefiniowanej przez użytkownika:

  (df
    .repartition(num_cores)
    .withColumn('new_col', udf(...))
  )

Funkcje zdefiniowane przez użytkownika mogą również mieć problemy z pamięcią. Należy wziąć pod uwagę, że każde zadanie może wymagać załadowania wszystkich danych w partycji do pamięci. Jeśli te dane są zbyt duże, rzeczy mogą być bardzo powolne lub niestabilne. Ponowne dzielenie może również rozwiązać ten problem poprzez zmniejszenie każdego zadania.

Złączenie kartezjańskie

Jeśli widzisz sprzężenie kartezjańskie lub sprzężenie zagnieżdżonej pętli w DAG, powinieneś wiedzieć, że te sprzężenia są bardzo kosztowne. Upewnij się, że to było twoim zamiarem i zobacz, czy istnieje inny sposób.

Eksplodowanie sprzężenia lub eksplodowanie

Jeśli zobaczysz kilka wierszy przechodzących do węzła i znacznie większej liczby wychodzących, możesz mieć do czynienia z eksplodującym złączeniem lub użyciem funkcji explode().

Przeczytaj więcej o funkcji "explode" w przewodniku optymalizacji Databricks .