Hadoop - mozliwosci

Kto z Was pracuje jako hadoopek?
Czym sie zajmujecie? Jakie mozliwosci na rynku pracy daje znajomosc hadoopa?

Z tego co przesledzilem wydaje mi sie ze mozna zajmowac sie np. raportowaniem, administrowaniem, analiza danych, zasilaniem danych.
W ogloszeniach ze slowem kluczowym hadoop przewijaja sie czesto takie stanowiska jak big data engineer. To cos w stylu chlopca od ETL czy moze cos wiecej?

hadoop to tak 1/4 tego co robie w obecnej pracy.
zajmuje sie dostarczaniem danych rynkowych dla subskrybentow (standardowe real-time l1/l2 ale tez duzo bazujacych na statystyce/ml).
raporty/admin/analiza/etl to czesc obowiazkow, ale to raczej glupoty ktore nie zajmuja za duzo czasu procentowo, tzn raz robisz, wrzucasz do schedulera i dziala.
mysle ze znajomosc hadoopa jest bardziej na zasadzie "nice to have" w cv a nie cos co robisz full time, bo po pierwze to chyba malo kto szuka kogos wylacznie do tego a po drugie nudne to ;)

Teraz jest moda bardziej na Spark.

Pikex napisał(a):

Teraz jest moda bardziej na Spark.

Spark jest czescia ekosystemu Hadoop.
Opowiesz o mozliwosciach Sparkowcow?

Opowiesz o mozliwosciach Sparkowcow?

Jest sporo pracy, glownie w instytucjach finansowych przy przewalaniu danych.

Przewalanie danych to raportowanie i etl?

Pikex napisał(a):

Teraz jest moda bardziej na Spark.

przeciez spark jest czescia hadoopa. zakladam ze jak ktos mowi o znajomosci hadoopa to przynajmniej na poziomie usera zna takie rzeczy jak spark, hdfs, yarn, hive, kafka, flume, hbase itd itp
nie wiem jak to wyglada w innych miejscach bo nigdy nie szukalam pracy jako "data cokolowiek", u mnie wygladalo to tak ze kupilismy kilkadziesiat maszyn, skonfigurowalismy je w klaster, poinstalowalismy hadoopowe komponenty i teraz poza okazjonalnymi optymalizacjami czy failami interakcja z hadoopem sprowadza sie do:

1. konfiguracja i deploy serwisow java/scala/python do schedulera
2. pisanie sparkowych query/modeli

Julian_ napisał(a):

Przewalanie danych to raportowanie i etl?

Bierzesz dane z kilku zrodel laczysz je, filtrujesz i wypluwasz dalej. ETL, SQL i model ;)

katelx napisał(a):

Pikex napisał(a):

Teraz jest moda bardziej na Spark.

przeciez spark jest czescia hadoopa

Wiem, ale mozna go uzywac bez Hadoopa.

Sparka, to myślałem Julian, że już dawno znasz :P

Opowiem, jak to wygląda w data science. Czasami trafiają się takie asy w branży danologów, które zatrzymały się na etapie small data. Z jakiegoś dziwnego powodu prędzej czy później gdzieś znajdują pracę. Zauważyłem, że zazwyczaj są to osoby po SGH, albo po jakiejś innej socjologii czy statystyce stosowanej. Zagadka rozwiązała się, czy gdy rekruterka przez przypadek wysłała do mnie CC: z korespondencją innej osoby, dzięki czemu poznałem jej zarobki. Okazało się, że co niektórzy są tańsi od karaluchów, tańsi od meksykanów, więc ich zatrudniają.

Ktoś wyżej pisał coś o zarządzaniu klastrem. Współczuje tym którzy nie mają devops/mlops i data inżynierów w firmie.

dzika_kuna napisał(a):

Ktoś wyżej pisał coś o zarządzaniu klastrem. Współczuje tym którzy nie mają devops/mlops i data inżynierów w firmie.

