with Brak komentarzy

Środowisko analityczne big data dla źródeł IT i OT.

Spójrzmy razem z lotu ptaka na centrum przetwarzania danych Typowej Organizacji S.A. „Po lewej stronie” dojrzałe systemy z tradycyjnymi bazami danych i aplikacjami. „Po prawej”, pomału raczkuje ekosystem big data. W każdej z tych części, dane przetwarzane są w dwóch typach środowisk: operacyjnym i analitycznym. Dzięki temu pierwszemu środowisku biznes Typowej Organizacji S.A. w ogóle działa. To drugie pokazuje, jaka jest jego kondycja. I to właśnie o tym środowisku przeczytasz w dalszej części materiału.

Naszkicuję ogólny schemat architektury systemów analitycznych, który będzie uwzględniał poszczególne jej warstwy. Schemat ten obejmie swoim zakresem obszar big data. A dodatkowo oprócz aplikacji ze świata IT (Information Technology) rozszerzymy go również o assety ze świata OT (Operational Technology).

Uprzedzam uczciwie, że artykuł jest relatywnie długi (tak jakby inne nie były!). Mam jednak nadzieję, że poniższe hasła (#buzzwords) zachęcą Cię mimo wszystko do jego przeczytania. W zasadzie, tylko po to je tutaj umieściłem .

#AnalitykaBigData, #BigDataFabric, #IoT.

Środowisko operacyjne vs. środowisko analityczne.

Tak dla zachowania porządku, dosłownie kilka zdań na temat różnic pomiędzy nimi. Przede wszystkim obciążenia, jakie występują w każdym z tych środowisk mają zupełnie inny charakter i cechują się odmiennym profilem.

 

Obciążenia w środowisku operacyjnym są generowane w aplikacjach biznesowych i w urządzeniach (assetach), które wspierają, podtrzymują lub wprost generują biznes.

  • Systemy: ERP, CRM, media społecznościowe.
  • Pracujemy na danych bieżących.
  • Transakcje wpływają (bezpośrednio lub pośrednio) na wielkość naszego biznesu.
  • Na przykład insert do tabeli w bazie danych (nowa transakcja zakupu).
 

Obciążenia w środowisku analitycznym są generowane, aby „na koniec dnia” określić, jaki jest stan biznesu. Są silnikiem wiedzy na temat tego: co się dzieje, jak się dzieje, dlaczego tak się dzieje oraz co zrobić, aby działo się lepiej.

  • Systemy: hurtownie danych, Hadoop, BI/BA.
  • Pracujemy na danych bieżących (przetwarzanie w czasie rzeczywistym) i historycznych (przetwarzanie wsadowe).
  • Transakcje pomagają ocenić jakość prowadzonego biznesu.
  • Na przykład łączenie danych z różnych tabel w różnych bazach danych (korelacja danych z różnych źródeł).
 

Czy któreś z nich są ważniejsze? Moim zdaniem nie.

Oprócz pracy w korporacji jako konsultant i architekt, prowadzę również swoją własną firmę (niezwiązaną z branżą IT). Oto algorytm, który w niej zaimplementowałem.

 

moj algorytm

 

Działania operacyjne generują nasz biznes. Analiza tych działań dostarcza informacji na temat tego, jak ten biznes wygląda. Bez wiedzy, co działa źle, trudno jest wprowadzać udoskonalenia. 

A gdzie taki algorytm jest zaimplementowany w architekturze korporacyjnej? Ja widziałbym go na przykład tutaj:

  • dane ze środowiska operacyjnego zasilają hurtownie danych i są przygotowywane do wykonania analityki na żądanie,
  • w środowisku analitycznym przeprowadzane są badania,
  • na ich podstawie wysyłana jest informacja zwrotna do środowiska operacyjnego.
 

operacje vs. analityka

 

Dobrą praktyką jest, aby każdy ważny system w środowisku operacyjnym miał swojego „anioła stróża” w środowisku analitycznym. Architektura i wybór narzędzi do budowy takiego środowiska będzie w dużej mierze zależeć od tego co będzie analizowane.

 
Zaczynamy od źródeł.

Właśnie. Mimo, że rysować będziemy środowisko analityczne dla ekosystemu big data, to wypada zacząć ten obrazek od źródeł operacyjnych. To stąd płynie strumień danych, które są dalej przetwarzane i analizowane.

 

architektura big data dla IoT slajd1

 

Nasz system analityczny będziemy zasilać danymi ze środowiska operacyjnego IT (dane z aplikacji) oraz ze środowiska operacyjnego OT (dane z assetów). Komponenty architektury ze świata IT będę oznaczał na rysunku kolorem niebieskim, a te ze świata OT – pomarańczowym.

Pierwszym elementem naszej architektury jest „strefa lądowania”. Jest to miejsce, do którego będziemy ładować dane z systemów źródłowych. Dane te będą tutaj tymczasowo przechowywane, sortowane i klasyfikowane w określone tematy, tak aby komponenty z kolejnych warstw mogły je konsumować w zależności od swoich własnych potrzeb i wymagań. Ten element architektury jest wspólny dla danych IT i OT, chociaż w każdym z tych przypadków jest on nieco inaczej określany. W świecie IT mówimy o kolejce zdarzeń/wiadomości (message queue). W świecie OT jest to broker zdarzeń (event broker). Funkcja tego elementu w obydwu przypadkach jest jednak taka sama.

 

architektura big data dla IoT slajd2

 

Przykładowe narzędzia do wykorzystania w tym miejscu: Kafka, RabbitMQ.

 
Przechowywanie.

To najniższa warstwa w części analitycznej. Narzędzia z tej warstwy pozwalają na składowanie danych o różnych formatach i różnym przeznaczeniu. Podczas budowania naszej architektury do wyboru mamy tutaj: bazy relacyjne, bazy NoSQL, obiektowe pamięci masowe (S3), kolekcje indeksów, analityczne bazy danych i systemy plików.

 

architektura big data dla IoT slajd3

 

W bazach NoSQL będziemy przechowywać dane niestrukturalne, które najczęściej będą wykorzystywane po stronie środowisk operacyjnych. Będą to te dane, dla których musimy zagwarantować między innymi krótkie czasy opóźnień oraz szybkie inserty.

Przykładowe narzędzia do wykorzystania w tym miejscu: mongoDB, Casandra, HBase.

Pamiętaj, że wybór narzędzia należy zawsze dostosować do scenariusza wykorzystania. Na przykład, na potrzeby przechowywania zdjęć, filmów i opisów produktów w sklepie internetowym lepszą bazą będzie mongoDB. Z kolei do przechowywania logów lub danych z sensorów bardziej będzie nadawać się Casandra. HBase natomiast świetnie sprawdzi się w przypadku przechowywania danych niestrukturalnych dla środowiska transakcyjnego.

 

System plików HDFS wykorzystamy do budowy jeziora danych (data lake). Dane tutaj przechowujemy w postaci surowej (RAW) i używamy do przetwarzań wsadowych. Nie korzystamy z żadnego schematu/modelu, tak jak to ma miejsce w przypadku tradycyjnych hurtowni.

Przykładowe narzędzia do wykorzystania w tym miejscu: Cloudera, Hortonworks, MapR.

 

Przestrzeń obiektowa S3 jest coraz chętniej wykorzystywana w środowiskach big data. Jest to miejsce do składowania danych „chłodnych”, czyli takich, które nie są często używane (przetwarzanie wykonywane np. raz na kwartał). Dane przechowywane w tym miejscu mogą być opisane kontekstowo z wykorzystaniem metadanych, które są częścią obiektu i są przechowywane razem z danymi. Storage S3 jest to również dobre miejsce do przechowywania danych, które muszą spełniać określone regulacje prawne. Przed audytorami i regulatorami znakomicie „broni się” obiektowa pamięć masowa, która korzysta z technologii WORM (więcej informacji na ten temat znajdziesz w tym artykule). Takie macierze obiektowe traktowane są również jako target dla kopii bezpieczeństwa i w ten sposób rozwiązują wiele problemów związanych z backupem danych w obszarze big data.

Przykładowe narzędzia do wykorzystania w tym miejscu: Hitachi Content Platform (HCP), Dell-EMC Elastic Cloud Storage (ESC), ScalityRING, AWS S3.

 

Na pewno już zauważyłeś(aś), że z powyższych trzech elementów rysuje nam się bardzo ciekawa trójwarstwowa architektura środowiska:

 

trzy warstwy storage

 

Indeksy pozwalają na zbudowanie struktury w świecie danych niestrukturalnych. Charakteryzują się bardzo losowym dostępem i często wykorzystują zapytania w języku naturalnym. Jest to bardzo ważny element, który uzupełnienia nasze jezioro danych, zbudowane na HDFSie. Potrzebujemy w naszej architekturze dobrego i skalowalnego silnika indeksowania, aby móc efektywnie wyszukiwać surowe dane w często bardzo głębokim jeziorze danych.

Przykładowe narzędzia do wykorzystania w tym miejscu: Hitachi Content Intelligence (HCI), Solr, ElasticSearch.

 

I na koniec analityczne bazy danych. To tutaj definiujemy schematy i modele dla danych, które są przechowywane poniżej w jeziorze danych. Na żądanie użytkowników biznesowych i na potrzeby analityki danych tworzymy tzw. data marty. Do wykorzystania mamy bardzo różne typy baz danych: MPP (Massively Parallel Processing), OLAP (OnLine Analitical Processing), bazy kolumnowe, a nawet bazy relacyjne.

Przykładowe narzędzia do wykorzystania w tym miejscu: Teradata, Vertica, Netezza, SAP HANA, PostgreSQL.

Możemy tutaj wykorzystać również komponenty ekosystemu Apache, takie jak Impala, Hive, Presto, czy Drill. Posłużą one nam do dostarczenia interfejsu SQL-owego dla danych przechowywanych poniżej w jeziorze danych (w HDFSie lub w pamięciach S3).

 
Przetwarzanie.

Nad warstwą przechowywania, dodajemy elementy związanie z przetwarzaniem danych. I w tym zakresie mamy w zasadzie trzy możliwości.

 

architektura big data dla IoT slajd4

 

Przetwarzanie w czasie rzeczywistym – każde zdarzenie jest procesowane indywidualnie, nie jesteśmy świadomi zdarzeń i danych historycznych. Informacja zwrotna jest przekazywana natychmiast.

Przykładowe narzędzia do wykorzystania w tym miejscu: Hitachi Operational Intelligence (HOI), Spark, Storm (raczej już nie stosowany), Flink.

 

Przetwarzanie wsadowe – procesy są grupowane i przetwarzane jednocześnie. Wykorzystywane do analityki danych historycznych.

Przykładowe narzędzia do wykorzystania w tym miejscu: Spark, MR (MapReduce).

 

Przetwarzanie mikro-wsadowe – jest czymś pośrednim pomiędzy tymi dwoma poprzednimi typami. Korzystamy tutaj z technik stosowanych w przetwarzaniu wsadowym, ale dla scenariuszy czasu rzeczywistego. Prawie każdy przypadek przetwarzania w czasie rzeczywistym można przeprocesować za pomocą technik wykorzystywanych w przetwarzaniu mikro-wsadowym.

Przykładowe narzędzia do wykorzystania w tym miejscu: Spark.

 
Analityka.

Tutaj poszczególne elementy narysuję, stosując dwa podziały: w zależności od rodzaju analityki (często musimy wybrać więcej niż jeden) oraz w zależności od rodzaju danych jakie będziemy badać. Jeżeli chodzi o ten pierwszy podział, to nasza analityka może być:

  • deskrypcyjna – badamy co się dzieje lub co się stało,
  • diagnostyczna (jest to specyficzny rodzaj tej poprzedniej) – szukamy odpowiedzi, dlaczego to się stało,
  • predykcyjna – chcemy wiedzieć co się wydarzy,
  • preskryptywna – interesuje nas odpowiedź na pytanie co się powinno wydarzyć (tutaj używamy analityki predykcyjnej i dodatkowo podpowiadamy akcję „co należy zrobić”).

Drugi rodzaj klasyfikacji związany jest z konkretnym scenariuszem wykorzystania oraz konkretnym typem danych, które analizujemy. Na rysunku znajdziesz tylko te najbardziej powszechne przykłady. W rzeczywistości istnieje ich o wiele więcej.

 

architektura big data dla IoT slajd5

 

Przykładowe narzędzia do wykorzystania w tym miejscu: Pentaho, Cognos, Microstrategy, Spark MLlib, Python, R.

 
Wizualizacja.

I została nam ostatnia warstwa w tej części obrazka. Tutaj rysujemy elementy, które pozwalają zwizualizować wyniki naszych badań analitycznych. Tego typu narzędzi jest bardzo wiele. Ale generalnie możemy je sklasyfikować na przykład w ten sposób:

  • wizualizacja samoobsługowa – zależy nam na tym, aby dostarczyć narzędzie łatwe w obsłudze, z przyjemnym interfejsem dla użytkownika biznesowego. Użytkownik ten będzie mógł samodzielnie tworzyć raporty oraz korzystać z paneli informacyjnych.
  • wizualizacja wbudowana – chcemy, aby nasz silnik wizualizacji został wbudowany wewnątrz aplikacji biznesowej. Celem jest dostarczenie narzędzia, z którego będzie można korzystać bez konieczności wychodzenia z tej aplikacji (np. wizualizacja realizowana wewnątrz Salesforce’a).
  • wizualizacja własna (custom) – dostarczamy dowolnych (własnych i „customizowanych”) paneli informacyjnych oraz raportów w odpowiedzi na każde zapotrzebowanie użytkownika.
 

architektura big data dla IoT slajd6

 

Przykładowe narzędzia do wykorzystania w tym miejscu: Pentaho, Tableau, QlickView.

 
Orkiestracja.

Chyba najważniejsza warstwa, od której często zależy powodzenie całego projektu.

 

architektura big data dla IoT slajd7

 

Oprócz orkiestracji oraz zarządzania danymi i procesami, dostarczamy tutaj również funkcję integracji danych. Dlaczego warstwa ta jest w środowiskach big data tak istotna? Oto kilka faktów:

Aż 70% projektów big data kończy się pilotem i eksperymentami. Nie wychodzą one poza ten etap i nie są wdrażane na produkcji (Gartner 2017).

W 2018 70% wdrożeń Hadoopa nie spełni pokładanych w nich celów dot. oszczędności kosztów oraz generowania większego przychodu dla firmy. Powodem są wyzwania związane z umiejętnościami oraz poziomem skomplikowania integracji danych i procesów (Gartner 2017).

Analitycy danych i mistrzowie danych (data scientist), spędzają większość swojego czasu (nawet do 80%) na przygotowywaniu danych (Gartner 2016). Uważam, że jest to zadanie dla inżynierów danych (data engineer) i osoby, które pracują na powyższych stanowiskach nie powinny zajmować się tego typu pracą, ponieważ jest to ogromne marnotrawstwo „zasobów” firmy. Ich rolą jest modelowanie i udoskonalanie algorytmów i predykcji.

 

A zupełnie przy okazji i na marginesie. Na wypadek, gdybyś wcześniej nie widział tej definicji. Oto jaki zakres wiedzy obejmuje nauka o danych (data science) oraz jakie umiejętności powinien posiadać mistrz danych (data scientist).

 

data science

 

Ale wróćmy do tematu. Skoro aż tyle projektów big data kończy się niepowodzeniem (brakiem implementacji na produkcji), to może istnieje jakieś zestawienie „złych praktyk”, które mógłby nas ustrzec przed potencjalną porażką takiego projektu. Ja natrafiłem na taką listę:

  • wykonywanie pracy ręcznie,
  • duża zależność od kodowania określonych elementów architektury,
  • wykorzystanie zbyt dużej ilości narzędzi i komponentów (duży poziom skomplikowania),
  • a przez to tworzenie zbyt dużej ilości zależności (jeszcze większy poziom skomplikowania),
  • tworzenie silosów danych,
  • „bezgraniczne” poleganie na umiejętnościach pojedynczych osób.
 

Krótki komentarz do tego ostatniego punktu. Oczywiście, dobrze jest polegać na doświadczeniu i umiejętnościach swoich pracowników.  Ale wyobraź sobie taki scenariusz. Dzisiaj Twój developer buduje (koduje) warstwę orkiestracji danych i procesów w środowisku, w którym korzystasz ze Sparka. Uzależniasz swoje rozwiązanie dość mocno od tego kodu (i człowieka, który go napisał), a pod nim również od samego Sparka. A za rok Spark przestaje być używany i jest zastępowany Flinkiem (i nie jest to przykład wyssany z palca, bo nawet teraz jesteśmy świadkami dokładnie takiej sytuacji ze Stormem, od którego dzisiaj już się pomału odchodzi).  Dużym wyzwaniem podczas budowania architektury w środowisku big data jest bardzo duża zmienność w ekosystemie istniejących tam narzędzi (zdecydowanie większa niż w tradycyjnych środowiskach aplikacyjnych). I tę zmienność należy moim zdaniem uwzględnić w swoim projekcie po stronie ryzyka i starać się to ryzyko mitygować dostępnymi sposobami.

A teraz wyobraźmy sobie sytuację, w której warstwę orkiestrującą budujesz bez konieczności jakiegokolwiek kodowania. Procesy, przepływ danych oraz ich transformacje kontrolujesz, wykorzystując do tego oprogramowanie, w którym workflow budowany jest z kolejnych modułów metodą "drag-and-drop". W każdej chwili możesz wymienić jakiś „przestarzały” komponent na inny (pod warunkiem, że jest wspierany przez oprogramowanie orkiestrujące), bez konieczności przepisywania kodu.

Gdybyśmy taką warstwę orkiestrującą i wszystkie inne warstwy, które do tej pory narysowaliśmy, chcieli przedstawić w postaci ogólnego schematu architektury, to powstałoby nam „coś”, co coraz częściej określane jest mianem Big Data Fabric.

 

big data fabric

 

Warstwa Global Data Fabric orkiestruje przepływem i transformacją danych. A ponadto łączy ze sobą w „jedną sieć” wszystkie komponenty przechowywania danych. W ten sposób pozbywamy się silosów danych. Z kolei warstwa, która kontroluje procesy pozwala na zautomatyzowanie poszczególnych kroków.

A gdyby tak obydwie te warstwy mogły być zbudowane w oparciu o to samo oprogramowanie? Idealnie! Pytanie tylko, czy w ogóle taki system istnieje? Ano istnieje. Ja wiem o co najmniej jednym takim rozwiązaniu. Daj proszę znać w komentarzach, jeżeli znasz oprogramowanie, które może pełnić tę rolę.

 
Operational Technology (OT).

Do tego miejsca narysowaliśmy typowy ekosystem środowiska analitycznego big data dla aplikacji IT. Teraz spróbujemy dodać do tego elementy ze świata OT. Pytanie tylko, po co mielibyśmy to robić? Z punktu widzenia narzędzi big data, środowisko OT jest kolejnym źródłem danych. A my chcemy połączyć (zblendować) informacje z aplikacji (IT) oraz informacje z maszyn, urządzeń, czujników (OT) w jednym systemie analitycznym. Po to, aby skorelować ze sobą te informacje i zyskać szerszą perspektywę w analizowaniu tych dwóch środowisk operacyjnych. Dzięki temu nasze aplikacje i assety staną się mądrzejsze, a nasza firma bardziej konkurencyjna i dochodowa. Kropka.

 

architektura big data dla IoT slajd8

 
 

Najpierw warstwa, która reprezentuje nasze rozwiązania brzegowe (edge). Tylko powiedz Ty mi Tomek, co to jest ten „brzeg”. W urządzeniach, które pracują w naszych fabrykach, brzegiem będzie samo urządzenie, np. robot, w którym zbieramy dane telemetryczne z jego czujników. Brzegiem w tym scenariuszu jest również cała fabryka, która agreguje dane z wszystkich robotów i wysyła je dalej do naszego centrum przetwarzania (core). Głównym zadaniem do zrealizowania w tych miejscach jest wyekstraktowanie danych z poszczególnych assetów, które znajdują się wewnątrz naszego rozwiązania brzegowego (fabryka, statek, pociąg, auto, robot, itp.). Technologie zastosowane do tego celu muszą mieć co najmniej trzy zdolności:

 

SDK (Software Development Kit) – biblioteki, które można wykorzystać do łatwego tworzenia interfejsów API, konektorów lub agentów, za pomocą których „wyciągniemy” dane z naszego asseta i dostarczymy je ze świata OT do świata IT.

Przykładowe narzędzia do wykorzystania w tym miejscu: Java, Python.

 

Brama ECU / OBU (Electronic Control Unit / OnBoard Unit) – są to zazwyczaj karty z takimi procesorami jak na przykład Arduino, czy Rasberry Pi. To tutaj tworzona jest pierwsza warstwa bardzo szybkiej analityki dla rozwiązania brzegowego. Ten element architektury powinien mieć zdolności podejmowania decyzji na podstawie przeprowadzonej analityki w czasie rzeczywistym. W tym miejscu następuje również pierwsza konsolidacja i agregacja danych telemetrycznych. I dopiero tak skonsolidowana paczka jest wysyłana do dalszej analizy do komponentów, które znajdują się w centrum przetwarzania (o nich za chwilę). Brama ECU/OBU jest często zainstalowana wewnątrz assetu, ale w zależności od skali środowiska, bram tych możemy potrzebować więcej. Przed wysłaniem paczki danych do centrum przetwarzania wykonujemy po drodze więcej agregacji (np. z wielu wbudowanych bram OBU do lokalnej bramy ECU). Budujemy w ten sposób architekturę brzegową, która składa się z wielu warstw.

Przykładowe narzędzia do wykorzystania w tym miejscu: Lumada, Cisco.

 

Producent zdarzeń – stąd wysyłamy zagregowane dane do centrum przetwarzania, do brokera zdarzeń (naszej kolejki asynchronicznej, opisanej już wcześniej). W przypadku aplikacji IT przykładem takiego brokera była Kafka. W świecie OT będziemy używać protokołów MQTT lub AMQP, które stają się standardem w tym zakresie.

Przykładowe narzędzia do wykorzystania w tym miejscu: MQTT producer, AMQP producer.

 

I na koniec pozostały nam jeszcze do narysowania elementy OT, które zainstalujemy w centrum przetwarzania danych (OT w centrali oraz OT zarządzanie).

 

architektura big data dla IoT slajd9

 

Tutaj potrzebujemy takich komponentów architektury:

 

Rejestr assetów – baza danych ze wszystkimi zarejestrowanymi assetami, które są wykorzystywane w produkcji (te, którymi zarządzamy i które monitorujemy).

Przykładowe narzędzia do wykorzystania w tym miejscu: Lumada, Pentaho.

 

Avatary – wirtualna reprezentacja assetu. Tutaj przechowujemy informacje o samym assecie, jego właściwości oraz jego aktualny stan.

Przykładowe narzędzia do wykorzystania w tym miejscu: Lumada, Pentaho.

 

Konsument zdarzeń – dane, które przychodzą z rozwiązań brzegowych do brokera zdarzeń są konsumowane właśnie tutaj. Ten element aktualizuje dane w avatarze.

Przykładowe narzędzia do wykorzystania w tym miejscu: MQTT consumer, AMQP consumer.

 

Interfejs do zarządzania flotą assetów – pojedynczy punkt do monitorowania, zarządzania i utrzymania całej floty naszych assetów.

Przykładowe narzędzia do wykorzystania w tym miejscu: Lumada, Pentaho.

 

Ufff! Nareszcie. Mamy pełen obraz. Kompletny system analityczny big data z uwzględnieniem źródeł operacyjnych zarówno IT jak i OT (IoT).

Dla każdego elementu architektury starałem się podać przykłady narzędzi, jakie można wykorzystać do zrealizowania danej funkcji. Podane przeze mnie rozwiązania nie stanowią oczywiście pełnej listy. Jeżeli znasz inne i chciałbyś się podzielić z nami tą wiedzą, to napisz proszę o tym w komentarzach pod artykułem.

Dziękuję, że wytrwałeś aż do tego miejsca .

 

Zostaw Komentarz