Architektury dużych zbiorów danych

Architektura danych big data zarządza pozyskiwaniem, przetwarzaniem i analizą danych, które są zbyt duże lub złożone w tradycyjnych systemach baz danych. Próg wprowadzania danych big data różni się między organizacjami, w zależności od ich narzędzi i możliwości użytkownika. Niektóre organizacje zarządzają setkami gigabajtów danych, a inne organizacje zarządzają setkami terabajtów. W miarę rozwoju narzędzi do pracy z dużymi zestawami danych definicja danych big data zmienia się z skupienia się wyłącznie na rozmiarze danych, aby podkreślić wartość pochodzącą z zaawansowanej analizy. Chociaż te typy scenariuszy zwykle mają duże ilości danych.

W ciągu lat środowisko danych uległo zmianie. Zmieniły się możliwości i oczekiwania względem operacji wykonywanych na danych. Koszty magazynowania znacznie spadły, podczas gdy metody zbierania danych nadal się rozszerzają. Niektóre dane docierają w szybkim tempie i wymagają ciągłej zbierania i obserwacji. Inne dane docierają wolniej, ale w dużych fragmentach i często w postaci dziesięcioleci danych historycznych. Może wystąpić problem z zaawansowaną analizą lub problem, który wymaga rozwiązania uczenia maszynowego. Architektury danych big data dążą do rozwiązania tych wyzwań.

Rozwiązania do obsługi danych big data zwykle obejmują co najmniej jeden z następujących typów obciążeń:

• Przetwarzanie wsadowe dużych zbiorów danych w spoczynku
• Przetwarzanie danych big data w czasie rzeczywistym w ruchu
• Interaktywna eksploracja danych big data
• Analiza predykcyjna i uczenie maszynowe

Podczas wykonywania następujących zadań należy wziąć pod uwagę architektury danych big data:

• Przechowywanie i przetwarzanie danych w ilościach, które są zbyt duże dla tradycyjnej bazy danych
• Przekształcanie danych bez struktury na potrzeby analizy i raportowania
• Przechwytywanie, przetwarzanie i analizowanie niezwiązanych strumieni danych w czasie rzeczywistym lub z małym opóźnieniem

Składniki architektury danych big data

Na poniższym diagramie przedstawiono logiczne składniki architektury danych big data. Poszczególne rozwiązania mogą nie zawierać każdego elementu na tym diagramie.

Proces rozpoczyna się od źródeł danych. Dane przechodzą do magazynu danych i przetwarzania komunikatów w czasie rzeczywistym, które są ze sobą połączone. Dane w magazynie danych są przekazywane do przetwarzania wsadowego, a następnie trafiają albo do magazynu danych analitycznych przed analityką i raportowaniem, albo bezpośrednio do analityki i raportowania. Dane w czasie rzeczywistym odbioru komunikatów są przesyłane do przetwarzania strumieniowego. Następnie przechodzi do magazynu danych analitycznych, a następnie do analizy i raportowania albo bezpośrednio do analizy i raportowania. Uczenie maszynowe wskazuje na przetwarzanie wsadowe i przetwarzanie strumieniowe.

Większość architektur danych big data obejmuje niektóre lub wszystkie następujące składniki:

• Źródła danych: Wszystkie rozwiązania do obsługi danych big data zaczynają się od co najmniej jednego źródła danych. Oto kilka przykładów:

  • Magazyny danych aplikacji, takie jak relacyjne bazy danych.
  • Pliki statyczne, które tworzą aplikacje, takie jak pliki dziennika serwera internetowego.
  • Źródła danych w czasie rzeczywistym, takie jak urządzenia Internetu rzeczy (IoT).

• Magazyn danych: Dane na potrzeby operacji przetwarzania wsadowego są zwykle przechowywane w rozproszonym magazynie plików, który może przechowywać duże ilości dużych plików w różnych formatach. Ten rodzaj magazynu jest często nazywany magazynem typu data lake. Opcje implementowania tego magazynu obejmują usługę Azure Data Lake Store, kontenery obiektów blob w usłudze Azure Storage lub OneLake w usłudze Microsoft Fabric.

