Architektura danych big data została zaprojektowana do obsługi wprowadzania, przetwarzania i analizy danych, które są zbyt duże lub zbyt złożone dla tradycyjnych systemów baz danych. Próg, który muszą osiągnąć organizacje, aby wejść do obszaru danych big data, różni się w zależności od możliwości użytkowników i ich narzędzi. W niektórych przypadkach może oznaczać setki gigabajtów danych, a w innych setki terabajtów. Ponieważ narzędzia do pracy z dużymi zestawami danych są zaawansowane, tak samo znaczenie danych big data. Coraz bardziej określenie to odnosi się do wartości, które można wyodrębnić z zestawów danych za pośrednictwem zaawansowanych metod analizy, a nie wyłącznie rozmiaru danych, mimo że w takich przypadkach jest on zwykle dość duży.
W ciągu lat środowisko danych uległo zmianie. Zmieniły się możliwości i oczekiwania względem operacji wykonywanych na danych. Koszty związane z magazynowaniem znacznie spadły, ale istnieje teraz zdecydowanie więcej sposobów zbierania danych. Niektóre dane docierają bardzo szybko i stale wymagane jest ich zbieranie i obserwowanie. Inne dane docierają wolniej, ale w bardzo dużych fragmentach, często w postaci dekad danych historycznych. Mogą pojawić się skomplikowane problemy analityczne lub wymagające użycia uczenia maszynowego. To właśnie tego typu wyzwania pomagają pokonywać architektury danych big data.
Rozwiązania do obsługi danych big data obejmują na ogół co najmniej jeden z następujących typów obciążenia:
- Przetwarzanie wsadowe źródeł danych big data w stanie spoczynku.
- Przetwarzanie w czasie rzeczywistym danych big data w ruchu.
- Interakcyjna eksploracja danych big data.
- Analiza predykcyjna i uczenie maszynowe.
Rozważ użycie architektur danych big data, gdy potrzebujesz:
- Przechowywać i przetwarzać dane w ilościach zbyt dużych dla tradycyjnych baz danych.
- Przekształcać dane nieustrukturyzowane na potrzeby analizy i raportowania.
- Przechwytywać, przetwarzać i analizować niepowiązane strumienie danych w czasie rzeczywistym lub z niewielkim opóźnieniem.
Składniki architektury danych big data
Na poniższym diagramie przedstawiono składniki logiczne, które są zgodne z architekturą danych big data. Poszczególne rozwiązania mogą nie zawierać wszystkich elementów znajdujących się na tym diagramie.
Większość architektur big data zawiera niektóre lub wszystkie z następujących składników:
Źródła danych. Wszystkie rozwiązania typu big data powstają w oparciu o co najmniej jedno źródło danych. Oto kilka przykładów:
- Magazyny danych aplikacji, takie jak relacyjne bazy danych.
- Pliki statyczne tworzone przez aplikacje, takie jak pliki dzienników serwerów internetowych.
- Źródła danych czasu rzeczywistego, np. urządzenia IoT.
Magazyn danych. Dane do operacji przetwarzania wsadowego są na ogół przechowywane w rozproszonym magazynie plików, który może pomieścić duże ilości dużych plików w różnych formatach. Taki rodzaj magazynu jest często określany jako data lake. Opcje implementacji tego magazynu obejmują usługę Azure Data Lake Store, kontenery obiektów blob w usłudze Azure Storage lub usługę One Lake w usłudze Microsoft Fabric.
Przetwarzanie wsadowe. Ponieważ zestawy danych są tak duże, rozwiązanie danych big data często musi przetwarzać pliki danych przy użyciu długotrwałych zadań wsadowych do filtrowania, agregowania i przygotowywania danych do analizy. Na ogół zadania te obejmują odczytywanie plików źródłowych, przetwarzanie ich i zapisywanie danych wyjściowych do nowych plików. Dostępne są następujące opcje:
- Uruchamianie zadań U-SQL w usłudze Azure Data Lake Analytics
- Używanie zadań Hive, Pig lub niestandardowych zadań mapowania/redukcji w klastrze hadoop usługi HDInsight
- Używanie programów Java, Scala lub Python w klastrze SPARK usługi HDInsight
- Używanie języka Python, Scala lub SQL w notesach usługi Azure Databricks
- Używanie języka Python, Scala lub SQL w notesach usługi Microsoft Fabric
Wprowadzanie komunikatów w czasie rzeczywistym. Jeśli rozwiązanie zawiera źródła danych czasu rzeczywistego, architektura musi obejmować sposób na przechwytywanie i przechowywanie komunikatów w czasie rzeczywistym do przetwarzania strumieniowego. Może to być zwykły magazyn danych, gdzie przychodzące komunikaty są umieszczane w folderze w celu przetworzenia. Jednak wiele rozwiązań wymaga, aby magazyn wprowadzający komunikaty pełnił rolę bufora dla komunikatów, a także oferował zwiększanie w poziomie skali przetwarzania, niezawodne dostarczanie i inne elementy semantyki kolejkowania komunikatów. Ta część architektury przesyłania strumieniowego jest często określana jako buforowanie strumienia. Opcje obejmują usługi Azure Event Hubs, Azure IoT Hub i Kafka.
Przetwarzanie strumienia. Po przechwyceniu komunikatów w czasie rzeczywistym rozwiązanie musi je przetworzyć, filtrując, agregując i przygotowując w inny sposób dane do analizy. Przetworzony strumień danych zostaje następnie zapisany do ujścia danych wyjściowych.
- Usługa Azure Stream Analytics to usługa zarządzanego przetwarzania strumienia w oparciu o stale działające zapytania SQL pracujące na niepowiązanych strumieniach.
- Możesz również użyć technologii przesyłania strumieniowego Apache typu open source, takich jak przesyłanie strumieniowe spark w klastrze usługi HDInsight lub usłudze Azure Databricks
- Azure Functions to bezserwerowa usługa obliczeniowa, która umożliwia uruchamianie kodu opartego na zdarzeniach, co jest idealnym rozwiązaniem w przypadku zadań przetwarzania uproszczonego strumienia
- Usługa Microsoft Fabric obsługuje przetwarzanie danych w czasie rzeczywistym za pomocą strumieni zdarzeń i przetwarzania platformy Spark.
Uczenie maszynowe. Odczytywanie przygotowanych danych do analizy (z przetwarzania wsadowego lub strumieniowego) służy algorytmy uczenia maszynowego do tworzenia modeli, które przewidują wyniki lub klasyfikują dane. Modele te można wytrenować na dużych zestawach danych, a wynikowe modele są używane do analizowania nowych danych i przewidywania. Można to zrobić przy użyciu usługi Azure Machine Learning, która udostępnia narzędzia do tworzenia, trenowania i wdrażania modeli. Alternatywnie możesz użyć wstępnie utworzonych interfejsów API do typowych zadań uczenia maszynowego, takich jak przetwarzanie obrazów, mowa, język i podejmowanie decyzji oferowanych przez usługi Azure AI Services.
Magazyny danych analitycznych. Wiele rozwiązań do obsługi danych big data przygotowuje dane do analizy, a następnie przekazuje przetworzone dane w formacie ustrukturyzowanym, który może być odpytywany za pomocą narzędzi analitycznych. Magazynem danych analitycznych używanym do obsługi tych zapytań może być relacyjny magazyn danych w architekturze Kimballa, stosowany w tradycyjnych rozwiązaniach z zakresu analizy biznesowej (BI). Dane mogą być także przedstawiane za pomocą zapewniającej niskie opóźnienia technologii NoSQL, np. HBase, lub interakcyjnej bazy danych Hive zapewniającej abstrakcję metadanych nad plikami danych w rozproszonym magazynie danych.
- Usługa Azure Synapse Analytics oferuje zarządzaną usługę magazynowania danych na dużą skalę w oparciu o chmurę.
- Usługa HDInsight obsługuje interakcyjne klastry Hive, HBase i Spark SQL, które można także wykorzystać do obsługi danych do analizy.
- Usługa Microsoft Fabric udostępnia różne magazyny danych, w tym bazy danych SQL, magazyny danych, magazyny typu lakehouse i magazyny zdarzeń, które mogą służyć do obsługi danych do analizy.
- Platforma Azure oferuje inne magazyny danych analitycznych, takie jak Azure Databricks, Azure Data Explorer, Azure SQL Database i Azure Cosmos DB.
Analiza i raportowanie. Celem większości rozwiązań typu big data jest udostępnienie szczegółowych informacji na temat danych przy użyciu analizy i raportowania. Aby dać użytkownikom możliwość analizowania danych, architektura może obejmować warstwę modelowania danych, np. wielowymiarowy moduł OLAP lub model danych tabelarycznych w usłudze Azure Analysis Services. Może również obsługiwać samoobsługową analizę biznesową, korzystając z technologii wizualizacji i modelowania w usłudze Microsoft Power BI lub Microsoft Excel. Analiza i raportowanie może również przyjmować formę interakcyjnej eksploracji danych przez analityków danych i naukowców pracujących z danymi. W przypadku tych scenariuszy wiele usług platformy Azure obsługuje notesy analityczne, takie jak Jupyter, umożliwiając tym użytkownikom korzystanie z istniejących umiejętności w języku Python lub Microsoft R. W przypadku eksploracji danych na dużą skalę można użyć programu Microsoft R Server, autonomicznego lub platformy Spark. Ponadto usługa Microsoft Fabric oferuje możliwość edytowania modeli danych bezpośrednio w usłudze, co zwiększa elastyczność i wydajność zadania modelowania i analizy danych.
Aranżacja. Większość rozwiązań typu big data składa się z powtarzanych operacji przetwarzania danych, zhermetyzowanych w ramach przepływów pracy, które przetwarzają dane źródłowe, przenoszą dane między różnymi źródłami i ujściami, ładują przetworzone dane do magazynu danych analitycznych lub wypychają wyniki bezpośrednio do raportu lub pulpitu nawigacyjnego. Aby zautomatyzować te przepływy pracy, możesz użyć technologii orkiestracji, takiej jak Azure Data Factory, Microsoft Fabric lub Apache Oozie i Sqoop.
Architektura lambda
Podczas pracy z bardzo dużymi zestawami danych uruchomienie żądań potrzebnych klientom może zająć dużo czasu. Te zapytania nie mogą być wykonywane w czasie rzeczywistym i często wymagają algorytmów, takich jak MapReduce, które działają równolegle w ramach całego zestawu danych. Wyniki są następnie przechowywane oddzielnie od danych pierwotnych i używane do wykonywania zapytań.
Jedną z wad tego podejścia jest wprowadzenie opóźnienia — jeśli przetwarzanie trwa kilka godzin, zapytanie może zwrócić wyniki, które mają kilka godzin. Idealnym rozwiązaniem jest uzyskanie niektórych wyników w czasie rzeczywistym (być może z pewną utratą dokładności) i połączenie tych wyników z wynikami z analiz wsadowych.
Architektura lambda, która została po raz pierwszy zaproponowana przez Nathana Marza, rozwiązuje ten problem, tworząc dwie ścieżki przepływu danych. Wszystkie dane przesyłane do systemu przechodzą przez te dwie ścieżki:
W warstwie wsadowej (ścieżka nieaktywna) wszystkie dane przychodzące są przechowywane w postaci pierwotnej i wykonywane jest przetwarzanie wsadowe na danych. Wynik tego przetwarzania jest przechowywany jako widok wsadowy.
W warstwie szybkiej (ścieżka aktywna) ma miejsce analizowanie danych w czasie rzeczywistym. Ta warstwa jest przeznaczona na potrzeby małych opóźnień kosztem dokładności.
Warstwa wsadowa trafia do warstwy obsługi, w której indeksowany jest widok wsadowy na potrzeby efektywnego wykonywania zapytań. Warstwa szybka aktualizuje warstwę obsługi za pomocą aktualizacji przyrostowych opartych na najnowszych danych.
Dane trafiające do ścieżki aktywnej są ograniczane przez wymagania dotyczące opóźnień nakładane przez warstwę szybką, dzięki czemu mogą być przetwarzane tak szybko, jak to możliwe. Często wymaga to pewnej utraty dokładności na rzecz jak najszybszego uzyskania danych. Rozważmy na przykład scenariusz IoT, gdzie duża liczba czujników temperatury wysyła dane telemetryczne. Warstwa szybka może służyć do przetwarzania przesuwającego się okna czasowego danych przychodzących.
Dane trafiające do ścieżki nieaktywnej nie podlegają natomiast tym samym wymaganiom dotyczącym małych opóźnień. Pozwala to zapewnić wysoką dokładność obliczeń w ramach dużych zestawów danych, co może być bardzo czasochłonne.
Ostatecznie ścieżka aktywna i nieaktywna zbiegają się w aplikacji klienta do analizy. Jeśli klient wymaga wyświetlania aktualnych, ale potencjalnie mniej dokładnych danych w czasie rzeczywistym, pobierane będą wyniki ze ścieżki aktywnej. W przeciwnym razie wybrane zostaną wyniki ze ścieżki nieaktywnej w celu wyświetlenia mniej aktualnych, ale bardziej dokładnych danych. Innymi słowy, ścieżka aktywna zawiera dane dla stosunkowo małego okna czasowego, po czym wyniki mogą zostać zaktualizowane za pomocą dokładniejszych danych ze ścieżki nieaktywnej.
Nieprzetworzone dane przechowywane w warstwie wsadowej nie mogą być modyfikowane. Dane przychodzące są zawsze dodawane do istniejących danych, a wcześniej pozyskane dane nigdy nie są zastępowane. Wszelkie zmiany na wartość określonego elementu danych są przechowywane jako nowy rekord zdarzenia oznaczony sygnaturą czasową. Umożliwia to przeprowadzanie ponownego obliczania w dowolnym momencie w czasie w ramach historii zebranych danych. Możliwość ponownego obliczenia widoku wsadowego na podstawie oryginalnych danych pierwotnych jest ważna, ponieważ umożliwia tworzenie nowych widoków w miarę rozwoju systemu.
Architektura kappa
Wadą architektury lambda jest jej złożoność. Logika przetwarzania jest wyświetlana w dwóch różnych miejscach — zimnych i gorących ścieżkach — przy użyciu różnych struktur. Prowadzi to do duplikowania logiki obliczeń i złożoności zarządzania architektury dla obu ścieżek.
Architekturę kappa jako alternatywę do architektury lambda zaproponował Jay Kreps. Ma ona te same podstawowe cele, co architektura lambda, ale z jedną istotną różnicą: wszystkie dane przepływają przez pojedynczą ścieżkę przy użyciu systemu przetwarzania strumienia.
Istnieją pewne podobieństwa do warstwy wsadowej architektury lambda: dane zdarzenia są niezmienne i wszystkie są zbierane, zamiast podzestawu. Dane są pozyskiwane jako strumień zdarzeń do rozproszonego, odpornego na uszkodzenia ujednoliconego dziennika. Te zdarzenia są uporządkowane i ich bieżący stan jest zmieniany tylko przez dołączanie nowego zdarzenia. Podobnie jak w przypadku warstwy szybkiej architektury lambda wszystkie operacje przetwarzania zdarzeń są wykonywane względem strumienia wejściowego i utrwalane jako widok w czasie rzeczywistym.
Jeśli chcesz ponownie obliczyć cały zestaw danych (co jest równoznaczne z warstwą wsadową w architekturze lambda), wystarczy po prostu odtworzyć strumień, zwykle korzystając z równoległości do przeprowadzania obliczeń w odpowiednim czasie.
Architektura Lakehouse
Usługa Data Lake to scentralizowane repozytorium danych, które umożliwia przechowywanie wszystkich struktur (takich jak tabele baz danych), częściowo ustrukturyzowanych danych (takich jak pliki XML) i danych bez struktury (takich jak obrazy i pliki audio) w nieprzetworzonym, oryginalnym formacie, bez konieczności używania wstępnie zdefiniowanego schematu. Usługa Data Lake została zaprojektowana pod kątem obsługi dużych ilości danych, dzięki czemu jest odpowiednia do przetwarzania i analizy danych big data. Korzystając z rozwiązań magazynu o niskich kosztach, magazyny typu data lake zapewniają ekonomiczny sposób przechowywania dużych ilości danych.
Magazyn danych to scentralizowane repozytorium, które przechowuje dane ustrukturyzowane i częściowo ustrukturyzowane na potrzeby raportowania, analizy i analizy biznesowej. Magazyny danych są niezbędne dla organizacji do podejmowania świadomych decyzji przez zapewnienie spójnego i kompleksowego wglądu w dane.
Architektura Lakehouse łączy najlepsze elementy magazynów danych i magazynów danych. Wzorzec ma na celu zapewnienie ujednoliconej platformy, która obsługuje zarówno dane ustrukturyzowane, jak i nieustrukturyzowane, umożliwiając wydajne zarządzanie danymi i analizę. Te systemy zwykle wykorzystują magazyn w chmurze o niskich kosztach w otwartych formatach, takich jak Parquet lub ORC, do przechowywania nieprzetworzonych i przetworzonych danych.
Oto niektóre typowe przypadki użycia architektury lakehouse:
- Ujednolicona analiza: idealne rozwiązanie dla organizacji wymagających jednej platformy do analizy danych historycznych i w czasie rzeczywistym.
- Uczenie maszynowe: obsługuje zaawansowane obciążenia analizy i uczenia maszynowego ze zintegrowanym zarządzaniem danymi.
- Nadzór nad danymi: zapewnia zgodność i jakość danych w dużych zestawach danych.
Internet rzeczy (IoT)
Z praktycznego punktu widzenia Internet rzeczy (IoT) reprezentuje dowolne urządzenie połączone z Internetem. Obejmuje to Twój komputer, telefon komórkowy, inteligentne zegarki, inteligentne termostaty, inteligentne lodówki, połączone samochody, implanty służące do monitorowania pracy serca i dowolne inne urządzenia łączące się z Internetem oraz wysyłające lub odbierające dane. Liczba połączonych urządzeń rośnie z dnia na dzień, a wraz z nią ilość danych zbieranych przez te urządzenia. Często dane są zbierane w środowiskach bardzo ograniczonych, czasami z dużym opóźnieniem. W innych przypadkach dane są wysyłane ze środowisk z niskimi opóźnieniami przez tysiące lub miliony urządzeń, co wymaga możliwości szybkiego pozyskiwania danych i ich odpowiedniego przetwarzania. W związku z tym do obsługi tych ograniczeń i unikalnych wymagań konieczne jest odpowiednie planowanie.
Architektury sterowane zdarzeniami są kluczowym elementem rozwiązań IoT. Na poniższym diagramie przedstawiono przykładową architekturę logiczną dla IoT. Diagram kładzie nacisk na składniki strumienia zdarzeń architektury.
Brama w chmurze pozyskuje zdarzenia urządzenia na granicy chmury, używając niezawodnego systemu obsługi komunikatów o niskich opóźnieniach.
Urządzenia mogą wysyłać zdarzenia bezpośrednio do bramy w chmurze lub za pośrednictwem bramy działającej w terenie. Brama działająca w terenie to wyspecjalizowane urządzenie lub oprogramowanie, zwykle kolokowane z urządzeniami, które odbiera zdarzenia i przekazuje je do bramy w chmurze. Brama pola może również wstępnie przetworzyć nieprzetworzone zdarzenia urządzenia, wykonując funkcje filtrowania, agregacji lub przekształcania protokołu.
Po pozyskaniu zdarzenia przechodzą przez co najmniej jeden procesor strumieni, który może kierować dane (na przykład do magazynu) lub wykonywać analizy i inne procesy.
Poniżej przedstawiono niektóre typowe typy przetwarzania. (Ta lista na pewno nie jest wyczerpująca).
Zapisywanie danych zdarzeń do zimnego magazynu w celu zarchiwizowania lub przeprowadzenia analizy partii.
Analiza ścieżki aktywnej badająca strumień zdarzeń (prawie) w czasie rzeczywistym w celu wykrycia anomalii, rozpoznania wzorców na przestrzeni przedziałów czasu lub wyzwolenia alertów po wystąpieniu w strumieniu określonego warunku.
Obsługa specjalnych typów komunikatów nietelemetrycznych z urządzeń, takich jak powiadomienia i alarmy.
Uczenie maszynowe.
W wyszarzonych polach przedstawiono składniki systemu IoT, które nie są bezpośrednio związane z przesyłaniem strumieniowym zdarzeń, ale zostały uwzględnione, aby informacje były kompletne.
Rejestr urządzenia to baza danych aprowizowanych urządzeń, w tym identyfikatorów urządzeń i zwykle metadanych urządzeń, takich jak lokalizacja.
Aprowizujący interfejs API to wspólny interfejs zewnętrzny aprowizujący i rejestrujący nowe urządzenia.
Niektóre rozwiązania IoT umożliwiają wysyłanie komunikatów poleceń i komunikatów sterujących do urządzeń.
Następne kroki
Zapoznaj się z następującymi odpowiednimi usługami platformy Azure:
- Azure IoT Hub
- Azure Event Hubs
- Azure Stream Analytics
- Azure Data Explorer
- Microsoft Fabric
- Azure Databricks