Month: October 2021

Google inwestuje nad Wisłą – współczesna montownia, czy stajnia wybitnych umysłów?

Google inwestuje nad Wisłą – współczesna montownia, czy stajnia wybitnych umysłów?

Marek Czuma

Google dokonało właśnie kolejnej dużej inwestycji w Polsce. Tym razem na tyle dużej, że potrzebowało wynająć 14 pięter w prestiżowym budynku The Warsaw Hub C. Taka informacja zawsze przyjemnie głaszcze nas po głowach łechcząc nieco nasze ego. Pytanie jednak, czy na pewno inwestycja powinna nas aż tak bardzo cieszyć? Czy może jednak na wyrost są szumne nagłówki o “wiekopomnych centrach rozwoju” oraz “skoku technologicznym”, za każdym razem gdy jakiś gigant technologiczny zechce zostawić tu nieco dolarów? Zapraszam na krótką notkę;-)

Po co Google wynajęło aż 14 pięter luksusowego wieżowca?

Niewątpliwie informacja o tym, że Google wynajęło kilkanaście pięter jest elektryzująca. Firma poinformowała, że ma zamiar zbudować w niej Centrum Rozwoju Technologii Google Cloud. W ramach tego posunięcia rekrutowani będą inżynierowie nie tylko z Polski, ale także zza granicy. Organizacja przypomina, że obecnie zatrudnia w naszym kraju ponad 900 pracowników, z czego pokaźną część stanowią inżynierowie.

Biuro jest zaaranżowane w stylu znanym nam dobrze z amerykańskich filmów o gigantach technologicznych. Każde z pięter odnosi się do któregoś regionu Polski. Na najwyższej kondygnacji spotykać się będzie zarząd, zaś do dyspozycji pracowników oddana została kawiarnia oraz taras z widokiem na miasto.

Siłownia w biurze Google w The Warsaw Hub, materiały prasowe, fot: Jacek Waszkiewicz

Poza tym ludzie pracujący w polskim oddziale Google będą mieli możliwość skorzystać z siłowni (także z widokiem na Warszawę), salonu do masażu, salonu gier, biblioteki czy miejsc dla rodziców z dziećmi. Biurowiec posiada także strzeżony parking dla rowerów oraz wtyczki do ładowania samochodów elektrycznych. Pierwsi pracownicy już pracują z nowego biura, ale to dopiero początek – zatrudnienie dopiero rusza.

Czym dokładnie jest nowa inwestycja Google w Warszawie?

Skoro znamy już standard życia pracowników Google w nowym warszawskim biurze, czas postawić pytanie z początku: czy jest się z czego AŻ TAK cieszyć? W końcu fajne miejsce pracy to nie wszystko – możemy być jedynie listkiem figowym, który zamaskuje fakt, że pracownicy traktowani są po prostu jako zwykła tania siła robocza, użyta jedynie do obsługi TYCH PRAWDZIWYCH centrów technologicznych – osadzonych gdzieś w Berlinie czy Paryżu.

Jak będzie naprawdę, życie pokaże. Moim zdaniem jednak – zdecydowanie jest się z czego cieszyć. W przeciwieństwie do budowy w Polsce kolejnych chmurowych Data Center (co samo w sobie jest oczywiście bardzo dobre, ale rewolucji nie wnosi), inwestycja Google to krok zdecydowanie jakościowy.

Jesteśmy na blogu Big Datowym, więc moje spojrzenie ma pewne skrzywienie w tą stronę. Google jako organizacja jest fundamentem branży Big Data i jej wkład jest nie do przecenienia. Jest także trzecim największym dostawcą usług chmurowych (GCP to ok. 10% światowego tortu) – zaraz po AWS oraz Azure. Rozwój technologi cloudowych to obecnie jeden z motorów rozwoju naszej branży – a być może nawet więcej, rozwoju współczesnego świata w ogóle (choć nie ma co traktować chmury “magicznie” – zapraszam do krótkiego zestawienia cloud vs. on premise oraz pogłębionej analizy na ten temat). W Polsce powstanie zaś… Centrum Rozwoju Technologii Google Cloud. I będzie największym tego typu miejscem w całej Europie.

Google w The Warsaw HUB
Centrum Rozwoju Technologii Google Cloud w The Warsaw Hub, materiały prasowe, fot: Jacek Waszkiewicz

Nad czym będą pracować inżynierowie w Centrum Rozwoju Technologii Google Cloud?

Zdecydowanie nie będzie to ośrodek typu “call-center”. Inżynierowie mają rozwijać wewnętrzne technologie Big Data oraz dbać o to, żeby Google Cloud Platform zdobywało kolejne kawałki rynkowego tortu.

Nad czym dokładnie będą pracować, oczywiście pozostaje w pewnej mierze tajemnicą. Jest jednak kilka elementów, które udało się “wyłuskać”, a które mogą zaciekawić pasjonatów. Poniżej kilka z nich:

  1. Praca nad usługami dynamicznie przydzielającymi moc obliczeniową dla klientów biznesowych.
  2. Rozwój maszyn wirtualnych
  3. Rozwijanie Google Compute Engine – czym Polacy zajmowali się już w przeszłości
  4. Rozwój Google Kubernetes Engine – nad czym także już pracowali. Kubernetesa znają chyba wszyscy w Big Data (lub chociaż o nim słyszeli). Miło będzie pracować z tą technologią mając świadomość, że chociaż częściowo powstaje w Warszawie;-).
  5. Rozwój globalnej infrastruktury sieciowej, która jest odpowiedzialna za łączenie serwerów i serwisów.
  6. Praca nad rozwiązaniami z zakresu analizy danych – można przypuszczać, że chodzi tu o rozwiązania typu Business Intelligence, takie jak Looker.
Image
Centrum Rozwoju Technologii Google Cloud w The Warsaw Hub, materiały prasowe, fot: Jacek Waszkiewicz

Inwestycja Google w Warszawie to także szkolenia

Poza pracą stricte inżynierską, Google będzie także edukować i dzielić się swoim know-how. W tym celu nowie biuro wyposażone zostało w dwupiętrowe audytorium na 100 miejsc, trzy duże sale warsztatowe oraz pracownię UXLab, która umożliwia prowadzenie warsztatów z UX design produktów i usług. Działalność edukacyjna będzie miała na celu rozwój kompetencji inżynierskich z zakresu przetwarzania chmurowego (cloud computing).

Poza szkoleniami indywidualnymi, Google ma zamiar pracować z firmami zainteresowanymi wykorzystaniem możliwości chmurowych. Dzięki temu nowe centrum może stać się pewnym silnikiem zmian w polskiej gospodarce, w kierunku usług chmurowych.

Niektórzy mogą wpaść w zachwyt, szczególnie biorąc pod uwagę chęć szkoleń i dzielenia się swoim know-how. Oczywiście Google nie będzie czynić tego charytatywnie. To działanie stricte biznesowe – będzie czerpać z tego zyski, choć pewnie w wielu miejscach w nieco dalszym terminie. Nawet jeśli szkolenia będą darmowe, firma będzie zyskiwać poprzez szybsze pozyskiwanie dobrych pracowników oraz klientów Google Cloud Platform.

Czy to źle? Absolutnie nie – takie działanie jest win-win. Wygrywamy wszyscy, bo organizacja się rozwija, osiąga zyski i wpływy, my zaś modernizujemy firmy i społeczeństwo. No i – miejmy nadzieję – zyskujemy wszyscy wpływy w budżecie państwa;-)

Blog RDF to miejsce, gdzie tematy techniczne spotykają się z biznesowymi. W wymiarze Big Data rzecz jasna. Dołącz do newslettera i razem budujmy polską społeczność Big Data;-).

 

Zrozumieć Sparka: czym różnią się podobne mechanizmy? Distinct vs dropDuplicates i inne.

Zrozumieć Sparka: czym różnią się podobne mechanizmy? Distinct vs dropDuplicates i inne.

