big data

Jak rozumieć systemy Big Data? Kluczowa rzecz.

Jak rozumieć systemy Big Data? Kluczowa rzecz.

Marek Czuma

Właśnie skończyłem kolejne szkolenie (nie byle jakie, bo to było 2-miesięczne, kompleksowe – serio, hardcore). Uświadomiło mi ono jedną bardzo konkretną rzecz w kontekście naszego zrozumienia systemów Big Data. Chciałem się nią podzielić. Artykuł przede wszystkim do technicznych, ale… nie tylko. Zdecydowanie nie tylko.

Złożoność – nasz główny wróg

Podchodząc do systemu przetwarzania bardzo dużych ilości danych, mamy jednego podstawowego wroga. Staje przed nami niczym behemot już na poziomie koncepcji. Jest to… stopień złożoności problemu. Przyznajmy szczerze – nie lubimy złożonych problemów. Ani w życiu prywatnym, ani zawodowym. Aby rozwiązać taki problem, należy wytężyć mózgownicę do takich granic, które u niektórych powodują niemały ból.

Szczególnie daje się to we znaki, gdy ktoś przeszedł do Big Data z “tradycyjnej IT”. Jeśli robiłeś wcześniej aplikacje webowe, możesz doznać szoku. I nie mówię nawet o tym, że dotychczas wszystkie Twoje problemy zawarte były w jednym pliku z logami, podczas gdy tutaj nawet pojedyncza technologia ma kilka serwisów, a każdy z nich swoje własne logi.

Po prostu złożoność jest inna. Robiąc aplikację webową (zostańmy przy tym), mam jasne wytyczne, standardy i zwykle prostą ścieżkę, którą uruchamia (najczęściej) użytkownik. Wejdziemy pod odpowiedni adres? W takim razie musimy wysłać zapytanie do bazy danych, dokonać kilku obliczeń i wyrenderować stronę końcową.

Gorzej, jeśli trzeba zbudować cały skomplikowany system, a wejście (rozumiane jako input)… cóż, wejścia czasami nie ma. Albo jest ich bardzo, bardzo wiele. Albo – co gorsza – jest wejście, wyglądające bardzo “tradycyjnie”(np. request użytkownika).

Jak zaprojektować system – problem złudnego “wejścia” (inputu)

Przypuśćmy taką prostą sytuację. Robimy aplikację-wyszukiwarkę filmów związanych z danymi miastami. W efekcie wpiszemy nazwę miasta, a otrzymujemy listę miast, które w ten czy inny sposób dotyczą go (czy to w kontekście tematyki czy lokalizacji).

Bardzo łatwo w takiej sytuacji zacząć całe projektowanie wychodząc od użytkownika i mając przeświadczenie, że to on musi uruchamiać całą machinę. No świetnie, zatem wcielmy się w taką rolę. Użytkownik wpisuje nazwę miasta i… i co? Czy mam teraz starać się wyszukiwać po internecie wszystkich możliwych informacji? Byłoby to całkiem, całkiem długotrwałym procesem.

No dobrze, więc może zacząć zbierać oraz przetwarzać dane, osobno? Pomysł dobry. Jednak i tutaj można łatwo wpaść w pułapkę wąskiego myślenia. Ciągle mamy z tyłu głowy użytkownika, więc zaczynają powstawać dziwne pomysły, na uruchamianie przetwarzania po wykonanym requeście, w trakcie itd. Ciągle mamy tą manierę, że staramy się wychodzić od jednego punktu i przejść przez wszystkie elementy systemu. To trochę tak, jakbyśmy starali się złapać bardzo dużo drewnianych klocków na raz. Nie ma szans – wypadnie. Kto próbował ekspresowo posprzątać po zabawach swoich dzieci u Dziadków, wie o co chodzi.

Słowo klucz: decentralizacja

Prowadząc szkolenie, gdzieś w połowie zorientowałem się, że coś jest nie tak. Zbadałem temat i zauważyłem, że kursanci bardzo dziwnie podeszli do budowy modułów. Chodziło konkretnie o te podstawowe rzeczy, jakimi jest wejście i wyjście aplikacji (input i output) oraz zarządzanie całością.  Zasadniczo cały projekt opierał się oczywiście o bardzo wiele mniejszych modułów. Niektóre pobierały dane z internetu, inne te dane czyściły i przetwarzały. Jeszcze inny moduł – streamingowy – służył do kontaktu użytkownika z systemem.

W pewnym momencie, po raz kolejny dostałem pytanie, które brzmiało mniej więcej tak: “No, skoro mamy mnóstwo małych modułów, to chyba musimy też gdzieś zbudować skrypt, który to wszystko uruchamia prawda?“. Uznałem, że czas na radykalną zmianę myślenia, przerwanie “starego” paradygmatu i zrozumienia o co chodzi w systemach do przetwarzania i obsługi dużych danych.

Myśl po nowemu – czyli jak poprawnie patrzeć na systemy Big Data?

Oczywiście nie ma jednej złotej zasady, dzięki której zrozumiemy “filozofię Big Data”. Jest jednak coś, czego zrozumienie może być przełomem. Pozwoli wygrać ze złożonością, pozwoli zrozumieć duży, skomplikowany system. Pomoże – wreszcie – przestać siwieć (albo, jak w moim przypadku jest – łysieć) z frustracji.

Otóż, chodzi o magiczne słowo: decentralizacja. Nie, mowa nie o technologii blockchain;-). Chodzi o umiejętność spojrzenie na cały system metodą “od ogółu do szczegółu” i zrozumienie poszczególnych elementów (modułów lub powiązań między nimi). Spójrzmy na kilka kwestii, które to tłumaczą.

  1. Każdy wielki system zbudowany jest z wielu mniejszych (co nie znaczy małych) modułów. Na etapie rozumienia całości, nie musimy wgłębiać się w technikalia czy implementację. Wystarczy nam ogólna wiedza o tym co dany moduł przyjmuje, a co zwraca (jakie jest jego zadanie). Dodatkowo jeśli wiemy z jakimi modułami łączy się (bezpośrednio, lub na poziomie logicznym) to już w ogóle bardzo dużo.
  2. Każdy moduł ma swoje zadanie. Niekoniecznie musi być zależne od innych modułów! Przykładowo, jeśli potrzeba nam w systemie pogody, to potrzeba nam pogody. Nie musimy wiązać tego z modułem, który pobiera filmy, albo składuje requesty od użytkownika. W momencie rozumienia modułu od pogody, musimy zbudować mechanizmy pobierające pogodę. Jak to zrobimy? Z wykorzystanie pythona, javy? A może Nifi?
  3. Każdy moduł może być uruchamiany niezależnie od użytkownika. I tutaj musimy znać miejsce takiego podsystemu w systemie.
    • Jeśli jest niezależny od czegokolwiek – wystarczy prosty skrypt oraz jakiś scheduler, typu Airflow czy Oozie. Pogodę możemy pobierać co godzinę niezależnie od wszystkiego.
    • Jeśli jest zależny, musimy wiedzieć w jaki sposób jest zależny. Znów najprawdopodobniej użyjemy schedulera, ale pewnie uzależnimy go od wyników innych modułów (jeśli dane nie zostały pobrane, nie ma sensu uruchamiać czyszczenia).
    • Może się okazać, że moduł naprawdę jest w ścisłym kontakcie z użytkownikiem. W takiej sytuacji, po prostu musimy to dobrze umieścić.
  4. Gdy pracujemy z danym modułem, możemy się zagłębić w szczegóły, a jednocześnie “zapomnieć” o reszcie systemu. Gdy – znów – zaciągamy dane pogodowe, nie musimy myśleć o tym jak one potem zostaną wykorzystane. Dzięki temu usuwamy element, który nas przytłacza. Aby to zrobić – to istotne – powinniśmy wcześniej dobrze zaprojektować całość, łącznie z szczegółowo opisanym wyjściem (output’em). Jakie dokładnie dane pogodowe muszę zwrócić? Gdzie je zapisać? Do jakiej tabeli? Z jaką strukturą? To wszystko powinno być spisane na etapie projektowania, przed implementacją.

Podsumowanie

Tak więc, wracając do problemu ze szkolenia – nie, nie musimy mieć żadnego skryptu, który uruchamia moduły jeden po drugim. Wręcz byłoby to zabiciem idei. Moduły za to powinniśmy uruchamiać w którymś z wyspecjalizowanych schedulerów (polecam Airflow). Dzięki nim możemy przeznaczyć do regularnego startu konkretny moduł, albo połączyć go z innymi. Do tego możemy obsłużyć różne wyniki (np. wysłać email, jeśli coś pójdzie nie tak), przejrzeć logi itd.

Zdaję sobie sprawę, że to co przedstawiłem powyżej, dla wielu jest banałem. Jest jednak taki etap (na początku), gdy trzeba “przeskoczyć” na inne myślenie. I warto zacząć właśnie od kwestii decentralizacji.

Między innymi takich rzeczy, poza stricte technicznymi, uczę na naszych RDFowych szkoleniach. Przejrzyj te, które możemy dla Was zrobić, a potem przekonaj szefa, że solidnie wykwalifikowany zespół, to lepsze wyniki firmy;-).

Zachęcam także do dołączenia do naszej rodzącej się polskiej społeczności Big Data! Obserwuj RDF na LinkedIn, subskrybuj newsletter i daj znać że żyjesz. Razem możemy więcej!

 

Zainstalowałem Apache Ozone. Oto pierwsze wrażenia i… pierwsze błędy

Zainstalowałem Apache Ozone. Oto pierwsze wrażenia i… pierwsze błędy

Marek Czuma

O tym, że Apache Ozone jest mniej podobny do HDFSa niż można przypuszczać, pisałem w artykule o budowie. Ponieważ postanowiłem stworzyć system do gromadzenia i analizy danych giełdowych, musiałem też zbudować nowy eksperymentalny klaster (czy może lepiej: klasterek;-)). Uznałem, że to znakomita okazja, żeby przetestować dość nowy, dojrzewający niczym włoska szynka system do gromadzenia danych: Apache Ozone.

W tym artykule znajdziesz kilka moich obserwacji oraz – co ważniejsze – lekcji. Będą z pewnością przydatne, jeśli także chcesz spróbować swoich sił i zbadać ten teren. Będą przydatne, ponieważ dokumentacja jest wybrakowana i nie odpowiada na wiele pytań, a społeczność… cóż, jeszcze właściwie nie istnieje. Bierz kubek mocnej jak wiedźmiński eliksir kawy – i zanurzmy się w przygodę!

Apache Ozone: obserwacje i informacje

Zacznijmy od mniej istotnej części, czyli moich subiektywnych przemyśleń na temat Apache Ozone. Poniżej 3 najistotniejsze z nich.

  1. Ozone to nie HDFS. To nawet nie system plików (FS). Opisywałem to już w artykule na temat tego jak Ozone jest zbudowany (o architekturze). Podchodząc do “kontynuacji HDFSa” oczekiwałem podobnego systemu plików, jednak zapewne z nieco inną architekturą. Przeliczyłem się mocno. Ozone bowiem to nie File System, a Object Store. Skutkuje to przede wszystkim bardzo płaską strukturą. Nie zrobimy więc rozbudowanych, hierarchicznych struktur, jak miało to miejsce w HDFSie.
  2. Ozone ma bardzo, bardzo niewielką społeczność. Co rodzi mocne komplikacje. No właśnie. To jest naprawdę problematyczna część. Warto wziąć poprawkę na termin w jakim to piszę. Apache Ozone jest dostępny w repozytorium głównym Mavena od listopada ubiegłego roku. Wersja GA została (jeśli się nie mylę) udostępniona dopiero w zeszłym roku. To wszystko sprawia, że technologia jest jeszcze mało dojrzała – przynajmniej w obszarze społeczności. Jest to bardzo ciekawy moment dla osób z pionierskim zacięciem;-). Praktycznie żaden błąd na który się natknąłem, nie był nigdzie w Internecie opisany. Rzecz bardzo rzadko spotykana. Chociaż ciekawa!
  3. Warto od samego początku poznać architekturę. Ja przyznam, że miałem dwa podejścia do Ozona. Za pierwszym razem poległem. Było to spowodowane moją gorącą krwią i chęcią jak najszybszego przetestowania w boju nowej technologii. To błąd! Naprawdę warto przeznaczyć trochę czasu, żeby wgryźć się najpierw w to jak zbudowany jest Apache Ozone. Jeśli tego nie zrobimy, bardzo ciężko będzie rozwiązywać problemy, których trochę po drodze na pewno będzie. Jak już napisałem punkt wyżej – Ozone nie ma właściwie społeczności, więc najpewniej większość opisanych błędów spotkasz… w tym artykule. Aby je rozwiązać po prostu warto wiedzieć jak to wszystko działa:-).

Apache Ozone: problemy, które rozwiązałem

Instalując Apache Ozone napotkałem kilka problemów, które rozwiązałem, a którymi chcę się podzielić. Liczę, że ustrzeże Cię to przed wyrywaniem sobie włosów z głowy z powodu frustracji.

INTERNAL_ERROR Allocated 0 blocks. Requested 1 blocks

Wszystkie serwisy działają, ale plik nie chce się przekopiować z lokalnego systemu plików na Ozone. Podczas kopiowania (polecenie “ozone sh key put /vol1/bucket1/ikeikze2.pdf ikeikze2.pdf”) pojawia się następujący błąd:

INTERNAL_ERROR Allocated 0 blocks. Requested 1 blocks

Co to oznacza? Nie wiadomo. Wiadomo jedynie, że – mówiąc z angielska – “something is no yes”. W tym celu udajemy się do logów. Tu nie chcę zgrywać ozonowego mędrca, więc powiem po prostu: popróbuj. Problem może być w paru logach, ale z całą pewnością ja bym zaczął od logów datanode. Logi znajdują się w folderze “logs”, w folderze z zainstalowanym Ozonem (tam gdzie jest też folder bin, etc i inne).

Przykład ścieżki do logów datanoda:

[ścieżka_do_folderu_gdzie_jest_ozone]/logs/ozone-root-datanode-headnode.log

Problem z liczbą nodów

Zacznijmy od komunikatu błędu, który można dostać po przejrzeniu logów ze Storage Container Manager (SCM).

ERROR org.apache.hadoop.hdds.scm.SCMCommonPlacementPolicy: Unable to find enough nodes that meet the space requirement of 1073741824 bytes for metada
ta and 5368709120 bytes for data in healthy node set. Required 3. Found 1.

Rozwiązanie: Należy zmienić liczbę replik, ponieważ nie mamy wystarczająco dużo datanodów w klastrze, aby je przechowywać (nie mogą być trzymane na tej samej maszynie). Aby to zrobić należy wyłączyć wszystkie procesy Ozone, a następnie zmienić plik ozone-site.xml. Konkretnie zmieniamy liczbę replik. Poniżej rozwiązanie, które na pewno zadziała, ale niekoniecznie jest bezpieczne – zmieniamy liczbę replik na 1, w związku z czym nie wymaga on wielu nodów do przechowywania replik.

<property>
       <name>ozone.replication</name>
       <value>1</value>
</property>

Szybsze (automatyczne) uruchamianie Ozone

W tym miejscu pokazane jest jak należy stawiać Apache Ozone. Jak widać są dwie ścieżki i tylko jedna z nich nadaje się do czegokolwiek.

  1. W pierwszej stawiamy każdy serwis osobno: Storage Container Manager, Ozone Manager oraz Datanody. Jest to chociazby o tyle problematyczne, że jeśli mamy tych datanodów dużo, to trzeba by wchodzić na każdy z nich osobno.
  2. Na szczęście istnieje też opcja uruchamiania wszystkiego jednym skryptem. W tym celu należy uruchomić plik start-ozone.sh znajdujący się w folderze sbin.

Jednak aby to zrobić, należy najpierw uzupełnić konfigurację. Zmiany są dwie:

  1. Należy dodać kilka zmiennych do pliku ozone-env.sh w folderze “[folder_domowy_ozone]/etc/hadoop“.
  2. Nalezy utworzyć plik workers wewnątrz tego samego folderu co [1].

Zmienne: tu należy dodać kilka zmiennych wskazujących na użytkowników ozona. Sprawa jest niejasna, bo Ozone przeplata trochę nomenklaturę z HDFS. Ja dodałem obie opcje i jest ok.

export OZONE_OM_USER=root
export OZONE_SCM_USER=root
export OZONE_DATANODE_USER=root
export HDFS_OM_USER=root
export HDFS_SCM_USER=root
export HDFS_DATANODE_USER=root

workers: tutaj dodajemy adresy workerów. Może to oczywiście być także node na którym uruchamiamy inne serwisy.

workernode01.example.com
workernode02.example.com
workernode03.example.com

Po tym wszystkim możemy uruchomić skrypt start-ozone.sh

OM wyłącza się po uruchomieniu klastra

Po uruchomieniu klastra (sbin/start-ozone.sh) Ozone Manager zwyczajnie pada. Kiedy zajrzymy w logi, znajdziemy taki oto zapis:

Ratis group Dir on disk 14dd99c6-de01-483f-ac90-873d71fb5a44 does not match with RaftGroupIDbf265839-605b-3f16-9796-c5ba1605619e generated from service id omServiceIdDefault. Looks like there is a change to ozone.om.service.ids value after the cluster is setup

Były także inne logi, natomiast wiele wskazywało na Ratisa oraz omServiceIdDefault a także ozone.om.service.ids. Jeśli mamy następujący problem, oznacza to, że nasz klaster próbuje automatycznie włączyć tryb HA na Ozon Manager. Ponieważ mi na takim trybie nie zależy (mój klaster jest naprawdę mały i nie miałoby to większego sensu), wprost wyłączyłem HA. Aby to zrobić, należy zmodyfikować ustawienia.

Plik ozone-site.xml (znajdujący się w [katalog ozona]/etc/hadoop/ozone-site.xml)

<property>
   <name>ozone.om.ratis.enable</name>
   <value>false</value>
</property>

Oczywiście po zaktualizowaniu ozone-site.xml plik powinien być rozesłany na wszystkie nody, a następnie klaster powinien zostać uruchomiony ponownie. Jeśli chcesz skorzystać z trybu HA, wszystkie (chyba;-)) informacje znajdziesz tutaj.

Przy requestach zwykłego użytkownika (nie-roota) wyskakuje błąd o brak dostępów do logów

A więc wszystko już poszło do przodu, spróbowaliśmy z roota (lub innego użytkownika, którym instalowaliśmy Ozone na klastrze) i wszystko było ok. Przynajmniej do czasu, aż zechcemy spróbować podziałać na innym użytkowniku. Wtedy dostajemy taki oto błąd:

java.io.FileNotFoundException: /ozone/ozone-1.2.1/logs/ozone-shell.log (Permission denied)
    at java.io.FileOutputStream.open0(Native Method)
    at java.io.FileOutputStream.open(FileOutputStream.java:270)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:133)
    at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
    at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
    at org.apache.log4j.DailyRollingFileAppender.activateOptions(DailyRollingFileAppender.java:223)
(...)
log4j:ERROR Either File or DatePattern options are not set for appender [FILE].

Pocieszające jest to, że błąd ten nie oznacza, że polecenie do Ozone nie zostało wykonane. Oznacza jedynie, że nie mamy uprawnień do pliku z logami Ozone Shell. Żeby powiedzieć dokładniej, nie mamy dostępu do zapisu na tym pliku.

Nie jest to więc błąd stricte “Ozonowy”. Jest za to stricte linuxowy – należy nadać użytkownikowi odpowiednie uprawnienia. Można to zrobić na kilka różnych sposobów. Jeśli Twój klaster, podobnie jak mój, jest jedynie klastrem eksperymentalnym, możesz śmiało nadać uprawnienia zapisu “innym użytkownikom” pliku. Wchodzimy do folderu z logami i wpisujemy następującą komendę:

chmod a+rw ozone-shell.log

Podsumowanie

Apache Ozone to naprawdę ciekawa i – mam nadzieję – przyszłościowa technologia. Musi jednak jeszcze trochę wody w Wiśle upłynąć, aby zyskała popularność oraz dojrzałość HDFSa. Zachęcam jednak do eksperymentowania i dzielenia się tutaj wrażeniami;-)

Zachęcam także do dołączenia do naszej rodzącej się polskiej społeczności Big Data! Obserwuj RDF na LinkedIn, subskrybuj newsletter i daj znać że żyjesz. Razem możemy więcej!

 

Jak zbudowany jest Apache Ozone?

Jak zbudowany jest Apache Ozone?

Marek Czuma

Apache Ozone to następca HDFS – przynajmniej w marketingowym przekazie. W rzeczywistości sprawa jest nieco bardziej złożona i proste analogie mogą być złudne. Jako, że jestem w trakcie budowy systemu do analizy spółek giełdowych, buduję także nowy, eksperymentalny klaster (czy może – klasterek;-)). Uznałem to za idealny moment, żeby przetestować, bądź co bądź nową technologię, jaką jest Apache Ozone. W kolejnym artykule podzielę się swoimi obserwacjami oraz problemami które rozwiązałem. Zacznijmy jednak najpierw od poznania podstaw, czyli architektury Apache Ozone. Zapraszam!

Czym (nie) jest Apache Ozone?

Jeśli Ozone to następca HDFSa, a HDFS to system plików, to Apache Ozone jest systemem plików prawda? Nie. I to jest pierwsza różnica, którą należy dostrzec. HDFS był bliźniaczo podobny (w interfejsie i ogólnej budowie użytkowej, nie architekturze) do standardowego systemu plików dostępnego na linuxie. Mieliśmy użytkowników, foldery, a w nich pliki, ewentualnie foldery, w których mogły być pliki. Albo foldery. I tak w kółko.

Apache Ozone to rozproszony, skalowalny object store (/storage). Na temat podejścia object storage można przeczytać tutaj. Podstawową jednak różnicą jest to, że Ozone ma strukturę płaską, a nie hierarchiczną. Również, podobnie jak HDFS, dzieli pliki na bloki, także posiada swoje repliki, jednak nie możemy zawierać zagnieżdżonych folderów.

Podstawowa budowa Apache Ozone

Ozone oczywiście jest systemem rozproszonym – działa na wielu nodach (serwerach/komputerach).

Oto podstawowy opis struktury:

  1. Volumes – podobne do kont użytkowników lub katalogów domowych. Tylko admin może je utworzyć.
  2. Buckets – podobne do folderów. Bucket może posiadać dowolną liczbę keys, ale nie może posiadać innych bucketów.
  3. Keys – podobne do plików.

Ozone zbudowany jest z kilku podstawowych komponentów/serwisów:

  1. Ozone Manager (OM) – odpowiedzialny za namespacy. Odpowiedzialny za wszystkie operacje na volumes, buckets i keys. Każdy volume to osobny root dla niezależnego namespace’u pod OM (to różni go od HDFSa).
  2. Storage Container Manager (SCM) – Działa jako block manager. Ozone Manage requestuje blocki do SCM, do których klientów można zapisać dane.
  3. Data Nodes – działa w ramach Data Nodes HDFSowych lub w uruchamia samodzielnie własne deamony (jeśli działa bez HDFSa)

Ozone oddziela zarządzanie przestrzenią nazw (namespace management) oraz zarządzanie przestrzenią bloków (block space management). To pomaga bardzo mocno skalować się Ozonowi. Ozone Manager odpowiada za zarządzanie namespacem, natomiast SCM za zarządzanie block spacem.

Ozone Manager

Volumes i buckets są częścią namespace i są zarządzane przez OM. Każdy volume to osobny root dla niezależnego namespace’a pod OM. To jedna z podstawowych różnic między Apache Ozone i HDFS. Ten drugi ma jeden root od którego wszystko wychodzi.

Jak wygląda zapis do Ozone?

  1. Aby zapisać key do Ozone, client przekazuje do OM, że chce zapisać konkretny key w konkretnym bucket, w konkretnym volume. Jak tylko OM ustali, że możesz zapisać plik w tym buckecie,OM zaalokuje block dla zapisu danych.
  2. Aby zaalokować blok, OM wysyła request do SCM. To on tak naprawdę zarządza Data Nodami. SCM wybiera 3 data nody (najprawdopodobniej na repliki) gdzie klient może zapisać dane. SCM alokuje blok i zwraca block ID do Ozone Managera.
  3. Ozone Manager zapisuje informacje na temat tego bloku w swoich metadanych i zwraca blok oraz token bloku (uprawnienie bezpieczeństwa do zapisu danych na bloku) do klienta.
  4. Klient używa tokena by udowodnić, że może zapisać dane na bloku oraz zapisuje dane na data node.
  5. Gdy tylko zapis jest ukończony na data node, klient aktualizuje informacje o bloku w OM.

Jak wygląda odczyt danych (kluczy/keys) z Ozone?

  1. Klient wysyła request listy bloków do Ozone Manager.
  2. OM zwraca listę bloków i tokenów bloków, dzięki czemu klient może odczytać dane z data nodes.
  3. Klient łączy się z data node i przedstawia tokeny, po czym odczytuje dane z data nodów.

Storage Container Manager

SCM jest głównym nodem, który zarządza przestrzenią bloków (block space). Podstawowe zadanie to tworzenie i zarządzanie kontenerami. O kontenerach za chwilkę, niemniej pokrótce, są to podstawowe jednostki replikacji.

Storage Container Manager

Tak jak napisałem, Storage Container Manager odpowiada za zarządzanie danymi, a więc utrzymuje kontakt z Data Nodami, gra rolę Block Managera, Replica Managera, ale także Certificate Authority. Wbrew intuicji, to SCM (a nie OM) jest odpowiedzialny za tworzenie klastra Ozone. Gdy wywołujemy komendę init, SCM tworzy cluster identity oraz root certificates potrzebne do CA. SCM zarządza cyklem życia Data Node.

  1. SCM do menedżer bloków (block manager). Alokuje bloki i przydziela je do Data Nodów. Warto zawuażyć, że klienci pracują z blokami bezpośrednio (co jest akurat trochę podobne do HDFSa).
  2. SCM utrzymuje kontakt z Data Nodami. Jeśli któryś z nich padnie, wie o tym. Jeśli tak się stanie, podejmuje działania aby naprawić liczbę replik, aby ciągle było ich tyle samo.
  3. SCM Certificate Authority jest odpowiedzialne za wydawanie certyfikatów tożsamości (identity certificates) dla każdej usługi w klastrze.

SCM nawiązuje regularny kontakt z kontenerami poprzez raporty, które te składają. Ponieważ są znacznie większymi jednostkami niż bloki, raportów jest wiele wiele mniej niż w HDFS. Warto natomiast pamiętać, że my, jako klienci, nie komunikujemy się bezpośrednio z SCM.

Kontenery i bloki w Ozone(Contrainers and blocks)

Kontenery (containers) to podstawowe jednostki w Apache Ozone. Zawierają kilka bloków i są całkiem spore (5gb domyślnie).

Containers

W konkretnym kontenerze znajdziemy ileś bloków, które są porcją danych. Jednak same bloki nie są replikowane. Informacje o blokch nie są też zarządzane przez SCM – są trzymane tylko informacje o kontenerach i to kontenery podlegają replikacji. Kiedy OM requestuje o zaalokowanie nowego bloku do SCM, ten “namierza” odpowiedni kontener i generuje block id, które zawiera w sobie ContainerIs + LocalId (widoczne na obrazku powyżej). Klient łączy się wtedy z Datanode, który przechowuje dany kontener i to datanode zarządza konkretnym blokiem na podstawie LocalId.

FunctionalOzone

Data Nodes

Data Nody to serwery, na których dzieje się prawdziwa, docelowa magia Ozone. To tutaj składowane są wszystkie dane. Warto pamiętać, że to z nimi bezpośrednio łączy się klient. Zapisuje on dane w postaci bloków. Data node agreguje te dane i zbiera do kontenerów (storage containers). W kontenerach, poza danymi, znajdują się też metadane opisujące je.

Jak to wszystko działa? Kiedy chcemy odczytać plik, uderzamy do OM. Ten zwraca nad listę bloków, która składa się z pary ContainerId:LocalId. To dość chude informacje, ale wystarczą, aby można było udać się do konkretnych kontenerów i wyciągnąć konkretne bloki (LocalId to po prostu unikatowy numer ID w ramach kontenera, czyli w ramach dwóch różnych kontenerów moga być dwa bloki o LocalID=1, natomiast w ramach jednego kontenera nie).

Podsumowanie

Mam szczerą nadzieję, że tym artykułem pomogłem odrobinę zrozumieć architekturę Apache Ozone. Przyznam, że pełnymi garściami czerpałem z dokumentacji. Choć – jestem przekonany – jest to pierwszy polski materiał na temat tej technologii, to z pewnością nie jest ostatni. Jestem w trakcie instalowania Ozone na eksperymentalnym klasterku RDFowym i na bieżąco piszę artykuł o doświadczeniach i błędach, jakie napotkałem. Obserwuj RDF na LinkedIn i zapisz się na newsletter, to nie przegapisz!

 

Szukanie podobieństw w tekstach przy pomocy Spark ML – efekty

Szukanie podobieństw w tekstach przy pomocy Spark ML – efekty

Marek Czuma

Co ty na to, żeby zbudować system, dzięki któremu wyszukujemy podobne wypowiedzi polityków? Tak dla sprawdzenia – jeśli jeden coś powiedział, poszukamy czy jego oponenci nie mówili przypadkiem podobnie. Dzięki temu być może oczyścimy trochę debatę – świadomość, że nasi przedstawiciele nie różnią się aż tak bardzo, może być bardzo orzeźwiająca. Jednak taki mechanizm to dużo danych do przetworzenia i zinterpretowania. Dodatkowo tekstowych.

Dziś w artykule o podobnym problemie przy wykorzystaniu Apache Spark. Porozmawiamy więc o sztucznej inteligencji – a konkretniej machine learning, natural language processing (NLP) oraz text similarity. Wyjątkowo jednak nie w kontekście pythona, a właście Scali i Sparka.

Text Similarity (AI) w Apache Spark

Wróćmy do problemu podobieństw wypowiedzi polityków. Oczywiście musimy najpierw zebrać dane. Ile może ich być? Jeśli bazujemy na krótkich wypowiedziach – ogromne ilości. Wszystko zależy od tego jak bardzo chcemy się cofać w czasie i jak wiele osób wziąć pod lupę (Sejm? Senat? Rząd? Polityków lokalnych? A może zagranicznych?). Sumarycznie można się pokusić jednak o miliony, dziesiątki a nawet setki milionów krótkich wypowiedzi. A im bardziej w używaniu jest Twitter, tym więcej.

Pytanie, czy do tak dużych zbiorów można użyć bibliotek Pythonowych? Wiele z nich bazuje na jednej maszynie, bez możliwości naturalnego przetwarzania rozproszonego. Oczywiście nie wszystkie i z pewnością jest tam najmocniej rozwinięte środowisko do NLP. Na tym blogu skupimy się dziś jednak na mało popularnym pomyśle. Sprawdzimy na ile naprawdę poważnym rozwiązaniem może być Apache Spark w świecie machine learning. Dziś pokażę owoc eksperymentu nad przetwarzaniem tekstu w Apache Spark.

Po pierwsze: efekt

Zanim wskażę jakie techniki można zastosować, spójrzmy co udało się osiągnąć.

Zacznijmy od podstawowej rzeczy

  1. Bazujemy na zbiorze, który ma ~204 tysiące krótkich tekstów – konkretnie tweetów.
  2. Tweety dotyczą trzech dziedzin tematycznych:
    • COVID – znakomita większość (166543 – 81,7%)
    • Finanse – pewna część (28874 – 14,1%)
    • Grammy’s – margines (8490 – 4,2%)
  3. W ramach systemu przekazujemy tekst od użytkownika. W odpowiedzi dostajemy 5 najbardziej podobnych tweetów.

Efekty

Poniżej kilka efektów. Chcę zauważyć, że sporą rolę odgrywa tutaj kwestia nierówności zbiorów. Dane związane z ceremonią przyznania nagród Grammy’s są właściwie marginalne (nieco ponad 4%). Tweety COVIDowe zapełniają natomiast nasz zbiór w ponad 80%. Jest to istotne, gdyż przy sprawdzaniu efektywności najbardziej naturalnym odniesieniem jest zwykłe prawdopodobieństwo. W zbiorze 100 “najbardziej podobnych” tekstów (do jakiegokolwiek), ok 80 powinno być związanych z COVID-19, nieco ponad 10 to najpewniej finansowe, natomiast muzyczne będą w liczbie kilku sztuk.

Text Similarity w Apache Spark na przykładzie wywołania tweetów związanych z COVID-19

Fraza covidowa, najprostsza

Wyszukiwania zacznijmy od najprostszego podejścia: frazą wyszukiwaną niech będzie podobna do tej, o której wiemy, że istnieje w podanym zbiorze. Liczba w nawiasie to stopień podobieństwa – od -1 do 1 (gdzie 1 to identyczne).

Fraza: Praying for health and recovery of @ChouhanShivraj . #covid #covidPositive (zmiany są bardzo drobne).

Podobne wykryte frazy:

  1. Praying for good health and recovery of @ChouhanShivraj (0.9456217146059263)
  2. Prayers needed for our vascular surgeon fighting Covid @gpianomd #COVID19 #Prayers #frontlinedoctors (0.8043357071420172)
  3. Prayers for your good health and speedy recovery from #COVID19 @BSYBJP (0.801822609000082)
  4. Hon’ble @CMMadhyaPradesh Shri @ChouhanShivraj Ji tested #COVID19 positive. Praying for his speedy recovery. (0.7740378229093525)
  5. I pray for Former President Shri @CitiznMukherjee speedy recovery. Brain tumor wounds ji a lot, God may heal his p…  (0.7626450268959205)

Jak widać każda z tych fraz pochodzi z grupy COVIDowych. Dodatkowo dotyczy pragnień szybkiego powrotu do zdrowia oraz modlitwy za cierpiących.

Fraza finansowa, trudniejsza

Przejdźmy do czegoś odrobinę trudniejszego – sprawdźmy coś finansowego. Niech będzie to fraza, którą absolutnie wymyślę od początku do końca.

Fraza: Ford’s earnings grow another quarter

Podobne wykryte frazy:

  1. XLE Goes Positive Brent UP Big &amp; WTI UP Big Rally $XOM ExxonMobil Buy Now for the Rest of 2018 GASOLINE INVENTORIE… (0.7579525402567442)
  2. Morgan Stanley Begins Covering Murphy Oil $MUR Stock. “Shares to Hit $26.0” (0.7211353533183933)
  3. Seaport Global Securities Lowers Cabot Oil &amp; Gas Q2 2018 Earnings Estimates to $0.15 EPS (Previously $0.17).… (0.7211353533183933)
  4. William E. Ford Purchases 1000 Shares of BlackRock Inc. $BLK Stock (0.7195004202231048)
  5. Anadarko Petroleum Is On A Buyback Binge $APC (0.7187907206133348)

W tym przypadku podobieństwa są znacznie mniejsze. Warto zauważyć jednak dwie rzeczy: Po pierwsze – system wskazuje, że podobieństwa są mniejsze (0.76 to dużo mniej niż 0.95). Prawdopodobnie bardzo podobne po prostu więc nie istnieją. Druga rzecz – wszystkie podobne tweety pochodzą ze zbioru finansowych! Zbioru, który stanowi ok 14% całości danych. Pozwala to nabrać przekonania, że odpowiedzi nie są przypadkowe.

Fraza muzyczna, najtrudniejsza

Na koniec – najtrudniejsze zadanie ze wszystkich. Wybierzemy zdanie, które teoretycznie powinno pasować do zbioru będącego marginesem całości – do Grammy’s. Dodatkowo zdanie to wymyślę całkowicie. A niech tam – niech dotyczy najwspanialszej piosenkarki w dziejach! Oczywiście moim, zupełnie subiektywnym i amatorskim okiem;-).

Fraza: Amy Lee is the greatest singer of all time!

  1. Christina Aguilera &amp; Norah Jones were the only multiple recipients for ‘Best Female Pop Vocal Performance’ in the 2000s. (0.7306395709876714)
  2. @billboardcharts @justinbieber @billieeilish @oliviarodrigo @taylorswift13 @kanyewest Taylor the only real queen let’s be honest she deserves the Grammy for evermore but the #GRAMMYs wont give her. (0.7019156211438091)
  3. #GRAMMYs keep doing dirty to Lana Del Rey? Even though her talent is among the best this world has to offer (0.6868772967554752)
  4. Kylie Minogue deserved at least one nomination for Magic #GRAMMYs (0.6820704278110573)
  5. The answer will always be YES. #GRAMMYs #TwitterSpaces #SmallBusinesses #BlackOwned #adele #bts (0.6816903814884498)

I to właśnie te wyniki, przyznam, najmocniej wprowadziły mnie w euforię i ekscytację, gdy je zobaczyłem. I to nie tylko z powodu mojego niekłamanego uczucia do wokalistki Evanescence. Gdy spojrzymy na to “zdrowym, chłopskim okiem”, nie ma tutaj słowa o Grammy’s. Nie ma też szczególnego podobieństwa w słowach między pięcioma wymienionymi tweetami. Jest za to… kontekst. Jest podobieństwo tematyczne, jest znaczenie sensu.

A to wszystko naprawdę niedużym kosztem:-).

Text Similarity w Apache Spark na przykładzie wywołania tweetów muzycznych (z Grammy’s)

Apache Spark a text similarity – wykorzystane techniki

No dobrze, ale przejdźmy do konkretów – co należy zrobić, aby dostać takie wyniki? Tu zaproszę od razu do następnego artykułu, w którym pokażę dokładniej jak to zrobić. Dzisiejszy potraktujmy jako zajawkę. Żeby nie przeoczyć następnego – zapisz się na newsletter;-).

 

Po dość długich staraniach i wyeliminowaniu kilku ewidentnie beznadziejnych podejść, za sprawą kolegi Adama (za co ukłony w jego stronę) zacząłem czytać o embeddingach USE (Universal Sentence Encoder). Od razu powiem, że moją podstawową działką jest Big Data rozumiane jako składowanie i przetwarzanie danych. Sztuczna inteligencja to dopiero temat, który badam i definitywnie nie jestem w nim specem (choć parę kursów w tym kierunku ukończyłem i coś niecoś działałem). Liczę jednak, że obcowanie ze specami w tej działce (takimi jak właśnie Adam;-)) pomoże w eksploracji tego ciekawego gruntu.

Wróćmy jednak do USE. To była istne objawienie. Warto zaznaczyć, dla tych którzy nie do końca są zaznajomieni z tematyką machine learning, że komputer oczywiście tak naprawdę nie rozumie tekstu. Żeby mógł wyszukiwać podobieństwa, dzielić na grupy, uczyć się klas itd – potrzebne są liczby. Stąd wziął się pomysł sprowadzania tekstów do wektorów i różnego rodzaju wectorizerów – mechanizmów, które sprowadzają tekst do wektorów. Wektorów, czyli tablic jednowymiarowych o określonej długości (tu można się pomylić. Wielowymiarowe wektory dalej są jednowymiarowymi tablicami). Nieco bardziej rozbudowaną wersją są embeddingi, które mogą przechowywać w sobie wektory, natomiast które posiadają dodatkowe cechy pomocne. Jedną z nich (kluczową?) jest to, że słowa które chcemy zamienić na liczby, nabierają kontekstu. Pomaga to szczególnie mocno w niektórych przypadkach – na przykład naszych tweetów, które zawierają krótkie, czasami niezbyt treściwe przekazy. Jeśli będziemy je porównywali w prosty, czysto “statystyczny” sposób zestawiając wyrazy, nie uzyskamy odpowiedniego efektu.

Machine Learning w Apache Spark

Aby korzystać z dobrodziejstw ludzkości w zakresie machine learning, w tym text similarity w Apache Spark, należy wykorzystać bibliotekę Spark MlLib (w repozytorium Mavena dostępna tutaj). Tylko tutaj UWAGA! Wewnątrz biblioteki MlLib dostępne są dwa “rozgałęzienia”:

  1. Spark MlLib – starsza (choć wciąż utrzymywana) wersja, operująca bezpośrednio na RDD.
  2. Spark ML – nowocześniejsza część biblioteki. Możemy tutaj pisać operując na Datasetach i Dataframe’ach.

Wracając do technik – jednym z embeddingów jest właśnie USE. Jest on znacznie znacznie lepszym rozwiązaniem niż nieco podstarzały word2Vec, o innych, prostszych (np. Count Vectorizer) nie wspominając. Problem? Ano właśnie – nie wchodzi on w skład podstawowej biblioteki MlLib. Nie jest to jednak problem nie do przeskoczenia. Istnieje w Internecie gotowy zestaw rozwiązań, które poszerzają podstawowe biblioteki Sparkowe. Mam tu na myśli John Snow Labs. Udostępniają oni naprawdę imponująca liczbę algorytmów, które po prostu możemy wykorzystać – i to z całkiem niezłym skutkiem. Omówienie poszczególnych algorytmów można znaleźć tutaj. Samą bibliotekę do przetwarzania tekstu, czyli Spark-NLP zaciągniemy bez problemu z głównego repozytorium Mavena. To dzięki niej możemy rozwiązać bardzo wiele problemów, m.in. text-similarity w Apache Spark;-)

Jak technicznie dokładnie to zrobić, pokażę w kolejnym artykule. Już teraz zapraszam do subskrybowania;-).

Cosine Similarity

Skoro tylko udało mi się już porządnie sprowadzić tekst do jakiś ludzkich kształtów (czyli liczb;-)), należało znaleźć najlepszy z nich. Najlepszy – czyli najbardziej podobny do takiego, który wprowadzę. Dość dużo spędziłem czasu na szukaniu różnych gotowych rozwiązań. W końcu zdecydowałem się na zastosowanie czystej matematyki. Mowa tu o cosine similarity. Nie mam pojęcia jak to się tłumaczy na polski, a “podobieństwo kosinusowe” mi po prostu nie brzmi (ani nie znalazłem żeby tak się mówiło).

Z grubsza sprawa jest dość prosta – chodzi o to, żeby znaleźć podobieństwo między dwoma (niezerowymi) wektorami osadzonymi na jakiejś płaszczyźnie. Nie jest to żadna technika rakietowa i nie dotyczy ani NLP, ani nawet machine learning. Dotyczy zwykłej, prostej, nudnej matmy i można się zapoznać nawet na wikipedii.

Wzór na cosine similarity wygląda następująco:

{\displaystyle {\text{cosine similarity}}=S_{C}(A,B):=\cos(\theta )={\mathbf {A} \cdot \mathbf {B} \over \|\mathbf {A} \|\|\mathbf {B} \|}={\frac {\sum \limits _{i=1}^{n}{A_{i}B_{i}}}{{\sqrt {\sum \limits _{i=1}^{n}{A_{i}^{2}}}}{\sqrt {\sum \limits _{i=1}^{n}{B_{i}^{2}}}}}},}

Efekt jest prosty: wynik jest od -1 do 1. Im bliżej 1 tym bliższe są oba wektory. Problem? Oczywiście – w Sparku nie ma implementacji;-). Na szczęście jest to wzór na tyle prosty, że można go sobie zaimplementować samemu. Ja to zrobiłem w ramach UDF.

Podsumowanie

I to tyle! Tak więc można sprawę uprościć: zebrałem tweety, użyłem USE (od John Snow Labs) oraz cosine similarity. W efekcie dostałem naprawdę solidne wyniki podobieństwa. I to nie tylko jeśli chodzi o sam tekst, ale przede wszystkim jego znaczenie.

Już w najbliższym artykule pokażę jak dokładnie napisałem to w Sparku. Jeśli interesują Cię zagadnienia dotyczące Sparka, pamiętaj, że prowadzimy bardzo ciekawe szkolenia – od podstaw. Pracujemy z prawdziwymi danymi, na prawdziwych klastrach no i… cóż, uczymy się prawdziwego fachu;-). Jeśli interesuje Cię to – Zajrzyj tutaj!

Zostań z nami na dłużej. Razem budujmy polskie środowisko Big Data;-). Jeśli chcesz pozostać z nami w kontakcie – zapisz się na newsletter lub obserwuj RDF na LinkedIn. Koniecznie, zrób to i razem twórzmy polską społeczność Big Data!

 

Inspiracja: prawdziwe datasety, które pomogą Ci w nauce Big Data

Inspiracja: prawdziwe datasety, które pomogą Ci w nauce Big Data

Marek Czuma

Któż z nas nie miał w szkole dosyć matematycznych zadań o “Ali Kasi i Małgosi, które dzieliły między sobą truskawki”? Albo na statystyce o obliczaniu prawdopodobieństwa stosunku “kul białych do kul czarnych które pozostaną w urnie po wyciągnięciu jednej z nich”? Niestety, nieżyciowe (czy gorzej – pseudożyciowe) przykłady zabijają piękno nauki. Nauki, która jest przecież wspaniałym narzędziem do poznawania i budowania świata.

Prawdziwe datasety do nauki Big Data – czemu warto?

Dokładnie tak samo jest w Big Data. Poznając technologie, często bazujemy na przykładach nudnych, oklepanych, o których wiemy, że nie sprawią nam żadnych niespodzianek. Są to “zbiory danych” które tworzymy sami. W locie, na potrzeby przykładu. Nierealne, w zbyt dużej liczbie potrafiące przyprawić o mdłości.

Oczywiście proste, jasne przykłady też są potrzebne! Sam je na szkoleniach stosuję. Warto jednak od samego początku obcować z prawdziwymi danymi. Choćby dlatego, że takie dane przeważnie nie są najpiękniejsze. Mają swoje wady, brudy, dziury. Mają więc wszystko to, co cechuje prawdziwe dane. Te, z którymi będziemy się zmagać w komercyjnych projektach. Dane, które zaskakują. Dane, które sprawiają problemy i zmuszają do wytężenia mózgownicy.

Poza tym jednak, są to dane, które najzwyczajniej w świecie są po prostu… ciekawe. Pracując z nimi możemy się czegoś dowiedzieć. Niekoniecznie musi nam się to przydać podczas najbliższej randki z Żoną czy w trakcie spotkania z kumplami w pubie. Wystarczy jednak, że cokolwiek o świecie dowiemy się dzięki naszej pracy z danymi. Satysfakcja gwarantowana. Podobnie zresztą jak to, że zaczną nam wpadać do głowy nowe pomysły, które pomogą nam w analizie danych.

Poniżej prezentuję listę kilku zestawów danych z których można skorzystać, które urozmaicą naszą naukę Big Data;-). Dla smaczku dodam jeszcze, ze w wielu przypadkach datasety te są świetnie znane moim kursantom. Wykorzystuję je  – m.in. szkoleniach ze Sparka – i sprawdzają się znakomicie.

Dane z Netflixa

Od przeglądania seriali Netflixa znacznie lepiej wejść na Bigdatowy szlak walki z potworami obliczeń i odszukać niespodzianki w danych, które na temat platformy znamy.

Kto nie korzystał z Netflixa? Ten czasoumilacz już dawno przestał być jedynie towarzyszem rozrywkowych wieczorów. Obecnie jest jednym z największych nośników i propagatorów kultury (co oczywiście ma swoje plusy i minusy). Czy nie byłoby fajnie popracować z danymi na temat jego filmów, reżyserów, dat i innych ciekawych rzeczy?

Źródło: Kaggle.

Pobieranie: netflix_titles.csv.

Wielkość: 3.4 MB.

Kolumny:

show_id
type
title
director
cast
country
date_added
release_year
rating
duration
listed_in
description

 

Przestępstwa ze zbiorów policji z Bostonu (crimes)

Jeśli kogoś nie rajcuje świat seriali, to może coś poważniejszego? Proponuję wcielić się w rolę urzędnika lub analityka kryminalnego. Zbadajmy, w jakim dystrykcie strzelaniny odgrywały największą rolę w poszczególnych latach. I nie tylko to, bo także całą masę innych rzeczy. Do zestawu danych dorzucony jest zbiór offense codes.

Źródło: Jak w poprzednim punkcie, Kaggle.

Pobieranie: crime oraz offense_codes.

Wielkość: 58 mb.

Kolumny:

incident_number
offense_code
offense_code_group
offense_description
district
reporting_area
shooting
occured_on_date
year
month
day_of_week
hour
ucr_part
street
lat
long
location

 

Użytkownicy telekomów (telecom users)

Być może przestraszyłeś/aś się nieco ponurych tematów, które podsunąłem wyżej. W takim razie mam coś bardzo przyziemnego. Czas na analizę użytkowników telekomów. Dataset znacznie mniejszy, natomiast wciąż ciekawy i można tu spędzić chwilę agregując i monitorując;-).

Źródło: Oczywiście niezawodny Kaggle.

Pobieranie: telecom_users

Wielkość: <1MB

Kolumny:

customerID
gender
SeniorCitizen
Partner
Dependents
tenure
PhoneService
MultipleLines
InternetService
OnlineSecurity
OnlineBackup
DeviceProtection
TechSupport
StreamingTV
StreamingMovies
Contract
PaperlessBilling
PaymentMethod
MonthlyCharges
TotalCharges
Churn

Tweety

Osobiście uważam, że Twitter to jedno z najlepszych źródeł danych do pracy z Big Data. Szczególnie, jeśli mówimy o zrobieniu większego projektu na samym początku drogi. Wynika to z faktu, że API (choć ma ograniczenia) pozwala w dłuższej perspektywie zgromadzić naprawdę duże ilości danych. Do tego są to dane które są dość dobrze ustrukturyzowane, ale nie aż tak jakbyśmy mieli je dostać w idealnie przygotowanej relacyjnej bazie danych. Poza tym prezentują realną wartość wyrażanych ludzkich emocji, wiedzy, przemyśleń. Jeśli chcesz zobaczyć mój system do analizy twittera, kliknij tutaj;-).

Tylko leniuch przy dzisiejszych możliwościach narzeka na brak solidnego materiału do pracy;-)

Dziś jednak nie o pełnym potencjale API Twitterowego, a o przykładowych zbiorach tweetów (statusów). Ja ostatnio na potrzeby swoich eksperymentów NLP pobrałem 3 zbiory danych: dotyczące COVID, dotyczące finansów oraz Grammy’s. Jak na przykładowe zbiory do ćwiczeń, dane są imponujące i zawierają ponad 100 000 tweetów.

Źródło: Kaggle.

Pobieranie: covid19_tweets, financial, GRAMMYs_tweets

Wielkość: Łącznie ~80 mb

Kolumn nie załączam z prostego powodu: w każdym z datasetów są nieco inne. Warto osobiście załadować (np. do Sparka) i popatrzeć.

Wiedźmińskie imiona

Na koniec załączam “dataset” który jest być może wątkiem humorystycznym bardziej niż realnymi danymi. Jeśli jednak człowiek kreatywny, to i z tym sobie poradzi;-). Poniżej do pobrania udostepniam listę ponad 100 imion z uniwersum Wiedźmina. Po prostu imiona, nic więcej. Można jednak dorobić sztuczne id, wylosować zawody lub upodobania i poprzypisywać do… no cóż, chociażby do tweetów z punktu wyżej.

Moim zdaniem grunt, żeby nauka była owocna, ale i dawała trochę radości i zabawy. A co jak co, ale akurat praca z danymi to może być zarówno koszmarnie nudny spektakl jak i najprawdziwsza zabawa:-).

Pobieranie: nazwy postaci z Wiedźmina.

TO TYLE. Mam nadzieję, że datasety które podrzucam przydadzą Ci się i nieco ubarwią naukę Big Data. Jeśli chcesz zostać w kontakcie – zapisz się na newsletter lub obserwuj RDF na LinkedIn. Koniecznie, zrób to i razem twórzmy polską społeczność Big Data!

 

HBase: jak zbudowany jest model danych?

HBase: jak zbudowany jest model danych?

Marek Czuma

Jest rok 2005 – inżynierowie Google publikują przełomowy dokument. “Big Table Paper” opisuje jak zbudowana powinna być baza danych, żeby mogła obsługiwać ogromne ilości danych. Z dokumentu tego natychmiast korzystają dwa ośrodki mające istotny wpływ na rozwój branży. Pierwszy z nich to NSA – amerykańska Agencja Bezpieczeństwa Narodowego, znana powszechnie z olbrzymiego systemu inwigilacji oraz poprzez postać Edwarda Snowdena. Drugi to fundacja Apache wraz ze swoim projektem Hadoop, który jest fundamentem współczesnego Big Data. W NSA powstaje Accumulo, w Apache HBase.

Ta ostatnia baza błyskawicznie zdobywa popularność i pozwala na przechowywanie potężnych ilości danych. Jak działa HBase i jego model? Jak wygląda struktura danych? W kolejnych artykułach weźmiemy pod lupę architekturę oraz różne HBasowe zagwozdki.

HBase – model danych

Zanim przejdziemy do architektury, warto poznać model jaki kryje się za danymi w HBase. Model ten jest bowiem z jednej strony niezbyt intuicyjny, z drugiej sam w sobie bardzo dużo mówi o tym jakie dane powinniśmy trzymać w bazie.

Rodzajów nierelacyjnych baz danych jest całkiem sporo. Gdy będziemy szukać informacji na temat HBase znajdziemy dwa opisy. Po pierwsze – że HBase to baza kolumnowa (column oriented). Po drugie – że to baza typu klucz-wartość (key-value store).

Ogólna budowa struktury HBase

Moim zdaniem znacznie bardziej fortunne byłoby stwierdzenie, że jest to baza zorientowana na column-familie (column familie oriented database) niż kolumnowa. Problem polega na tym, że coś takiego jak column familie oriented w powszechnych metodykach nie istnieje. Najmocniej przemawia jednak do mnie key-value store i to z dwóch powodów.

Po pierwsze – wynika to z Big Table Paper i tak właśnie przedstawia się największa alternatywa HBase, czyli Accumulo. Po drugie – ten model naprawdę ma w swojej strukturze klucz i wartość.

Jak to wygląda w praktyce? Zanim przejdziemy dalej, dwa podstawowe pojęcia:

  1. Namespace – czyli inaczej “baza danych”. Na tej samej instancji możemy mieć bazę związaną ze statusami z Twittera oraz osobną bazę na kwestie finansowe.
  2. Table – czyli swojska tabelka. Tabele są z grubsza tym czym tabelki w innych bazach, czyli  pewnym opisem zestawu danych. W “normalnych” bazach tabele mają zawsze kolumny. Tu także, jednak z pewną ważną modyfikacją…

Baza typu klucz-wartość (key-value store)

Zacznijmy od podstawowej rzeczy: wszystkie wiersze w tabeli zbudowane są na zasadzie klucz-wartość. Kluczem jest rowkey, czyli unikatowy w skali tabeli id. Wartością natomiast wszystkie dane zawarte w tym wierszu. Oddaje to dość prosty, poniższy rysunek.

HBase to baza typu klucz-wartość (key-value store).

Żeby zrozumieć dobrze na czym naprawdę polega struktura danych w HBase należy wziąć pod lupę owo “value”. Można spodziewać się, że albo siedzi tam jedna, konkretna wartość (np. liczba, tekst itd), albo że spotkamy tam kolumny. Otóż… pudło! Owszem, kolumny tam znajdziemy, ale niekoniecznie tak bezpośrednio.

W HBase kolumny pogrupowane są w “rodziny”, czyli column-families (cf). Dopiero pod cf znajdują się określone kolumny. I teraz uwaga! Znajdują się, jednak w żaden sposób nie są wymuszone, czy zdefiniowane w strukturze tabeli. Pojedynczy wiersz ma następującą strukturę.

Struktura wierszy tabeli w Apache HBase

Kolumny jednak dodawane są podczas… no właśnie, podczas dodawania konkretnego wiersza. Na etapie schematu (schemy) wymuszone mamy jedynie rowkey oraz column families. Efekt jest taki, że każdy wiersz może mieć inne kolumny (choć muszą mieścić się w ramach tych samych column families). Taka struktura ma oczywiście swoje wady – a konkretnie potencjalny bałagan. Należy bardzo uważać podczas pracy na takich danych, aby nie starać się “na siłę” odwołać do kolumn których może nei być.

Z drugiej strony ma to jednak daleko idące zalety, szczególnie w świecie Big Data. Można wykorzystać HBase jako zbiornik na dane, które są delikatnie ustrukturyzowane. Dane, które mają bardzo ogólną strukturę, a w środku mogą się nieco różnić. To pozwala umieszczać na przykład dane w pierwszym kroku ETL (extract, zaraz po zaciągnięciu ze źródła, z delikatnym “retuszem”).

Poznaj HBase dokładniej i zacznij z niego korzystać

To wszystko! Dzisiejszy artykuł bardzo krótki, jedynie wprowadzający do tematyki HBase. Tak naprawdę stanowi on niezbędną podstawę pod kolejny, na temat architektury HBase. Koniecznie zapisz się na nasz newsletter, aby nie przegapić;-).

 

Jeśli chcesz poznać HBase od podstaw, pod okiem specjalisty – zapraszam na nasze szkolenie. Nie tylko krok po kroku w usystematyzowany sposób poznasz jak obsługiwać HBase. Zrobisz także dużo ciekawych ćwiczeń na prawdziwej infrastrukturze Big Data, co znacząco przybliży Cię do świata realnego. Przekonaj swojego szefa i rozpocznij swoją przygodę z HBase!

Na dziś to tyle – jeszcze raz zachęcam do newslettera i powodzenia z HBase!

Big Data w New Space – technologie BD w branży kosmicznej

Big Data w New Space – technologie BD w branży kosmicznej

Marek Czuma

XXI wiek to okres głębokiej rewolucji w kwestiach kosmicznych. Najpierw kosmos został kompletnie zdeprecjonowany (łącznie z rozważaniami nad likwidacją NASA za Barracka Obamy). Następnie powstały bezprecedensowe próby rozwinięcia podboju kosmosu przez… sektor prywatny, z Elonem Muskiem na czele. Potem do gry weszli Chińczycy, którzy postawili Stanom Zjednoczonym potężne wyzwanie i… zaczęło się. Cała ta wielka przygoda nie mogła oczywiście odbyć się bez nowoczesnych technologii przetwarzania danych. Tak Big Data weszła do New Space.

New Space

Sektor prywatny pokazał, że do kosmosu można podchodzić w zupełnie nowy sposób. “Po rynkowemu” – z konkurencją, obniżając ceny, grając jakością, wskazując zupełnie nowe pola do rozwoju, a nade wszystko – robiąc na tym solidny biznes.

Odpowiedzią na rozwój sytuacji po stronie Chin oraz rodzących się nowych możliwości były śmiałe pomysły rządu Amerykańskiego – program powrotu człowieka na księżyc “Artemis” (wraz z Artemis accords) oraz utworzenie Space Force (sił kosmicznych).

Powstała całkowicie nowa domena – ochrzczona jako New Space. Wraz z “Baronami kosmosu” (wielkimi przedsiębiorcami wykładającymi swoje pieniądze na rozwój sektora kosmicznego), rywalizacją między mocarstwami i… coraz szybszym postępem technologicznym, który wykorzystywany jest obficie w życiu codziennym milionów osób.

A teraz pytanie retoryczne: czy mogą tak olbrzymie posunięcia technologiczne obyć się bez Big Data? Odpowiedź jest znana. I właśnie dlatego czas liznąć temat Big Data w New Space.

W tym artykule chcę podejść do sprawy bardzo ogólnie, fragmentarycznie i technicznie zarazem. Przedstawię kilka miejsc o których wiemy, że wykorzystywane są technologie Big Data oraz jakie dokładnie. Niech będzie to zaledwie zajawką tego olbrzymiego tematu, jakim jest Big Data w kosmosie.  Będziemy go zgłębiać w późniejszych materiałach, ale teraz – po prostu liźnijmy tą fascynującą rzeczywistość;-)

Big Data w JPL (NASA)

Pierwszym kandydatem, którego powinniśmy odwiedzić jest amerykańska NASA, a konkretnie JPL. Jet Propulsion Laboratory to centrum badawcze NASA położone w Kalifornii, które odpowiada za… naprawdę całą masę rzeczy. Niektórzy utożsamiają JPL (JPL – nie JBL, czyli firmy od naprawdę fajnych głośników;-)) z pracą nad łazikami. Słusznie, ale rzeczy które leżą w ich zasięgu jest cała masa.

Według JPL na potrzeby NASA zbierane są setki terabajtów… każdej godziny. Setki Terabajtów! Czy jesteśmy w stanie wyobrazić sobie tak gigantyczne dane? Wystarczy pomyśleć o liczbach, które się generują po miesiącu, dwóch, trzech latach… No jednym słowem: kosmos.

Czego wykorzystują do przetwarzania i analizy takich potwornych ilości danych amerykańscy inżynierowie z NASA? Mamy tu dobrze znane name technologie. Z pewnością jest ich więcej, ja dotarłem do takich jak:

  • Hadoop
  • Spark
  • Elasticsearch + Kibana

Apache Spark w JPL (NASA) – SciSpark

Oczywiście szczególnie mocno, jako freaka na tym punkcie, cieszy mnie użycie Sparka;-). Jeśli chcesz się dowiedzieć na jego temat coś więcej – dobrze będzie jak zaczniesz od mojej serii “Zrozumieć Sparka”. Pytanie – do czego wykorzystywany jest Apache Spark w JPL? Oczywiście do przetwarzania zrównoleglonego danych pochodzących z łazików, satelit i czego tam jeszcze nie mają.

Co ciekawe jednak, inżynierowie  big data w JPL utworzyli osobny program, który nazwali SciSpark. Program jest już niestety zarzucony, ale warto rzucić na niego okiem. Nie znalazłem informacji o przerwaniu prac, jednak wskazują na to przestarzałe treści, oddanie projektu fundacji Apache oraz ostatnie commity z 2018 roku. Na czym jednak polegał SciSpark? Jak wiadomo NASA i generalnie technologie kosmiczne to nie tylko wyprawy na Marsa, Księżyc i badanie czarnych dziur w galaktykach odległych o miliard lat świetlnych. To także, a może przede wszystkim, poznawanie naszego miejsca do życia – Ziemi. I program SciSpark powstał właśnie po to, aby pomagać w przetwarzaniu danych dotyczących naszego środowiska, zmian klimatycznych itd. I tak Big Data pomaga nie tylko w eksploracji “space”, ale także “ze space” pomaga poznawać Ziemię.

SciSpark Technicznie

Wchodząc w temat bardzo technicznie – program został napisany przede wszystkim w Scali. Chociaż twórcy zdają sobie sprawę, z istnienia PySparka oraz tego, że python jest naturalnym językiem Data Sciencystów, uznali że nie będzie odpowiedni ze względów wydajnościowych. Jak mówią sami:

“Ten Spark (w scali – dopisek autora) został  wybrany by uniknąć znanych problemów związanych z opóźnieniami (latency issue) wynikających z narzutu komunikacyjnego spowodowanego kopiowaniem danych z workerów JVM do procesu deamona Pythona w środowisku PySpark. Co więcej – chcemy zmaksymalizować obliczenia w pamięci, a w PySparku driver JVM zapisuje wynik do lokalnego dysku, a następnie wczytuje przez proces Pythona”.

Trzon SciSpark polega na rozszerzeniu sparkowych struktur RDD (Resilient Distributed Dataset) i utworzeniu nowych – sRDD (Scientific Resilient Distributed Dataset). Struktury te mają być dostosowane bardziej do wyzwań naukowców. W jaki sposób dokładnie, z chęcią zgłębię kod SciSparka i napiszę o tym osobny artykuł, dla chętnych geeków;-).

Poza Sparkiem, SciSpark posiada oczywiście całą architekturę systemu – z HDFSem, użytkownikami i interfejsem użytkownika (UI) włącznie. Poniżej ona – dla ciekawskich;-).

Architektura SciSpark – systemu tworzonego przez JPL (NASA).

Co ciekawe, SciSpark został upubliczniony i udostępniony fundacji Apache. Efekt jest oczywisty – teraz także i Ty możesz przeczesać kod, który pierwotnie tworzyli inzynierowie big data z NASA. Publiczne repozytorium znajdziesz tutaj.

Hadoop w NASA

Oczywiście przetwarzanie przetwarzaniem, ale gdzieś trzeba te dane przechowywać. Służy ku temu kolejna świetnie znana nam technologia, czyli Hadoop. Konkretniej być może warto powiedzieć hadoopowym systemie plików, czyli HDFS. To bardzo intuicyjny i dość oczywisty wybór, ponieważ HDFS pozwala rozproszyć pliki na wielu maszynach, co w przypadku tak ogromnych danych jest absolutnie niezbędne.

Prawdopodobnie – tu moja osobista opinia – z biegiem lat będzie trzeba przerzucić się na coś “nowszej generacji” z powodu różnych problemów i ograniczeń HDFSa. Być może dobrym pomysłem byłoby wykorzystanie Apache Ozone. Nie znalazłem informacji czy ktokolwiek w NASA wykorzystuje ten system z przyczyn dość banalnych (pomyśl tylko co wyskoczy gdy wpiszesz “NASA Ozone” w wyszukiwarkę). Wydaje mi się jednak – po pierwszych próbach wykorzystania Ozone, że musi w Wiśle jeszcze trochę wody upłynąć, zanim technologia dojrzeje.

W kontekście storowania plików, warto wspomnieć jakie to dokładnie są pliki. Oczywiście w systemach NASA budowane są liczne ETL’e, a więc i surowe pliki z pewnością są bardzo rozmaitych formatów. Jeśli jednak dane są już przetworzone, to z grubsza zapisywane są w dwóch formatach:

  1. HDF – czyli Hierarchical Data format – to format plików, który został wymyślony już w ubiegłym wieku. Od początku projektowany był tak, żeby mógł przechowywać duże dane. Od początku też – co ważne – wykorzystywany był przez NASA. Nie jest wielką tajemnicą, że tego typu instytucje nie mają zwrotności bolidu F1. Jeśli już do czegoś się przyspawają, pozostanie to z nimi na wieki;-). Więcej na temat HDF można przeczytać w tym dokumencie amerykańskiej agencji.
  2. NetCDF – czyli Network Common Data Form – to z kolei format plików (i związanych z nimi bibliotek), które przeznaczone są do przechowywania danych naukowych. Co ciekawe, pierwotnie NetCDF bazowało na koncepcji Common Data Format opracowanej przez… NASA. Potem jednak NetCDF poszło swoją drogą. To także jest format, który został zapoczątkowany już kilkadziesiąt lat temu.

Elasticsearch w JPL

Zasadniczo problem był następujący: jak w czasie rzeczywistym odtwarzać i przeglądać dane telemetryczne z bardzo, bardzo odległych źródeł. Jednym z najważniejszych był łazik Curiosity. Ten oddalony od nas o 150 milionów mil badał powierzchnie marsa (w rzeczywistości wartość ta dynamicznie się zmienia wraz z krążeniem obu planet wokół słońca). Trzeba było wykorzystać nowoczesne technologie Big Data. Jak może to wyglądać w praktyce? Przykład podaje Tom Soderstrom, Chief Technology and Innovation Officer, and Dan Isla, IT Data Scientist.

“Jeśli udałoby nam się dokładnie przewidzieć parametry termiczne, czas jazdy Curiosity mogłaby wzrosnąć dramatycznie, co mogłoby nas doprowadzić do przełomowych odkryć. I odwrotnie – błąd mógłby poważnie wpłynąć na misję za dwa miliardy dolarów.”

W kibanie można tworzyć wspaniałe środowisko do analizy. I właśnie to skusiło JPL z NASA.

Wcześniej inżynierowie JPL żmudnie zbierali dane i wrzucali je do powerpointa, gdzie potem analitycy mogli je analizować. Trwało to kupę czasu i cóż… z naszej dzisiejszej perspektywy wygląda to wręcz nieprawdopodobnie głupio. Możemy sobie tylko wyobrazić jaką rewolucję wprowadziło zastosowanie technologii Big Data. Konkretnie inżynierowie big data z NASA napisali całą platformę, nazwaną Streams, dzięki której dane mogły przychodzić w czasie “rzeczywistym” (o ile można tak nazywać komunikację z Marsem), a następnie być analizowane i przeszukiwane na bieżąco.

Właśnie w tym przeszukiwaniu i analizowaniu pomógł Elasticsearch wraz ze swoją wierną towarzyszką Kibaną. Dzięki spojrzeniu na problem przeglądania danych telemetrycznych jak na problem wyszukiwania (search problem) można było zaprzegnąć ES i rozwiązać rzeczy do tej pory nierozwiązywalne. Przede wszystkim sprawnie można było ograniczyć zakres poszukiwanych danych i skupić się tylko na tym co trzeba. Można było ładnie wizualizować i przeglądać to co zostało znalezione. Analitycy dostali w swoje ręce narzędzia, o których wcześniej się nie śniło.

JPL to niejedyne miejsce wykorzystujące Big Data w New Space

Zaczynając artykuł byłem przekonany, że zajmie on tylko kawałeczek. Teraz, gdy opowiedziałem o wykorzystaniu Big Data w NASA widzę jak bardzo się pomyliłem. Nie chcę rozwijać materiału jeszcze bardziej, dlatego już teraz zapraszam na drugą część;-). Jeśli chcesz dowiedzieć się jak Big Data wykorzystywana jest w innych obszarach New Space – zapisz się na newsletter lub obserwuj RDF na LinkedIn. Zrób to koniecznie i razem twórzmy polską społeczność Big Data!

 

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