big data

Na co zwracać uwagę rekrutując “świeżaka” do działu Big Data?

Na co zwracać uwagę rekrutując “świeżaka” do działu Big Data?

Marek Czuma

Jeśli odpowiadasz za rozwój działu Big Data w Twojej firmie, podstawą jest oczywiście solidny zespół. Dziś chciałbym dać kilka subiektywnych rzeczy, na które można zwrócić uwagę podczas rekrutacji. Liczę, że pomogą dobrać odpowiednie osoby i w konsekwencji zbudować znakomicie działający mechanizm;-).

Na samym początku dajmy dwa założenia:

  1. Rekrutujemy “świeżaka”, który dopiero będzie doszkalany, lub będzie szlifował podstawową wiedzę.
  2. Raczej skupię się na procesie samej rozmowy i tego co zrobić wokół niej. Kwestie techniczne dotyczące wynajdywania takich osób zostawiam HRom;-).

Zacznij rozmowę i… bądź człowiekiem, z którym chce się pracować!

Zanim przejdziemy do 6 rzeczy, które uważam za istotne – najpierw drobna uwaga. Choć zwykło się sądzić, że rozmowa rekrutacyjna jest pewnego rodzaju “odpytką”, zwracam na piękne podejście języka polskiego do tej sprawy. Otóż – mamy tu do czynienia z rozmową. To sugeruje, że mamy dwie strony, które w pewnym zakresie powinny się traktować po partnersku (trochę to inaczej wygląda niż “interview” prawda?;-)). Dokładnie tak powinniśmy podchodzić do rozmowy – chociaż my reprezentujemy firmę, mamy lepszą pozycję i więcej pewności siebie – nie daj się skusić aby wykorzystać to do podbudowania swojego ego.

Pamiętaj, że także aplikant jest stroną. Oznacza to, że także i firma musi się spodobać jemu! Jest to szczególnie silne w dzisiejszej sytuacji, gdzie w Polsce IT jest książkowym przykładem rynku pracownika. A więc co zrobić? Przede wszystkim stań na rzęsach, żeby człowiek z którym rozmawiasz, poczuł się swobodnie.

Druga rzecz która jest z tym związana, to prawdziwe przetestowanie umiejętności aplikanta. Nie, nie zrobimy tego tworząc stresowe sytuacje. No, chyba że rekrutujesz do sił specjalnych. W większości sytuacji jednak, budując zespół Big Data warto zadbać o takie luźne podejście. To właśnie wtedy możemy przetestować najbardziej umiejętności. Uśmiechnij się, zażartuj, zadaj proste pytanie “na rozruch”. Niech kandydat poczuje się pewnie – wtedy wyjdzie z niego maksimum jego wiedzy.

Daruj sobie wszelkiego rodzaju kodowanie “live”, na oczach ekipy rekrutującej. Już słyszę głosy oburzenia – “ale ale, muszę przetestować jak działa w sytuacjach stresowych!”. Nie prawda, nie musisz. Poza tym, nawet jeśli w naszej robocie jest stres, to nie wynika on z tego, że szef patrzy przez ramię (a jeśli tak, to czas zreformować się od środka). Stres stresowi nie jest równy. Jeśli chcesz przetestować możliwości koderskie, powiedz że wyjdziesz zrobić sobie (rozmówcy?) kawę i wrócisz za 15 minut.

Pomijam oczywiście różne dziwne pytania typu o to jakim zwierzęciem byłbyś. Cóż… rozmawiając, po prostu dążmy do tego, żeby sprawdzić czy to dobry fachowiec oraz czy będzie pasował do zespołu. Tylko tyle i aż tyle. Nie róbmy sztuki dla sztuki.

ZAWSZE pamiętaj, że aplikant jest stroną!

A już teraz przechodzimy do 6 rzeczy, na które ja zwracam uwagę, rozmawiając z nowymi koleżankami i kolegami!

Wiedza teoretyczna

Zacznijmy od najbardziej banalnej rzeczy. Oczywiście podstawą wszystkiego jest posiadanie wiedzy teoretycznej. O ile na późniejszych etapach sprawdzać ją można nieco inaczej, to w przypadku “świeżaka” po prostu trzeba zadawać pytania i słuchać odpowiedzi. Najlepiej, żeby pytania były dość standardowe. Być może to kogoś oburzy, ale naprawdę wielu rzeczy można się nauczyć – nie trzeba od kompletnego nowicjusza oczekiwać zagwozdek Scalowych czy Javowych, bo realnie to tylko jedno z bardzo wielu narzędzi (choć jest fundamentalne!).

Warto jednak, żeby znał podstawy, szczególnie te “sztampowe”. To właśnie pytania, które można znaleźć wpisując w DuckDuck Go (;-)) “java interview questions”. Co to może być? Kilka podpowiedzi – niezależnie od tego czy rekrutujemy osobę dopiero do przeszkolenia, czy Inżyniera Big Data w stopniu juniora.

  1. [Java] Interfejs a klasa abstrakcyjna, enkapsulacja, kolekcje, co robi dany kod, streamy.
  2. [Scala] Trait a klasa abstrakcyjna, konstruktory, paradygmat funkcyjny w scali (ogólnie), opisać map/filter/foldLeft, companion objecty, package objecty, czym jest podłoga/underscore (jak powie że wszystkim i niczym, albo że czymkolwiek to śmiało zaliczaj;-)).
  3. [Bazy Danych] czym są relacyjne bazy danych, co to jest klucz obcy, czym jest SQL, rozwiązać przykładowe zadanie z SQL, działanie indeksów.

