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 ;)
Pikex napisał(a):
Teraz jest moda bardziej na Spark.
Spark jest czescia ekosystemu Hadoop.
Opowiesz o mozliwosciach Sparkowcow?
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:
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?
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:
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:
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 :)
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 ;)
Aby pisać „sparki” wystarczy podstawowa znajomość Scali. Jeśli znasz Javę i ogarniasz streamy, to powinieneś szybko się wdrożyć.
PinkLion