• Przetwarzanie wsadowe: Zestawy danych są duże, dlatego rozwiązanie danych big data często przetwarza pliki danych przy użyciu długotrwałych zadań wsadowych do filtrowania, agregowania i przygotowywania danych do analizy. Zazwyczaj te zadania obejmują odczytywanie plików źródłowych, ich przetwarzanie i zapisywanie danych wyjściowych w nowych plikach. Możesz użyć następujących opcji:

  • Użyj języka Python, Scala lub SQL w notesach usługi Azure Databricks.
  • Użyj języka Python, Scala lub SQL w notesach Fabric.

• Pozyskiwanie komunikatów w czasie rzeczywistym: Jeśli rozwiązanie zawiera źródła czasu rzeczywistego, architektura musi przechwytywać i przechowywać komunikaty w czasie rzeczywistym na potrzeby przetwarzania strumienia. Na przykład można mieć prosty magazyn danych, który zbiera komunikaty przychodzące do przetwarzania. Jednak wiele rozwiązań wymaga magazynu do przechwytywania wiadomości, aby służyć jako bufor dla wiadomości oraz obsługiwać skalowanie poziome, niezawodne dostarczanie i inne semantykę kolejkowania wiadomości. Ta część architektury przesyłania strumieniowego jest często nazywana buforowaniem 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 dane do analizy. Przetworzone dane strumienia są następnie zapisywane w ujściu danych wyjściowych.

  • Możesz używać otwartych technologii przesyłania strumieniowego Apache, takich jak Spark Streaming, oraz technologii przesyłania strumieniowego w Azure Databricks.
  • Azure Functions to bezserwerowa usługa obliczeniowa, która może uruchamiać kod sterowany zdarzeniami, który jest idealnym rozwiązaniem w przypadku zadań przetwarzania uproszczonego strumienia.
  • Sieć szkieletowa obsługuje przetwarzanie danych w czasie rzeczywistym przy użyciu strumieni zdarzeń i przetwarzania platformy Spark.

• Magazyn danych analitycznych: Wiele rozwiązań do obsługi danych big data przygotowuje dane do analizy, a następnie obsługuje przetworzone dane w formacie ustrukturyzowanym, który może wykonywać zapytania za pomocą narzędzi analitycznych. Magazyn danych analitycznych, który obsługuje te zapytania, może być magazynem danych relacyjnych w stylu Kimball. Większość tradycyjnych rozwiązań analizy biznesowej (BI) używa tego typu magazynu danych. Alternatywnie można prezentować dane za pomocą technologii NoSQL o małym opóźnieniu, takiej jak HBase, lub interaktywna baza danych Hive, która zapewnia abstrakcję metadanych na plikach danych w rozproszonym magazynie danych.

  • Fabric udostępnia różne magazyny danych, w tym bazy danych SQL, hurtownie danych, lakehouse'y i eventhouse'y. Te narzędzia mogą udostępniać dane do analizy.
  • Platforma Azure udostępnia inne magazyny danych analitycznych, takie jak Azure Databricks, Azure Data Explorer, Azure SQL Database i Azure Cosmos DB.

• Analiza i raportowanie: Większość rozwiązań do obsługi danych big data stara się zapewnić wgląd w dane za pośrednictwem analizy i raportowania. Aby umożliwić użytkownikom analizowanie danych, architektura może obejmować warstwę modelowania danych, taką jak wielowymiarowy moduł przetwarzania analitycznego online lub model danych tabelarycznych w usługach Azure Analysis Services. Może również obsługiwać samoobsługowe analizy biznesowej przy użyciu technologii modelowania i wizualizacji w usłudze Power BI lub programie Excel.

  Analitycy danych mogą również analizować i raportować przez interaktywną eksplorację danych. W tych scenariuszach wiele usług platformy Azure obsługuje notesy analityczne, takie jak Jupyter, aby umożliwić 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. Za pomocą usługi Fabric można również edytować modele danych, co zapewnia elastyczność i wydajność modelowania i analizy danych.

• Orkiestracja: Większość rozwiązań big data składa się z powtarzających się operacji przetwarzania danych, które są zawarte w przepływach pracy. Operacje wykonują następujące zadania:

  • Przekształcanie danych źródłowych
  • Przenoszenie danych między wieloma źródłami i ujściami
  • Ładowanie przetworzonych danych do magazynu danych analitycznych
  • Wypchnij wyniki bezpośrednio do raportu lub pulpitu nawigacyjnego

  Aby zautomatyzować te przepływy pracy, użyj technologii orkiestracji, takiej jak Azure Data Factory, Fabric lub Apache Oozie i Apache Sqoop.

Architektura lambda

Podczas pracy z dużymi zestawami danych uruchomienie typu zapytań potrzebnych klientom może zająć dużo czasu. Te zapytania nie mogą być wykonywane w czasie rzeczywistym i często wymagają algorytmów przetwarzania rozproszonego, takich jak MapReduce , które działają równolegle w całym zestawie danych. Wyniki zapytania są przechowywane oddzielnie od danych pierwotnych i używane do dalszego wykonywania zapytań.

Jedną z wad tego podejścia jest to, że wprowadza opóźnienie. Jeśli przetwarzanie trwa kilka godzin, zapytanie może zwrócić wyniki, które są sprzed kilku godzin. Najlepiej byłoby uzyskać wyniki w czasie rzeczywistym, co może wiązać się z utratą dokładności, a następnie połączyć te wyniki z wynikami analizy wsadowej.

Architektura lambda rozwiązuje ten problem, tworząc dwie ścieżki dla przepływu danych. Wszystkie dane wchodzące do systemu przechodzą przez następujące dwie ścieżki:

• Warstwa wsadowa (ścieżka zimna) przechowuje wszystkie dane przychodzące w postaci pierwotnej i wykonuje przetwarzanie wsadowe danych. Wynik tego przetwarzania jest przechowywany jako widok zbiorczy.

• Warstwa szybkiego przetwarzania (gorąca ścieżka) analizuje dane w czasie rzeczywistym. Ta warstwa jest przeznaczona na potrzeby małych opóźnień kosztem dokładności.

Warstwa wsadowa przekazuje dane do warstwy serwującej, która indeksuje widok wsadowy w celu wydajnego wykonywania zapytań. Warstwa szybka aktualizuje warstwę obsługi za pomocą aktualizacji przyrostowych opartych na najnowszych danych.

Źródło przepływu danych to ujednolicony dziennik danych zdarzeń. Dane przechodzą do warstwy szybkiego przetwarzania lub warstwy wsadowej. Z warstwy szybkości linia ciągła wskazuje na klienta analitycznego, a linia przerywana wskazuje na warstwę obsługującą. Z warstwy wsadowej dane przechodzą do warstwy serwującej, a następnie do klienta analitycznego. Warstwa prędkości jest oznaczona jako ścieżka gorąca. Warstwa wsadowa i warstwa obsługi są oznaczone jako ścieżka zimna.

Dane, które przepływają do ścieżki gorącej, muszą być przetwarzane szybko ze względu na wymagania dotyczące opóźnień nakładane przez warstwę szybkości. Szybkie przetwarzanie zapewnia, że dane są gotowe do natychmiastowego użycia, ale mogą wprowadzać niedokładność. Rozważmy na przykład scenariusz IoT, w którym wiele czujników temperatury wysyła dane telemetryczne. Warstwa szybkości może przetwarzać przesuwane przedziały czasu danych przychodzących.

Dane, które przepływają do ścieżki zimnej, nie podlegają tym samym wymaganiom dotyczącymi małych opóźnień. Ścieżka zimna zapewnia wysoką dokładność obliczeń w dużych zestawach danych, ale może zająć dużo czasu.

Ostatecznie ścieżka aktywna i nieaktywna zbiegają się w aplikacji klienta do analizy. Jeśli klient musi wyświetlać dane w odpowiednim czasie, ale potencjalnie mniej dokładne dane w czasie rzeczywistym, uzyskuje jego wynik ze ścieżki gorącej. W przeciwnym razie klient wybiera wyniki ze ścieżki zimnej, aby wyświetlić mniej aktualne, ale dokładniejsze dane. 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.

Surowe dane przechowywane w warstwie wsadowej są niezmienialne. Dane przychodzące są dołączane do istniejących danych, a poprzednie dane nie są zastępowane. Zmiany wartości określonej danej są przechowywane jako nowy rekord zdarzenia ze znacznikiem czasowym. Rekordy zdarzeń ze sygnaturą czasową umożliwiają ponowne obliczanie w dowolnym momencie w historii zebranych danych. Możliwość ponownego skompilowania widoku wsadowego z oryginalnych danych pierwotnych jest ważna, ponieważ umożliwia tworzenie nowych widoków w miarę rozwoju systemu.

Uczenie maszynowe w architekturze lambda

Architektury lambda obsługują obciążenia uczenia maszynowego, dostarczając zarówno dane historyczne na potrzeby trenowania modelu, jak i danych w czasie rzeczywistym na potrzeby wnioskowania. Warstwa wsadowa umożliwia trenowanie na kompleksowych historycznych zestawach danych przy użyciu obciążeń Azure Machine Learning lub Fabric Data Science. Warstwa szybkości ułatwia wnioskowanie i ocenianie modelu w czasie rzeczywistym. Takie podwójne podejście umożliwia trenowanie modeli w oparciu o pełne dane historyczne, zapewniając jednocześnie natychmiastowe prognozy na przychodzących strumieniach danych.

Architektura kappa

Wadą architektury Lambda jest jego złożoność. Logika przetwarzania pojawia się w dwóch różnych miejscach, w zimnej i gorącej ścieżce, za pośrednictwem różnych frameworków. Ten proces prowadzi do zduplikowania logiki obliczeniowej i złożonego zarządzania architekturą dla obu ścieżek.

Architektura Kappa jest alternatywą dla architektury Lambda. Ma on takie same podstawowe cele jak architektura lambda, ale wszystkie dane przepływa przez jedną ścieżkę za pośrednictwem systemu przetwarzania strumieniowego.

Źródło przepływu danych to ujednolicony dziennik danych zdarzeń. Dane przechodzą do warstwy szybkości lub magazynu długoterminowego. Linia z danych źródłowych do magazynu długoterminowego brzmi "przekazywanie zdarzeń do magazynu długoterminowego." Długoterminowa warstwa magazynowania wskazuje na warstwę szybkości. Ten wiersz odczytuje "przelicz zdarzenia dziennika z przechowywania, jeśli to konieczne". Warstwa szybkościowa wskazuje klienta analitycznego i jest przedstawiona na zielono.

Podobnie jak warstwa partii architektury Lambda, dane związane ze zdarzeniami są niezmienne i wszystkie są zbierane, zamiast jedynie części danych. 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 szybkości architektury Lambda, wszystkie operacje przetwarzania zdarzeń są wykonywane na strumieniu wejściowym i utrwalane jako widok w czasie rzeczywistym.

Jeśli musisz ponownie skompilować cały zestaw danych (odpowiadający warstwie wsadowej w architekturze lambda), możesz odtworzyć strumień. Ten proces zwykle używa równoległości do ukończenia obliczeń w odpowiednim czasie.

Uczenie maszynowe w architekturze Kappa

Architektury kappa umożliwiają ujednolicone przepływy pracy uczenia maszynowego przez przetwarzanie wszystkich danych za pośrednictwem jednego potoku przesyłania strumieniowego. Takie podejście upraszcza wdrażanie i konserwację modelu, ponieważ ta sama logika przetwarzania ma zastosowanie zarówno do danych historycznych, jak i w czasie rzeczywistym. Za pomocą obciążeń Azure Machine Learning lub Fabric Data Science można tworzyć modele, które przetwarzają dane przesyłane strumieniowo, umożliwiając ciągłe uczenie się i adaptację w czasie rzeczywistym. Architektura obsługuje algorytmy uczenia online, które aktualizują modele przyrostowo po nadejściu nowych danych.

Architektura Lakehouse

Usługa Data Lake to scentralizowane repozytorium danych, które przechowuje dane ustrukturyzowane (tabele baz danych), częściowo ustrukturyzowane dane (pliki XML) i dane bez struktury (obrazy i pliki audio). Te dane są w nieprzetworzonym, oryginalnym formacie i nie wymagają wstępnie zdefiniowanego schematu. Usługa Data Lake może obsługiwać duże ilości danych, dlatego nadaje się do przetwarzania i analizy danych big data. Magazyny typu Data lake korzystają z tanich rozwiązań magazynu, które 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 mogą pomóc w podejmowaniu świadomych decyzji, zapewniając spójny i kompleksowy widok danych.

Architektura Lakehouse łączy najlepsze elementy jezior danych i magazynów danych. Wzorzec ma na celu zapewnienie ujednoliconej platformy, która obsługuje zarówno dane ustrukturyzowane, jak i nieustrukturyzowane, co umożliwia wydajne zarządzanie danymi i analizę. Systemy te zwykle używają magazynu w chmurze o niskich kosztach w otwartych formatach, takich jak Parquet lub Optimized Row Columnar, do przechowywania zarówno nieprzetworzonych, jak i przetworzonych danych.

Typowe przypadki użycia architektury lakehouse obejmują:

• Ujednolicona analiza: Idealne rozwiązanie dla organizacji, które potrzebują jednej platformy do analizy danych historycznych i w czasie rzeczywistym
• Nadzór nad danymi: Zapewnia zgodność i jakość danych w dużych zestawach danych

Uczenie maszynowe w architekturze usługi Lakehouse

Architektury usługi Lakehouse doskonale sprawdzają się w obsłudze pełnych przepływów pracy uczenia maszynowego, zapewniając ujednolicony dostęp do danych ustrukturyzowanych i nieustrukturyzowanych. Analitycy danych mogą używać obciążeń analizy danych sieci szkieletowych do uzyskiwania dostępu do danych pierwotnych na potrzeby eksploracyjnej analizy, inżynierii cech i trenowania modeli bez złożonego przenoszenia danych. Architektura obsługuje pełny cykl życia uczenia maszynowego, od przygotowywania danych i tworzenia modeli przy użyciu notesów usługi Azure Machine Learning lub Fabric po wdrażanie i monitorowanie modelu. Ujednolicona warstwa magazynu umożliwia wydajną współpracę między inżynierami danych i analitykami danych przy zachowaniu rodowodu i zarządzania danymi.

IoT

IoT reprezentuje każde urządzenie, które łączy się z Internetem i wysyła lub odbiera dane. Urządzenia IoT obejmują komputery, telefony komórkowe, inteligentne zegarki, inteligentne termostaty, inteligentne lodówki, połączone samochody i implanty monitorowania serca.

Liczba połączonych urządzeń rośnie każdego dnia, a więc ilość generowanych przez nich danych. Te dane są często zbierane w środowiskach, które mają znaczne ograniczenia, a czasami duże opóźnienia. W innych przypadkach tysiące lub miliony urządzeń wysyłają dane ze środowisk o małych opóźnieniach, co wymaga szybkiego pozyskiwania i przetwarzania. Należy odpowiednio zaplanować obsługę tych ograniczeń i unikatowych wymagań.

Architektury sterowane zdarzeniami są kluczowym elementem rozwiązań IoT. Na poniższym diagramie przedstawiono architekturę logiczną IoT. Diagram podkreśla składniki przesyłania strumieniowego zdarzeń architektury.

Przepływ danych rozpoczyna się od urządzeń po lewej stronie, połączonych z bramą pola, która następnie łączy się z bramą w chmurze. Brama w chmurze łączy się z różnymi zadaniami za pomocą przetwarzania strumieniowego. Zadania obejmują magazyn zimny, analizę ścieżki gorącej, powiadomienia i uczenie maszynowe. Analiza wsadowa wskazuje na chłodne przechowywanie. Przetwarzanie strumieniowe wskazuje zaplecze aplikacji, które wskazuje polecenie i kontrolę, interfejs API aprowizacji i rejestr urządzeń. Interfejs API udostępniania wskazuje rejestr urządzeń. Komendy i kontrola wskazują na oryginalną bramkę polową oraz inne urządzenia, a nie na oryginalne urządzenia w przepływie danych.

Brama chmury pozyskuje zdarzenia urządzeń na granicy chmury za pośrednictwem niezawodnego systemu przesyłania komunikatów o niskim opóźnieniu.

Urządzenia mogą wysyłać zdarzenia bezpośrednio do bramy w chmurze lub za pośrednictwem bramy pola. 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 polowa może również wstępnie przetwarzać surowe zdarzenia urządzenia, polegające na wykonywaniu funkcji filtrowania, agregacji lub przekształcania protokołu.

Po spożyciu zdarzenia przechodzą przez jeden lub więcej procesorów strumieni, które mogą kierować dane do miejsc docelowych, takich jak przechowywanie, lub przeprowadzać analizy oraz inne formy przetwarzania.

Typowe typy przetwarzania to:

• Zapisywanie danych zdarzeń w zimnym magazynie na potrzeby archiwizowania lub analizy wsadowej.

• Analiza ścieżek gorących. Przeanalizuj strumień zdarzeń niemal w czasie rzeczywistym, aby wykrywać anomalie, rozpoznawać wzorce w kroczących oknach czasu lub wyzwalać alerty, gdy określony warunek występuje w strumieniu.

• Obsługa specjalnych typów komunikatów nietelemetrycznych z urządzeń, takich jak powiadomienia i alarmy.

• Uczenie maszynowe na potrzeby konserwacji predykcyjnej, wykrywania anomalii i inteligentnego podejmowania decyzji.

Na poprzednim diagramie szare pola to składniki systemu IoT, które nie są bezpośrednio związane z przesyłaniem strumieniowym zdarzeń. Są one uwzględnione na diagramie w celu uzyskania kompletności.

• Rejestr urządzeń to baza danych aprowizowanego urządzenia, w tym identyfikatory urządzeń i zazwyczaj metadane urządzenia, takie jak lokalizacja.

• Interfejs API aprowizacji jest typowym interfejsem zewnętrznym umożliwiającym aprowizowanie i rejestrowanie nowych urządzeń.

• Niektóre rozwiązania IoT umożliwiają wysyłanie komunikatów poleceń i sterowania do urządzeń.

Uczenie maszynowe w architekturze IoT

Architektury IoT używają uczenia maszynowego do inteligentnego przetwarzania brzegowego i analizy opartej na chmurze. Urządzenia brzegowe mogą uruchamiać lekkie modele na potrzeby podejmowania decyzji w czasie rzeczywistym, podczas gdy kompleksowe modele przetwarzają zagregowane dane w chmurze przy użyciu obciążeń Azure Machine Learning lub Fabric Data Science. Typowe aplikacje obejmują konserwację predykcyjną, wykrywanie anomalii i zautomatyzowane systemy odpowiedzi. Architektura obsługuje zarówno analizę strumieniową, aby uzyskać natychmiastowy wgląd, jak i przetwarzanie wsadowe do szkolenia i doskonalenia modeli przy użyciu danych IoT z przeszłości.

Dalsze kroki

• Centrum IoT
• Azure Data Explorer
• Przewodnik po decyzjach dotyczących usługi Microsoft Fabric: wybieranie magazynu danych
• Azure Databricks
• Azure Machine Learning
• Analiza danych sieci szkieletowej

Powiązane zasoby

• Architektury IoT
• Styl architektury danych big data
• Nowoczesna architektura analizy za pomocą usługi Azure Databricks
• Architektury danych big data z siecią szkieletową