Powyższe pytania są do każdego. Dalej kwestia się rozdziela w zależności od tego czy jest kimś, kto ma bardzo luźny związek z Big Data, czy to jednak już jakiś początkujący.

Osoba do przeszkolenia: tutaj po prostu należy sprawdzić na ile przygotowała się do rozmowy oraz jaki research zrobiła w kontekście Big Data. Można podpytać czemu w ogóle wyróżniamy taką dziedzinę jak Big Data skoro mamy tradycyjne rozwiązania, czy kojarzy jakieś technologie, a jeśli tak – niech coś opisze. Każda odpowiedź dodatkowa to plusik.

Jeśli natomiast osoba miała już kontakt z technologiami, sprawa jest prosta – bierzemy CV i lecimy po kolei, a rozmówca opisuje jak taki framework działa i co robi.

Projekt na repozytorium

Pisałem już o tym w artykule “Przeszedłem szkolenie Big Data – co dalej, by zostać prawdziwym ekspertem?”. Razem z CV (oraz wstępnym testem, jeśli takowy został przeprowadzony) osoba która aplikuje może dostarczyć także adres swojego repozytorium. Zajrzyj tam. Jeśli są jakieś projekty, bo powinien to być ogromny plus. Oczywiście jeśli projekty te mają ład i skład oraz nie są napisane w skandaliczny sposób.

Pamiętaj, że budowanie swojego projektu Big Datowego “po godzinach” wymaga naprawdę dużo dyscypliny, solidności i determinacji. Pokazuje także inicjatywność oraz odwagę programisty. Skoro już się odważył – wejdź w projekt i sprawdź jak jest napisany. Schludnie? Zgodnie ze wzorcami? Ma testy?

Oczywiście nie zapomnij porozmawiać o projekcie podczas rozmowy rekrutacyjnej. Niech opisze dlaczego akurat to zrobił, dlaczego wybrał te technologie, niech powie co zrobił źle. Z czego jest dumny, a co mógłby poprawić? To naprawdę nie wstyd zrobić coś źle, czy nawet fatalnie w projekcie “po godzinach”. Jeśli tylko potrafi się na tym nauczyć, to jest to gigantyczny plus. Co ważne w kontekście Big Data – spytaj, czy uruchamiał to u siebie na komputerze, czy miał do dyspozycji jakąś bardziej zaawansowaną infrastrukturę (klaster).

Prace podejmowane przedtem – także poza branżowe

Jeśli zatrudniamy studentów, warto zerknąć do CV. Być może będzie to ich pierwsza praca. Jeśli tak – nic w tym złego. Jeśli jednak mają się czym pochwalić wcześniej, wiele to mówi o nich samych. I niekoniecznie chodzi tu o doświadczenie branżowe. Cóż… jeśli zatrudniasz studenta, który ma już doświadczenie branżowe, to jest to naprawdę wymarzona sytuacja.

Może się jednak okazać, że Twój potencjalny przyszły współpracownik pracował na kasie, jako hostessa, w call center lub na zbiorach truskawek. W takiej sytuacji trudy życia zaznał w młodym wieku, gdy większość osób “baluje”. Pokazuje to, że jest pracowity, nie boi się “ubrudzić”, ćwiczył dyscyplinę i zna smak pracy.

Umiejętność łączenia wątków i “dobrego kombinowania”

Zdarza się, że osoba ma braki w wiedzy teoretycznej. Naszą rolą jest wtedy stopniowe naprowadzanie na właściwą odpowiedź. Możemy posłużyć się analogiami lub podsunąć logiczną ścieżkę, po której może dotrzeć do odpowiedzi. I tutaj ujawnia się umiejętność łączenia wątków i dobrego kombinowania. Umiejętność znacznie ważniejsza, niż wyuczona formułka z wiedzy teoretycznej.

Pomyślmy logicznie – Big Data to ogromna dziedzina. Można siedzieć latami w konkretnych technologiach i ciągle mieć wrażenie, że nie wiemy zbyt dużo. Nowa osoba i tak jest skazana na ciągłą naukę. Pytanie jednak, czy będzie to robić świadomie, poznając mechanizmy, rozumiejąc je i łącząc ze sobą wątki? Bez tego nie damy rady zbudować dużych, spójnych systemów, a już na pewno nie będą one wydajne.

Właśnie dlatego szalenie ważne jest przetestowanie tej umiejętności. Najlepiej zrobić to właśnie wtedy, gdy pojawiają się braki w wiedzy.

Nastawienie oraz potencjał dopasowania do zespołu

Co jak co, ale sama wiedza techniczna nie wystarczy. Współczesne systemy buduje się przez pracę zespołową i to właśnie ona powinna być głównym kryterium wyboru. No dobrze – przynajmniej jednym z paru głównych;-). Rozmowa rekrutacyjna i cały ten proces to okazja, żeby sprawdzić, czy osoba która do nas aplikuje nada się w boju. A na to składają się z grubsza trzy rzeczy:

  1. Umiejętności techniczne – załatwione przez poprzednie punkty (i następny)
  2. Dopasowanie do zespołu
  3. Nastawienie do pracy

W kontekście drugiego punktu, wszystko zależy od tego jaki macie zespół. Nie zachęcam oczywiście do dyskryminacji, natomiast osoba “z innej bajki” może wiele napsuć. Wiem, bo sam kiedyś byłem z innej bajki;-). Źle się czułem w danym miejscu, źle pracowałem i chyba także źle wpływałem na resztę zespołu. Wiem też jak bardzo duże profity potrafi przynieść dobrze dobrana załoga. Tu jednak już rola osób które rekrutują, aby znały tą specyfikę i umiały ją zgrabnie modelować poprzez dodanie nowych członków.

Jeśli chodzi o trzeci punkt – można wprost spytać jak osoba z którą rozmawiamy podchodzi do pracy i zdobywania nowych umiejętności. Jest systematyczna, czy woli pracować “zrywami”? Ma metodyczne podejście, czy chaotyczne? Lubi dopracować swoje dzieło, czy chce zrobić jak najwięcej w jak najkrótszym czasie?

Umiejętność myślenia “po bigdatowemu”… lub chociaż potencjał;-)

Big Data to wciąż młoda, trochę jeszcze dzika branża. Trzeba tu myśleć w nieco inny sposób, niż w wielu miejscach. Mowa przede wszystkim o “odgórnym” spojrzeniu na architekturę. Aby sprawdzić potencjał takiego myślenia, warto dać rozmówcy zadanie. Zadanie bardziej intelektualne niż techniczne. Przykładowo może to być coś w tym stylu:

“Dostałeś za zadanie stworzenie systemu, który zbiera dane z wielu miejsc dotyczących kulinariów – np. z wikipedii oraz kilku blogów. Masz na tej podstawie zbudować dużą bazę przepisów oraz wiedzy o nich. Produktem (celem biznesowym) ma być stworzenie aplikacji, która będzie inteligentną wyszukiwarką takich rzeczy. Ma ona pokazywać takie rzeczy jak składniki, dane naukowe, język w jakim został napisany przepis itd.”.

No i przyglądamy się jak nasz rozmówca myśli – bo to jest podstawowy cel. Rozwiązań tego zadania jest pewnie nieskończenie wiele. Podobnie jak błędów które można popełnić. Najprawdopodobniej problem pojawi się w kwestii czasowej oraz tego w jakim momencie zbierać dane. Ludzie znający jedynie “tradycyjne” IT często chcą na polecenie użytkownika wysyłać requesty. To zrodzi problemy, ponieważ na odpowiedź trzeba będzie czekać bardzo długo. I tak dalej i tak dalej…

Grunt, żebyśmy brali żywy udział w takim ćwiczeniu. Naprowadzajmy, zadawajmy pytania i najważniejsze – nie dajmy się przyspawać do jednej wizji.

Co po przyjęciu?

Jeśli zdecydowałeś/aś o przyjęciu kandydata – to gratuluję! Pamiętaj, że to dopiero początek. Taka osoba wymaga teraz opieki, szkolenia oraz stopniowego nabywania praktyki. Jeśli zastanawiasz się jak zrobić to najlepiej – nie czekaj. Kliknij tutaj, a potem napisz do mnie. Razem z ekspertami RDF pomożemy Ci w budowie Twojego działu Big Data. Chociażby szkoleniem;-).

Tymczasem zapraszam do naszego newslettera. Zostańmy w kontakcie i… razem budujmy naszą wspólną, polską społeczność Big Data!

 

Najczęstsze problemy ze starym Sparkiem (1.X) – co warto wiedzieć, zaczynając projekt

Najczęstsze problemy ze starym Sparkiem (1.X) – co warto wiedzieć, zaczynając projekt

Marek Czuma

Każdy kto zmuszony został korzystać ze starej wersji Sparka (<2.0) wie jak wiele wody musi upłynąć, aby zrobić niekiedy – wydawałoby się – proste rzeczy. Liczę, że poniższe zestawienie pomoże w rozwiązaniu choć części problemów.

Spark 1.X (1.6) – czyli przygotuj się na nowe (stare?) doznania.

Właśnie dowiedziałeś się, że znalazłeś się w nowym projekcie. Oczywiście musi z Twojej strony paść pierwsze, zapobiegawcze pytanie: “w jakich technologiach będę robić?”. Odpowiedź która przychodzi sprawia, że rozpływasz się niczym aktorka w reklamie czekolady: “Spark, będzie Spark…”.

Znakomicie! Szkoda tylko, że nikt nie wspomniał co to za Spark. Chodzi bowiem o starego dobrego Sparka 1.6, weterana Big Data. Zasłużony dla branży, odznaczony tysiącem orderów procesingu, choć czasem wolelibyśmy podziwiać go jedynie na starych fotografiach.

