Jak zacząć pracę w Big Data? Moja Historia

Jak zacząć pracę w Big Data? Moja Historia

Jeśli myślisz o pracy w branży Big Data to sądzę, że zainteresuje Cię to, co chcę opowiedzieć.

W tym artykule cofniemy się do zeszłego roku (2022). Wyjaśnię, jak znalazłem rozwiązanie na wybranie odpowiedniej technologii i z jakimi przeszkodami się zmagałem szukając “furtki” do świata Big Data;-).

Zanim usłyszałem o Big Data

Początek roku był mglisty ze względu na to, że miałem kilka podejść do różnych technologii. Już wcześniej zdobyłem podstawowe umiejętności programowania obiektowego w Pythonie. Znałem również podstawy webdevu oraz relacyjnych i nierelacyjnych baz danych. W pracy używałem zarówno Pythona, jak i Javy do realizowania testów automatycznych, które pisałem i dokumentowałem (pozdro shared service). Ciągnęło mnie do wszystkiego, co się świeciło, w związku z czym zacząłem nawet czytać o Ruscie, myśląc o tym żeby zrealizować w nim pracę inżynierską (na szczęście odrzuciłem ten pomysł odpowiednio wcześnie).

Na przełomie drugiego kwartału dostałem zaproszenie do zaangażowania się w projekcie Javowym, ale ta technologia mnie przerosła – brak rzeczywistego doświadczenia w webdevie oraz poziom skomplikowania aplikacji z pewnością odegrał tu swoją rolę.

Mijał czas, a ja wciąż nie wiedziałem w którą stronę się rozwijać. Byłem niesamowicie sfrustrowany – i słusznie. Wpadłem na pomysł, aby do realizowania projektów wykorzystać równie pragnących (jak wtedy myślałem) rozwoju znajomych. Średnio to wyszło, ale cieszę się, że mimo mojej ówczesnej natarczywości jeszcze ze mną rozmawiają. Czas nieubłaganie mijał, a obrona mojej pracy inżynierskiej zbliżała się wielkimi krokami, więc postanowiłem działać. Z wykorzystaniem Flaska oraz Selenium stworzyłem WATS, czyli Web Automation Testing Simplified. Aplikację, która potwierdziła naszą tezę, mówiącą o tym, że testy automatyczne tworzy się dość łatwo i może to robić osoba niekoniecznie techniczna. I co najlepsze, działa i wygląda!

Dane, machine learning i… kolejne frustracje

Gdy napisałem aplikację do pracy inżynierskiej, poczułem że Python nie jest wcale takim prostym narzędziem (to złudne przeświadczenie narosło we mnie, kiedy próbowałem nauki języków kompilowanych). Aby zgłębić bardziej ten język postanowiłem zainteresować się uczeniem maszynowym. Nie rozumiałem matematyki idącej za algorytmami uczenia maszynowego, ale samo sprzątanie danych i robienie z nich rzeczywistego użytku w postaci wykresów zrobiło na mnie ogromne wrażenie. Postanowiłem bardziej się w to zagłębić. Spojrzałem ile zarabiają MLOpsi. Chciałem tyle samo. Zacząłem cisnąć temat. Zrobiłem certyfikaty Azure, aby zapoznać się bardziej z tematem chmur, danych oraz AI (były za darmo kiedy się uczęszczało na Virtual Training Day, kiedyś to było…). Jednak stanąłem przed ścianą, której nie mogłem pokonać.

Brak wiary w swoje możliwości, który wynikał z niezrozumienia algebry, nasilił się jeszcze bardziej wraz z realizowaniem zaawansowanych technik wytwarzania modeli uczenia maszynowego. Chciałem wejść w temat, jednak nie mogłem. Byłem na siebie zły z powodu wyboru uczelni, ponieważ nie poszedłem na Informatykę na studia dzienne. Postanowiłem, że powinienem obrać inną ścieżkę.

Zdając sobie sprawę że nie zostanę Data Scientistem, postanowiłem się uczyć metodologii DevOpsu. Jenkins, Docker, K8s, Ansible. Szło naprawdę dobrze, nawet ogarnąłem ładnie Jenkinsa oraz Dockera, ale odczułem, że pociąg już odjechał, a bez Kubernetesa nie ma co podchodzić do rekrutacji na juniora. Nie miałem też nikogo, kto mógłby mnie wyprowadzić z tego błędu.

Big Data – pierwsze spojrzenie

Znajomy raz podrzucił mi pomysł Data Engineeringu. Olałem to, bo pomyślałem że nic w tym ciekawego. Sprzątać dane, żeby inni mogli robić to, co jest najbardziej interesujące? To było w momencie, kiedy wypalałem się tematem ML, ale jeszcze nie upadłem przed ścianą.