mozesz rozwinac? devops wydaje mi sie typowo korpo wynalazkiem, kolejna sztuczna i bezuzyteczna na poziomie indywidualnego zespolu rola zaraz obok BA, QA i architekta.
w mojej firmie jest 10 osob technicznych. trzymanie dedykowanego devopsa zeby zainstalowal teamcity czy kafke to bylby niezly zart...

Z moich obserwacji Hadoop jako stack (YARN + HDFS + Hive) to raczej jest dalej używany w większości w instytucjach finansowych (banki, ubezpieczenia, ...), ale bardziej z powodów prawnych niż technicznych. Tak przynajmniej wynika z dyskusji z ludźmi po meetupach. I jeśli Hadoop, to rzadko jako samo utrzymywalny stack, a częściej jako dystrybucja Cloudera Hortonworks. Ku precyzji, to co napiszę, to wynik mojej obserwacji rynku francuskiego, a przez "obserwuję" mam na myśli oferty o pracę, konferencje, blogi.

Jeśli chodzi o szerzej rozumiane Big Data (chociaż wolę termin data engineering), to firmy skłaniają się w stronę cloudowych rozwiązań. Dlaczego?

• koszty devops - trudno znaleźć devopsów, a tych dobrych jeszcze trudniej. Minimalizuje się więc koszty infrastruktury w projektach.
• scaling - to, że dzisiaj potrzebujesz 10 node'ów, żeby przetworzyć 1TB nie znaczy, że jutro jak będziesz miał 2TB, to łatwo dodasz sobie 10 kolejnych. W chmurze takie dylematy są o wiele mniej poważne - istnieją, bo nie możesz sobie w nieskończoność dodawać node'ów, tworzyć 2 tysięcy klastry itd, bo na wszystko prawie są limity, ale skalowalność jest o wiele bardziej elastyczna
• ludzie - mało kogo dzisiaj bawi praca w stylu "kurcze, mam 10% miejsca na dysku, musimy dodać nową maszynę - piszę ticket do IT, IT kupuje serwer, a ja przez 5 dni biję się z myślami, jak grać z danymi, żeby ich nie stracić" (karykatura, ale coś w tym jest)

Oczywiście, nie umniejszam znajomości Hadoop. Sam od tego zaczynałem i się cieszę, bo można znaleźć wiele odpowiedników w serwisach chmurowych, a część z nich jest nawet implementowana (np. EMR w AWS). Ale nie samym Hadoopem człowiek żyje i tak:

• MapReduce - nie widziałem, żeby ktoś tego dzisiaj wymagał. Spark z OS, trochę mniej Flink, a z cloudowych to Dataflow i Databricks (serverlessowe rozwiązania)
• YARN - Kubernetes wydaje się go wygryzać do wysyłania jobów na cluster - nie mylić ze schedulingiem
• Oozie - Airflow jest o wiele bardziej elastyczny, przypomina coś w rodzaju Infrastructure As Code, nawet jeśli chodzi tylko o joby, które schedulujesz
• Hive - z moich obserwacji jeden z ostatnich bastionów Hadoopa, który jako tako jest na rynku wymagany
• HDFS - zastąpiony przez tańsze w utrzymaniu serwisy do przechowywania obiektów (S3, GCS)
• HBase - BigTable, DynamoDB, łatwo skalowalne, DynamoDB oferuje nawet możliwość streamingu zapisywanych danych
• streaming broker - jeśli mnie pamięć nie myli, nie istnieje w stacku Hadoopa

