Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Więc widać na osi czasu zadań luki, takie jak następujące:
Istnieje kilka powodów, dla których może się to wydarzyć. Jeśli luki stanowią dużą część czasu poświęconego na wykonywanie zadań, musisz ustalić, co powoduje te luki i czy jest to oczekiwane, czy wręcz przeciwnie. Istnieje kilka rzeczy, które mogą wystąpić podczas przerw:
- Nie ma do zrobienia żadnej pracy
- Sterownik kompiluje złożony plan wykonywania
- Wykonywanie kodu innego niż spark
- Sterownik jest przeciążony
- Klaster działa nieprawidłowo
Brak pracy
W przypadku obliczeń uniwersalnych, brak pracy do wykonania jest najbardziej prawdopodobnym wyjaśnieniem luk. Ponieważ klaster jest uruchomiony, a użytkownicy przesyłają zapytania, oczekiwane są luki. Te luki to czas między przesyłaniem zapytań. Rozważ użycie zasobów obliczeniowych bezserwerowych . W przypadku bezserwerowych nie zapłacisz za czas bezczynności, co potencjalnie znacznie zmniejsza koszty.
Złożony plan wykonania
Na przykład jeśli używasz withColumn() w pętli, tworzy bardzo kosztowny plan do przetwarzania. Przerwy mogą być czasem, który kierowca spędza na samym budowaniu i przetwarzaniu planu. Jeśli tak jest, spróbuj uprościć kod. Użyj selectExpr(), aby połączyć wiele wywołań withColumn() w jedno wyrażenie lub przekonwertować kod na język SQL. Nadal możesz osadzić kod SQL w kodzie języka Python, używając języka Python do manipulowania zapytaniem za pomocą funkcji ciągów. To często rozwiązuje ten typ problemu.
Wykonywanie kodu innego niż Spark
Kod platformy Spark jest napisany w języku SQL lub przy użyciu interfejsu API platformy Spark, takiego jak PySpark. Każde wykonanie kodu, które nie jest Spark, pojawi się na osi czasu jako przerwy. Możesz na przykład mieć pętlę w języku Python, która wywołuje natywne funkcje języka Python. Ten kod nie jest wykonywany na platformie Spark i może być widoczny jako luka na osi czasu. Jeśli nie masz pewności, czy kod jest uruchomiony na platformie Spark, spróbuj uruchomić go interaktywnie w notesie. Jeśli kod używa platformy Spark, zadania platformy Spark będą widoczne w komórce:
Możesz również rozwinąć listę rozwijaną Zadania platformy Spark w komórce, aby sprawdzić, czy zadania są aktywnie wykonywane (w przypadku, gdy platforma Spark jest teraz bezczynna). Jeśli nie używasz platformy Spark, nie zobaczysz zadań platformy Spark w komórce lub zobaczysz, że żadna z nich nie jest aktywna. Jeśli nie możesz uruchomić kodu interaktywnie, możesz spróbować zalogować się w kodzie i sprawdzić, czy możesz dopasować luki do sekcji kodu według sygnatury czasowej, ale może to być trudne.
Jeśli widzisz przerwy na osi czasu spowodowane działaniem kodu innego niż Spark, oznacza to, że wszyscy pracownicy są bezczynni i prawdopodobnie marnują pieniądze podczas tych przerw. Być może jest to zamierzone i nieuniknione, ale jeśli możesz napisać ten kod do używania Sparka, w pełni wykorzystasz klaster. Zacznij od tego samouczka , aby dowiedzieć się, jak pracować z platformą Spark lub jeśli kod inny niż Spark jest zamierzony, rozważ użycie zasobów obliczeniowych bezserwerowych . W przypadku bezserwerowych nie zapłacisz za czas bezczynności, co potencjalnie znacznie zmniejsza koszty.
Sterownik jest przeciążony
Aby określić, czy sterownik jest przeciążony, należy przyjrzeć się metrykom klastra.
Jeśli klaster znajduje się w środowisku Databricks Runtime 13.0 lub nowszym, kliknij pozycję Metryki wyróżnione na tym zrzucie ekranu:
Zwróć uwagę na wizualizację rozkładu obciążenia serwera. Należy sprawdzić, czy sterownik jest mocno obciążony. Ta wizualizacja ma blok koloru dla każdej maszyny w klastrze. Czerwony oznacza mocno obciążone, a niebieski oznacza wcale niezaładowane.
Na poprzednim zrzucie ekranu przedstawiono zasadniczo bezczynny klaster. Jeśli sterownik jest przeciążony, wyglądałoby to następująco:
Widzimy, że jeden kwadrat jest czerwony, podczas gdy pozostałe są niebieskie. Przerzuć mysz na czerwony kwadrat, aby upewnić się, że czerwony blok reprezentuje twój sterownik.
Aby naprawić przeciążony sterownik, zobacz Przeciążony sterownik Spark.
Klaster działa nieprawidłowo
Nieprawidłowe działanie klastrów jest rzadkie, ale jeśli tak jest, może być trudno ustalić, co się stało. Możesz po prostu ponownie uruchomić grupę, aby sprawdzić, czy to rozwiąże problem. Możesz również przyjrzeć się dziennikom, aby sprawdzić, czy istnieje coś podejrzanego. Karty Dziennik zdarzeń i Dzienniki sterowników, wyróżnione na poniższym zrzucie ekranu, to miejsca, które warto sprawdzić:
Aby uzyskać dostęp do dzienników pracowników, możesz włączyć przesyłanie dzienników klastra. Możesz również zmienić poziom dziennika, ale może być konieczne skontaktowanie się ze swoim zespołem ds. kont Databricks, aby uzyskać pomoc.