Był późny grudzień, a ja nie miałem żadnych postanowień noworocznych. Na LinkedIn pojawił mi się artykuł Marka, który ogłaszał zapisy na szkolenie Fundament Sparka. Podczas nauki Data Science widziałem jakieś sugestie o Sparku, że ma bibliotekę do ML, do konkretnego Data Engineeringu oraz do analizy danych w zbiorach oraz streamowanych i że można go postawić na tanich kompach. Podobało mi się, że to narzędzie jest tak potężne, a na dodatek moja dotychczasowa edukacja pozwalała mi na łatwe wejście w temat. Postanowiłem, że zapiszę się na kurs. W końcu najlepsza inwestycja to ta w siebie. Nie myliłem się.

Po przerobieniu kursu zaintrygowany możliwościami Sparka, pythonową zwinnością i javową elegancją Scali w połączeniu z nowym dla mnie programowaniem funkcyjnym, podjąłem decyzję o dalszym rozwoju w stronę Data Engineeringu. Postanowiłem przerwać pasmo niepowodzeń i plątania się po technologiach.

Big Data – “all in”!

Ukończywszy kurs, Marek zaproponował mi udział w programie mentoringowym. Zależało mi na zmianie pracy, spróbowałem. Szeregowaliśmy wiedzę, siedzieliśmy na spotkaniach i podejmowaliśmy po kolei tematy, metodycznie. Jednocześnie, ciągle wysyłałem CV. Miesiąc po zakończeniu kursu dostałem propozycję pracy przy Sparku jako Big Data Support Engineer.

Uważam to za sukces mój, jak i Marka, bo bez uszeregowanej wiedzy przekazanej w dobry sposób i przygotowania pod względem technicznym do wykonywania tej pracy prawdopodobnie nie byłoby tak łatwo. Albo co gorsza, znowu bym się pogubił.

Dlatego, z pełnym przekonaniem, jeżeli się zastanawiasz czy mentoring to dobry pomysł, to uwierz mi, że jest. Nieważne na jakim poziomie zaawansowania, warto mieć opatrzność drugiej osoby, zwłaszcza z doświadczeniem.

Aktualnie, wraz z drugim uczestnikiem programu mentoringowego realizujemy projekt wykorzystujący realne dane (które sami pozyskujemy i przechowujemy :)) w środowisku okołoprodukcyjnym. Wykorzystujemy techniki, sposoby wytwarzania oprogramowania oraz standardy projektowe takie, jakie znajdziesz w realnym produkcyjnym środowisku. Oczywiście, głównym fundamentem jest Scala oraz Spark.

Pracuję również nad swoim blogiem technologicznym, w którym będę opisywać napotykane problemy, obserwacje oraz wnioski i mam nadzieję, że skończę to w niedalekiej przyszłości. 🙂

Zwieńczając to wszystko, bardzo się cieszę, że postawiłem na Fundament Sparka i Program Mentoringowy RDF – mocny kickstart dla kariery w danych.


A teraz czas na “Słowo od Mentora” 😉

Rafał od samego początku wykazywał OGROMNY zapał, był niezwykle pracowity i metodyczny. Bez tego nawet oferta podana na tacy nic by nie zdziałała;-).

Gratuluję! I… jestem dumny:-).

UWAGA! Jeśli Ciebie również interesuje mentoring…

Po prostu napisz na marek.czuma@riotechdatafactory.com.

Ułożymy razem plan i ruszymy z działaniem.

Akurat pojawiło się kilka wolnych miejsc, więc nie czekaj;-)

W poniższym wideo mówię ciut więcej na temat mentoringu. Jeśli masz pytania – po prostu do mnie napisz.

Pamiętaj! Zawsze jesteś mile widziany/a

Spark: czemu jedna akcja tworzy wiele jobów?

Spark: czemu jedna akcja tworzy wiele jobów?

Zgłębiając kwestie wydajnościowe zauważyłem, że dzieje się coś dziwnego: jedna akcja generuje wiele jobów. Postanowiłem to sprawdzić i opisać tutaj:-). Śmiało, częstuj się. A jeśli artykuł okaże się przydatny – podziel się nim na LinkedIn… czy gdziekolwiek chcesz.

Kawka w dłoń i ruszamy!

Podstawy – jak działa aplikacja sparkowa?

Bardzo często mówiąc o tym, że piszemy w sparku, mówimy “muszę napisać joba sparkowego”, “mój job szedł 30 godzin!” i inne.

