Biznes

W tym miejscu przeczytasz wpisy związane z biznesem Big Data/AI. Co zrobić, aby pomóc w rozwoju firmy, jak wdrażać, jak projektować, jak rozwiązywać problemy projektowe i inne.

W podróży Big Data – jak odnaleźć się w dżungli technologii?

W podróży Big Data – jak odnaleźć się w dżungli technologii?

Marek Czuma

Nie ma znaczenia czy dopiero zaczynasz swoją przygodę z Big Data, czy masz już doświadczenie, czy jesteś inżynierem, czy patrzysz na branżę stricte biznesowo. W każdym przypadku przyjdzie taki moment, w którym poczujesz się zagubiony mnogością technologii oraz tym jak bardzo są “niedookreślone”. W tym materiale postaram się wprowadzić względny porządek i przeprowadzić Cię suchą stopą przez bagno technologii obsługujących duże dane. Bierz zatem kubek mocnej jak otchłań Data Lake’a kawy – i zaczynamy!

Metodologia

Małe zastrzeżenie…

Zacznijmy od bardzo podstawowego zastrzeżenia: to co tu zaproponuję, może być bardzo łatwo podważone. Co więcej – to co tu pokażę, będzie z całą pewnością niepełne. BA! Niepełne? Dobre sobie… to będzie zaledwie muśnięcie Big Datowej rzeczywistości. Wszystko to wynika z faktu, że branża przyjęła już naprawdę pokaźne rozmiary i wprowadzenie poważnej metodologii porządkującej pojęcia oraz technologie, wymagałoby pracy dyplomowej. Być może nawet doktoratu. Czemu? Cóż – tego jest po prostu najzwyczajniej w świecie tak dużo i odpowiadają na tak wiele potrzeb, że łączenie technologii staje się prawdziwą sztuką.

Zatem powiedzmy sobie: ten artykuł jest dla Ciebie, jeśli wiesz coś niecoś o Big Data, ale wszystko zaczęło się mieszać. Zastanawiasz się nad tym które z topowych technologii służą do czego i jak można je połączyć. Z takim podejściem – zaczynamy!

Podział ze względu na przeznaczenie

Dzielić technologie można ze względu na wiele rzeczy – możemy podzielić patrząc na języki programowania, możemy podzielić patrząc czy jest to technologia chmurowa, a można poszukać pod kątem popularności. Można też – i tak zrobimy – podzielić ze względu na przeznaczenie, cel jakiemu służą.

Mój podział będzie następujący:

  1. Storages
  2. Bazy danych (nierelacyjne)
  3. Full-text search
  4. Przetwarzanie danych
  5. Komunikacja z danymi
  6. Schedulers
  7. Messaging
  8. Technologie analityczne

Jeszcze raz zaznaczę: jest to z całą pewnością obraz niepełny. Jest jeszcze trochę obszarów, które nie zostały tu wzięte pod uwagę. Ten pozwoli jednak złapać pewien punkt zaczepienia – i o to chodzi;-).

Storages

Czemu służą?: Storages (nie mam pojęcia jak przetłumaczyć to poprawnie, poza dość prostackimi “magazynami danych”) służą przechowywaniu ogromnych ilości danych w sposób możliwie prosty.

Krótki komentarz: Temat storages nie jest dobrze zdefiniowany. Niekiedy jako storage traktuje się wszystko, co przechowuje dane, a więc także bazy danych. Ja wyodrębniłem tu jednak “data storage” jako “prosty” system, który pozwala przechowywać dane w sposób mniej złożony, niż bazy. Należą więc do tego wszelkiego rodzaju rozproszone systemy plików, Data Lakes itd.

Przedstawiciele:

  1. HDFS (Hadoop Distributed File System)
  2. ADLS gen 2 (Azure Data Lake Storage gen 2)
  3. Amazon S3 (na AWS)
  4. Google Cloud Storage (na GCP)
  5. Delta Lake
  6. Kudu (wymienione także w Bazach Danych)
  7. Ozone (wymienione także w Bazach Danych)

Bazy danych (noSql)

Czemu służą?: Bazy danych służą przechowywaniu ogromnych ilości danych. Różnią się jednak nieco od Storages. Ich przeznaczenie zawiera bardziej ustrukturyzowaną formę przechowywania danych, a także możliwości bardziej zaawansowanej manipulacji danymi (przeglądania, usuwania pojedynczych rekordów itd).

Krótki komentarz: W temacie baz danych mamy bardzo dużo i coraz więcej technologii, które mogą nas interesować. Niektóre z nich nieco mieszają się ze Storages. To są właśnie te płynne granice o których już wspominałem. UWAGA! Wspominam tu jedynie o stricte big datowych, nierelacyjnych bazach danych. Nie znajdziemy tu więc popularnego mysql czy postgresql. Mamy wiele rodzajów baz danych – przede wszystkim key-value store, graph db, document store.

Przedstawiciele:

  1. HBase
  2. Accumulo
  3. MongoDB
  4. Cassandra
  5. CosmosDB (Azure)
  6. Dynamo DB (AWS)
  7. Google Cloud Datastore (GCP)
  8. Kudu (wymienione także w Storages)
  9. Ozone (wymienione także w Storages)
  10. Neo4j
  11. Druid

Full Text Searches

Czemu służą? Technologie full-text search (przeszukiwania pełno-tekstowego) także (znów!) odpowiadają za przechowywanie danych. Tym razem jednak przechowywanie zaprojektowane jest tak, aby dało się to potem bardzo dobrze przeszukiwać. Szczególnie mocny akcent położony jest na przeszukiwanie tekstu wraz z różnymi funkcjami wbudowanymi, tak aby nie było szczególnie trudne zbudowane wyszukiwarki zawierającej wyszukiwanie podobnych wyrazów czy uwzględnianie literówek.

Krótki komentarz: W przeciwieństwie do pozostałych obszarów, full-text searche zdają się być zdominowane przez dwie technologie. Co więcej – obie zbudowane są na tym samym silniku. Nie oznacza to jednak, że jest to jedyna oferta na rynku! Co ciekawe, full-text searche mogą stanowić także znakomity mix przydatny do analizy danych. Ciekawym przykładem jest zastosowanie Elasticsearcha w NASA (konkretniej JPL) m.in. do analizy danych przysyłanych przez łaziki.

Przedstawiciele:

  1. Lucene – nie jest samodzielną osobną technologią, a raczej silnikiem, na którym powstały inne.
  2. Elasticsearch
  3. Solr
  4. Sphinx

Przetwarzanie danych (processing)

Czemu służą? Technologie do przetwarzania danych oczywiście… przetwarzają dane;-). Oczywiście mowa tu o bardzo dużych danych. W związku z tym technologie te zwykorzystują mechanizmy zrównoleglania obliczeń. Można te technologie wykorzystywać do ogromnej ilości celów. Od strandardowego czyszczenia, przez harmonizację (sprowadzenie datasetów do wspólnej postaci pod kątem schematu), opracowywanie raportów statystycznych, aż po wykorzystywanie algorytmów sztucznej inteligencji.

Krótki komentarz: Technologie do przetwarzania danych podzielimy z grubsza na dwa rodzaje: batchowe i streamingowe. Batchowe to te, których zadaniem jest pobrać dużą paczkę danych, “przemielić je” i zwrócić wynik. Streamingowe natomiast działają w trybie ciągłym. W przeciwieństwie do pierwszego rodzaju – “nie kończą się”.

Przedstawiciele:

  1. Spark
  2. Spark Structured Streaming – choć zawiera się w pierwszym punkcie, zasługuje na osobne wyróżnienie.
  3. Kafka Strams – świetnie wspólgra z Kafką. Dodatkowo cechuje się daleko posuniętą prostotą.
  4. Flink
  5. Storm
  6. Map Reduce – choć obecnie nie jest już raczej implementowany w nowych systemach, to znajduje się w galerii sław i nie można o nim nie wspomnieć!
https://cdn.analyticsvidhya.com/wp-content/uploads/2020/11/repartition.jpg
Klasyka gatunku. Witamy w Sparku!;-)

Komunikacja z danymi (interfejsy SQL-like)

Czemu służą? Technologie które mam na myśli powodują, że w prostszy sposób możemy dostać się do danych, które normalnie przechowywane są w postaci plików (lub w innej postaci, natomiast wciąż kiepskiej w kontekście pracy z danymi). Przykładem jest, gdy chcemy składować pliki na HDFS, ale zależy nam na zachowaniu możliwości pracy z tymi danymi (prostych operacji przeszukiwania, dodawania itd). Technologie te dostarczają często interfejs obsługi danych składowanych w różnych miejscach, podobny do SQL.

Przedstawiciele:

  1. Hive
  2. Impala
  3. Shark
  4. BigSQL

Schedulery

Czemu służą? Kiedy tworzymy joby, bardzo często mamy potrzebe ustawienia ich aby były uruchamiane o tej samej porze. Temu właśnie służą między innymi schedulery.

Krótki komentarz:  Poza prostymi funkcjami określania kiedy jakie joby powinny zostać uruchomione, schedulery pozwalają także ustawić całą ścieżkę zależności w uruchamianiu jobów. Np. “jeśli zaciąganie danych zostanie ukończone, rozpcoznij czyszczenie, a potem harmonizację. Jeśli na którymś etapie coś pójdzie nie tak, wyślij maila z alertem”. Do tego dochodzą jeszcze możliwości (lepszego lub gorszego) monitoringu tych jobów oraz całych workflowów.

Przedstawiciele:

  1. Oozie
  2. Airflow
  3. Luigi
  4. Jenkins (częściowo)
  5. Pinball (stworzony przez Pinterest, natomiast nie jest obecnie aktywnie przez pinterest rozwijany)
  6. Step Functions (AWS)
  7. Workflows (GCP)
  8. Logic Apps (Azure)

Messaging

Czemu służą? Technologie do messagingu czy też kolejkowania, to technologie, które – nieco banalizując – są “punktem przesyłu” wielu danych. Wykorzystuje się je szczególnie często w kontekście przetwarzania streamingowego danych. Kiedy produkujemy jakieś dane, nie musimy się zastanawiać gdzie mają być dalej przetworzone. Wystarczy wykorzystać technologię kolejkowania i już. To jakie inne procesy podepną się pod ten “punkt przesyłu” to już zupełnie inna sprawa.

Krótki komentarz: Bardzo często technologie te zestawiane są z frameworkami do przetwarzania streamingowego. Wymienione zostały m.in. parę punktów wyżej (np. Spark Structured Streaming, Flink czy Kafka Streams). Warto tu dodać, że technologie tego typu są także często wykorzystywane w procesie IoT (internetu rzeczy – Internet of Things), gdy poszczególne urządzenia mogą raportować o swojej aktywności.

Przedstawiciele:

  1. Kafka
  2. RabbitMQ
  3. Event Hub (Azure)
  4. Kinesis (AWS)
  5. Pub/Sub (GCP)
  6. IBM MQ (IBM)

Technologie analityczne (BI – Business Intelligence)

Czemu służą? Za pomocą narzędzi analitycznych możemy tworzyć dashboardy, które pomogą nam analizować wcześniej zebrane dane.

Krótki komentarz: Warto pamiętać właśnie o takim aspekcie jak “wcześniej zebrane dane”. Nie wystarczy, że będziemy mieli aplikację analityczną. Aby w pełni wykorzystać jej potencjał, należy zawczasu pomyśleć o tym jak powinien wyglądać nasz pipeline, aby odpowiednie dane (nie za duże, nie za małe, odpowiednio ustrukturyzowane itd.) mogły zostać przez narzędzie BI zaciągnięte.

Przedstawiciele:

  1. Apache Superset
  2. Power BI (Azure)
  3. Amazon QuickSite (AWS)
  4. Google Data Studio (GCP)
  5. Holistics
  6. Looker
  7. Tableau

I jak się w tym wszystkim nie zagubić?

Mam nadzieję, że tym artykułem chociaż odrobinę pomogłem w uporządkowaniu spojrzenia na świat Big Data. Mnóstwo technologii nie zostało tutaj ujętych. Jest to jednak dobry punkt startowy;-). Jeśli widzisz potrzebę, aby coś tutaj dodać lub zmienić – daj sobie swobodę napisania o tym w komentarzu:-).

Jeśli chcesz tworzyć polską społeczność Big Data – odwiedź nas koniecznie na LinkedIn oraz zapisz się do newslettera!

 

3 kroki do przodu: jak Big Data może pomóc Polsce w opanowaniu inflacji?

3 kroki do przodu: jak Big Data może pomóc Polsce w opanowaniu inflacji?

Marek Czuma

Inflacja po raz pierwszy (od dawna) weszła “pod strzechy” – nie jest już jedynie tematem dyskusji eksperckich. Wręcz przeciwnie – od kilku miesięcy jest bohaterką pierwszych stron gazet w całym kraju – z brukowcami włącznie. Powodem jest znaczne przyspieszenie utraty wartości waluty, co w przypadku naszej historii wzbudza szczególnie nieprzyjemne skojarzenia. Dodatkowo niektórzy zarzucają stronie rządowej, że oficjalna inflacja jest zaburzona.

Chciałbym dzisiaj zaproponować pewne rozwiązanie, które pomogłoby nam w analizie inflacji, a co za tym idzie – w odpowiedniej kontroli nad nią. Wszystko co poniżej to pewna ogólna wizja, która może posłużyć jako inspiracja. Jeśli jest chęć i zapotrzebowanie, bardzo chętnie się w tą wizję zagłębię architektonicznie i inżyniersko. Zachęcam także do kontaktu, jeśli TY jesteś osobą zainteresowaną tematem;-).

Krótka lekcja: jak liczona jest inflacja?

Czym jest inflacja?

Zanim przejdziemy do rozwiązania, zacznijmy od problemu. Czym jest inflacja i jak liczy ją GUS? Przede wszystkim najważniejsze to zrozumieć, że inflacja to spadek wartości pieniądza w czasie. Dzieje się tak w sposób praktyczny poprzez wzrost cen. Za ten sam chleb, wodę – musimy zapłacić więcej. I teraz to najważniejsze: inflacja jest inna dla każdego z nas. Każdy z nas ma bowiem inny portfel.

Jeśli zestawimy samotnego programistę oraz rodzinę wielodzietną, gdzie Tata zarabia jako architekt a Mama jako tłumaczka, ich budżety bedą zupełnie inne. Nawet jeśli zarabiają podobne kwoty, w rodzinie większy udział prawdopodobnie będzie na pieluchy, przedmioty szkolne i parę innych rzeczy. W przypadku młodego singla z solidną pensją, do tego z rozrywkowym podejściem do życia, znacznie większy procent budżetu zajmie alkohol, hotele, imprezy itd. Jeśli ceny alkoholi pójdą w górę o 40%, dla niektórych inflacja będzie nie do zniesienia, dla innych z kolei może nie zostać nawet zauważona.

Jak liczone jest CPI (inflacja konsumencka)?

Aby zaradzić tego typu problemom, GUS wylicza coś takiego jak CPI (Consumer Price Index) – indeks zmiany cen towarów i usług konsumpcyjnych. W skrócie mówimy inflacja CPI, czyli inflacja konsumencka. Warto zaznaczyć tutaj jeszcze, że zupełnie inna może być inflacja odczuwana na poziomie budżetów firm (a właściwie dla różnych firm jest także oczywiście różna).

Nie będziemy się tutaj wgryzać zbyt mocno w to jak dokładnie wylicza się inflację CPI. Skupimy się jedynie na paru najważniejszych rzeczach, które przydadzą nam się do późniejszej odpowiedzi na nasz inflacyjny problem;-). Dla zainteresowanych polecam solidniejsze omówienia:

  1. Najpierw u źródła – “Co warto wiedzieć o inflacji?” przez GUS.
  2. “Ile naprawdę wynosi inflacja?” Marcin Iwuć
  3. “GUS zaniża inflację? Ujawniamy!” – mBank
Koszyk inflacyjny 2021. Autor: Pawelmhm

Na nasze potrzeby powiedzmy sobie bardzo prosto, w jaki sposób GUS liczy CPI. Potrzeba do tego podstawowej rzeczy, czyli koszyka inflacyjnego. Taki koszyk to grupy towarów, które podlegają badaniu. GUS oblicza to na podstawie ankiet wysyłanych przez 30 000 osób. Już tutaj powstaje pewien problem – ankiety te mogą być wypełniane nierzetelnie.

Następnie, jeśli mamy już grupy produktów, musimy wiedzieć jak ich ceny zmieniają się w skali całego kraju. Aby to zrobić, wyposażeni w tablety ankieterzy, od 5 do 22 dnia każdego miesiąca, ruszają do akcji – a konkretnie do wytypowanych wcześniej punktów (np. sklepów spożywczych) w konkretnych rejonach. W 2019 roku badanie prowadzono w 207 rejonach w całej Polsce.

Big Data w służbie jej królew… to znaczy w służbie Rządu RP

Taka metodologia prowadzi do bardzo wielu wątpliwości. Badanie GUSu zakrojone jest na bardzo szeroką skalę. Mimo to jednak wciąż są to jedynie wybrane gospodarstwa oraz wybrane punkty sprzedaży. Chcę tutaj podkreślić, że nie podejrzewam naszych statystyków o manipulacje. Może jednak dałoby się zrobić tą samą pracę lepiej, bardziej precyzyjnie i znacznie mniejszym kosztem?

Cyfryzacja paragonowa – czyli jak Rząd przenosi nasze zakupy do baz danych?

Zanim przejdziemy dalej, powiedzmy najpierw coś, z czego być może większość z nas sobie nie zdaje sprawy. Ostatnie lata to stopniowe przechodzenie z tradycyjnych kas fiskalnych na kasy wirtualne oraz online. Na potrzeby artykułu nie będę wyjaśniał różnic. To co nas interesuje to fakt, że oba typy kas, zakupy raportują bezpośrednio do Rządu. Na ten moment objęta jest tym stanem rzeczy gastronomia, ale docelowo ma to objąć (wedle mojej wiedzy) także inne sektory posługujące się paragonami.

Jak zbudować system liczący inflację?

Przenieśmy się mentalnie do momentu, w którym każda, lub niemal każda sprzedaż jest odnotowywana przez państwo i zapisywana w tamtejszej bazie danych (najprawdopodobniej nierelacyjnej). Można to wykorzystać, aby zbudować system, który pozwoli nam liczyć inflację pozbawioną potrzeby wysyłania armii ankieterów. Co więcej – pozwoli to zrobić dokładniej oraz da nam potężne narzędzie analityczne!

Bazy danych / Storage

Przede wszystkim – zakładam, że wszystkie dane trzymane są w jakiejś nierelacyjnej bazie danych – na przykład w Apache HBase. Może to być jednak także rozproszony system plików, jsk HDFS. W takiej bazie powinny być trzymane wszystkie dane dotyczące transakcji – paragony, faktury, JPK itd. Osobną sprawą pozostają informacje dotyczące firm i inne dane, które są bardziej “ogólne” – dotykają mniejszej liczby podmiotów i nie są tak detaliczne.

W nowoczesnym systemie do liczenia inflacji Spark odegrałby kluczową rolę

Te dane, ze względu na niewielką liczbę i bardzo klarowną strukturę, można trzymać w bazie relacyjnej (np. PostgreSQL). Można jednak także jako osobną tabelę HBase, choć z przyczyn analitycznych (o których potem) znacznie lepiej będzie zrobić to w bazie relacyjnej. Można także zastosować rozwiązanie hybrydowe – wszystkie dane dotyczące firm trzymać w bazie nierelacyjnej, jako swoistym “magazynie”, natomiast pewną wyspecyfikowaną, odchudzoną esencję – w bazie relacyjnej.

Dodatkowo zakładam, że koszyk inflacyjny jest już wcześniej przygotowany. Da się ten proces uprościć poprzez informatyzację ankiet – jest to już zresztą robione (według wiedzy jaką mam). Taki koszyk można trzymać w bazie relacyjnej, ze względu na relatywnie niewielką liczbę danych (W 2021 roku zawierał on 12 grup produktów. Nawet jeśli w każdej z nich byłoby parę tysięcy produktów, liczby będą  sięgać maksymalnie kilkudziesięciu tysięcy, niezbyt rozbudowanych rekordów).

W dalszej części dodam jeszcze możliwość tworzenia kolejnych koszyków i w takiej sytuacji prawdopodobnie należałoby już je wydzielić do osobnej bazy nierelacyjnej. W dalszym ciągu jednak ogólne adnotacje mogłyby pozostać w bazie relacyjnej (tak, żeby można było np. sprawnie wyciągnąć dane z HBase po rowkey, czyli id).

Jeśli zdecydujemy się na zastosowanie bazy row-key, jak HBase, uważam że i tak zaistnieje potrzeba wykorzystania HDFS (może być tak, że w HBase będzie wygodniej pierwotnie umieszczać pliki paragonowe). Będziemy tu umieszczać kolejne etapy przetworzonych danych z konkretnych okresów.

Jeszcze inną opcją jest zastosowanie Apache Kudu, który mógłby nieco zrównoważyć problemy HBase i HDFS i zastąpić oba byty w naszym systemie. Jak widać, opcji jest dużo;-)

Przygotowanie danych

Kiedy mamy już dane zebrane w przynajmniej dwóch miejscach, powinniśmy je przygotować. Same z siebie stanowią jedynie zbiór danych, głównie tekstowych. W drugim  etapie należy te dane przetworzyć, oczyścić i doprowadzić do postaci, w jakiej ponownie będziemy mogli dokonać już finalnej analizy inflacji.

 

Finałem tego etapu powinny być dane, które będą pogrupowane tak, żebyśmy mogli je później wykorzystać. Wstępna, proponowana struktura wyglądać może następująco:

  1. Okres badania
    1. Grupa produktów
      1. Punkt sprzedaży
        1. towar

Musimy więc wyciągnąć surowe dane (z HBase), przetworzyć je, a następnie zapisać jako osobny zestaw – proponuję tu HDFS. Jak to uczynić? Możemy do tego celu wykorzystać Apache Spark oraz connector HBase Spark przygotowany przez Clouderę. Następnie dane muszą być poddane serii transformacji, dzięki którym dane:

  • Zostaną wydzielone jako osobne paragony
  • Zostaną podzielone na produkty
  • Poddane będą oczyszczeniu z wszelkich “śmieci” uniemożliwiających dalszą analizę
  • Wykryta zostanie grupa produktów dla każdego z nich
  • Pogrupowane zostaną po grupie produktów oraz okresie

Na końcu dane zapisujemy do HDFS. Wstępna struktura katalogów:

  1. Dane przygotowane
    1. Dane całościowe
      1. okres
        1. Tutaj umieszczamy plik *.parquet lub *.orc

Liczenie inflacji

Skoro mamy już przygotowane dane, czas policzyć inflację. Do tego celu także wykorzystamy Apache Spark, dzięki któremu możemy w zrównoleglony sposób przetwarzać dane. W najbardziej ogólnym kształcie sprawa wygląda dość prosto:

  1. Łączymy się z bazą danych (relacyjną), w której trzymamy konkretny koszyk
  2. Wybieramy okres za jaki chcemy policzyć inflację
  3. Pobieramy dane z HDFS/Kudu, które okresem odpowiadają [2].
  4. Wybieramy grupy produktów zgodne z koszykiem [1]
  5. Przeliczamy inflację za pomocą danych, które są już solidnie przygotowane.

I teraz ważne: efekt zapisujemy do relacyjnej bazy danych.

Analiza

Czemu akurat do relacyjnej bazy danych? Odpowiedź wydaje się oczywista:

  1. Dane będą niewielkie – choć od raz umożna powiedzieć, że z naszego procesu można wycisnąć więcej niż tylko wynik 6.8% 😉 – jest też sporo rzeczy przy okazji, takie jak jakie produkty wzrosły najmocniej, w jakich regionach, co ma największą zmiennośći itd.
  2. Dane będą solidnie ustrukturyzowane
  3. Dane umieszczone w relacyjnych bazach pozwalają na znacznie lepszą i prostszą analizę.

I właśnie ten trzeci punkt powinien nas zainteresować najmocniej. Można bowiem na klastrze zainstalować jakieś narzędzie BI, spiąć z bazą i… udostępnić analitykom. Takim narzędziem może być (znów open sourcowy) Apache Superset. Przynajmniej na dobry początek. W drugim rzucie należałoby się pokusić o zbudowanie dedykowanej aplikacji analitycznej. To jednak można zostawić na  później. Na etap, w którym analitycy będą już zaznajomieni z systemem i będą mogli włączyć się w czynny proces budowy nowego narzędzia.

Rozwój

Wyżej opisałem podstawowy kształt systemu do badania inflacji. Warto jednak nie zatrzymywać się na tym i pomyśleć jak można tą analizę wynieść na wyższy poziom. Podstawową prawdą na temat inflacji jest to, że każdy ma swoją, więc nie da się dokładnie obliczać jak pieniądz traci na wartości. Cóż… dlaczego nie możnaby tego zmienić? Wszak mając do dyspozycji WSZYSTKIE (oczywiście upraszczając) dane, można zrobić “nieskończenie wiele” koszyków inflacyjnych.

Czym mogłoby być te koszyki inflacyjne? Kilka propozycji.

  1. Dlaczego nie wykorzystać rozwoju technologii Big Datowych do podnoszenia świadomości finansowej oraz obywatelskiej Polaków? Niech każdy będzie mógł na specjalnym portalu wyklikać swój własny koszyk i regularnie otrzymywać powiadomienia dotyczące swojej własnej inflacji. Takie podejście byłoby bardzo nowatorskie i z pewnością wybilibyśmy się na tle innych państw.
  2. Koszyki mogą powstawać dla różnych grup społecznych. Dzięki temu można będzie dokładniej badać przyczyny rozwarstwienia społecznego, niż jedynie osławiony współczynnik Giniego, czy także inne, powiedzmy sobie szczerze – skromne narzędzia, na podstawie których wyciągane są bardzo mocne dane.
  3. Koszyki dla firm – oczywistym jest, że firmy mają znacząco różny koszyk od ludzi. Jest oczywiście inflacja przemysłowa (PPI), natomiast dotyczy ona produkcji przemysłowej (i to w dośćwąskim zakresie). Dzięki wyborowi produktów w “naszym systemie” można będzie obliczyć także jak bardzo wartość pieniądza spada dla różnych rodzajów firm.

Potencjalne korzyści

Powyżej opisałem przykładowy system, który pozwoliłby nam wynieść analizę inflacji na zupełnie inny poziom. Poniżej chciałbym zebrać w jedno miejsce kilka najważniejszych korzyści, jakie niosłyby takie zmiany:

  1. Mniejsze koszty – cykliczne uruchamianie jobów mających na celu sprawdzenie inflacji to koszt znacznie mniejszy, niż utrzymywanie armii ankieterów.
  2. Dokładniejsza inflacja – precyzja liczenia inflacji weszłaby na zupełnie inny poziom. Oczywiście na początku należałoby przez kilka lat liczyć w obu systemach, aby sprawdzić jak bardzo duże są różnice.
  3. Różne modele inflacji – a więc koszyki o których pisałem powyżej, które spowodują, że przestanie być prawdziwa teza o tym, że “liczenie prawdziwej inflacji nie jest możliwe”.
  4. Regionalizacja inflacji – Inflacja inflacji nie jest równa. Zupełnie inaczej ceny mogą się kształtować w różnych województwach. Również i to mógłby liczyć “nasz system”.
  5. Większe możliwości analityczne – stopy nie są jedynym narzędziem, który można użyć w walce z inflacją. Ekonomiści wskazują, że poza wysokością stóp procentowych także inne czynniki wpływają na inflację. Są to m.in. skala dodruku pieniądza, rozwój świadczeń socjalnych, regulacje gospodarcze czy wysokość podatków pośrednich. Dzięki Big Datowemu systemowi, Rząd zyskałby znacznie większe możliwości analityczne do śledzenia wpływu swoich zmian na gospodarkę.
  6. Wyższe morale i poczucie, że państwo gra “w pierwszej lidze” – unowocześnia swoje działanie na poziom niespotykany w innych krajach.

Potencjalne zagrożenia

Rozwój zaawansowanych systemów to oczywiście także zagrożenia. O tych najważniejszych poniżej:

  1. Możliwości analityczne muszą wiązać się z większą inwigilacją – i jest to chyba największy problem. Im większe możliwości analizy chcemy sobie zafundować, tym głębiej trzeba zinfiltrować życie obywateli. Oczywiście przed infiltracją współcześnie uciec się nie da, ale należy zawsze mieć na uwadze mądre wyważanie.
  2. Koszt utrzymania systemu – To system zbierania bardzo dużych danych i analizy ich. Wymagać będzie zaawansowanych klastrów obliczeniowych oraz odpowiedniego zespołu administracyjnego. Na pensjach – dodajmy – zdecydowanie rynkowych, nie urzędniczych.
  3. Kwestia bezpieczeństwa – czasami zapominamy, że informatyzacja państwa to problem w bezpieczeństwie danych. Jeśli jesnak dane dotyczące zakupów i tak miałyby być zbierane – czemu ich nie wykorzystać?

Big Data to nasza wielka szansa – także w sektorze rządowym

Jesteśmy Państwem, które w wielu miejscach wiecznie próbuje nadgonić resztę (choć w wielu także tą resztę przegoniło). Big Data może pozwolić na działać lepiej, szybciej, precyzyjniej i… taniej. Wykorzystajmy tą szansę. Za nami poglądowy pomysł na to jak zbudować jeden z takich systemów, które mogłyby pomóc nam budować nowoczesne państwo. Jeśli chcesz dowiadywać się o innych pomysłach, które ukazują Big Data w odpowiednim kontekście, zapraszam na nasz profil LinkedIn oraz do zapisania się na newsletter RDF. Do zobaczenia na szlaku BD!;-)

 

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

 

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!

 

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.