Marek Czuma

Pracując ze sparkiem bardzo często spotykamy mechanizmy, które budzą naszą konsternację z powodu bardzo dużego podobieństwa. Czy każde z tych mechanizmów ma inne działanie? Jeśli tak, to jakie są praktyczne różnice? Postanowiłem zanurkować nieco w kod i sprawdzić najbardziej popularne funkcje. Zapraszam!

Aha… to oczywiście artykuł w serii “Zrozumieć Sparka”. Poprzednio omawiałem joiny – zainteresowanych zapraszam tutaj.

Porządkujemy – czyli orderBy vs sort

Pierwszy mechanizm, który bierzemy na tapet to sortowanie. Spark daje nam przynajmniej dwie funkcje, które spełniają to zadanie: orderBy() oraz sort(). Czym się różnią?

Tutaj sprawa jest banalnie prosta – orderBy() to po prostu alias dla sort(). Mówi nam o tym poniższy fragment kodu:

/**
   * Returns a new Dataset sorted by the given expressions.
   * This is an alias of the `sort` function.
   *
   * @group typedrel
   * @since 2.0.0
   */
  @scala.annotation.varargs
  def orderBy(sortExprs: Column*): Dataset[T] = sort(sortExprs : _*)

Mamy dwie funkcje orderBy() – obie wywołują sort().

Zmieniamy nazwy kolumn: withColumnRenamed vs alias

Załóżmy, że mamy dataframe i nie pasuje nam nazwa jednej z kolumn. W takiej sytuacji mamy do dyspozycji dwie – cztery metody: withColumnRenamed(), alias(), as() oraz name(). Zajmijmy się najpierw różnicami między withColumnRenamed oraz alias.

  1. Zwracany typ:
    • alias() to funkcja zwracająca typ Column,
    • withColumnRenamed() zwraca Dataset[Row] (czyli Dataframe).
  2. Co dzieje się w środku:
    • alias() jest jedynie… aliasem dla funkcji name(). Nie robi nic innego. O tym co robi name() rozdział niżej.
    • withColumnRenamed() ma logikę, która zmienia schemat. Warto dodać, że sama zmiana nazwy kolumny dzieje się poprzez wykorzystanie funkcji as(). To – zdradzę przedwcześnie – jest alias dla aliasu. A alias jest aliasem dla name(). WOW! No nic… poniżej podrzucam jak zbudowana jest funkcja withColumnRenamed():

      def withColumnRenamed(existingName: String, newName: String): DataFrame = {
    val resolver = sparkSession.sessionState.analyzer.resolver
    val output = queryExecution.analyzed.output
    val shouldRename = output.exists(f => resolver(f.name, existingName))
    if (shouldRename) {
      val columns = output.map { col =>
        if (resolver(col.name, existingName)) {
          Column(col).as(newName)
        } else {
          Column(col)
        }
      }
      select(columns : _*)
    } else {
      toDF()
    }
  }
  3. Kiedy stosować:
    • alias() stosujemy wtedy, gdy możemy odwołać się do konkretnej kolumny – klasycznym przykładem jest zastosowanie funkcji select(). Tak jak poniżej: 
      peopleDF.select(col("name").alias("firstName"))
    • withColumnRenamed() wywołujemy na Dataframe. W efekcie dostajemy nowy Dataframe ze zmienioną nazwą kolumny. Wygląda to tak jak poniżej: 
      peopleDF.withColumnRenamed("name", "firstName")

 

Zmienianie nazw ciąg dalszy – as vs alias vs name

Skoro już znamy różnice między withColumnRenamed oraz alias, warto przejść do kolejnych meandrów sparkowego labiryntu. Tym razem poszukajmy czym różnią się od siebie trzy funkcje: as(), alias() oraz name().

Otóż, tym razem sprawa jest prostsza. Albo i bardziej zaskakująca, sam(/a) już musisz to rozstrzygnąć. Otóż – nie ma różnic. A konkretniej as() jest aliasem dla name(), tak samo jak alias() jest aliasem dla name().