Cóż… według nomenklatury sparkowej, nie jest to poprawne. Co gorsza – może być nieco mylące. Okazuje się bowiem, że to co nazywamy “jobem sparkowym” (czyli cały kod który ma coś zrobić i jest uruchamiany przy użyciu sparka) to tak naprawdę “aplikacja” (application). Aplikacja natomiast składa się z… jobów.

Nie mówię, że masz dokonywać rewolucji w swoim słowniku. Sam zresztą też chwalę się ile to nie trwał “mój job”;-). Pamiętaj jednak, że prawdziwe joby siedzą pod spodem aplikacji.

No dobrze – ale czym dokładnie są te joby? I jak jest zbudowana aplikacja sparkowa? Oczywiście to nie miejsce na szkolenie (na listę oczekujących kursu online “Fundament Apache Spark” możesz zapisać się tutaj). Spróbujmy jednak bardzo pokrótce zrozumieć jak zbudowana jest taka aplikacja.

Zróbmy to w kilku krokach:

  1. Podczas pisania kodu posługujemy się dwoma rodzajami: akcjami i transformacjami:
    • transformacje pozwalają nam przetworzyć RDD/Dataset na inny RDD/Dataset. Nie są jednak wykonywane od razu (lazy evaluation)
    • akcje z kolei wykonują wspomniane wcześniej transformacje i tym samym kończą pewną robotę do zrobienia – czyli joba;-).
  2. Job, czyli praca do wykonania. No właśnie – mamy kilka transformacji, które składają się w jeden ciąg operacji dokonywanych na danych. Na końcu są np. zapisane na HDFS albo wyświetlone na ekranie. I to jest właśnie 1 job. Tak więc powiedzmy to sobie wreszcie – 1 akcja = 1 job, yeeeaahh!
  3. Czyli w aplikacji może być kilka jobów. To teraz kolejne zagłębienie. Job składa się ze… stage’y. Czyli z etapów. Jak to się dzieje? Wróćmy do transformacji – bo na tym etapie mamy tylko z transformacjami do czynienia (w końcu akcja kończy joba).
    • Transformacje też możemy podzielić!
    • Narrow Transformations – gdy transformacje z jednej partycji wyprowadzają dokładnie jedną partycję. Narrow Transformations (np. filtry) są dokonywane w pamięci.
      • przykłady: filter, map, union, sample, intersection
    • Wide Transformations – gd transformacje wyprowadzają z jednej partycji wejściowej kilka partycji wyjściowych. Tutaj, ponieważ wide transformations powodują shuffling, dane muszą zostać zapisane na dysk.
      • przykłady: groupBy, join, repartition (te trzy, szczególnie dwa pierwsze, to klasyki – postrachy inżynierów sparkowych)
    • No i właśnie dlatego, że wide transformations powodują shuffling (przemieszanie danych między partycjami/executorami/nodami), musi zakończyć się jakiś etap joba. Czyli stage;-).

I można by kilka rzeczy dodać, ale tyle wystarczy, a nawet może zbyt wiele.

Nie mogłem jednak się powstrzymać. Uff… liczę, że jeszcze ze mną jesteś!

Ale dlaczego jedna akcja tworzy wiele jobów?!

Wspomniałem wyżej, że jednej akcji odpowiada jeden job w aplikacji. Jakie było moje zdziwienie, gdy zobaczyłem co następuje.

Oto mój kod. Przykładowy, ćwiczeniowy, prosty do zrozumienia (zmienna spark to instancja SparkSession):

val behaviorDF: Dataset[Row] = spark.read
  .option("header", "true")
  .csv(pathToBehaviorFile)

behaviorDF.show()
val brandCountDF: Dataset[Row] = behaviorDF.groupBy("brand")
  .count()
  .as("brandCount")

val userIdCount: Dataset[Row] = behaviorDF.groupBy("user_id")
  .count()
  .as("userCount")

val behaviorsWithCounts: Dataset[Row] = behaviorDF.join(brandCountDF, "brand")
  .join(userIdCount, "user_id")

behaviorsWithCounts.show(20)

 

Jak widać mamy dwie akcje:

  1. behaviorDF.show() – linijka 23 (w rzeczywistości)
  2. behaviorsWithCounts.show(20) – linijka 35 (w rzeczywistości).

Czyli z grubsza powinny być 2, może 3 joby (jeśli liczyć także wczytywanie danych).

Co zastałem w Spark UI?

WHAAAT…

Jak to się stało?

Czemu mam… 5 różnych jobów do akcji z linijki 35?

