Charakterystyka architektury danych strumieniowych (Streaming Data Architecture) obejmuje dużą objętość (high volume) ciągle generowanych danych z dużą prędkością (high velocity). Krótko mówiąc, pewne zdarzenia generują dane w sposób ciągły i tworzą one strumień danych (data stream). Najprostsze przykłady takich zdarzeń to czujnik urządzenia IoT mierzący ciśnienie lub osoba klikająca link na stronie internetowej lub w aplikacji mobilnej. Dane strumieniowe (streaming data) mogą mieć formę nieustrukturyzowaną lub półustrukturyzowaną, zazwyczaj jako pary klucz-wartość w formacie JSON lub XML.
Chociaż technologie strumieniowe nie są nowe, w ostatnich latach szybko się rozwijają. Dla tych, którzy szukają jasności w kwestii obsługi strumieniowania danych (data streaming), istnieje kilka aspektów, które należy wziąć pod uwagę i ocenić: Co oznacza architektura danych strumieniowych (Streaming Data Architecture)? Czym różni się przetwarzanie strumieniowe (stream processing) od przetwarzania w czasie rzeczywistym (real-time)? Jak powinna być zaprojektowana, aby obsługiwać strumieniowanie danych (data streaming)? Jakie mogą być komponenty architektury danych strumieniowych (Streaming Data Architecture)? Jakie są korzyści z zastosowania architektury danych strumieniowych (Streaming Data Architecture)?
Streaming Data jest częścią naszych usług Data Science – dowiedz się, jak możemy pomóc Twojej firmie.
Co to jest Architektura Danych Strumieniowych (Streaming Data Architecture)?
Architektura Danych Strumieniowych (Streaming Data Architecture) składa się z komponentów oprogramowania, zbudowanych i połączonych w celu pozyskiwania (ingest) i przetwarzania danych strumieniowych (streaming data) z różnych źródeł. Architektura Danych Strumieniowych (Streaming Data Architecture) przetwarza dane zaraz po ich zebraniu. Przetwarzanie obejmuje alokację do wyznaczonego magazynu (storage) i może obejmować wyzwalanie dalszych kroków przetwarzania, takich jak analityka, dalsza manipulacja danymi lub pewnego rodzaju przetwarzanie w czasie rzeczywistym (real-time processing).
Istnieje kilka podejść do przetwarzania danych. Pierwszym, „staromodnym”, jest przetwarzanie wsadowe (batch processing), czyli przetwarzanie dużej objętości danych naraz. Tutaj skupimy się jednak na różnicy między przetwarzaniem strumieniowym (stream processing) a operacjami w czasie rzeczywistym (real-time operations). Najprostsze wyjaśnienie jest takie, że operacje w czasie rzeczywistym (real-time operations) dotyczą reakcji na dane, podczas gdy przetwarzanie strumieniowe (stream processing) dotyczy działań podejmowanych na danych.
Rozwiązania w czasie rzeczywistym (real-time solutions) gwarantują wykonanie danych w krótkim czasie po ich zebraniu. Reakcja na dane jest niemal natychmiastowa – przetwarzanie może zająć minuty, sekundy, a nawet milisekundy, w zależności od wymagań biznesowych i zastosowanego rozwiązania. Przykładem zastosowania operacji w czasie rzeczywistym (real-time operation) mogą być operacje kupna/sprzedaży na giełdzie, kiedy notowanie musi być dostarczone zaraz po złożeniu zlecenia.
W przeciwieństwie do tego, przetwarzanie w architekturze danych strumieniowych (streaming data architecture) to ciągłe obliczenia, które zachodzą, gdy dane przepływają przez system. Nie ma obowiązkowego ograniczenia czasowego poza mocą komponentów, zastosowanym rozwiązaniem technologicznym i tolerancją biznesową na opóźnienia (latency). Oznacza to, że nie ma ostatecznego terminu dla wyniku lub reakcji systemu, gdy dane nadchodzą, więc dane są przetwarzane na bieżąco. Sukces tej architektury zależy od dwóch rzeczy: w dłuższej perspektywie czasowej wskaźniki wyjściowe (output rates) muszą być co najmniej równe wskaźnikom wejściowym (input rates) i musi mieć wystarczającą ilość pamięci do przechowywania w kolejce danych wejściowych wymaganych do obliczeń. Przetwarzanie strumieniowe (stream processing) jest korzystne w przypadku częstych zdarzeń do śledzenia lub jeśli zdarzenia muszą być wykrywane od razu i szybko reagować, np. w przypadku cyberbezpieczeństwa lub wykrywania oszustw (fraud detection).
Przetwarzanie w architekturze danych strumieniowych (Streaming Data Architecture) jest zazwyczaj złożonym wyzwaniem. Aby wykorzystać tę technologię na swoją korzyść, będziesz potrzebować rozwiązania składającego się z wielu komponentów. Podczas projektowania architektury danych strumieniowych (striming data architecture) należy również wziąć pod uwagę charakterystykę strumieni danych (data streams). Zazwyczaj generują one ogromną objętość danych i wymagają dalszego wstępnego przetwarzania, ekstrakcji i transformacji, aby stać się bardziej użytecznymi.
Jakie mogą być komponenty i projekt Architektury Danych Strumieniowych (Streaming Data Architecture)?
Niezależnie od używanej platformy, architektura danych strumieniowych (streaming data architecture) musi zawierać następujące kluczowe grupy komponentów:
1. Brokerzy wiadomości (Message Brokers) w Architekturze Danych Strumieniowych (Streaming Data Architecture)
Grupa komponentów, która pobiera dane ze źródła, przekształca je w standardowy format wiadomości i strumieniuje (streaming data architecture) je na bieżąco, aby udostępnić je do użytku, co oznacza, że inne narzędzia mogą nasłuchiwać i konsumować wiadomości przekazywane przez brokerów. Popularne narzędzia do przetwarzania strumieniowego (stream processing tools) to oprogramowanie open source Apache Kafka lub komponenty PaaS (Platform as a Service), takie jak Azure Event Hub, Azure IoT Hub, GCP Cloud Pub/Sub lub GCP Confluent Cloud, która jest natywną dla chmury platformą strumieniowania zdarzeń (event streaming platform) opartą na Apache Kafka. Microsoft Azure obsługuje również Kafka jako typ klastra HDInsight, więc w ten sposób może być używany jako PaaS.
Oprócz wymienionych powyżej przykładów dostępne są również inne narzędzia, takie jak Solace PubSub+ lub Mulesoft Anypoint, które są zazwyczaj zbudowane na bazie komponentów open source, aby zapewnić kompletne, wielochmurowe środowisko integracyjne (multi-cloud integration environment), obsługujące między innymi dane strumieniowe (streaming data) i pozwalające na usunięcie narzutu związanego z konfiguracją i utrzymaniem platformy.
2. Narzędzia do przetwarzania (Processing Tools)
Wyjściowe strumienie danych (output data streams) z opisanego powyżej brokera wiadomości (message broker) lub procesora strumieniowego (stream processor) muszą być przekształcone i ustrukturyzowane, aby mogły być dalej analizowane za pomocą narzędzi analitycznych (analytics tools). Wynikiem takiej analizy mogą być pewne działania, alerty, dynamiczne pulpity nawigacyjne (dynamic dashboards) lub nawet nowe strumienie danych (data streams). Jeśli chodzi o frameworki open source, które koncentrują się na przetwarzaniu architektury danych strumieniowych (streaming data architecture), najbardziej popularne i powszechnie znane to Apache Storm, Apache Spark Streaming i Apache Flink. Microsoft Azure obsługuje wdrażanie Apache Spark i Apache Storm jako typ klastra HDInsight. Oprócz tego Azure zapewnia własne rozwiązanie o nazwie Stream Analytics, które jest czystym komponentem PaaS Azure, działającym jako silnik analityki w czasie rzeczywistym (real-time analytics) i złożonego przetwarzania zdarzeń (complex event-processing engine), który jest przeznaczony do analizowania i przetwarzania dużych ilości szybko strumieniowanych danych (fast streaming data) z wielu źródeł jednocześnie. Tak więc, w pewnym stopniu, wpisuje się zarówno w analitykę danych, jak i przetwarzanie w czasie rzeczywistym (real-time processing).
W przypadku GCP kluczowymi platformami do przetwarzania strumieniowanych danych (streamed data processing) są Dataproc, który obejmuje Spark i Flink, oraz oddzielne, własne rozwiązanie, czyli Dataflow.
3. Narzędzia do analizy danych (Data Analytics Tools)
Gdy architektura danych strumieniowych (streaming data architecture) jest przygotowana do konsumpcji przez procesor strumieniowy (stream processor) i narzędzie do przetwarzania (processing tool), musi zostać przeanalizowana, aby zapewnić wartość. Istnieje wiele różnych podejść do analizy danych strumieniowych (streaming data analytics), ale skupmy się na najbardziej znanych.
- Apache Cassandra to otwarta, rozproszona baza danych NoSQL, która zapewnia niskie opóźnienia (low latency) w obsłudze zdarzeń strumieniowych (streaming events) dla aplikacji. Strumienie Kafka (Kafka streams) mogą być przetwarzane i utrwalane w klastrze Cassandra. Możliwe jest również wdrożenie innej instancji Kafka, która odbiera strumień zmian z Cassandra i udostępnia je innym aplikacjom do podejmowania decyzji w czasie rzeczywistym (real time decision making).
- Innym przykładem jest Elasticsearch, który może odbierać strumieniowane dane (streamed data) bezpośrednio z tematów Kafka (Kafka topics). Dzięki formatowi danych Avro i rejestrowi schematów (schema registry), mapowania Elasticsearch (Elasticsearch mappings) są tworzone automatycznie i można wykonywać szybkie wyszukiwanie tekstowe lub analizę w Elasticsearch.
- Azure zapewnia również CosmosDB z Cassandra API, dzięki czemu możliwości Apache Cassandra są zabezpieczone w tej chmurze. GCP wspiera ten obszar za pomocą Firebase Realtime Database, Firestore, a także BigTable.
4. Magazyn Danych Strumieniowych (Streaming Data Storage)
Koszt przechowywania (storage cost) jest generalnie stosunkowo niski, dlatego organizacje przechowują swoje dane strumieniowe (streaming data). Data lake to najbardziej elastyczna i tania opcja przechowywania danych o zdarzeniach, ale jego prawidłowe skonfigurowanie i utrzymanie jest dość trudne. Może obejmować odpowiednie przetwarzanie danych, partycjonowanie danych i uzupełnianie danymi historycznymi (backfilling), więc ostatecznie utworzenie operacyjnego data lake może stać się wyzwaniem. Wszyscy dostawcy chmury zapewniają odpowiednie komponenty służące jako data lakes. Azure zapewnia Azure Data Lake Store (ADLS), a GCP ma Google Cloud Storage. Inną opcją może być przechowywanie danych w hurtowni danych (data warehouse) lub w trwałym magazynie (persistent storage) wybranych narzędzi, takich jak Kafka, Databricks/Spark, BigQuery
Podsumowując:
Nowoczesny Architektura danych strumieniowych ma pewne istotne korzyści, które należy wziąć pod uwagę przy projektowaniu konkretnych rozwiązań. Gdy jest odpowiednio zaprojektowany, eliminuje potrzebę inżynierii dużych danych, jego wydajność jest wysoka, można go szybko wdrożyć, z wbudowaną wysoką dostępnością i tolerancją na uszkodzenia. Ta architektura jest również elastyczna, aby obsługiwać wiele przypadków użycia, przy niskim całkowitym koszcie posiadania.Aby osiągnąć powyższe, organizacje mogą wybrać rozwiązania pełnowymiarowe lub opracować odpowiednie plany architektury, aby zapewnić szybką i niezawodną dostawę rozwiązań dostosowanych do potrzeb biznesowych.Może to Cię zainteresować:
- Wprowadzenie do wdrażania modelu ML za pomocą silnika Google Kubernetes
- Czym jest bezpieczeństwo cyberdanych?
- Różne rodzaje analiz i jak je wdrożyć