Funkcja name() natomiast jest dość prostym mechanizmem. Jeśli obecna kolumna ma jakieś metadane powiązane z nią, zostaną propagowane na nową kolumnę. W  implementacji użyty jest Alias – warto jednak pamiętać, że nie chodzi tu o funkcję alias(), a o case classę Alias. Implementacja funkcji name() poniżej:

def name(alias: String): Column = withExpr {
    expr match {
      case ne: NamedExpression => Alias(expr, alias)(explicitMetadata = Some(ne.metadata))
      case other => Alias(other, alias)()
    }
  }

Usuwamy duplikaty w Sparku – distinct vs dropDuplicates

Prędzej czy później przychodzi taki moment, że w efekcie różnych transformacji dostajemy identyczne obiekty w naszych dataframach. Jest to szczególnie uciążliwe, gdy musimy pracować na unikatowych danych. Poza tym jednak najzwyczajniej w świecie niepotrzebnie zajmują one miejsce. Aby tego uniknąć, usuwamy duplikaty. Tylko jak to zrobić w Sparku? Istnieją dwa sposoby – distinct() oraz dropDuplicates().

Distinct jest najprostszą formą usuwania duplikatów. Tutaj sprawa jest prosta – na dataframe wywołujemy funkcję distinct(), po czym Spark wyszukuje rekordy, które w całości się pokrywają i zostawia tylko jeden z nich. Tak więc w tym przypadku wszystkie kolumny muszą się pokrywać, aby rekord został uznany za duplikat.

Implementacja:

sampleDF.distinct()

Sprawa ma się nieco inaczej, jeśli weźmiemy na warsztat funkcję dropDuplicates(). W tym przypadku możemy wybrać które kolumny bierzemy pod uwagę. W takiej sytuacji “duplikatem” może być np. osoba o tym samym imieniu i nazwisku, ale z innym PESELem.

Implementacja z przykładowymi kolumnami:

sampleDF.dropDuplicates("name", "age")

Co ważne – po takim wywołaniu, zwrócony dataframe oczywiście będzie zawierał wszystkie kolumny, nie tylko wyszczególnione w “dropDuplicates()”.

Tak więc, podsumowując – różnica polega na tym, że distinct() bierze wszystkie kolumny, zaś dropDuplicates() pozwala nam wybrać o które kolumny chodzi.

Explode vs ExplodeOuter

Niekiedy posługując się dataframe, stykamy się z kolumną, która zawiera listę – np. listę imion, liczb itd. Czasami w takiej sytuacji potrzebujemy, żeby te dane znalazły się w osobnych wierszach. Aby to zrobić, używamy funkcji explode – a właściwie jednej z dwóch “eksplodujących” funkcji.

Różnica jest bardzo prosta: explode() pominie nulle, natomiast explode_outer() rozbuduje naszą strukturę także o nulle.

Tak więc, jeśli chcemy rozbić nasze dane pomijając pry tym wartości typu null – wybierzemy explode().

Podsumowanie

Mam nadzieję, że zestawienie powyższych metod rozwieje różne wątpliwości, które mogą niekiedy przychodzić. Spark to złożona, duża technologia. Jeśli chcesz zgłębić ją bardziej – przekonaj swojego szefa, żeby zapisał Ciebie i Twoich kolegów/koleżanki na szkolenie ze Sparka. Omawiamy całą budowę od podstaw, pracujemy na ciekawych danych, a wszystko robimy w miłej, sympatycznej atmosferze;-) – Zajrzyj tutaj!

A jeśli chcesz pozostać z nami w kontakcie – zapisz się na newsletter. Koniecznie, zrób to!

 

Zrozumieć Sparka: joiny

Zrozumieć Sparka: joiny

Marek Czuma

Spark to rozległa i złożona technologia. Zrozumienie go wymaga zarówno silnych podstaw teoretycznych, jak i konkretnej, mozolnej praktyki. W serii “Zrozumieć Sparka” postaram się dogłębnie przybliżyć różne aspekty tego zacnego frameworku do przetwarzania danych.