Otóż – mogą być za to odpowiedzialne dwie rzeczy:

  1. DataFrame to abstrakcja zbudowana na RDD. 1 akcja odpowiada 1 jobowi, ale… na RDD. Dataframe czasami “pod spodem” może wykonywać jeszcze inne akcje. JEDNAK TO NIE TO BYŁO MOJE ROZWIĄZANIE. Dotarłem do takiego wyjaśnienia więc się nim dzielę. U mnie natomiast DUŻO WAŻNIEJSZY okazał się pkt 2.
  2. Włączone Adaptive Query Execution – czyli mechanizm optymalizacyjny Apache Spark. Może być włączony albo wyłączony. Od Sparka 3.2.0 AQE włączone jest domyślnie!

Po ustawieniu prostej konfiguracji “spark.sql.adaptive.enabled” na “false”, jak poniżej…

val spark: SparkSession = SparkSession.builder()
  .appName("spark3-rdf-tests")
  .config("spark.sql.adaptive.enabled", false)
  //      .master("local[*]")
  .getOrCreate()

 

… i uruchomieniu aplikacji raz jeszcze, efekt w 100% pokrył się z moją wiedzą teoretyczną.

OMG CO ZA ULGA

UWAGA! Warto pamiętać, że AQE jest z zasady dobrym pomysłem. Nie wyłączaj tego, jeśli nie wiesz dokładnie po co to chcesz robić.

Ja na przykład wyłączam w celach edukacyjnych;-)


Szkolenie z Apache Spark – może tego właśnie potrzebujesz?

Jeśli reprezentujesz firmę i potrzebujecie solidnie przeczołgać się ze Sparka… jesteśmy tu dla Was!

Mamy solidnie sprawdzoną formułę.

I własny klaster, na którym poeksperymentujecie;-)

Więcej informacji na tej stronie.

Możesz też po prostu napisać na: kontakt@riotechdatafactory.com !


Co to jest Adaptive Query Execution?

No to teraz pokrótce: co to jest Adaptive Query Execution?

Przeczytasz o tym w dokumentacji Sparka, o tutaj.

Mówiąc jednak prosto i zwięźle: Adaptive Query Execution to mechanizm zawarty w Spark SQL, który pozwala zoptymalizować pracę aplikacji. AQE dokonuje optymalizacji bazując na “runtime statistics”. Temat samych statystyk będę poszerzał w przyszłości tutaj lub na kanale YouTube. Zapisz się na newsletter, żeby nie przegapić;-). I przy okazji zgarnij jedynego polskiego ebooka wprowadzającego w branżę Big Data (i to kompleksowo!).

AQE ma 3 podstawowe funkcjonalności:

  1. Łączenie partycji po shufflingu – dzięki temu mechanizmowi bardziej wydajnie dobierane są partycje. Widać to m.in. na powyższym przykładzie – gdy porównasz liczby partycji w obu przypadkach.
  2. Dzielenie partycji ze “skośnościami” po shufflingu (data skewness) – spark będzie optymalizował partycje, które podlegają “skośności” (są zbyt duże, co wychodzi dopiero po shufflingu).
  3. Zamiana “sort-merge join” na “broadcast join” – zamienia jeśli statystyki którakolwiek strona joina jest mniejsza niż poziom pozwalający na taką operację.

W praktyce AQE daje zauważalne rezultaty. Widać to dość symbolicznie na mojej małej aplikacji (ładuję tam jedynie 5 gb z hakiem), gdzie wynik z ~5.4 min zszedł do ~5 min.

Minusy? Przede wszystkim mniejsza czytelność podczas monitoringu joba. Co z jednej strony może wydać się śmieszne, ale w rzeczywistości, gdy musimy zoptymalizować jakąś bardzo złożoną aplikację – może zrobić się uciążliwe.

Podsumowanie

Podsumowując:

  1. Od Sparka 3.2.0 domyślnie włączony jest Adaptive Query Execution.
  2. To mechanizm, który pozwala na bardzo konkretną optymalizację. Powoduje niestety pewne “zaszumienie” monitoringu aplikacji.
  3. W efekcie zamiast zasady 1 akcja = 1 job, nasza aplikacja będzie bardziej porozbijana.
  4. Można to wyłączyć (aby nie zachęcać do pójścia “na łatwiznę” – jak to zrobić zostało zawarte w tekście;-)). Nie rób jednak tego bez solidnej argumentacji.
  5. Zapisz się na newsletter i przeczytaj ebooka, który pokaże Ci Big Data z kilku różnych storn. A jak Ci się spodoba, napisz o tym w sieci żeby i inni wiedzieli:-).

Jeśli natomiast szukasz czegoś, co pokaże Ci podstawy Sparka od A do Z… 

Może sprawdzisz kurs “Fundament Apache Spark”?

“Podobno” niektórzy od tego kursu… zaczęli całą przygodę z branżą;-).