Udostępnij przez


Tworzenie systemów monitorowania i obserwowania w czasie rzeczywistym dla multimediów

Azure Data Explorer
Azure Functions
Microsoft Fabric
Azure Blob Storage
Azure Event Hubs

W tej architekturze opisano rozwiązanie, które zapewnia niemal w czasie rzeczywistym monitorowanie i obserwowanie danych telemetrycznych systemów i urządzeń użytkowników. Koncentruje się na przypadku użycia dla branży medialnej.

Architektura

Diagram przedstawiający architekturę, która zapewnia niemal w czasie rzeczywistym monitorowanie i obserwowanie systemów i danych telemetrycznych urządzenia użytkownika.

Na diagramie przedstawiono dwa przepływy danych. Po lewej stronie użytkownicy łączą się z urządzeniami klienckimi przy użyciu odtwarzaczy generujących dane telemetryczne za pośrednictwem wyzwalaczy HTTP (krok 1). Dane przepływają na platformę Azure, gdzie funkcja przetwarza je w celu zbierania danych telemetrycznych urządzenia (krok 2). Dane są trasowane przez usługę Azure Event Hubs do usługi Azure Blob Storage (krok 2), następnie do usługi Azure Event Grid, a na koniec do strumienia zdarzeń pozyskiwania i przekształcania. Dane mogą również przechodzić bezpośrednio z Event Hubs do strumienia zdarzeń. Przetworzone dane przepływają do centrum zdarzeń (krok 3), a na koniec do centrum analizy danych w czasie rzeczywistym (krok 4). System wydarzeń łączy się również z systemem Data Activator (krok 5). Strumień zdarzeń pozyskiwania i przekształcania łączy się z Data Activator linią przerywaną. W drugim przepływie danych aplikacje i usługi po lewej stronie łączą się za pośrednictwem danych telemetrycznych i łączników z usługą Blob Storage lub Event Hubs (krok 1). Ten przepływ jest zgodny z tą samą ścieżką co pierwszy przepływ z usługi Blob Storage do usługi Event Grid, a następnie do strumienia zdarzeń. Funkcja, usługa Event Hubs, usługa Blob Storage i usługa Event Grid znajdują się w sekcji reprezentującej platformę Azure. Strumień zdarzeń, eventhouse, Aktywator danych i centrum inteligencji czasu rzeczywistego znajdują się w sekcji reprezentującej platformę.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych

Urządzenia klienckie i aplikacje przesyłają strumieniowo nieprzetworzone dane telemetryczne do usługi Microsoft Fabric za pośrednictwem protokołu HTTP i łączników. Strumienie zdarzeń pozyskiwają dane. Funkcje czasu rzeczywistego technologii Fabric przekształcają, normalizują i utrwalają dane telemetryczne w bazie zdarzeń, będącej skalowalną bazą danych szeregów czasowych. Inteligentne pulpity nawigacyjne czasu rzeczywistego dostarczają wniosków, a Aktywator Danych wyzwala zautomatyzowane działania oparte na wykrytych wzorcach.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

  1. Instrumentacja: Instrumentacja odbywa się za pośrednictwem sond lub agentów zainstalowanych w systemach w celu monitorowania danych. Ci agenci mają różne formy. Na przykład na platformie przesyłania strumieniowego wideo na żądanie firma może używać otwartych standardów dash.js do zbierania metryk jakości doświadczenia (QoE) od klientów.

  2. Przetwarzanie: Klienci zbierają nieprzetworzone dane telemetryczne bezpośrednio za pośrednictwem wywołań HTTP do specyficznych dla usługi punktów końcowych. Usługa Azure Functions obsługuje dane przychodzące. Alternatywnie można przekazywać dane telemetryczne za pośrednictwem systemów zewnętrznych do rozwiązań magazynu trwałego, takich jak Azure Blob Storage lub data lake. Strumienie zdarzeń Fabric zapewniają środowisko bez kodu do kierowania tych danych do natywnych jednostek Fabric, takich jak magazyn zdarzeń lub aktywator danych.

  3. Przekształcanie i trwałość: Fabric zarządza przekształcaniem danych przy użyciu zasad aktualizacji tabel i zmaterializowanych widoków. Magazyn zdarzeń przechowuje przekształcone dane i obsługuje analizę o wysokiej przepływności w dużych zestawach danych szeregów czasowych. To podejście uzupełnia istniejące mechanizmy pozyskiwania. Zapewnia również bardziej zintegrowaną i skalowalną alternatywę dla tradycyjnych potoków, które korzystają z usług Azure Functions i Data Explorer na potrzeby transformacji i analizy.

  4. Monitoring: Centrum inteligencji real-time w usłudze Fabric centralizuje dostęp do zdarzeń przesyłania strumieniowego i danych z monitorowania. Możesz używać tego narzędzia do wizualizacji metryk, ustawiania alertów oraz monitorowania wydajności w dzierżawie Fabric. Ta architektura koncentruje się głównie na monitorowaniu aplikacji, usług oraz urządzeń klienckich posiadających odtwarzacze — jak pokazano po lewej stronie diagramu. Te składniki generują dane telemetryczne i sygnały operacyjne pozyskiwane i analizowane przez inne składniki. Służą one jako podstawowe cele obserwacji.

  5. Wykrywanie anomalii: funkcja Real-Time Intelligence obejmuje wbudowane wykrywanie anomalii oparte na sztucznej inteligencji za pośrednictwem aktywatora danych. Ta funkcja może automatycznie identyfikować nietypowe wzorce lub naruszenia progów w danych przesyłanych strumieniowo i wyzwalać akcje dynamiczne. Te możliwości używają modeli uczenia maszynowego do wykrywania anomalii w czasie rzeczywistym bez ręcznej konfiguracji. Usługa Eventhouses obsługuje również zaawansowane funkcje wykrywania anomalii, które uwzględniają sezonowość, trendy i historyczne punkty odniesienia. Ta funkcja umożliwia dokładniejsze i kontekstowe szczegółowe informacje w dużych zestawach danych szeregów czasowych.

