Od zera do bohatera #2: 7 pytań, które musisz zadać, projektując system przetwarzający dane

W poprzednim wpisie serii Od zera do bohatera starałem się przekonać Cię, że niezbędne jest rozumienie danych, które przetwarzamy. Dzisiaj z kolei dowiesz się, na jakie rzeczy (w pierwszej kolejności) zwrócić uwagę projektując system przetwarzający dane.

Dla uproszczenia, na potrzeby naszych rozważań spójrzmy na przetwarzanie danych jako transformacja ich ze stanu A do B:

Stan A jest źródłem, a B jest Twoim celem.

1. Gdzie i czym jest Twój punkt B? 🙂

Nawiązując do poprzedniego wpisu – zbieranie, przechowywanie i przetwarzanie danych ma jedynie sens jeżeli przynosi wartość lub jest po prostu wymagane (np. regulacjami prawnymi).

Zanim zaczniesz dane zbierać, musisz sobie odpowiedzieć na pytanie, co chcesz mieć na końcu „rury” zwanej data pipeline 🙂 Ma to być system Business Intelligence z raportami dla użytkownika? System analityczny? Wyciąganie dodatkowych wniosków z danych używając uczenia maszynowego? A może źródło danych dla innego systemu? I to prowadzi nas do drugiego pytania.

2. Jak wygląda Twój system w skali makro?

W skali mikro, transformację A => B możemy rozumieć jako cały proces w naszym systemie.

Pojedyncza transformacja może być jedynie składową przetwarzania. Możemy mieć więcej takich pomniejszych kroków (Ax => Bx). Może to wyglądać tak:

A gdy spojrzymy na to w skali makro, to nasz system może być częścią większego procesu przetwarzania danych:

System ten może produkować dane dla użytkowników i być źródłem dla innych systemów. Warto zrobić kilka kroków do tyłu, aby zobaczyć całość z dystansu.

Ostatnio przygotowywaliśmy się do stworzenia propozycji dla klienta przeniesienia części jego systemów do chmury. Z całej rozmowy z doświadczonym architektem wyszło, że konieczna jest wiedza, jak działa ten system w skali makro.

Dlaczego? Z reguły, samo przerzucenie środkowego elementu całego procesu do chmury (patrząc holistycznie) nie niesie ze sobą wystarczających wartości dla klienta. Co z tego, że wrzucimy dane, które już gdzieś tam składujemy na chmurze, a później i tak je pobieramy oraz analizujemy na blaszakach (on-premises)?

To kiedy pojawia się wartość w tym konkretnym przypadku? Na pewno jeżeli udałoby się przerzucić na chmurę również początek (zbieranie danych z różnych źródeł, np. od dostawców) i/lub koniec procesu (cała analiza danych, której wyjściem może być raport, dane zagregowane itp.).

Dobrze, teraz odpowiedzmy sobie pokrótce jakie dane możemy napotkać.

3. Dane ustrukturyzowane czy nie?

Cofnijmy się na chwilę do lat 90, gdzie dysponujemy jedynie danymi, które można załadować do relacyjnej bazy danych. NoSQL nie jeszcze w powszechnym użyciu, nie mówiąc już o idei „dużych danych” (Big Data).

W takich okolicznościach, przetwarzanie danych możemy sprowadzić do baz i hurtowni danych. Oczywiście jest to małe uproszczenie, ale tak naprawdę rozmawiamy o kilku modelach danych wraz z narzędziami ETL (Extract, Load, Transform) do ich przetwarzania. Do tego dochodzi analityka (np. w postaci kostek OLAP – więcej poniżej), wnioskowanie (np. z użyciem eksploracji danych) i raporty. Na tym moglibyśmy zakończyć bardzo wysokopoziomowe omawianie procesu przetwarzania danych 🙂

Wróćmy jednak do roku 2020, gdzie nie jest już tak łatwo. Jako ciekawostkę, znalazłem dokument, który obrazuje, jak wygląda zbiór technologii danych dzisiaj:

Dlaczego o tym wspominam? Ano dlatego, że dzisiaj potrafimy ogarnąć zdecydowane więcej różnych danych, co nieco utrudnia, ale jednocześnie daje mnóstwo możliwości.

Planując budowę systemu opartego na danych, musimy odpowiedzieć sobie na pytanie – z jakimi danymi się będziemy musieli zmierzyć.

Dane ustrukturyzowane (ang. structured data) to dane z ustalonym z góry modelem. Często to dane relacyjne – takie jakie możemy zapisać w klasycznej bazie danych. Możemy opisać je tabelami i relacjami pomiędzy nimi. To właśnie te, które przetwarzamy już „od dekad”.

Dane nierelacyjne (NoSQL), a w zasadzie nie tylko relacyjne (Not Only SQL) w większości zaliczane są do danych nieustrukturyzowanych. Zdarza się, że klasyfikowane są jako dane częściowo ustrukturyzowane (ang. semi-structured data). Dane te możemy przechować w jednym z czterech głównych typów baz:

• Typu: klucz-wartość (Key value store) – gdzie klucz identyfikuje dany obiekt,
• Dokumentowa (Document store) – możemy zapisać tam pliki typu JSON,
• Kolumnowa (Column store) – pod tym pojęciem często mamy dwa aspekty: kolumnowy sposób zapisywania danych na dysku oraz tworzenie tzw. rodzin kolumn (column family),
• Grafowa (Graph store) – zoptymalizowana pod zapisywanie grafów, czyli wezłów i połączeń między nimi, np. reprezentujących jakaś sieć społecznościową.

Dane nieustrukturyzowane, są tymi, które bardzo mocno namieszały w świecie przetwarzania danych. Scharakteryzować można je w dwóch słowach: wszystko inne 🙂 Również można powiedzieć o tych danych, że nie mają wcześniej ustalonego modelu ich przechowywania.

Mogą to być dane takie jak pliki tekstowe, wiadomość email, obraz, dźwięk, wideo czy informacje pochodzące z social media. Zaliczamy do tego dane płynące z różnych urządzeń podpiętych do sieci (Internet of Things).

Pamiętaj, to jest jedynie nomenklatura. Nie chodzi o to, żeby taką czy inną klasyfikację „wykuć na blachę”, niczym budowę pantofelka na lekcjach biologii. Jak wszyscy wiemy, wiedza o pantofelku przydaje nam się na każdym kroku 🙂 W przypadku omawianych typów danych, ważne jest, aby mieć po prostu świadomość, z jakim wachlarzem możliwości mamy do czynienia.

4. Przetwarzasz paczkami czy strumieniowo?

Typ danych to jeden aspekt, ale również musimy przeanalizować, jak te dane są nam dostarczane.

Dane możemy przetwarzać paczkami (ang. batch processing), np. raz dziennie uruchamiamy proces, który pobiera jakieś pliki, zbiera dane z innych baz i je przetwarza. Często są to długotrwałe procesy.

Innym rodzajem jest tzw. przetwarzanie strumieniowe (ang. streaming processing). Dane takie są dostarczane praktycznie cały czas. Dostarczycielem takich danych są np. urządzenia IoT (Internet of Things), który wysyłają przeróżne metryki.

Nic nie stoi na przeszkodzie, aby łączyć te dwa przetwarzania. Możemy pobierać dane strumieniowe, przetwarzać je i wzbogacać (ang. data enrichment) wcześniej pobranymi danymi batchowymi.

Oczywiście dane mogą być jeszcze wprowadzane przez użytkowników, ale dotyczy to głównie systemów transakcyjnych, o czym poniżej.

5. Projektujesz system transakcyjny czy analityczny?

W dużej mierze jest to związane z pytanie pierwszym, ale warto omówić to osobno. Czym się charakteryzują oba systemy? Otóż, system transakcyjny, zwany również OLTP (ang. Online Transaction Processing) jest systemem, w którym główną rolę odgrywa wymieniona w nazwie transakcyjność. Co to znaczy? Fajnie wyjaśnia to Wikipedia, która podaje, że można to pojęcie rozumieć na dwa sposoby.

W rozumieniu bazodanowym jest to operacja, która w sposób atomowy (niepodzielny) ma za zadanie wykonać jakąś konkretną operację (zobacz: ACID). Inaczej mówiąc odbędzie się wszystko, albo nic. Drugie znaczenie jest znaczeniem finansowym, np. przelew pieniędzy z jednego rachunku na inny.

A podsumować to można tak – system OLTP może użyć pierwszego typu transakcji, żeby zrealizować drugi. Nie możemy dopuścić, aby taka operacja wykonała się częściowo. Przykładowo, pobrane zostały pieniądze z jednego konta, a nie zapisane na drugim. Celowo to upraszczam i nie wchodzę w omówienie fizycznej realizacji przelewów z uwzględnieniem systemów takich jak Elixir.

Kolejną ważną cechą systemu OLTP jest to, że jest on projektowany, aby poradzić sobie z częstymi aktualizacjami danych. Z założenia ten system powinien być szybki. Samo w sobie jest dość relatywnym pojęciem, ale mówimy tu o szybkości na tle systemów analitycznych.

Systemy analityczne możemy rozumieć w różny sposób. Jakbyśmy razem z Martym McFlyem wrócili raz jeszcze do lat 90, to podział byłby prosty. Odpowiednikiem analitycznym systemu OLTP jest OLAP (Online Analytical Processing). Dzisiaj warto doprecyzować, co rozumiemy przez to pojęcie. Może to być ogólne określenie systemów analitycznych albo idea, która polega na budowaniu tzw. kostek OLAP-owych. Służą one do analizowania danych pod różnym kątem (tzw. wymiarami).

Dzisiaj mamy tego znacznie więcej. Przykładowo możemy zbudować system, który będzie używał danych do analiz w oparciu o uczenie maszynowe, np. pobierając dane z jeziora danych (Data Lake). Możliwości i kombinacji jest wiele, zwłaszcza jeżeli uwzględnimy dane nieustrukturyzowane.

Co ważne – narzędzia oraz modele systemów analitycznych są optymalizowane pod kątem analiz na potężnych zbiorach danych. Ma to pewne konsekwencje. Przykładowo odpowiedź takiego systemu (w porównaniu z systemem transakcyjnym) nie musi być natychmiastowa oraz aktualizacja danych jest bardziej problematyczna. Wcześniej taki system trzeba zasilić danymi, a to także może trwać „chwilę”. Dlatego warto zastanowić się, co tak naprawdę chcemy osiągnąć.

Czy taki podział powoduje, że te dwa rozwiązania są wykluczające? Oczywiście, że nie. Nietrudno wyobrazić sobie rozwiązanie, które będzie łączyło dwa podejścia. System OLTP będzie źródłem (albo jednym z wielu) dla systemu analitycznego, który to będzie konsolidował dane i wykonywał na nich przeróżne analityki. Efektem może być udostępniony raport w systemie Business Intelligence.

Żeby było ciekawiej, niektóre rozwiązania, w których próbuje się zapewnić spójność lub tzw. spójność ostateczną (po angielsku brzmi to zdecydowanie lepiej – eventual consistency) dryfują gdzieś pomiędzy. Nie do końca spełniają wymagania systemów OLTP, ale też nie są systemami analitycznymi (sensu stricto). Znowu – to tylko klasyfikacja i podpada pod dyskusję akademicką. Najważniejsze, żeby rozumieć, co się robi i robić to dobrze 🙂 A żeby się tak stało, to musimy brać pod uwagę cechy konkretnych narzędzi oraz technologii.

6. Jaki jest wolumen danych?

Tutaj będzie krótko, bo chyba jest to dość jasne. Jest to jedno z tych V opisujących Big Data – Volume. Oczywiście ten aspekt musimy brać pod uwagę nie tylko w przypadku dużych danych.

Często wolumen musimy analizować razem z rodzajem danych, jakie przychodzą (patrz pkt. 3). Dodatkowo ważne jest, aby spojrzeć na ilość danych nie tylko przez pryzmat inicjalnego zasilenia systemu. Musimy przyjrzeć się, jak te dane będą przyrastać z czasem. Pozwala to wybrać technologie i zaprojektować rozwiązanie, które będzie się dobrze skalować.

Pamiętajmy, że nie wszystkie rozwiązania nadają się do dużych zbiorów danych. Niekiedy z kolei nie warto odpalać potężnej machinerii jeżeli tych danych nie jest tak dużo. Wielokrotnie słyszałem historię, w której pojawiały się pomysły tworzenia systemów Big Data, które mogłyby być ogarnięte zwykłymi hurtowniami lub wręcz bazami danych. W skrajnych przypadkach – excelami 🙂

Dlaczego, więc się tworzy takie systemy? Bo jest to sexy 🙂 W momencie jak technologie Big Data stawały się modne, usłyszałem ciekawe i pełne prawy powiedzenie profesora Dan Ariely z uniwersytetu Duke:

Big Data jest jak seks nastolatków. Wszyscy o tym mówią, nikt tak naprawdę nie wie, jak to właściwie robić, każdy myśli, że inni to robią, więc wszyscy udają, że oni też.

7. Ile masz czasu na przetwarzanie?

Szybkość przetwarzania danych to jest to kolejne V w definicji Big Data – Velocity. Wspominałem, że systemy transakcyjne z założenia powinny być szybsze niż te analityczne, ale tutaj chodzi o coś innego.

Z punktu widzenia biznesowego może się okazać, że dane po jakimś konkretnym punkcie w czasie stają się bezużyteczne. Albo trochę mniej dramatycznie – permanentne spóźnianie się z raportem dla regulatora też może mieć swoje konsekwencje.

Często są to też fizyczne ograniczenia. Jeżeli chcemy, aby użytkownicy rano mogli korzystać z odpowiednich raportów, to musimy zapewnić, że puszczone w nocy przetwarzanie zakończy się, zanim pojawią się w pracy.

Oczywiście istnieje jeszcze jedna klasa rozwiazań ze względu na czas przetwarzania, tzw. systemy czasu rzeczywistego (ang. Real-time) lub zbliżone do czasu rzeczywistego (ang. Near real-time). Tutaj cały proces zachodzi w bardzo krótkim czasie.

Podsumowanie

Jak widzisz, nie ma tutaj pytania czy robimy hurtownie danych, Data Lake czy modny ostatnio Lake House. To co będziesz budował(a), jest pochodną tego, jakimi danymi dysponujesz. W szczególności ich rodzaju, wolumenu oraz wymaganiami biznesowymi.

I tu pomogą pytania, które przedstawiłem w artykule. Oczywiście im bardziej szczegółowo podchodzimy do danego rozwiązania, tym lista pytań będzie się powiększać. Może obejmować np. pytanie o politykę retencji danych (ile chcemy trzymać dane w systemie), czy przetwarzamy dane wrażliwe lub podpadające pod jakieś regulacje. I wiele więcej.

Zrozumienie tych podstawowych pojęć pomoże Ci odnaleźć się w technologicznym gąszczu. Dzięki temu później będzie nam łatwiej poruszać się po konkretnych rozwiązaniach.

W kolejnym wpisie z serii bliżej przyjrzymy się konkretnym źródłom danych.

Słowo na dziś z ITmowy

Przypadek brzegowy, który bardzo rzadko występuje

To wyrażenie nie występuję jedynie w IT, ale jest często w tej branży używane. Poniżej przykłady użycia: