Jak analityka danych radzi sobie z ogromnymi ilościami danych

Analityka danych prowadzona w odpowiedni sposób może przynieść przełom w analityce biznesowej.

Według Allied Market Research, rynek przetwarzania danych przeżywa rozkwit i cieszy się ogromnym zainteresowaniem. Obecna wartość tego rynku to 650 mln USD i szacuje się, że do 2031 r. wzrośnie ona do poziomu 5 mld USD. Dlatego tak dużo pisze się na temat obsługi danych z wykorzystaniem różnych platform programistycznych. Aby lepiej zrozumieć ten fenomen, przyjrzyjmy się kilku pomysłom i potwierdzonym w praktyce przykładom przetwarzania danych.

Krótko mówiąc, istnieje wiele przykładów klientów, którzy chcą zbudować lub uporządkować swoje ekosystemy danych. Tego typu procesy obejmują monitorowanie wykorzystania danych przez użytkowników biznesowych, co jest możliwe dzięki raportom lub bezpośredniemu dostępowi do danych. I szczerze mówiąc, nie można zrobić tego źle. Istnieją jednak sytuacje, w których na początku projektu może on obejmować tylko niektóre przypadki użycia i podstawowe wymagania architektury, kluczowe w procesie tworzenia ekosystemu danych spełniającego oczekiwania klienta.

Z naszego doświadczenia wynika, że budowanie platform do analizy danych z zastosowaniem rozwiązań chmurowych jest bardzo efektywne. Wykorzystuje się w nich sztuczną inteligencję (AI) i uczenie maszynowe (ML). Dzisiaj opiszemy, w jaki sposób platforma Azure Data Platform może spełniać oczekiwania klientów.

Wyzwania

Podczas korzystania z wybranej platformy napotkaliśmy dwa problemy:

• Po pierwsze, musieliśmy przechowywać dane z wielu źródeł w jednym miejscu i jednocześnie zachować możliwość udostępniania tych danych innym użytkownikom.
• Po drugie, musieliśmy połączyć dane GitHub z danymi JIRA i stworzyć wizualne wskaźniki do monitorowania wydajność programistów.

Wymagań co do systemu nie było zbyt wiele, jednak musieliśmy wziąć pod uwagę kilka najistotniejszych kwestii:

• System powinien działać na platformie Azure Cloud

• Koszt obsługi i utrzymania systemu powinien być jak najniższy
• Preferowane narzędzie do wizualizacji danych to Power BI 

Biorąc pod uwagę powyższe oczekiwania, w naszym projekcie musieliśmy skupić się na przechowywaniu danych i połączeniu JIRA z GitHub. Te dwa aspekty okazały się mieć kluczowe znaczenie dla wybranych możliwości przetwarzania danych. Aby jednak uzyskać jaśniejszy obraz sytuacji, trzeba poznać pewien istotny kontekst.

Kontekst

Najważniejszą kwestią było zorganizowanie przechowywania danych. Nasze wcześniejsze doświadczenia wskazywały, że możemy użyć kolumnowego magazynu RDBMS do przechowywania danych w fazie przejściowej. Następnie moglibyśmy je przekształcić i ustrukturyzować. Istnieje wiele nowych typów danych, np. JSON czy pliki blob, jednak klasyczny RDBMS musi spełniać ważne wymagania architektury systemowej. Ostatecznie uznaliśmy, że RDBMS nie będzie optymalnym rozwiązaniem do przechowywania tego typu danych.

Ekosystem Synapse

Azure funkcjonuje na bazie ekosystemu danych w chmurze. Ten system to Synapse Analytics, który obejmuje następujące elementy:

• Potok danych

• Jezioro danych

• Dedykowana pula SQL

• Bezserwerowa pula SQL
• Pula Apache Spark

Na platformie Azure dostępne są także inne usługi. Mamy do wyboru np. platformę Analysis Services, AI\ML i Power BI (Business Intelligence). Można tu dodawać różne funkcje Azure, aplikacje logiczne itp., aby spełniać swoje wymagania. My mogliśmy akurat z łatwością powtórzyć zabiegi mające na celu wdrożenie systemu analitycznego na Synapse z naszego poprzedniego projektu. Za pomocą Data Factory połączyliśmy ponad 10 źródeł danych. Następnie załadowaliśmy je do jeziora danych. Potem wyodrębniliśmy dane zapytań z tabel w dedykowanej lub bezserwerowej puli SQL za pomocą SQL; dedykowana pula SQL zawiera statyczne tabele w warstwie nieprzetworzonej, podczas gdy bezserwerowa ankieta SQL zawiera tabele zewnętrzne. Daje to możliwość odpytywania danych za pośrednictwem studia zarządzania lub dostawcy danych OLEDB (było to jednym z wymagań).

