Databricks job aborted?
Problem
Ładujesz dane do Databricks. Skrypt uruchamiałeś już dziesiątki razy. Tym razem jednak dostałeś komunikat: "Job aborted". To jest główny, podobno najbardziej znaczący komunikat błędu.
Próbujesz ponownego uruchomienia? Dzwonisz do wsparcia technicznego?
Jakie rozwiązania możesz zaproponować?
Propozycje rozwiązań
Co można zasugerować do puli rozwiązań?
- Klaster znalazł się w nieokreślonym stanie i wymaga restartu?
- Pliki Delta stały się nieczytelne, zostały zniszczone, uszkodzone lub nie ma do nich dostępu
- Zabrakło pamięci na przetwarzanie
- Zmiany w danych spowodowały, że job został anulowany
Databricks job aborted - Problemy z klastrem
Błąd, który dostałeś wygląda w ten sposób:
Jeżeli kluster przestał odpowiadać i błąd jest nie tylko w tym jednym przetwarzaniu ale w wielu, wtedy masz winowajcę. Uruchamiasz ponownie cluster, startujesz joby i gotowe.
Jeżeli to nie jest Twój przypadek to co powiesz na:
Restart.
To jedna z prostszych rzeczy które można zrobić. Niestety czasami cluster jest zajęty innymi przetwarzaniami. Nie możesz uruchomić go ponownie, bez oczekiwania na zakończenie innych przetwarzań.
Uruchomienie notebooka na innym klustrze, pokaże czy błąd był spowodowany błędną konfiguracją klustra. Jeżeli tak, to masz winowajcę.
Czasami może jednak się okazać, że przetwarzania nie możesz ponowić i wyizolować i uruchomić jeszcze raz.
W moim przypadku restart clustra nie pomógł.
Trzeba zasugerować inne rozwiązanie.
Uszkodzone pliki
Jeżeli pliki są nie czytelne to znaczy, że nie da się przeczytać danych z tabel, na których pracujesz.
Jakie powinny być inne objawy choroby uszkodzonych plików?
Czytanie z nich powinno też dać błąd.
Czyli na przykład, gdy będziesz próbował dane z jednej tabeli zapisać do innej, tymczasowej tabeli, tylko na potrzeby testów, wtedy możesz stwierdzić czy z danymi jest wszystko dobrze.
Jak widzisz w powyższym przykładzie zapisuje dane do tabeli tymczasowej zds_part
W moim przypadku udało się czytać z tabeli. Czyli pliki nie były skorumpowane.
Brakuje pamięci na przetwarzanie
Kod błędu nie wskazuje na ten problem. Nie dostaliśmy sławnego java.lang.OutOfMemoryError. Ale też nie wiemy do końca co się stało. Więc warto sprawdzić szczegóły.
Przeglądając długi jak poemat "stack trace" znalazłem odniesie w którym etapie (stagu) jest błąd.
Zaczyna robić się interesująco.
Znajdźmy teraz ten stage i zobaczmy co tam jest ciekawego.
W stagu możesz podejrzeć logi Sparka. Nas interesuje to co znalazło się na wyjściu z błędem czyli stderr.
Czytając logi znajdziemy w którym miejscu jest błąd: "Failed to store executor broedcast".
Ale to co jest ciekawe jest kilka linijek wyżej:
Not enough space to cache
Czyli cache, którego próbował użyć Spark jest zbyt mały.
Ot całe rozwiązanie zagadki.
Gdzie jeszcze job aborted?
Brak pamięci to nie jedyna przyczyna job aborted. Ta lista powinna być zapewne dłuższa.
Wstawianie danych do tabeli też kończy się u mnie czasami błędem "Job aborted" i nie dostaje żadnych więcej szczegółów. Czytanie logów sparka i tym razem doprowadzi do rozwiązania.
Miałem przypadek, gdy wstawiałem dane do tabeli a metadane były innego typu. Czyli na przykład do kolumny "date" wstawiałem string. Albo do kolumny typu bigint próbowałem wstawić string.
Błąd związany z typami danych dawał błąd: "Job aborted".
Podsumowując, "Job aborted" był skutkiem:
- Braku pamięci
- Niekompatybilnych matadanych