Zaczynamy “z grubej rury” od czegoś, co wycisnęło niejedną łzę u Inżynierów Big Data. Chodzi oczywiście o joiny – mechanizm znany także z tradycyjnego SQL. Z pewnością pojawią się na ten temat także artykuły zaawansowane, dlatego dzisiaj zaczniemy dość lekko – od krótkiego omówienia typów joinów. Wiem, wiem – niby temat znany. W praktyce jednak czasem niedopowiedziany. Niech więc zostanie rozwiązany od podstaw;-).

Czym są joiny w Sparku?

Joiny to mechanizm znany dobrze ludziom pracującym z relacyjnymi bazami danych. Polega na łączeniu tabel. Wyobraź sobie, że masz tabelę, w której są zebrane dane o pracownikach – pesele, imiona, nazwiska, wykształcenie… Zaraz obok możesz zobaczyć tabelkę, w której widać dane dotyczące stanowisk – nazwy stanowisk, pensje, nazwa departamentów w firmie, pesele itd.

Jeśli chcemy pracować na danych dotyczących spraw stanowiskowych w kontekście ludzi – musimy te dwie tabele połączyć. I właśnie temu służą joiny;-). Problematyka w teorii dość prosta, w praktyce ma kilka zagwozdek o których warto wspomnieć. Przede wszystkim właśnie ta podstawowa – czyli różnice w joinach.

Typy joinów w Sparku

Chcąc połączyć tabele, mamy do dyspozycji kilka typów takiego mechanizmu. Podstawowe to inner join, left (outer) join, right (outer) join, full outer join oraz cross join. Dodatkowo możemy w sparku skorzystać z jeszcze dwóch: semi joina oraz anti joina. Omówienie każdego z nich będzie prostsze, jeśli spojrzymy najpierw na ten popularny w internecie diagram.

Wyjaśnijmy czym są owe kółeczka oznaczone jako A oraz B. Jak już napisałem, w tradycyjnych bazach danych będą to tabele. W Sparku będą to Dataframy lub Datasety. Skupimy się tutaj na Dataframach (alias dla Dataset[Row]), gdyż jest to struktura tabelaryczna, stricte przygotowana właśnie pod pracę na tabelach.

Na powyższym obrazku mamy zawsze dwie strony – lewą (A) i prawą (B). Dla wyjaśnienia: to który dataframe jest po lewej a który po prawej to rzecz czysto umowna, w zależności od tego po której stronie jaki dataframe umieścimy w kodzie. Podstawowy schemat tworzenia joina wygląda bowiem następująco:

firstDF.join(secondDF, columns, "joinType")

tak więc w takiej sytuacji “firstDF” będzie “lewym” dataframe, a “secondDF” będzie “prawy”.

Zanim przejdziemy do omówienia poszczególnych typów, zachęcam do przyjrzenia się powyższemu obrazkowi. Jeśli natomiast zapamiętać będzie ciężko, być może poniższe dzieło odrobinę pomoże:

 

W przykładach będę posługiwał się następującymi strukturami:

  1. Dataframe peopleDF zawiera id, firstName, lastName i age.
  2. Dataframe jobsDF zawiera id oraz job – czyli nazwę zawodu (np. “teacher”).

Wyglądają mniej więcej tak:

 

 

Inner Join

Zaczynamy od najprostszego typu, będącego jednocześnie domyślnym podczas łączenia tabel w Sparku. Innej join doprowadza do połączenia tych rekordów, które są wspólne – czyli wtedy, gdy warunek zostanie spełniony.

Ponieważ w Sparku inner join jest domyślny, nie musimy go określać podczas łączenia tabel. Obie poniższe implementacje są poprawne:

val innerJoin: Dataset[Row] = peopleDF.join(jobsDF, "id")
val innerJoin2: Dataset[Row] = peopleDF.join(jobsDF, Seq("id"), "inner")