Reasumując, Hadoop jako narzędzie do pierwszej pracy - nie. Raczej radziłbym opanować serwisy data jednego z chmurowych dostawców (GCP wydaje się zyskiwać na popularnośći, ostatnio nawet Twitter na niego przeszedł (https://cloud.google.com/twitter/). A co do OS rozwiązań, to:

• Kafka do streamingu
• Spark do przetwarzania danych
• Kubernetes do wykonywania programów (resurce manager)
• i później jakieś bazy NoSQL, co kto woli, ja zaczynałem od Cassandry (łatwiej zrozumieć DynamoDB), Elasticsearch (do dokumentów i wyszukiwarki). Pracowałem też z Neo4J, ale akurat ciężko się go skalowało
• nieśmiertelny SQL - ignorowałem go przez długi czas, ale po jednym projekcie typowo ETL-owym, bazującym na SQL, przekonałem się jakie możliwości oferuje
• Python i Scala jeśli piszez w Javie - subiektywne odczucie, ale te 2 języki dzisiaj są najczęściej przypisywane do przetwarzania danych

Jeśli jesteś ciekawy info o tych technologiach, to bloguję o nich, i o przetwarzaniu danych, na https;//www.waitingforcode.com .

No i to tyle :)

A co sadzicie o Apache Sqoop?

bartosz25 napisał(a):

Z moich obserwacji Hadoop jako stack (YARN + HDFS + Hive) to raczej jest dalej używany w większości w instytucjach finansowych (banki, ubezpieczenia, ...), ale bardziej z powodów prawnych niż technicznych.

to fakt, wlasnie to jest glownym powodem dla ktorego postawilismy to u siebie, umowy z klientami (glownie hedge funds) nie bardzo pozwalaja na wysylanie danych byle gdzie. uzywamy tez azure ale wylacznie do danych agregowanych, mamy audyt ktory to sprawdza.

Jeśli chodzi o szerzej rozumiane Big Data (chociaż wolę termin data engineering), to firmy skłaniają się w stronę cloudowych rozwiązań. Dlaczego?

ciezko mi uwierzyc zeby struktura mojego zespolu oraz jednoczesne zarzadzanie klastrem (tickety! :), etl i wlasciwymi appkami klienckimi moglo sie wydarzyc w typowym banku inwestycyjnym, po prostu typowy model zarzadania it w takiej organizacji zaklada separacje rol i procedury uniemozliwiajace efektywna prace.

• MapReduce - nie widziałem, żeby ktoś tego dzisiaj wymagał. Spark z OS, trochę mniej Flink, a z cloudowych to Dataflow i Databricks (serverlessowe rozwiązania)

chyba zbedne majac sparka...

• YARN - Kubernetes wydaje się go wygryzać do wysyłania jobów na cluster - nie mylić ze schedulingiem

yarn wydaje sie duzo prostszy do zarzadzania zasobami

• Oozie - Airflow jest o wiele bardziej elastyczny, przypomina coś w rodzaju Infrastructure As Code, nawet jeśli chodzi tylko o joby, które schedulujesz

oozie to generalnie porazka, jesli chodzi o scheduling to juz chyba lepiej sobie crona postawic i jakas kolejke w bazie danych ;)

Julian_ napisał(a):

A co sadzicie o Apache Sqoop?

mysle ze dosc niszowa sprawa, w praktyce uzywanie dodatkowego toola do importu danych z bazy relacyjnej wydaje mi sie przerostem formy nad trescia bo malo kto daje dostep do bazy danych, juz predzej sra csv do jakiegos sftp etc

Julian_ napisał(a):

Przewalanie danych to raportowanie i etl?

Napisalem nizej/wyzej. Czasami jest to polaczenie danych z kilku zrodel i odfiltrowanie niepotrzebnych informacji. Czasami jeszcze przepuszczenie przez dodatkowe reguly. Przygotowanie raportu ile sie poprawnie przetworzylo a ile nie. Nic specjalnego, zwykle mielenie danych, tyle ze w wiekszej ilosci ;)

Scala jest podobno znacznie trudniejsza od javy, na jakim poziomie trzeba obcykac scale by smigac nia po api sparkowym?

Aby pisać „sparki” wystarczy podstawowa znajomość Scali. Jeśli znasz Javę i ogarniasz streamy, to powinieneś szybko się wdrożyć.