Korzystanie z Azure Synapse Analytics zapewnia nam najniższy koszt niezbędnych usług. Co więcej, mamy do dyspozycji moc dedykowanej puli SQL ze wszystkimi funkcjami Azure DWH. Oznacza to również, że można wstrzymać tę usługę i uruchomić ją ponownie zależnie od potrzeb. Nie będziemy jednak rozpisywać się tu na temat wszystkich zalet tych usług; komplet niezbędnych informacji można znaleźć w dokumentacji Microsoft.

Wracając do naszego projektu, oto jedna z architektur referencyjnych opartych na ekosystemie Azure Data. (patrz rys.1).Rysunek 1. Architektura oparta na ekosystemie Azure Data

Powyższy rysunek przedstawia cały proces — od ekstrakcji danych ze źródeł po orkiestrację, analizę i wizualizację. W ramach opracowanego rozwiązania zastosowaliśmy ekosystem Databricks.

Ekosystem Databricks

Ekosystem Databricks zapewnia ujednolicony zestaw narzędzi dla inżynierów i analityków danych. Pomaga tworzyć potoki danych i uczenia maszynowego. Narzędzie to umożliwia programistom wykonywanie różnych poleceń Spark w wygodnym formacie przypominającym notatnik. Architektura platformy Databricks składa się z dwóch podstawowych elementów:

• Infrastruktura wykorzystywana przez Databricks
• Infrastruktura należąca do klienta

Dlatego pakiet Databricks jest w stanie działać z każdą usługą chmurową. Rozwiązanie to umożliwia też pełniejszą integrację systemu z innymi usługami w chmurze. Na przykład w omawianym projekcie połączyliśmy notatniki Databricks z innymi usługami Azure, takimi jak Data Factory, ADLS, Azure Monitor, Event Hubs i Active Directory.

W zależności od typu obciążenia, zespół może przyjrzeć się klastrom zoptymalizowanym pod kątem pamięci dla konwersji wymagających dużej ilości pamięci lub klastrom uczenia maszynowego z zainstalowanymi dodatkowymi bibliotekami uczenia maszynowego. Integracja GPU lub krótkoterminowe klastry zadań to optymalne rozwiązania, gdy priorytetem są oszczędności kosztów. Databricks to narzędzie, które zarządza infrastrukturą chmury i wdraża ją w swoim imieniu.

Budowanie jeziora danych

Aby zbudować nowoczesne jezioro danych, nasz zespół przyjął podejście zwane lakehouse (repozytorium danych). Dane zostały podzielone na trzy warstwy według formatu i zastosowanej konwersji.

Warstwy srebrna i złota korzystały z biblioteki open-source’owej Delta Lake. W rezultacie otrzymaliśmy efektywną strukturę dla zapytań ad-hoc i na potrzeby raportowania. Delta Lake stworzone na bazie innego formatu open-source’owego Parquet, daje użytkownikowi do dyspozycji zaawansowane funkcje, które przekładają się na solidną strukturę, szybkość działania, możliwość wersjonowania i zgodność bazy z założeniami ACID (atomowość, spójność, izolacja i trwałość).

W efekcie nasz zespół stworzył niedrogie rozwiązanie, w którym pamięć masowa w całości opierała się na usłudze Azure Data Lake Gen2. Udało nam się również ograniczyć koszt mocy obliczeniowej zatrzymując klastry deweloperskie i wykorzystując klastry zadań do zaplanowanych obciążeń ETL (wyodrębniania, przekształcania i ładowania).

Integracja danych z JIRA i GitHub

Naszym początkowym celem było połączenie ze sobą dwóch źródeł danych JIRA i GitHub, po to by stworzyć jezioro danych. Następnie przekształcone dane będą wykorzystane do opracowania raportów pokazujących zależność między pracą programistów w GitHub a zamkniętymi zgłoszeniami w JIRA; kierownik projektu zobaczy dane dotyczące efektywności zespołu. Po zakończeniu tego etapu prac, kilkakrotnie rozszerzyliśmy zakres źródeł danych:

Po pierwsze, podpięliśmy GitLab jako dodatkowe źródło do GitHub, ponieważ niektóre projekty przechowują tam kod, co dało nam możliwość podłączenia większej liczby projektów do pulpitu nawigacyjnego.

Po drugie, połączyliśmy źródła społecznościowe Twitter i Telegram. Były one potrzebne do uzyskania informacji niezbędnych do opracowania interaktywnej mapy, wyświetlającej wiadomości z ich geograficznymi lokalizacjami. W tym celu skorzystaliśmy z NLP (przetwarzanie języka naturalnego), aby rozpoznać nazwę miasta, gdy jest wspominana, i przypisać ją do właściwej lokalizacji geograficznej. Użyliśmy również automatycznego ładowania i przesyłania strumieniowego Databricks, aby skrócić czas, po którym dane są dostępne do analizy.

Efekty

Zbudowaliśmy czterowarstwowe jezioro danych do przechowywania danych surowych i przetworzonych:  nieprzetworzonych (Raw), wzbogaconych (Cleansed), nadzorowanych (Curated) i laboratoryjnych (Laboratory). Laboratorium to dodatkowa warstwa, która łączy elementy z pierwszych trzech warstw. Jest wykorzystywana do autoanalizy i uczenia maszynowego. Dla tej warstwy nie przyjęto żadnych konkretnych reguł, ponieważ dane są przechowywane w różnych formatach w zależności od potrzeb biznesowych.

Podczas prac nad rozwiązaniem stosowaliśmy różne podejścia do przechowywania i przetwarzania danych w jeziorze danych. Kierowaliśmy się następującymi założeniami:

1. Unikaliśmy korzystania z pliku metadanych do określania, który plik został przetworzony, a który nie. Postanowiliśmy korzystać z dwóch folderów do przetwarzania, ponieważ nie potrzebowaliśmy dodatkowych plików metadanych. Przetwarzaliśmy plik i przenosiliśmy go do folderu archiwum, gdzie warstwa nieprzetworzona (Raw) przechowuje dane w oryginalnym formacie. Niektóre potoki korzystają z wbudowanej funkcji automatycznego ładowania w celu śledzenia przyrostów.
2. Ustandaryzowaliśmy format danych w drugiej warstwie danych wzbogaconych (Cleansed) i użyliśmy formatu Delta Lake dla wszystkich źródeł. Dzięki temu byliśmy w stanie ujednolicić wszystkie rodzaje danych i skorzystać z rewelacyjnej funkcji formatu danych, dającej nam możliwość śledzenia historii zmian. 
3. Dane z naszych źródeł zapisaliśmy w jednym modelu danych. Warstwę nadzorowaną (Curated) skonfigurowaliśmy tak, aby mogło z niej korzystać narzędzie BI lub aplikacja. 
4. Mieliśmy jeszcze jedną warstwę tymczasową, wspomnianą warstwę laboratoryjną (Laboratory), z której korzystaliśmy na różne potrzeby, np. prowadzenie eksperymentów i zapewnianie dostępu do danych zespołowi data science.
5. Zespół data science tworzył różne powtarzalne eksperymenty, związane z uczeniem maszynowym (ML), a narzędzie MLFlow obsługiwało podstawowe procesy ML-ops.

Do logiki transformacji użyliśmy notatników Python i uruchomiliśmy je na klastrze Databricks. Aby śledzić wykonanie wszystkich notatników, podpięliśmy monitor Azure, w którym przechowywaliśmy wszystkie niestandardowe powiadomienia. Mieliśmy notatnik przeznaczony do zapisywania logów, których ponownie używaliśmy w innych miejscach. Do orkiestracji korzystaliśmy z Data Factory. Aby na koniec sprawdzić, czy opracowane procesy przebiegają poprawnie i czy nie występują w nich nieudane wykonania, połączyliśmy Power BI bezpośrednio z Azure Monitor i utworzyliśmy pulpit, na którym mieliśmy podgląd stanu systemu. Wykorzystaliśmy też platformę MLFlow do monitorowania wskaźników wydajności procesów uczenia maszynowego i wersjonowania modeli.

Jakie były efekty naszej pracy? Aby osiągnąć założony cel, potrzebowaliśmy tych wszystkich ustalonych wcześniej reguł i dobrego systemu monitoringu. Na koniec podłączyliśmy do naszego systemu Power BI, aby zwizualizować połączenie między JIRA i Github (patrz rys. 2).Rysunek 2. Połączenie JIRA i Github

W ramach drugiej iteracji podłączyliśmy do naszego rozwiązania sieci społecznościowe. Następnie pobraliśmy nieprzetworzone informacje i zapisaliśmy je w warstwie nieprzetworzonej (Raw) naszej architektury. Później przekształciliśmy te dane i zapisaliśmy w warstwie nadzorowanej (Curated). Pomiędzy tymi procesami stosowaliśmy NLP, aby móc określić geolokalizację zapisaną w wiadomości i poszerzyć nasz model danych o atrybuty współrzędnych geograficznych. Na koniec użyliśmy mapy, aby wyświetlić wiadomości i wzmianki historyczne w określonym regionie zidentyfikowanego kraju. Efekty możesz zobaczyć tutaj.

Słowem podsumowania

Na pierwszy rzut oka realizacja powyższego projektu może wydawać się prostym zadaniem. Jednak osiągnięcie opisanych wyżej rezultatów jest możliwe tylko dzięki zastosowaniu odpowiedniej architektury. Opracowane rozwiązanie można rozbudować tak, aby spełniało nowe potrzeby biznesowe, mimo że każdy nowy przypadek będzie wiązał się z określonymi wymaganiami architektonicznymi, przypadkami użycia i decyzjami. Nie da się stworzyć idealnego, uniwersalnego rozwiązania jednorazowego, ponieważ każde rozwiązanie ewoluuje i staje się doskonalsze po kilku iteracjach.

Chcesz dowiedzieć się, w jaki sposób dane, którymi dysponujesz, mogą pomóc twojej organizacji sprostać różnym wyzwaniom biznesowym? Nasi eksperci są gotowi udzielić ci odpowiedzi, których możesz potrzebować. Skontaktuj się z nami.