Generują one następujący efekt:

Left (outer) join

Left join, czy też posługując się pełną nazwą – left outer join, to mechanizm, który łączy obie tabele po konkretnych kolumnach, natomiast zapewnia, że wszystko z lewej strony będzie miało miejsce w finalnej tabeli. Jeśli więc nie uda się powiązać (“zmatchować”) rekordów, kolumny z “prawej strony” będą wypełnione nullami.

Implementacja wygląda następująco:

val leftJoin: Dataset[Row] = peopleDF.join(jobsDF, Seq("id"), "left_outer")

I daje efekt w postaci takiej tabelki:

Zwróć uwagę na to że rekordy w peopleDF kończą się na id 18, natomiast tabela job posiada id od 1 do 13, a potem 19 i 20. Na tym przykładzie widać, że część nie powiązana została wypełniona nullami.

Right (outer) join

W przypadku right joina sprawa jest prosta – to po prostu “lustrzane odbicie” left joina. Łączy on więc obie tabele po konkretnych kolumnach, natomiast zapewnia, że wszystko z prawej strony znajdzie swoje miejsce w finalnej tabeli. Jeśli więc któreś rekordy z prawej tabeli nie będą miały swojego odpowiednika (match nie zostanie zrealizowany/“nie zmatchuje się”), to w tabeli finalnej kolumny z lewej w tych rekordach będą nullami.

Implementacja:

val rightJoin: Dataset[Row] = peopleDF.join(jobsDF, Seq("id"), "right_outer")

Nawet jeśli powyższy opis brzmi jak skomplikowany, poniższy efekt powinien wszystko rozjaśnić:

Full outer  join

Full outer join jest przeciwieństwem inner joina – bierze wszystko. Tak więc można powiedzieć, że jest sklejeniem left i right joinów wraz z usunięciem duplikatów.

Implementacja:

val fullJoin: Dataset[Row] = peopleDF.join(jobsDF, Seq("id"), "full")

Efekt:

Cross join (cartesian/iloczyn kartezjański)

Cross join nazywany jest także iloczynem kartezjańskim. Pochodzi to od matematycznego mechanizmu operacji na macierzach – właśnie iloczynu kartezjańskiego. Dla ciekawskich, z matematyczną definicją oraz kilkoma ćwiczeniami można zapoznać się tutaj.

Dla nas jednak chyba łatwiejsza będzie “definicja zbanalizowana by Maro” – czyli proste “łączymy każdy rekord z każdym”. W związku z tym, że każdy z każdym, nie ma tu potrzeby (ani miejsca) by wpisać kolumnę, po której łączymy.

Implementacja:

val crossJoin: Dataset[Row] = peopleDF.crossJoin(jobsDF)

Jak widać, efekt jest znacznie bardziej okazały, niż przy pozostałych typach łączeń. Przedstawiam tylko część, natomiast w tym przypadku rekordów jest aż 270:

Semi join

Pozostały jeszcze dwa typy joinów, zwykle pomijane. Chociaż są znacznie rzadziej spotykane, warto moim zdaniem znać oba, gdyż oba mogą okazać się naprawdę przydatne. Jeśli taka potrzeba zajdzie, po prostu zastosujemy przygotowaną już konstrukcję, zamiast robić “skok przez plecy” z selectem, równaniami, wherami i filtrami.

Pierwszym z nich jest Semi Join. To nic innego jak inner join, który… pomija kolumny z lewej strony. Tak więc po zmatchowaniu rekordów, brane są pod uwagę tylko kolumny z lewej strony.

Implementacja:

val semiJoin: Dataset[Row] = peopleDF.join(jobsDF, Seq("id"), "left_semi")

Efekt:

Anti Join

Ostatnim, najciekawszym moim zdaniem, joinem – jest anti join. Jest on pewnego rodzaju “dopełnieniem” semi-joina. Albo jego przeciwieństwem – zależy jak patrzeć. Chodzi w każdym razie  to, że chociaż kolumny są takie same – a więc jedynie z lewej strony – to… w finalnej tabeli znajdują się tylko rekordy, które nie zostały zmatchowane, nie da się ich powiązać między tabelami.

Implementacja:

val antiJoin: Dataset[Row] = peopleDF.join(jobsDF, Seq("id"), "left_anti")

Efekt:

Implementacja inaczej

Warto zauważyć jedną rzecz: wszędzie powyżej poszedłem na łatwiznę i łączyłem po takiej samej kolumnie. Może się jednak okazać, że nie będzie takich samych kolumn! Cóż wtedy zrobić? Opcji jest jak zawsze kilka. Przede wszystkim dwie (poniższe konstrukcje nie odpowiadają już schematom których trzymaliśmy się przez większość artykułu):

Opcja nr 1: zróbmy tak, żeby były takie same kolumny. Czyli po prostu zmieńmy nazwy kolumn, które mają być matchowane.

val leftJoin: Dataset[Row] = peopleDF.join(jobsDF.withColumnRenamed("personId", "id"),
      Seq("id"), "left_outer")

Opcja nr 2: powiedzmy, które kolumny mają być matchowane. Tak, to zdecydowanie brzmi rozsądniej:

val leftJoin: Dataset[Row] = peopleDF.join(jobsDF, peopleDF("id") === jobsDF("personId"), "left_outer")

To samo można także zrobić za pomocą następującej składni:

val leftJoin: Dataset[Row] = peopleDF.join(jobsDF, peopleDF("id").equalTo(jobsDF("personId")), "left_outer")

Kolejną rzeczą jaką warto rozważyć jest łączenie po kilku tabelach. Możemy to zrobić bardzo prosto:

val leftJoin: Dataset[Row] = peopleDF.join(jobsDF, Seq("id", "pesel"), "left_outer")

Można także budować bardziej skomplikowane warunki joinów:

val leftJoin: Dataset[Row] = peopleDF.join(jobsDF, peopleDF("id").equalTo(jobsDF("personId")).and(peopleDF("age").gt(jobsDF("minimumAge"))), "left_outer")

Niebezpieczeństwa

Skoro joiny są takie proste i przyjemne, to czy można ich używać bez ograniczeń i bez głębszej refleksji? Otóż… jest dokładnie odwrotnie. Napisałem na początku, że mechanizm ten wycisnął niejedną łzę u inżynierów korzystających ze sparka. Oto dlaczego:

Nie będziemy się tutaj rozwodzić nad tym co i jak w detalu. Sprawa jest prosta: join to uruchomienie shufflingu – czyli przerzucania danych między partycjami oraz nodami. To z kolei bardzo zasobożerna sprawa i warto jej unikać. Na ile oczywiście się da, bo najczęściej się po prostu nie da.

W kolejnych artykułach zagłębimy się w kwestie wydajnościowe właśnie. Na ten moment, z racji że są to podstawy, polecam przejrzeć kod pod kątem akcji, które wykonujemy po joinie. Być może warto po połączeniu tabel zrobić bowiem cache(), persist() lub checkpoint(). Gdybyśmy wywoływali dwukrotnie akcje, dwukrotnie będzie zrobiony także join – a po co, jak nie trzeba?;-).

Ciąg dalszy…

Mam szczerą nadzieję, że wiesz już teraz wszystko czego trzeba, aby zacząć przygodę z joinami w Sparku. Oczywiście w kolejnych artykułach zagłębimy się nieco w tym zagadnieniu – zostań z nami przez newsletter!

Jeśli czujesz, że Twoje wiedza na temat Sparka jest nieuporządkowana i frustruje Cię to, to mam dobrą wiadomość. Organizujemy szkolenia dla firm z zakresu… właśnie Apache Spark. Jeśli masz dobrego szefa, podeślij mu kontakt do nas – możemy pojawić się u Ciebie w firmie i pokazać wszystko od 0 do Spark Inżyniera;-). Strona ze szkoleniem dostępna jest tutaj.

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