Jak zbudować swoją infrastrukturę Big Data? Wybrać rozwiązania chmurowe, czy on-premise (własną infrastrukturę)? Zapraszam do pogłębionej analizy.

Twój partner w świecie Big Data/AI – raporty, analizy, przemyślenia
Jak zbudować swoją infrastrukturę Big Data? Wybrać rozwiązania chmurowe, czy on-premise (własną infrastrukturę)? Zapraszam do pogłębionej analizy.
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:
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.
A już teraz przechodzimy do 6 rzeczy, na które ja zwracam uwagę, rozmawiając z nowymi koleżankami i kolegami!
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.
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.
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).
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.
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.
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:
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?
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.
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!
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.
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:
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)
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:
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:
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:
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!
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.
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ę:-).
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.
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.
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.
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.
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 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)
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 |
0.68 |
Join |
58.12 seconds |
0.98 |
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.
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ą;-).
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!
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.
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:
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:
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.
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.
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.