Składniki

  • Blob Storage to skalowalna usługa magazynu obiektów dla danych bez struktury. W tej architekturze usługa Blob Storage przechowuje nieprzetworzone dane telemetryczne pochodzące z aplikacji, usług lub dostawców zewnętrznych. Traktuj te dane jako przejściowe, jeśli nie jest wymagana żadna dalsza analiza. Telemetria kieruje przez Fabric EventStream do eventhouse. Natywne funkcje Fabric umożliwiają przekształcanie i utrwalanie danych na potrzeby analityki o wysokiej przepustowości.

  • Azure Event Grid to zarządzana usługa routingu zdarzeń, która umożliwia architektury sterowane zdarzeniami. W tej architekturze usługa Event Grid służy jako niezawodny system dostarczania zdarzeń, który nasłuchuje zdarzeń publikowanych przez usługę Blob Storage, takich jak tworzenie lub usuwanie blobów. Te zdarzenia wyzwalają przetwarzanie podrzędne za pośrednictwem funkcji platformy Azure, które subskrybują powiadomienia usługi Event Grid. Ta integracja umożliwia dynamiczne, sterowane zdarzeniami przepływy pracy, które obsługują pozyskiwanie i routing telemetrii w szerszej architekturze opartej na sieci szkieletowej.

  • Azure Event Hubs to platforma przesyłania strumieniowego danych big data i usługa pozyskiwania zdarzeń, która może odbierać i przetwarzać miliony zdarzeń na sekundę. W tej architekturze usługa Event Hubs działa jako brama, często nazywana ingestorem zdarzeń, dla potoku zdarzeń. Ingestor zdarzeń jest składnikiem lub usługą znajdującą się między wydawcami zdarzeń i użytkownikami zdarzeń. Umożliwia oddzielenie produkcji strumienia zdarzeń od konsumpcji zdarzeń.

  • Azure Functions to bezserwerowa usługa obliczeniowa, której można użyć do uruchamiania kodu wyzwalanego przez zdarzenia bez konieczności jawnego aprowizowania infrastruktury ani zarządzania nią. W tej architekturze Azure Functions analizuje i przekształca dane pozyskiwane za pośrednictwem punktów końcowych HTTP i usługi Blob. Dane telemetryczne są kierowane do strumieni zdarzeń i magazynów zdarzeń na potrzeby skalowalnej transformacji i analizy.

  • Strumień zdarzeń Fabric to funkcja w Fabric, która umożliwia pozyskiwanie, przekształcanie i routing zdarzeń w czasie rzeczywistym. W tej architekturze strumienie zdarzeń Fabric udostępniają różne złącza źródłowe do pobierania danych zdarzeń z różnych źródeł. Za pomocą tego podejścia można tworzyć przetwarzanie danych zdarzeń, przekształcanie i logikę routingu bez konieczności pisania kodu.

  • Fabric eventhouse to baza danych analitycznych zoptymalizowana pod kątem danych szeregów czasowych i obciążeń analitycznych w czasie rzeczywistym. W tej architekturze platformy zdarzeń są dostosowane do zdarzeń, które są oparte na czasie i strumieniowe oraz zawierają dane ustrukturyzowane, częściowo ustrukturyzowane i nieustrukturyzowane. Dane można pobierać z wielu źródeł w wielu potokach i wielu formatach danych. Te dane są indeksowane i partycjonowane na podstawie czasu pobierania.

  • Data Activator to funkcja bez potrzeby pisania kodu w Fabric, która automatycznie wykonuje akcje, gdy wykrywa wzorce w zmieniających się danych. W tej architekturze aktywator danych służy jako aparat wykrywania zdarzeń o małych opóźnieniach, który wyzwala akcje, gdy wykrywa określone wzorce lub warunki w źródłach danych. Monitoruje te źródła danych z opóźnieniem podrzędnym i inicjuje akcje, gdy dane spełniają progi lub wykrywa określone wzorce. Te akcje obejmują wysyłanie wiadomości e-mail lub powiadomień usługi Teams, uruchamianie przepływów usługi Power Automate lub integrowanie z systemami zewnętrznymi.