Czy jednak Spark <2.0 jest taki zły? Z mojego doświadczenia powiem dość prosto: jeśli przestawisz się i zdobędziesz zawczasu odpowiednią wiedzę, unikniesz gorzkich rozczarowań. Nie są to jednak rzeczy, które drastycznie zmieniają posługiwanie się Apache Spark i ciągle jest to solidna, przemyślana technologia do zrównoleglenia obliczeń. Jeśli pracowałeś/aś wcześniej głównie na 2.X (o “trójce” nie wspominam), to mam dobrą wiadomość: nie przeżyjesz szoku. Co najwyżej od czasu do czasu zmarszczysz czoło i sapniesz pod nosem to i owo. Na szczęście twórcy Sparka bardzo dobrze zadbali o kompatybilność wsteczną. Pracując tu, nie musimy zmagać się z koszmarami znanymi z innych technologii (pozdrawiam wszystkich programistów Scala Play – trzymajcie się tam!).

Poniższa lista jest moim (a także kilku osób które poprosiłem o radę – dzięki wielkie Panowie) subiektywnym zbiorem informacji, które spowodują, że praca w nowym projekcie ze “starym sprzętem” będzie naprawdę fajna. Mam przynajmniej taką nadzieję:-).

Subiektywna lista zmian w starym Sparku, które warto znać

Zacznijmy od spisania wszystkich rzeczy. Potem niektóre z nich (te, które nie są oczywiste zaraz po przywołaniu do tablicy;-)) opiszę nieco dokładniej.

  1. Brak możliwości wczytywania z CSV do DataFrame.
  2. Inna praca ze SparkContext / SparkSession
  3. Spark 1.X działa ze Scalą 2.10 (Spark 2.X – 2.11, Spark 3.X – 12) – oczywiście teoretycznie podział jest bardziej płynny, ale bardzo możliwe, że pracując ze Sparkiem 1.X, zmuszony/a będziesz robić to we współpracy ze starszą wersją Scali.
  4. Rozwoj Machine Learning od Sparka 2.0
  5. Spark Structured Streaming zostaje wprowadzony dopiero od Sparka 2.0.
  6. Od wersji 2.0 Dataframe staje się aliasem dla Dataset[Row], obie kolekcje mają ujednolicony interfejs.
  7. Poniżej 2.0 gdzie indziej znajdywały się encodery.
  8. Po prostu… wydajność. W codziennej, inżynierskiej robocie tego nie widzimy, ale przy procesowaniu to ma znaczenie.

Brak możliwości wczytywania z CSV do Dataframe

Jak wczytać dane z CSV? To proste!

val sampleDF = spark.read
      .option("header","true")
      .csv("sample_data.csv")

No jednak… nie. To jest proste, jeśli korzystasz ze Sparka >=2.0. Niestety, w “jedynkach” sprawa miała się nieco gorzej. Nie dysponujemy po prostu odpowiednią biblioteką, która dałaby nam dostęp do źródła typu csv. Na szczęście łatwo to naprawić.

Przede wszystkim – otwieramy nasz build.sbt (jeśli używamy sbt, inaczej maven itd.) i dodajemy odpowiednią bibliotekę:

libraryDependencies ++= Seq(
  ...
  "com.databricks" % "spark-csv_2.10" % "1.5.0",
  ...
)

Następnie, już podczas wczytywania danych:

sqlContext.read
      .format("com.databricks.spark.csv")
      .option("header", "true")
      .load(sample_data.csv)

I już:-). Zauważ tylko, że wykorzystujemy tu sqlContext, a nie sparkSession.

Inna praca ze SparkContext / SparkSession

A właściwie to… po prostu brak SparkSession. Został dodany od Sparka 2.0, więc jeśli używasz nieco bardziej leciwych wersji – zapomnij, że coś takiego istnieje. Zamiast tego musisz nauczyć się żonglować SparkContext oraz SQLContext.

Jak to wygląda w praktyce? Na przykład tak:

val conf = new SparkConf().setAppName("RDFSparkAppName")

val sc: SparkContext = new SparkContext(conf)
val sqlContext: SQLContext = new org.apache.spark.sql.SQLContext(sc)

// UDFs REGISTERING
val pseudonymisationUDF: PseudonymisationUDF = new PseudonymisationUDF
sqlContext.udf.register("pseudonymisationUDF", pseudonymisationUDF, DataTypes.StringType)

// DATAFRAME CREATING
val sampleDF: DataFrame = sqlContext.read
  .format("com.databricks.spark.csv")
  .option("header", "true")
  .load("sample_data.csv")

// RDD CREATING
val sampleRDD: RDD[Array[Byte]] = sc.parallelize(ids)
  .map(i=> Bytes.toBytes(i))

W większości będzie trzeba operować na sqlContext, ale jak widać zdarzają się sytuacje, gdy trzeba użyć także sparkContext. Warto wiedzieć jednak, że sparkContext da się wyciągnąć z sqlContext.

Rozwój Machine Learning od Spark 2.0

I tu istotna zmiana: popularny moduł Spark MlLib, oparty o RDD, od sparka 2.0 przechodzi w stan utrzymania (maintanance). Choć w dokumentacji sparka 2.X możemy przeczytać, że prawdopodobnie od Sparka 3 MlLib będzie wyłączony – tak się nie stało. Ciągle możemy go używać, jednak nie jest już rozwijany.

W zamian jednak, od Sparka 2.0 mamy do dyspozycji Spark ML. To moduł oparty o Dataframe. Co ciekawe – Spark Ml nie jest oficjalną nazwą, natomiast jest to pakiet, w którym znajdziemy interesujące nas klasy.

Zmiany w Dataset i Dataframe

Oczywiście nie można nie wspomnieć o najważniejszej zmianie. Jeśli korzystasz ze Sparka <2, najprawdopodobniej będziesz używać RDD. Jest jednak opcja, żeby pracowć z Dataframe. Należy jednak pamiętać, że największa magia optymalizacyjna zaczyna się w tym temacie dopiero od Spark 2.0. Od tego momentu Dataframe staje się aliasem dla Dataset[Row], zaś Dataset i Dataframe mają ujednolicony interfejs.

Encodery w innym miejscu w Sparku 1.X

Encodery wykorzystujemy w Sparku aby przekonwertować DataFrame a Dataset. Robimy to za pomocą metody “as[T]”, gdzie “T” to konkretna case class. Co prawda nie jest to najlepszy sposób na otrzymanie silnego, klarownego Dataset, ale jest oficjalny, dlatego go tutaj przedstawiam.

Spark 1.X

case class Person(id: Int, name: String)

val encoder = org.apache.spark.sql.catalyst.encoders.ExpressionEncoder[Person]

// creating some DF
val someDF = ...

val dataset = someDF.as(encoder)

Spark >= 2.X

case class Person(id: Int, name: String)
val encoder = org.apache.spark.sql.Encoders.product[Person]

// creating some DF val someDF = ...

val dataset = someDF.as(encoder)

Wydajność

Pisząc kod oczywiście nie mamy styczności z wydajnością. Nie zmienia to jednak postaci rzeczy, że podczas wykonywania joba to właśnie ona ma kluczowe znaczenie. I tutaj po prostu warto pamiętać, że pierwsze Sparki były znacznie, znacznie wolniejsze i posiadały mniejsze możliwości.

W tym eksperymencie porównywano Sparka 1.6 oraz 2.0. Sumowano miliard liczb, dokonywano joina oraz sprawdzano groupBy. Największe wrażenie robią dwa pierwsze testy – wyniki w tabelce.

 

Primitive

Spark 1.6

Spark 2.0

Sum

15.6
seconds

0.68
seconds

Join

58.12  seconds

0.98
seconds

Warto oczywiście pamiętać, że taki eksperyment niesie szereg wątpliwości (np. kwestia nodów). Nie zmienia to jednak postaci rzeczy, że między sparkiem 1.6 a 2.0 jest spora różnica. Wynika ona z optymalizacji, jakie zostały przeprowadzone pod spodem Datasetów oraz Dataframów. Co warto wiedzieć – między ostatnią wersją 2.X oraz 3.0 także wprowadzono optymalizacje, dzięki którym możliwości Sparka stały się jeszcze większe. Twórcy chwalą się nawet, że 3 jest nawet 17x szybszy, co zostało wykazane w teście TPCDS.

Podsumowanie

Jeśli już siedzisz w projekcie ze Sparkiem 1.X – nie masz wyjścia, trzeba robić. Pamiętaj, że nie jest taki zły, a pod kątem inżynierskim jest nawet dość mocno podobny. Bez obaw, po prostu postaraj się pamiętać o tym jakie rzeczy mogą Cię zaskoczyć i… rób swoje. Powodzenia!

A – właśnie. Jeśli jesteś zainteresowany/a tego typu rzeczami, zapisz się na newsletter RDF. Wspólnie tworzymy polską społeczność Big Data. Liczę, że od dzisiaj także z Tobą;-).

 

Przeszedłem szkolenie Big Data – co dalej, by zostać prawdziwym ekspertem?

Przeszedłem szkolenie Big Data – co dalej, by zostać prawdziwym ekspertem?

Marek Czuma

Big Data to branża, która rozlewa się na coraz większe obszary. Siłą rzeczy inżynierowie Big Data stają się dla rynku niebywale potrzebni, co generuje coraz większe zapotrzebowanie na szkolenia personelu mające w założeniu wytworzyć wielu ekspertów w przyspieszonym tempie.

Jeśli jesteś jednym z tych szczęśliwców, którzy właśnie stali się świeżo upieczonymi inżynierami Big Data – gratulacje! Witamy w naszej działce;-). Pamiętaj jednak, że to dopiero początek. W artykule zastanowię się chwilę nad tym co zrobić, żeby szkolenie było jedynie świetną podstawą pod dalszy rozwój. Prawdziwy ekspert bowiem to coś znacznie więcej niż “po prostu pracownik”. I – co ważniejsze – prawdziwy ekspert, to ktoś znacznie potrzebniejszy nam wszystkim, niż często myślimy;-). Zatem – kawa w dłoń i ruszamy!

Co tak naprawdę musisz umieć w Big Data? Kilka słów o “T-shape”

Po przekrojowym szkoleniu z Big Data masz podstawy pod działanie i dalszy rozwój. Aby mądrze pokierować swoim rozwojem warto zastanowić się jaki chcielibyśmy osiągnąć “efekt finalny”. Oczywiście mamy tu solidny cudzysłów, bo finału nigdy nie będzie;-). Pytanie jednak czy wchodzić w jedną technologię? A może jedno środowisko, np. konkretną chmurę? A gdyby tak poznać wszystkie kluczowe technologie? Cóż począć… Aby pójść odpowiednią drogą i podejść do sprawy z głową, warto zabrać się do tego metodycznie.

Osobiście uważam że najfajniejszym wzorcem, który może stanowić punkt wyjścia jest T-Shape, czyli po polsku “kształt literki T”. Na czym owa koncepcja polega?

T-Shape to pomysł spopularyzowany przez Davida Guesta już w 1991 roku. Zasadniczo sprawa jest do bólu prosta – litera “T” ma dwa paski. Górny – poziomy – pokazuje szeroki zakres wiedzy, jaki powinniśmy posiąść w wybranej dziedzinie – w tym przypadku Big Data/AI. Kreska pionowa symbolizuje głębokość poznania fachu. Jeśli zespolimy to wszystko w jedną myśl, zobaczymy że powinniśmy poznać szeroki kontekst, “zjeść chleb z niejednego pieca”. Natomiast w zaledwie jednej lub paru rzeczach powinniśmy być bardzo dobrzy, mistrzowscy, stanowić swoistą elitę.

Taka koncepcja podoba mi się niezmiernie, ponieważ daje luksus przeszukiwania nowinek, poznawania branży, próbowania niektórych rzeczy. Z drugiej strony zachęca, aby znaleźć to co najbardziej lubię i zgłębić w sposób ekspercki, w wielu okolicznościach, w różnych konfiguracjach i środowiskach, aby zrealizować niejeden cel. Dzięki temu wiele miejsc możemy “liznąć”, natomiast będziemy też mieli też “swoje terytorium”, gdzie czujemy się komfortowo, pewnie i na którym panujemy.

Taka koncepcja pozwala także wytworzyć eksperta, który ma szerokie spojrzenie, nie zamyka się na jeden wąziutki obszar. Prawdopodobnie będzie miał także nieco pokory, gdyż będzie zdawał sobie sprawę z tego, że “pod spodem” jest ogrom wiedzy której nie widać na pierwszy rzut oka.

Po pierwsze – zdefiniuj swoją drogę

Przeszedłeś już pierwsze szkolenie z Big Data? Znakomicie! Pamiętaj jednak, że to naprawdę dopiero skromny początek. Miej pokorę i wewnętrzny luz – branża nie raz i nie dwa udowodni Ci, że jesteś jeszcze ledwie padawanem. To nie problem! O ile nie masz wygórowanego mniemania o sobie rzecz jasna.

Podejdź do sprawy metodycznie. Otwórz na komputerze dokument tekstowy, nazwij go “mój rozwój w Big Data”. No dobrze, zwykły notes też może być ;-). Przede wszystkim zdefiniuj w jakich rzeczach chcesz się rozwijać. Jak to zrobić? Zacznijmy od przyjemnych rzeczy – wypisz wszystkie technologie oraz dziedziny, które najbardziej Ci się spodobały podczas szkolenia.

Taka lista może wyglądać tak:

  1. Spark
  2. Elasticsearch
  3. HBase
  4. Nifi
  5. Przetwarzanie danych
  6. Bazy danych
  7. Apache Superset
  8. Analiza danych
  9. Machine Learning
  10. Flink

Ok – jedno jest pewne: nie będziesz “wymiatać” w każdym z tych punktów. Technologie się zmieniają, poza tym każda z nich jest na tyle rozbudowana, że można by poświęcić najbliższe pół życia na dokształcanie się. Niemniej nie znaczy to, że lista nie ma sensu, wręcz przeciwnie!

Zacznij od zastanowienia się jaka działka zainteresowała Cię najmocniej. Gdyby ktoś powiedział Ci: “słuchaj, od teraz przez najbliższy rok będziesz robić tylko w tym”, co by to było? Nie chodzi tu o technologie, ale o to w którą stronę pójść. Przechowywanie danych? Przetwarzanie danych? A może analiza?

Załóżmy, że uznałeś, że to w czym chcesz specjalizować się najmocniej, to przetwarzanie danych. Od razu widzisz, że z listy powyżej dobrze będzie poznać Sparka i Flinka. Z tych dwóch najbardziej spodobał Ci się Spark, więc to on wygrywa jako technologia, w której chcesz zostać absolutnym mistrzem. Gratulacje!

Skoro masz już pionową belkę literki “T”, czas na górną, czyli technologie, które znasz “mniej więcej”. Tutaj moim zdaniem warto zbudować taki zestaw technologii, który pozwoli Ci na bycie wszechstronnym. Warto więc poznać nieco narzędzi, które pozwolą przechowywać dane, analizować je, pobierać itd.

Finalnie lista mogłaby wyglądać  tak:

  1. Spark – jako technologia, w której się specjalizujesz.
  2. HBase – jako nierelacyjna baza danych
  3. HDFS – jako naturalne dopełnienie HBase
  4. Postgresql – jako relacyjna baza danych.
  5. Elasticsearch – fulltext search, dzięki któremu będziesz mógł/mogła lepiej udostępniać dane pod zaawansowane przeszukiwanie
  6. Apache Superset – do analizy danych

Brawo! Masz 5 technologii, które musisz poznać czysto użytkowo i jedną, którą będziesz szlifować nawet na posiedzeniach w toalecie. Teraz już wiesz w jakim kierunku zmierzać!

