Analiza infrastruktury i danych IoT. Wybór bazy

Rozwój rozwiązań w zakresie Internet of Things nikogo dzisiaj nie dziwi, a zjawisko to nie wymaga specjalnego uzasadnienia. Zastanówmy się jednak, jak z perspektywy architektury infrastruktury podejść do dwóch kluczowych wyzwań – tego, jaki rodzaj bazy wybrać do przechowywania danych, oraz jak modelować dane w najlepszy możliwy sposób?

Andriy Zabavskyy. Data Architect w SoftServe. Ma ponad 15-letnie doświadczenie w projektowaniu i wdrażaniu systemów intensywnego przetwarzania danych oraz systemów wspomagania decyzji na dużą skalę, w tym rozwiązań z zakresu inteligencji operacyjnej i zaawansowanej analityki. Posiada wiedzę w zakresie tworzenia i wdrażania architektury danych na poziomie przedsiębiorstwa dla różnych domen biznesowych, stosowania sprawdzonych metodologii projektowych oraz adaptowania nowych, najnowocześniejszych technologii i podejść, takich jak NoSQL, masywnie równoległe przetwarzanie, przetwarzanie strumieniowe i przetwarzanie w chmurze.

Określenie problemu na przykładzie Monitora Aktywności (MA)

Chcąc lepiej zrozumieć wyzwanie, któremu chcemy stawić czoła, przeanalizujmy przykład z życia codziennego, a dokładnie monitorowanie aktywności fizycznej.

Wymogi Biznesowe

W obszar śledzenia aktywności fizycznej zaangażowane są następujące strony:

• Użytkownik, który pragnie śledzić swoją aktywność fizyczną i różne rodzaje wskaźników zdrowotnych;
• Monitor aktywności — urządzenie o różnym stopniu złożoności, cechach i możliwościach;
• Urządzenie pośrednie, które zazwyczaj stanowi pomost między monitorem aktywności a światem zewnętrznym. W większości przypadków jest to smartfon.

Scenariusz Użytkowania

Rozważmy dwa najpopularniejsze scenariusze użytkowania MA (Monitora Aktywności).

W przypadku stałego monitoringu wskaźników zdrowotnych, urządzenie nieustannie monitoruje kluczowe wskaźniki zdrowotne, takie jak tętno lub poziom stresu, a także liczbę wykonywanych kroków w określonym przedziale czasowym, np. na minutę.

Natomiast w przypadku śledzenia konkretnej aktywności fizycznej, użytkownik ma możliwość śledzenia wybranych czynności lub treningów, które wykonuje. Aktywność taka ma ustalony początek i koniec, a w jej trakcie urządzenie zbiera szeroką gamę wskaźników, jak tempo, uderzenia na minutę, wysokość itp., zazwyczaj w krótszych przedziałach, na przykład co sekundę.

Wymogi Analizy

Rozważmy scenariusze analizy danych. Prosta analiza opisowa pozwala odpowiedzieć na pytanie, jak sobie radzę ja lub inni użytkownicy z mojej sieci. Mogę np. przeanalizować moje codzienne wskaźniki zdrowotne (tętno, liczba kroków) lub wskaźniki zagregowane dla danego okresu (tempo maks. i min., prędkość, kalorie, itp.). Jako rodzic mogę też w czasie rzeczywistym analizować wskaźniki zdrowotne moich dzieci (wymóg ten brzmi trochę dziwnie, ale dobrze ilustruje typowe przypadki wykorzystania innych rozwiązań IoT, jak np. nadzór nad wszystkimi pojazdami właściciela firmy transportowej).

Zaawansowana Analiza Diagnostyczna/Zapytania Ad-hoc daje nam odpowiedź na pytanie, dlaczego coś się stało. Jako użytkownik Monitoringu Aktywności pragnę analizować moje osiągnięcia w porównaniu z innymi użytkownikami w moim wieku czy mieszkającymi w mojej lokalizacji. Chciałbym się też dowiedzieć, jakie aktywności wykonywane są najczęściej i w jakich lokalizacjach. Natomiast jako analityk danych chciałbym zbadać, jak inne zewnętrzne zmienne, np. warunki pogodowe, wpływają na aktywność różnych osób lub jaka jest zależność między średnim tempem biegu, a wiekiem/wagą/wzrostem ludzi.

Wizja Rozwiązania Wybór Bazy

Szeroka Perspektywa

Szczegółowa analiza rozwiązania z perspektywy architektury oraz jego podział na elementy nie są opisane w niniejszym artykule. Niemniej, musimy zrozumieć, jaki rodzaj bazy wybieramy i jak wygląda jej powiązanie ze źródłem danych. W dużym skrócie – rozwiązanie powinno zostać opracowane z wykorzystaniem trzech warstw pokazanych na poniższym obrazie:

Trzy warstwy rozwiązania

Rolę warstwy Edge (krawędź) w naszym przykładzie pełni monitor aktywności, Fog (mgła) to smartfon, a Cloud (chmura) to centralna baza danych, gdzie przechowywane są wszystkie dane, do których dostęp mogą mieć wszystkie osoby zainteresowane analizą danych.

Warstwa Egde nie komunikuje się bezpośrednio z Cloud, ale jest zsynchronizowana z bardziej zaawansowanym urządzeniem pośredniczącym w Fog, które może przesyłać dane bezpośrednio do chmury.

Ważne: warstwy Edge i Fog mają również swoje własne wbudowane bazy danych, które obsługują część podstawowych potrzeb w zakresie analiz operacyjnych. Zostawmy jednak wybór wbudowanej bazy danych i skoncentrujmy się na wyborze silników baz danych w chmurze, dla potrzeb szerszych analiz.

Kluczowe Czynniki Wyboru

Chcąc wybrać najlepszą bazę, spełniającą nasze potrzeby analityczne, musimy przełożyć nasze wymagania na czynniki, które faktycznie wpłynęłyby na faktyczny wybór. Dodajmy do tego również wymagania niefunkcjonalne, które odgrywają istotną rolę przy doborze silnika.

Poniżej znajduje się przykładowa lista wymaganych możliwości:

Prosta analiza opisowa:

• Losowy dostęp do danych dla konkretnego użytkownika MA, stosując kryterium czasowe lub odpowiednie wskaźniki zdrowotne;
• Analiza dowolnie zdefiniowanych przedziałów czasowych jako podstawa ograniczona do konkretnego użytkownika MA lub kilku predefiniowanych użytkowników (dzieci lub dorosłych) i konkretnego lub konkretnych wskaźników;
• Agregacja na małych zakresach danych, z wykorzystaniem zakresu czasowego jako podstawy.

Zaawansowana Analiza Diagnostyczna/Zapytania Ad-hoc

• Agregacje dużego zakresu danych;
• Filtrowanie i Grupowanie różnych atrybutów wymiarów (osoba, monitor, lokalizacja, rodzaj aktywności);
• Analiza korelacji: analiza różnych wskaźników wg wspólnych osi/wymiarów.

Wymagania Niefunkcjonalne

Oprócz wymagań funkcjonalnych, które rozważaliśmy pod kątem potrzeb analizy danych, należy dodać również kilka niefunkcjonalnych, które są całkiem standardowe w obecnym świecie IoT:

• Big Data (możliwość określenia tego typu danych mianem Big Data): to całkiem oczywiste wymaganie, biorąc pod uwagę ambitnego producenta MA z dziesiątkami tysięcy użytkowników oraz urządzeniami, które mogą generować zestaw różnych wskaźników w każdej sekundzie, przez co potencjalna ilość danych może być naprawdę duża;
• Dostęp w czasie rzeczywistym do danych w zakresie ważnych wskaźników; załóżmy, że dostęp w czasie rzeczywistym do prostej analizy opisowej jest wymagany;
• Czas reakcji na zapytania analityczne powinien być dość krótki — kilka sekund w przypadku prostych zapytań opisowych i 20-30 sekund w przypadku innych, złożonych zapytań analitycznych.

Rozwiązanie

Obecnie nie ma jednej bazy zdolnej spełnić wszystkie istotne wymagania architektoniczne, stanowiącej „cudowny środek”. Nie dysponujemy bazą, która jednocześnie byłaby:

• w stanie obsługiwać szybkie losowe odczyty i zapisy oraz umożliwiać elastyczne grupowanie w skali Big Data;
• zorientowana na wiersz i kolumnę (zorientowanie wierszowe umożliwia szybsze zapisy, a kolumnowe szybsze agregacje dla większych zakresów danych).

Uwaga: można się spierać, że niektóre z tzw. silników NewSQL, jak Exasol, MemSQL, SAP HANA, itp., są w stanie wydajnie obsługiwać różne wzorce zapytań. W wielu przypadkach mogłoby to być prawdą, ale warto pamiętać, że na naprawdę dużą skalę (tj. dziesiątki terabajtów) staje się to szalenie kosztowne.

Mając to wszystko na uwadze, proponuję dwa rodzaje baz do obsługi różnych rodzajów scenariuszy analitycznych:

1. Baza NoSQL zdolna obsługiwać szybkie, losowe odczyty i zapisy. Najlepiej, jeśli ten rodzaj bazy byłby w stanie wydajnie realizować skanowanie krótkich zasięgów w oparciu o czas. W tym przypadku pasowałby zestaw silników danych pozycjonujących się jako bazy danych z szeregami czasowymi.

Taki rodzaj bazy w najlepszy możliwy sposób spełniałby wymogi związane z prostą analizą opisową w skali Big Data i w czasie rzeczywistym.

Ten rodzaj bazy traktowany jest również jako „gorący”, co oznacza, że dane w czasie rzeczywistym, dopiero co tworzone / przygotowane, są już gotowe do użycia.

2. Silnik typu Analitycznego/Hurtowni Danych ze wsparciem relacyjnego modelu danych. Odpowiedni projekt schematu gwiazdy modelu danych zapewnia maksymalną elastyczność, skuteczną agregację danych i dobrą skalowalność.

Taki rodzaj bazy w najlepszy możliwy sposób spełniałby wymogi związane z wydajną i elastyczną analizą danych. Dane z tej bazy określane są jako „colder (zimniejsze)” od tych real-time, co oznacza że dane nie są tak świeże i gorące, jak w scenariuszach czasu rzeczywistego, co z drugiej strony daje czas na lepsze przygotowanie do dokładniejszej i głębszej analizy.

Wysokopoziomowy podział danych i ich wykorzystanie przez użytkowników końcowych przedstawiono poniżej:

Dwa rodzaje baz

Wybór Technologii

Istnieje wiele różnych silników baz danych, które pasowałyby do obu powyższych opcji. Faktyczny wybór zależy od wielu czynników, jak np. istniejące licencje, ograniczenia budżetowe, dostawca rozwiązań chmurowych, umiejętności zespołu itp. Każdy silnik ma swoje wady i zalety, które są przedmiotem wielu artykułów porównawczych, jednak można wymienić kilka opcji godnych uwagi:

1. Bazy NoSQL z funkcjami szeregów czasowych: InfluxDB i OpensTSDB oraz wiele innych. Z oferty dostawcy usług chmurowych: Azure CosmosDB, AWS Dynamo DB lub GCP BigTable;
2. Skalowalna Hurtownia Danych: dostępnych jest wiele świetnych opcji, jak Vertica DB, SnowFlake DB, Azure Synapse (Hurtownia Danych), AWS Redshift lub GCP BigQuery.

Wnioski

W tym artykule skupiliśmy się na wyzwaniu z obszaru budowania rozwiązania z zakresu IoT, z perspektywy architektury infrastruktury, a konkretnie wyboru magazynowania. Zidentyfikowaliśmy dwa rodzaje przechowywania baz danych, które wymagają spełnienia wszystkich wymogów oraz uzasadniliśmy je. A zatem, następny krok to przygotowanie najbardziej wydajnego modelu danych!

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z