Alternatywy

Usługa Azure Data Factory udostępnia narzędzia do tworzenia przepływów pracy wyodrębniania, przekształcania i ładowania (ETL) oraz śledzenia i ponawiania zadań z graficznego interfejsu użytkownika (GUI). Usługa Data Factory ma minimalne opóźnienie wynoszące około 5 minut od czasu przyjmowania danych do ich zapisania. Jeśli system monitorowania może tolerować to opóźnienie, rozważ tę alternatywę.

Szczegóły scenariusza

Organizacje często wdrażają zróżnicowane i na dużą skalę technologie w celu rozwiązywania problemów biznesowych. Te systemy i urządzenia użytkowników generują duże zestawy danych telemetrycznych.

Ta architektura jest oparta na przypadku użycia w branży mediów. Przesyłanie strumieniowe multimediów do odtwarzania na żywo i wideo na żądanie wymaga identyfikacji i reagowania na problemy z aplikacjami w czasie zbliżonym do rzeczywistego. Aby obsługiwać ten scenariusz w czasie rzeczywistym, organizacje muszą zebrać ogromny zestaw telemetrii, który wymaga skalowalnej architektury. Po zebraniu danych muszą wykonywać inne typy analiz, takie jak sztuczna inteligencja i wykrywanie anomalii, aby skutecznie identyfikować problemy w tak dużym zestawie danych.

Po wdrożeniu technologii na dużą skalę system i urządzenia użytkowników, które współdziałają z nimi, generują ogromne zestawy danych telemetrycznych. W tradycyjnych scenariuszach organizacje analizują te dane za pośrednictwem systemu magazynu danych, aby wygenerować szczegółowe informacje, które obsługują decyzje dotyczące zarządzania. Takie podejście może działać w niektórych scenariuszach, ale nie jest wystarczająco dynamiczne w przypadku przypadków użycia multimediów przesyłanych strumieniowo. Aby rozwiązać ten problem, organizacje wymagają szczegółowych informacji w czasie rzeczywistym dla danych telemetrycznych, które generują serwery, sieci i urządzenia użytkowników. Systemy monitorowania często wykrywają awarie i błędy, ale ich wykrywanie niemal w czasie rzeczywistym jest trudne. Ta architektura koncentruje się na rozwiązywaniu tego problemu.

W ustawieniu transmisji strumieniowej na żywo lub wideo na żądanie systemy i różne klientów, takie jak urządzenia przenośne, komputery stacjonarne i telewizory, generują dane telemetryczne. Rozwiązanie pobiera nieprzetworzone dane i kojarzy kontekst z każdym punktem danych. Przykłady kontekstowe obejmują wymiary, takie jak geografia, system operacyjny użytkownika, identyfikator zawartości i dostawca sieci dostarczania zawartości. System zbiera, przekształca i zapisuje nieprzetworzone dane telemetryczne w usłudze Fabric eventhouse na potrzeby analizy. Narzędzia sztucznej inteligencji mogą interpretować dane i automatyzować ręczne procesy obserwacji i alertów. Funkcja aktywowania danych odczytuje dane z centrum analizy Real-Time w celu wyświetlania interaktywnych pulpitów nawigacyjnych i wyzwalania alertów.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Niezawodność

Niezawodność pomaga zapewnić, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Design review checklist for Reliability(Lista kontrolna dotycząca niezawodności).

Aplikacje krytyczne dla działania firmy muszą pozostawać aktywne nawet podczas zakłócania działania, takich jak awarie w regionie platformy Azure lub w sieci dostarczania zawartości. Następujące strategie, dwie podstawowe strategie i jedna strategia hybrydowa, obsługują tworzenie nadmiarowości w systemie:

  • Aktywne/aktywne: Duplikaty kodu i funkcji są uruchamiane. Jeden z systemów może przejąć jedną z tych operacji podczas awarii.

  • Aktywne/wstrzymanie: Tylko jeden węzeł służy jako węzeł aktywny lub podstawowy. Drugi węzeł pozostaje gotowy do przejęcia, jeśli węzeł podstawowy ulegnie awarii.

  • Mieszany: Niektóre składniki lub usługi korzystają z konfiguracji active-active, a inne używają konfiguracji aktywne-pasywna.

Nie wszystkie usługi platformy Azure mają wbudowaną nadmiarowość. Na przykład usługa Azure Functions uruchamia aplikację funkcji tylko w określonym regionie. Aby uzyskać więcej informacji na temat strategii wdrażania, w zależności od sposobu wyzwalania funkcji (HTTP i publikowania/subskrybowania), zobacz Niezawodność w usłudze Azure Functions.

Sieć szkieletowa obsługuje strefowo nadmiarowe strefy dostępności, w których zasoby są automatycznie replikowane między strefami bez konieczności jej konfigurowania. Aby uzyskać więcej informacji na temat replikacji danych między regionami dla danych przechowywanych w usłudze OneLake, zobacz Niezawodność w Fabric. Możesz włączyć lub wyłączyć tę funkcję w zależności od swoich wymagań.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dlaoptymalizacji kosztów.

Koszt tej architektury zależy od liczby przychodzących zdarzeń telemetrii, przechowywania nieprzetworzonych danych telemetrycznych w Blob Storage i magazynach zdarzeń Fabric, oraz od wybranego modelu cenowego, czy to dedykowanego, czy "pay-as-you-go" dla pojemności Fabric.

Aby oszacować łączne koszty, użyj kalkulatora cen platformy Azure.

Wydajność

Wydajność odnosi się do możliwości skalowania obciążenia w celu efektywnego zaspokojenia wymagań użytkowników. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu pod kątem wydajności.

W zależności od skali i częstotliwości nadchodzących danych telemetrycznych, przesyłanie strumieniowe w systemie Fabric może napotkać ograniczenia wydajnościowe. Te ograniczenia zwykle wynikają z następujących czynników:

  • Zimny start: Wywołania bezserwerowe wymagają czasu na zaplanowanie i skonfigurowanie środowiska przed uruchomieniem funkcji. Ta konfiguracja zajmuje do kilku sekund.

  • Częstotliwość żądań: Jeśli na przykład dotrze 1000 żądań HTTP, ale dostępny jest tylko pojedynczy serwer wątkowy, system nie może przetwarzać wszystkich żądań jednocześnie. Aby efektywnie obsługiwać je, należy skalować je w poziomie przez wdrożenie większej liczby serwerów.

  • Opóźnienie inicjowania strumienia zdarzeń: Po aktywowaniu nowych źródeł danych, przepływy strumienia zdarzeń Fabric mogą wprowadzać opóźnienie. To opóźnienie przypomina zimny start. Chociaż krótkie, może to mieć wpływ na scenariusze wrażliwe na opóźnienia.

  • Wzrosty danych o wysokiej częstotliwości: Jeśli tysiące zdarzeń telemetrii dociera jednocześnie, pojedyncza konfiguracja strumienia zdarzeń może nie przetwarzać ich jednocześnie. Aby utrzymać odpowiedź w czasie rzeczywistym, należy rozszerzać potoki strumienia zdarzeń i zoptymalizować reguły routingu na wielu celach.

Aby rozwiązać te problemy, użyj dedykowanych obszarów roboczych o pojemności w jednostkach SKU Fabric. Takie podejście zapewnia następujące korzyści:

  • Zapewnia spójną wydajność, usuwając opóźnienia inicjowania

  • Obsługuje skalowanie poziome przepływów zdarzeń w celu obsługi współbieżnych obciążeń związanych z pozyskiwaniem i przekształcaniem

Aby uzyskać więcej informacji, zobacz Sieć szkieletowa Real-Time Intelligence.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Autorzy zabezpieczeń:

Inni współautorzy:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki