Zamiana Dataframe w Dataset w Sparku. Taka, która działa.

Zamiana Dataframe w Dataset w Sparku. Taka, która działa.

Największy problem Dataframe w Sparku? Oczywiście – brak jasności, jaka schema jest w aktualnym DFie. W związku z tym często wykorzystuje się Dataset[T], gdzie T to konkretna Case Class. Dzięki temu, jeśli wywołujemy metodę, która zwraca Dataset[T], możemy być przekonani, że wiemy jakim typem operujemy, jaką nasz obiekt ma schemę.

Niestety, tak dobrze jest tylko w teorii. W praktyce Spark pozwala wyjść poza ramy schematu i dodać lub odjąć kolumny, które nie istnieją w case class T. Jest to bardzo mylące i osoby które o tym niewiedzą mogą przeżyć niezłą eksplozję mózgu. Pytanie – czy da się coś z tym zrobić? Jak najbardziej. Chociaż nie oficjalną ścieżką, bo to właśnie ona wprowadza w błąd.

Standardowe castowanie Dataframe do Dataset[T]

Na początku zobaczmy jak to powinno wyglądać według planu “standardowego”. W przykładzie będziemy się posługiwać case classą “Person”, która ma id, name i age. To do niej będziemy “równać” wszystkie Dataframy. Wykorzystamy do tego trzy DFy:

  1. perfectDF – będzie miał dokładnie takie kolumny jak powinniśmy mieć wykorzystując Person.
  2. bigDF – będzie zawierał jedną kolumnę więcej – “lastName”
  3. smallDF – będzie zawierał jedynie kolumny “id,name”. Będzie więc brakowało kolumny “age”

Dodam jeszcze, że cały kod pisany jest w Scali.

Poniżej przedstawiam uproszczone utworzenie pierwszego Dataframe’a. Reszta jest na podobnej zasadzie.

val perfectDF: Dataset[Row] = Seq(
      (1, "John", "26"),
      (2, "Anna", "28")
    ).toDF("id", "name", "age")

Czas na najważniejszą rzecz: oficjalnym i najbardziej popularnym sposobem na zamianę DF w DS[T] jest wywołanie df.as[T]. Aby to zrobić, musimy wcześniej zaimportować implicit._. Można ewentualnie zrobić także df.as[T](Encoders.product[T]).

Po takim “myku” spodziewamy się, że otrzymamy zmienną z typem Dataset[T]. W naszym przypadku, po zastosowaniu perfectDF.as[Person] faktycznie tak się dzieje. Wywołujemy więc “show()” aby sprawdzić jak wyglądają nasze dane i… wszystko gra. Mamy więc Dataset o jasnej schemie, gdzie możemy odwoływać się do konkretnych pól.

Problem zaczyna pojawiać się w sytuacji, gdy nasz Dataframe nie jest idealnie wpasowany do schematu klasy T. Przykładowo – zmienna bigDF to Dataframe, który zwiera kolumny “id”, “name”, “lastName”, “age”. Po wywołaniu metody bigDF.as[Person] możemy się spodziewać, że kolumna zostanie obcięta. Wszak w wyniku operacji dostajemy Dataset[Person], a klasa Person nie zawiera pola “lasName”. Niestety, jest zupełnie inaczej.

val bigDF: Dataset[Row] = Seq(
      (1, "John", "Smith", "27"),
      (3, "Anna", "Smith", "1")
    ).toDF("id", "name", "lastname", "age")

val bigDFAsPerson: Dataset[Person] = bigDF.as[Person]
bigDFAsPerson.show()
bigDFAsPerson.printSchema()

Efekt – w postaci schemy oraz wyglądu tabelki – można obserwować poniżej:

+---+----+--------+---+
| id|name|lastname|age|
+---+----+--------+---+
|  1|John|   Smith| 27|
|  3|Anna|   Smith|  1|
+---+----+--------+---+

root
 |-- id: integer (nullable = false)
 |-- name: string (nullable = true)
 |-- lastname: string (nullable = true)
 |-- age: string (nullable = true)

Sprawa ma się inaczej, gdy spróbujemy dokonać konwersji do klasy z Dataframe, który ma zbyt mało kolumn:

val smallDF: Dataset[Row] = Seq(
  (1, "maro"),
  (3, "ignacy")
).toDF("id", "name")

val smallDFAsPerson: Dataset[Person] = smallDF.as[Person]

smallDFAsPerson.show()
smallDF.printSchema()

Efekt: ponieważ nie ma jednej z kolumn, Spark rzuci wyjątek. A konkretniej AnalysisException.

21/08/30 21:25:11 INFO CodeGenerator: Code generated in 25.8197 ms
Exception in thread "main" org.apache.spark.sql.AnalysisException: cannot resolve '`age`' given input columns: [id, name];
    at org.apache.spark.sql.catalyst.analysis.package$AnalysisErrorAt.failAnalysis(package.scala:42)
    at org.apache.spark.sql.catalyst.analysis.CheckAnalysis$$anonfun$checkAnalysis$1$$anonfun$apply$3.applyOrElse(CheckAnalysis.scala:110)
    at org.apache.spark.sql.catalyst.analysis.CheckAnalysis$$anonfun$checkAnalysis$1$$anonfun$apply$3.applyOrElse(CheckAnalysis.scala:107)
    at org.apache.spark.sql.catalyst.trees.TreeNode$$anonfun$transformUp$1.apply(TreeNode.scala:278)
    at org.apache.spark.sql.catalyst.trees.TreeNode$$anonfun$transformUp$1.apply(TreeNode.scala:278)
    at org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:70)
    at org.apache.spark.sql.catalyst.trees.TreeNode.transformUp(TreeNode.scala:277)  
.
.
.
    at App$.main(App.scala:44)
    at App.main(App.scala)

 

Sprawdzony sposób na zamianę Dataframe do Dataset[T]

Na szczęście – jest możliwość, aby to naprawić. Aby nie przedłużać powiem tylko, że należy po prostu napisać swój własny kod, dzięki któremu rozszerzymy nieco Dataframe. Najpierw jednak rozpiszmy sobie jakie chcemy spełnić warunki.

Po konwersji z Dataframe, nowo utworzony Dataset:

  1. Nie będzie zawierał niepotrzebnych kolumn.
  2. Będzie miał nowo utworzone kolumny. Będą one wypełnione nullami.

Aby to zrobić, utwórz object SparkExtensions, a następnie dodaj kod:

import scala.reflect.runtime.universe.TypeTag
import org.apache.spark.sql.{DataFrame, Dataset, Encoders, Row}

object SparkExtensions {
  implicit class ExtendedDataFrame(df: DataFrame) {
    def to[T <: Product: TypeTag]: Dataset[T] = {
      import df.sparkSession.implicits._
      import org.apache.spark.sql.functions.col
      val columnsUniqueInT = Encoders.product[T].schema.diff(df.schema)
      val withAdditionalColumns: Dataset[Row] = columnsUniqueInT .foldLeft(df)((previousDF, column) =>
        previousDF.withColumn(column.name,
          lit(null).cast(column.dataType)))
      withAdditionalColumns.select(Encoders.product[T]
        .schema
        .map(f => col(f.name)): _*)
        .as[T]
    }
  }
}

Co tu się dzieje? Przede wszystkim trzy rzeczy:

  1.  Znajdujemy unikalne kolumny – robimy to poprzez różnicę tego co jest w naszej case class oraz w schemacie dataframe.
  2. Tworzymy Dataframe z dodatkowymi kolumnami, które wypełniamy nullami i castujemy do odpowiednich typów
  3. Tworzymy Dataframe (na bazie [2]), w którym wybieramy jedynie te kolumny, które są przewidziane w klasie T.

Jak tego użyć? Musimy zrobić dwie rzeczy: zaimportować nasz object SparkExtensions (import functions.SparkExtensions._), a następnie przy Dataframe zamiast “.as[Person]” zrobić “.to[Person]”.

val bigDFToPerson: Dataset[Person] = bigDF.to[Person]
bigDFToPerson.show()
bigDFToPerson.printSchema()

Efekt:

+---+----+---+
| id|name|age|
+---+----+---+
|  1|John| 27|
|  3|Anna|  1|
+---+----+---+

root
 |-- id: integer (nullable = false)
 |-- name: string (nullable = true)
 |-- age: string (nullable = true)

 

UWAGA! Taka opcja zakłada, że wszystko musi zgadzać się w 100%.

Jak wiadomo, pole w Datasetach sparkowych składa się z 3 rzeczy:

  1. Nazwy
  2. Typu
  3. Określenia, czy jest nullable czy nie – czyli czy może przyjmować null jako wartość.

Dla tych, którzy wolą nieco bardziej liberalną wersję, przygotowałem też metodę, która pozwala okrajać nie uwzględniając trzeciej rzeczy.

def to[T <: Product: TypeTag]: Dataset[T] = {
      import df.sparkSession.implicits._
      import org.apache.spark.sql.functions.col
      val columnsFromT = Encoders.product[T].schema.map(c=> (c.name,c.dataType))
      val columnsFromDF = df.schema.map(c=> (c.name, c.dataType))
      val columnsUniqueInT = columnsFromT.diff(columnsFromDF)
      val withAdditionalColumns: Dataset[Row] = columnsUniqueInT.foldLeft(df)((previousDF, column) =>
        previousDF.withColumn(column._1,
          lit(null).cast(column._2)))
      withAdditionalColumns.select(Encoders.product[T]
        .schema
        .map(f => col(f.name)): _*)
        .as[T]
    }

Zdaję sobie sprawę, że robi się już nieco mało estetycznie, ale zapewniam – działa;-). Stosuje się dokładnie tak samo jak w przypadku poprzedniej wersji.

Liczę głęboko, że taka metoda się przyda – w projekcie w którym pracowałem, problem typów był naprawdę mocno odczuwalny. Cóż – po więcej, choć zwykle nieco bardziej “wysokopoziomowych” artykułów – zapraszam do newslettera;-). Powodzenia!

 

Loading
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

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ą;-).

 

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

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

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.

 

Loading