Tu dodam jeszcze, że przy opracowywaniu listy warto kierować się także popularnością, żeby nie zacząć się rozwijać od początku w egzotycznych narzędziach. Jeśli jednak jesteś po przekrojowym szkoleniu, nie ma tutaj najmniejszego problemu, gdyż z całą pewnością technologie zostały dobrane solidnie.

Po drugie – wykorzystaj najlepsze sposoby, aby się rozwijać

Skoro wiesz już w czym się rozwijać, stwórz plan, dzięki któremu w konkrecie będziesz zdobywał wiedzę i umiejętności. Tu jeszcze od siebie dodam jedną rzecz – naprawdę potrzebne są obie rzeczy! To znaczy nie da się bez wiedzy teoretycznej poważnie zrozumieć dużej technologii. Wiem, że gdy podchodzimy do czegoś nowego, to ostatnią rzeczą jaką chcemy zrobić jest czytanie o architekturze i działaniu. “A co tam, przecież robiłem już coś podobnego!”. Cóż – zwykle takie podejście kończy się stworzeniem potworka. Każda technologia ma swoją specyfikę, swoje podejście i zanim siądziemy do kodu – warto o tym poczytać;-).

Co nie zmienia postaci rzeczy, że najważniejsza jest potem praktyka, która stopniowo wykształca w nas umiejętności i doświadczenie. Jak więc taką praktykę zdobyć? Poniżej 10 pomysłów.

  1. Przerabiaj tutoriale, które znajdziesz w internecie – jeśli chcesz coś poznać, żyjemy w czasach, gdzie wiedza jest wystawiona na tacy. Nie musisz już czychać na ostatnie egzemplarze czasopism z fragmentami kodu. Nie musisz chodzić do kawiarenki internetowej, aby ściągać przykłady. Może to niektórych dziwić, ale tak serio kiedyś było;-). Dziś nauka wymaga znacznie mniej determinacji. Niech Cię to nie rozleniwi. Podejdź z taką samą, jaką trzeba było wykazać kiedyś. Tutoriale na temat drobnych, konkretnych rzeczy, to absolutny standard i błogosławieństwo naszych czasów.
  2. Rób mini-kursy na portalach takich jak Data-Camp – Robiąc tam szkolenia otrzymujesz materiały teoretyczne, środowisko do ćwiczeń oraz… certyfikat, który potwierdzi Twoją wiedzę. Co prawda certyfikaty takie same w sobie nie zapewnią Ci złotych gór, ale są pewnego rodzaju wskazówką, że zależy Ci i czujesz głód wiedzy.
  3. Baw się technologią starając się ją “zepsuć” lub wykorzystać w niecodzienny sposób – kojarzysz, jak dzieci podchodzą do zabawek? Daj małemu chłopcu wieżę do spuszczania piłeczek i piłeczkę. Od razu zobaczysz w jak wielu konfiguracjach wieża ta może być zbudowana, oraz że piłeczka bynajmniej nie jest jedyną rzeczą, która może zjeżdżać na sam dół. Zainspiruj się małymi dziećmi – odkryj w sobie ciekawość technologii. Sprawdź jak to naprawdę działa, przetestuj wyjątki i sytuacje brzegowe, zrób coś dowcipnego, wykaż błędy. Takie podejście pozwala w niezwykle trwały sposób poznać tematykę, która na tutorialach pokazana jest jedynie powierzchownie.
  4. Buduj swoje własne projekty – a teraz moje ulubione. Gdy przygotowuję się do rozmów kwalifikacyjnych z potencjalnymi pracownikami, zawsze dostaję przynajmniej trzy rzeczy: CV, wyniki wstępnych etapów oraz… link do repozytorium kandydata. To co tam znajdę powie naprawdę, naprawdę wiele o człowieku, który aplikuje. Robiąc projekt, zdobywasz ogrom wiedzy, której nie zdobędziesz przerabiając przykłady czy dokumentację. Zmierzysz się z problemami, zobaczysz praktyczne wykorzystanie technologii. Dodatkowo wykażesz inicjatywność oraz charakter. Umiejętność wymyślenia, zaprojektowania i zbudowania projektu wynosi Cię do wyższej ligi. Zastanów się dodatkowo, w jaki sposób realizacja takiego projektu mogłaby pomóc Tobie i innym. Ulepsz choć malutki skrawek naszej rzeczywistości. Powodzenia!
  5. Dziel wiedzą ze współpracownikami – Zrobiłeś/aś research technologii? Odkryłeś/aś coś ciekawego? Podziel się ze swoimi współpracownikami. Dzięki temu utrwalasz wiedzę i zaczynasz lepiej rozumieć to co poznajesz. Dodatkowo budujesz w swoim środowisku solidną markę. No i na końcu… cóż, pomagasz koleżankom i kolegom budując dobre miejsce do pracy, a to bezcenne;-).
  6. Bądź aktywny w pracy i wykorzystuj projekty oraz okazje – o ile poprzednie punkty możesz realizować niemal zawsze, ten jest zależny od Ciebie tylko po części. Niejednokrotnie w firmie w której pracujesz będą nadarzały się okazje. Prawdopodobnie trzeba będzie zrobić jakiś research technologiczny, pomóc w przygotowaniu oferty dla klienta lub zrealizować projekt typu PoC (Proof of Concept – czyli prototyp, który ma zbadać jakąś ścieżkę). Być może po prostu pojawi się zapotrzebowanie na projekt. Jeśli te możliwości są zgodne z Twoją ścieżką rozwoju, nie bój się – idź w to! Poświęć dodatkowe godziny pracy. Nie obawiaj się wyjść z projektu, w którym już jest Ci wygodnie i cieplutko. Poznaj coś nowego, popełnij kilka (naście?set?) błędów i zdobądź dodatkową wiedzę oraz umiejętności.
  7. Rozmawiaj z bardziej doświadczonymi – jeśli pracujesz z kolegami, którzy siedzą już kilka lat w Big Data – nie bój się pytać ich o różne rzeczy. Dyskutuj, pytaj co sądzą o tej lub innej koncepcji. Pokazuj swoje projekty, poproś o code review. Obserwuj jak piszą kod i staraj się od nich jak najwięcej nauczyć. W ten sposób dokonasz szybkiego transferu wiedzy od ludzi, którzy musieli najprawdopodobniej przejść dość trudną, ciernistą drogę. Uwaga! Zawsze rób to z należytą pokorą.
  8. Rozwijaj swoją bazę wiedzy – nie myśl, że “masz to w głowie”. Zbuduj swoją bazę wiedzy, w której będziesz zapisywać swoją wiedzę i doświadczenie. Może to być jeden dokument, może to być folder z dokumentami “per technologia”. Oto na jakie aspekty możesz podzielić swoją bazę wiedzy:
    • Esencja wiedzy teoretycznej – zazwyczaj opis wynikający z dokumentacji
    • Obserwacje – tu możesz opisać np. rozwiązania często występujących wyjątków, czy rozwiązania zagwozdek, które Cię trapiły.
    • Odnośniki do ćwiczeń – jeśli masz już rozwiązany jakiś problem w kodzie, napisz tutaj gdzie dokładnie.
    • Materiały – czyli strony, które opisują daną technologię.
  9. Bądź uczestnikiem konferencji Big Data/Data Science – takich konferencji jest naprawdę sporo i przybywa ich z każdym rokiem. Nie dostaniesz tam żadnej precyzyjnej, szczegółowej wiedzy. Dostaniesz natomiast różne podejścia, różne spojrzenia, różne case studies. Warto pochodzić, aby zrozumieć jak działa branża.
  10. Chodź na gruntowne szkolenia – Data Camp i inne tego typu portale to bardzo dobry pomysł. Nie porozmawiasz tam jednak z instruktorem, nie poznasz wiedzy dogłębnie, tak jak na indywidualnych szkoleniach. Jeśli masz jakiś wpływ na to na jakie szkolenia wysyła Cię Twoja firma – zachęcam do naszej oferty;-). Osobiście przeprowadzając szkolenie zawsze stawiam nacisk na zrozumiałe podanie teorii oraz dużą ilość “mięsa”, dzięki czemu praktyka staje się potem jasna, a realizując projekt masz punkt odniesienia. Wejdź w kontakt i daj znać czego potrzebujecie, na pewno jakoś się dogadamy:-).

Po trzecie – koryguj swój kurs;-)

Czas na ostatni krok. Skoro wiesz już w czym i jak się rozwijać… nie bój się zmienić swojego kursu. Głupotą byłoby podejmowanie wiążącej decyzji dotyczącej całej ścieżki zawodowej na samym początku kariery. Poświęć na jej realizację kilka miesięcy, pół roku, ale potem pomyśl, czy nie warto byłoby dokonać rewizji swojego planu.

Być może pomyślisz, że skoro poświęciłeś/aś na coś mnóstwo czasu, to zmiana kursu będzie szarpaniem się między wszystkim i niczym, co w efekcie doprowadzi do tego, że nie będziesz ekspertem w niczym. Nie jest to prawda – w ten sposób budujesz górną belkę literki “T”. Przygotowujesz jednocześnie grunt pod belkę pionową. Pamiętaj jednak, że jeśli wiedzę teoretyczną poprzesz praktyką i podsumujesz w bazie wiedzy – to wiedza ta nie wyparuje. Będzie przy Tobie i będzie wspierać Twoją pracę, nawet jeśli finalnie technologie w których się specjalizujesz, będą inne.

Pamiętaj, dodatkowo, że im więcej się uczysz i ćwiczysz swój mózg, tym łatwiej jest Ci się nauczyć kolejnych rzeczy. Nie bój się zmiany kursu. Nie bój się planowania, ale nie spędzaj też nad nim połowy czasu. Końcem końców liczy się wiedza jaką posiadasz i doświadczenie, jakie masz na karku. Nie zaś perfekcyjnie zaplanowana ścieżka kariery. Tak więc… zaplanuj ją, rozwijaj się metodycznie, ale przede wszystkim – pracuj, pracuj, pracuj. Mądrze, ciężko, uparcie. A na pewno staniesz się wybitym ekspertem, który wpłynie na nasz świat;-). Tego Ci życzę!

Na koniec – zapraszam, zostań na dłużej, dołącz do newslettera i twórz naszą społeczność Big Data.