Wzorce rozwiązań usługi Azure Stream Analytics

Podobnie jak wiele innych usług na platformie Azure, usługa Stream Analytics najlepiej używać z innymi usługami do tworzenia większego kompleksowego rozwiązania. W tym artykule omówiono proste rozwiązania usługi Azure Stream Analytics i różne wzorce architektury. Te wzorce można tworzyć bardziej złożone rozwiązania. Wzorce opisane w tym artykule mogą być używane w wielu różnych scenariuszach. Przykłady wzorców specyficznych dla scenariuszy są dostępne w architekturach rozwiązań platformy Azure.

Tworzenie zadania usługi Stream Analytics w celu obsługi pulpitów nawigacyjnych w czasie rzeczywistym

Usługa Azure Stream Analytics umożliwia szybkie tworzenie pulpitów nawigacyjnych i alertów w czasie rzeczywistym. Proste rozwiązanie pozyskuje zdarzenia z usługi Event Hubs lub usługi IoT Hub i przesyła pulpit nawigacyjny usługi Power BI za pomocą zestawu danych przesyłanych strumieniowo. Aby uzyskać więcej informacji, zobacz szczegółowy samouczek Analizowanie fałszywych danych połączeń za pomocą usługi Stream Analytics i wizualizowanie wyników na pulpicie nawigacyjnym usługi Power BI.

To rozwiązanie można utworzyć za kilka minut przy użyciu witryny Azure Portal. Nie trzeba kodować w szerokim zakresie. Zamiast tego możesz użyć języka SQL, aby wyrazić logikę biznesową.

Ten wzorzec rozwiązania zapewnia najmniejsze opóźnienie od źródła zdarzeń do pulpitu nawigacyjnego usługi Power BI w przeglądarce. Usługa Azure Stream Analytics jest jedyną usługą platformy Azure z tą wbudowaną funkcją.

Używanie języka SQL na potrzeby pulpitu nawigacyjnego

Pulpit nawigacyjny usługi Power BI oferuje małe opóźnienia, ale nie można go używać do tworzenia pełnowartościowych raportów usługi Power BI. Typowym wzorcem raportowania jest najpierw wyprowadzenie danych do usługi SQL Database. Następnie użyj łącznika SQL usługi Power BI, aby wykonać zapytanie o dane SQL dla najnowszych danych.

W przypadku korzystania z usługi SQL Database zapewnia większą elastyczność, ale kosztem nieco większego opóźnienia. To rozwiązanie jest optymalne dla zadań z wymaganiami dotyczącymi opóźnień większymi niż jedna sekunda. W przypadku korzystania z tej metody można zmaksymalizować możliwości usługi Power BI, aby dodatkowo podzielić dane na raporty i podzielić je na kostkę oraz o wiele więcej opcji wizualizacji. Zyskujesz również elastyczność korzystania z innych rozwiązań pulpitu nawigacyjnego, takich jak Tableau.

Sql nie jest magazynem danych o wysokiej przepływności. Maksymalna przepływność do usługi SQL Database z usługi Azure Stream Analytics wynosi obecnie około 24 MB/s. Jeśli źródła zdarzeń w rozwiązaniu generują dane o wyższej szybkości, należy użyć logiki przetwarzania w usłudze Stream Analytics, aby zmniejszyć szybkość danych wyjściowych do języka SQL. Można użyć technik, takich jak filtrowanie, agregacje okienne, dopasowywanie wzorca ze sprzężeniami czasowymi i funkcje analityczne. Szybkość danych wyjściowych do języka SQL można zoptymalizować przy użyciu technik opisanych w artykule Dane wyjściowe usługi Azure Stream Analytics do usługi Azure SQL Database.

Dołączanie szczegółowych informacji w czasie rzeczywistym do aplikacji za pomocą komunikatów o zdarzeniach

Drugim najpopularniejszym zastosowaniem usługi Stream Analytics jest generowanie alertów w czasie rzeczywistym. W tym wzorcu rozwiązania logika biznesowa w usłudze Stream Analytics może służyć do wykrywania wzorców czasowych i przestrzennych lub anomalii, a następnie generowania sygnałów alertów. Jednak w przeciwieństwie do rozwiązania pulpitu nawigacyjnego, w którym usługa Stream Analytics używa usługi Power BI jako preferowanego punktu końcowego, można użyć innych pośrednich ujść danych. Te ujścia obejmują usługi Event Hubs, Service Bus i Azure Functions. Jako konstruktor aplikacji musisz zdecydować, który ujście danych działa najlepiej w danym scenariuszu.

Aby wygenerować alerty w istniejącym przepływie pracy biznesowej, należy zaimplementować logikę odbiorcy zdarzeń podrzędnych. Ponieważ możesz zaimplementować logikę niestandardową w usłudze Azure Functions, usługa Azure Functions jest najszybszym sposobem przeprowadzenia tej integracji. Aby zapoznać się z samouczkiem dotyczącym używania funkcji platformy Azure jako danych wyjściowych zadania usługi Stream Analytics, zobacz Uruchamianie usługi Azure Functions z zadań usługi Azure Stream Analytics. Usługa Azure Functions obsługuje również różne typy powiadomień, w tym tekst i wiadomość e-mail. Możesz również użyć usługi Logic Apps do takiej integracji z usługą Event Hubs między usługą Stream Analytics i usługą Logic Apps.

Z drugiej strony usługa Azure Event Hubs oferuje najbardziej elastyczny punkt integracji. Wiele innych usług, takich jak Usługi Azure Data Explorer i Time Series Szczegółowe informacje mogą korzystać ze zdarzeń z usługi Event Hubs. Usługi można połączyć bezpośrednio z ujściem usługi Event Hubs z usługi Azure Stream Analytics, aby ukończyć rozwiązanie. Usługa Event Hubs jest również brokerem obsługi komunikatów o najwyższej przepływności dostępnej na platformie Azure na potrzeby takich scenariuszy integracji.

Dynamiczne aplikacje i witryny internetowe

Możesz tworzyć niestandardowe wizualizacje w czasie rzeczywistym, takie jak pulpit nawigacyjny lub wizualizacja mapy, przy użyciu usług Azure Stream Analytics i Azure SignalR Service. W przypadku korzystania z usługi SignalR klienci sieci Web mogą być aktualizowani i wyświetlać zawartość dynamiczną w czasie rzeczywistym.

Dołączanie szczegółowych informacji w czasie rzeczywistym do aplikacji za pośrednictwem magazynów danych

Większość usług internetowych i aplikacji internetowych używa obecnie wzorca żądania/odpowiedzi do obsługi warstwy prezentacji. Wzorzec żądania/odpowiedzi jest prosty do skompilowania i można go łatwo skalować z niskim czasem odpowiedzi przy użyciu bezstanowego frontonu i skalowalnych magazynów, takich jak usługa Azure Cosmos DB.

Duże ilości danych często tworzą wąskie gardła wydajności w systemie opartym na cruD. Wzorzec rozwiązania do określania źródła zdarzeń służy do rozwiązywania wąskich gardeł wydajności. Wzorce czasowe i szczegółowe informacje są również trudne i nieefektywne do wyodrębniania z tradycyjnego magazynu danych. Nowoczesne aplikacje oparte na danych o dużej ilości często przyjmują architekturę opartą na przepływie danych. Usługa Azure Stream Analytics jako aparat obliczeniowy dla danych w ruchu to linchpin w tej architekturze.

W tym wzorcu rozwiązania zdarzenia są przetwarzane i agregowane w magazynach danych przez usługę Azure Stream Analytics. Warstwa aplikacji współdziała z magazynami danych przy użyciu tradycyjnego wzorca żądania/odpowiedzi. Ze względu na możliwość przetwarzania dużej liczby zdarzeń w czasie rzeczywistym usługa Stream Analytics jest wysoce skalowalna bez konieczności zbiorczego tworzenia warstwy magazynu danych. Warstwa magazynu danych jest zasadniczo zmaterializowanym widokiem w systemie. Dane wyjściowe usługi Azure Stream Analytics w usłudze Azure Cosmos DB opisują sposób użycia usługi Azure Cosmos DB jako danych wyjściowych usługi Stream Analytics.

W rzeczywistych aplikacjach, w których logika przetwarzania jest złożona i istnieje konieczność niezależnego uaktualnienia niektórych części logiki, wiele zadań usługi Stream Analytics może składać się z usługą Event Hubs jako pośredniczącego brokera zdarzeń.

Ten wzorzec poprawia odporność i możliwości zarządzania systemem. Jednak mimo że usługa Stream Analytics gwarantuje dokładnie jednokrotne przetwarzanie, istnieje niewielkie prawdopodobieństwo, że zduplikowane zdarzenia wylądowały w pośredniczącej usłudze Event Hubs. Ważne jest, aby podrzędne zadanie usługi Stream Analytics deduplikować zdarzenia przy użyciu kluczy logiki w oknie wyszukiwania. Aby uzyskać więcej informacji na temat dostarczania zdarzeń, zobacz Dokumentacja gwarancji dostarczania zdarzeń.

Używanie danych referencyjnych do dostosowywania aplikacji

Funkcja danych referencyjnych usługi Azure Stream Analytics została zaprojektowana specjalnie na potrzeby dostosowywania użytkowników końcowych, takich jak próg alertów, reguły przetwarzania i geofencingi. Warstwa aplikacji może akceptować zmiany parametrów i przechowywać je w usłudze SQL Database. Zadanie usługi Stream Analytics okresowo wysyła zapytania o zmiany z bazy danych i udostępnia parametry dostosowywania za pośrednictwem sprzężenia danych referencyjnych. Aby uzyskać więcej informacji na temat używania danych referencyjnych do dostosowywania aplikacji, zobacz Dane referencyjne SQL i dołączanie danych referencyjnych.

Ten wzorzec może również służyć do implementowania aparatu reguł, w którym progi reguł są definiowane na podstawie danych referencyjnych. Aby uzyskać więcej informacji na temat reguł, zobacz Przetwarzanie konfigurowalnych reguł opartych na progach w usłudze Azure Stream Analytics.

Dodawanie Edukacja maszyny do szczegółowych informacji w czasie rzeczywistym

Wbudowany model wykrywania anomalii w usłudze Azure Stream Analytics to wygodny sposób wprowadzenia Edukacja maszyny do aplikacji w czasie rzeczywistym. Aby uzyskać szerszy zakres potrzeb Edukacja maszynowych, zobacz Azure Stream Analytics integruje się z usługą oceniania usługi Azure Machine Edukacja.

W przypadku zaawansowanych użytkowników, którzy chcą uwzględnić trenowanie online i ocenianie w tym samym potoku usługi Stream Analytics, zobacz ten przykład, jak to zrobić z regresją liniową.

Magazynowanie danych w czasie rzeczywistym

Innym typowym wzorcem jest magazynowanie danych w czasie rzeczywistym, nazywane również magazynem danych przesyłanych strumieniowo. Oprócz zdarzeń przychodzących do usługi Event Hubs i usługi IoT Hub z aplikacji usługa Azure Stream Analytics uruchomiona w usłudze IoT Edge może służyć do wypełniania potrzeb związanych z czyszczeniem danych, redukcją danych oraz przechowywaniem danych i przesyłaniem dalej. Usługa Stream Analytics uruchomiona w usłudze IoT Edge może bezpiecznie obsługiwać ograniczenia przepustowości i problemy z łącznością w systemie. Usługa Stream Analytics może obsługiwać współczynniki przepływności do 200 MB/s podczas zapisywania w usłudze Azure Synapse Analytics.

Archiwizowanie danych w czasie rzeczywistym na potrzeby analizy

Większość działań związanych z nauką o danych i analizą nadal jest wykonywanych w trybie offline. Dane w usłudze Azure Stream Analytics można archiwizować za pomocą danych wyjściowych usługi Azure Data Lake Store Gen2 i formatów danych wyjściowych Parquet. Ta funkcja eliminuje problemy związane z przesyłaniem danych bezpośrednio do usług Azure Data Lake Analytics, Azure Databricks i Azure HDInsight. Usługa Azure Stream Analytics jest używana jako aparat ETL (Extract-Transform-Load) niemal w czasie rzeczywistym w tym rozwiązaniu. Dane zarchiwizowane w usłudze Data Lake można eksplorować przy użyciu różnych aparatów obliczeniowych.

Używanie danych referencyjnych do wzbogacania

Wzbogacanie danych jest często wymagane w przypadku aparatów ETL. Usługa Azure Stream Analytics obsługuje wzbogacanie danych przy użyciu danych referencyjnych zarówno z usługi SQL Database, jak i usługi Azure Blob Storage. Wzbogacanie danych można wykonać na potrzeby lądowania danych zarówno w usłudze Azure Data Lake, jak i w usłudze Azure Synapse Analytics.

Operacjonalizacja szczegółowych informacji z zarchiwizowanych danych

Jeśli połączysz wzorzec analizy offline ze wzorcem aplikacji niemal w czasie rzeczywistym, możesz utworzyć pętlę opinii. Pętla opinii pozwala aplikacji automatycznie dostosowywać się do zmieniających się wzorców w danych. Ta pętla opinii może być tak prosta, jak zmiana wartości progowej alertu lub tak złożona, jak ponowne trenowanie modeli maszyny Edukacja. Tę samą architekturę rozwiązania można zastosować zarówno do zadań usługi ASA działających w chmurze, jak i w usłudze IoT Edge.

Jak monitorować zadania usługi ASA

Zadanie usługi Azure Stream Analytics można uruchomić 24/7 w celu ciągłego przetwarzania zdarzeń przychodzących w czasie rzeczywistym. Jego gwarancja czasu pracy ma kluczowe znaczenie dla kondycji ogólnej aplikacji. Chociaż usługa Stream Analytics jest jedyną usługą analizy przesyłania strumieniowego w branży, która oferuje gwarancję dostępności na poziomie 99,9%, nadal ponosisz pewien poziom czasu pracy. W ciągu lat usługa Stream Analytics wprowadziła metryki, dzienniki i stany zadań w celu odzwierciedlenia kondycji zadań. Wszystkie z nich są udostępniane za pośrednictwem usługi Azure Monitor i można je dalej eksportować do pakietu OMS. Aby uzyskać więcej informacji, zobacz Monitorowanie zadania usługi Stream Analytics za pomocą witryny Azure Portal.

Istnieją dwie kluczowe kwestie do monitorowania:

• Stan niepowodzenia zadania

  Przede wszystkim musisz upewnić się, że zadanie jest uruchomione. Bez zadania w stanie uruchomienia nie są generowane żadne nowe metryki ani dzienniki. Zadania mogą ulec zmianie na stan niepowodzenia z różnych powodów, w tym o wysokim poziomie wykorzystania jednostek SU (czyli wyczerpaniu zasobów).

• Metryki opóźnienia limitu

  Ta metryka odzwierciedla, jak daleko za potokiem przetwarzania znajduje się czas zegara ściany (w sekundach). Niektóre opóźnienia są przypisywane logiki przetwarzania z natury. W rezultacie monitorowanie trendu rosnącego jest znacznie ważniejsze niż monitorowanie wartości bezwzględnej. Opóźnienie stanu stałego powinno zostać rozwiązane przez projekt aplikacji, a nie przez monitorowanie ani alerty.

Po awarii dzienniki aktywności i dzienniki diagnostyczne to najlepsze miejsca do rozpoczęcia wyszukiwania błędów.

Tworzenie odpornych i krytycznych aplikacji

Niezależnie od gwarancji umowy SLA usługi Azure Stream Analytics i tego, jak ostrożnie uruchamiasz aplikację kompleksową, występują awarie. Jeśli aplikacja ma krytyczne znaczenie, należy przygotować się na awarie, aby można było bezpiecznie odzyskać dane.

W przypadku aplikacji alertów najważniejszą rzeczą jest wykrycie następnego alertu. Możesz ponownie uruchomić zadanie od bieżącego czasu podczas odzyskiwania, ignorując wcześniejsze alerty. Semantyka czasu rozpoczęcia zadania jest określana po raz pierwszy, a nie przy pierwszym wejściu. Dane wejściowe są przywracane do tyłu przez odpowiedni czas, aby zagwarantować, że pierwsze dane wyjściowe w określonym czasie zostaną ukończone i poprawne. W rezultacie nie uzyskasz częściowych agregacji i nie wyzwolisz alertów.

Możesz również rozpocząć dane wyjściowe z pewnej ilości czasu w przeszłości. Zarówno usługi Event Hubs, jak i zasady przechowywania usługi IoT Hub przechowują rozsądną ilość danych, aby umożliwić przetwarzanie z przeszłości. Kompromis polega na tym, jak szybko można nadrobić zaległości do bieżącego czasu i rozpocząć generowanie terminowych nowych alertów. Dane szybko tracą swoją wartość w czasie, dlatego ważne jest, aby szybko nadrobić zaległości w bieżącym czasie. Istnieją dwa sposoby szybkiego nadrobienia zaległości:

• Aprowizuj więcej zasobów (SU) podczas nadrabiania zaległości.
• Uruchom ponownie z bieżącej godziny.

Ponowne uruchomienie z bieżącego czasu jest proste, a kompromis polega na pozostawieniu luki podczas przetwarzania. Ponowne uruchomienie w ten sposób może być ok w przypadku scenariuszy zgłaszania alertów, ale może być problematyczne w scenariuszach pulpitu nawigacyjnego i jest nieruchome w scenariuszach archiwizacji i magazynowania danych.

Aprowizowanie większej ilości zasobów może przyspieszyć proces, ale wpływ wzrostu szybkości przetwarzania jest złożony.

• Przetestuj, czy zadanie jest skalowalne do większej liczby jednostek jednostki SU. Nie wszystkie zapytania są skalowalne. Upewnij się, że zapytanie jest równoległe.

• Upewnij się, że w nadrzędnej usłudze Event Hubs lub usłudze IoT Hub jest wystarczająca liczba partycji, aby dodać więcej jednostek przepływności (TU), aby skalować przepływność wejściową. Pamiętaj, że każdy tu usługi Event Hubs maksymalnie osiąga szybkość wyjściową wynoszącą 2 MB/s.

• Upewnij się, że aprowizowaliśmy wystarczającą ilość zasobów w ujściach danych wyjściowych (czyli w usłudze SQL Database, Azure Cosmos DB), aby nie ograniczały one wzrostu liczby danych wyjściowych, co czasami może spowodować zablokowanie systemu.

Najważniejszą rzeczą jest przewidywanie zmiany szybkości przetwarzania, przetestowanie tych scenariuszy przed przejściem do środowiska produkcyjnego i przygotowanie do prawidłowego skalowania przetwarzania w czasie odzyskiwania po awarii.

W skrajnym scenariuszu, że wszystkie zdarzenia przychodzące są opóźnione, możliwe, że wszystkie opóźnione zdarzenia zostaną porzucone, jeśli do zadania zastosowano okno późnego przybycia. Upuszczanie wydarzeń może wydawać się tajemniczym zachowaniem na początku; Jednak biorąc pod uwagę, że usługa Stream Analytics jest aparatem przetwarzania w czasie rzeczywistym, oczekuje, że zdarzenia przychodzące będą zbliżone do czasu zegara ściany. Musi ona usuwać zdarzenia naruszające te ograniczenia.

Architektury lambda lub proces wypełniania wstecznego

Na szczęście poprzedni wzorzec archiwizacji danych może służyć do bezproblemowego przetwarzania tych późnych zdarzeń. Chodzi o to, że zadanie archiwizowania przetwarza zdarzenia przychodzące w czasie przybycia i archiwizowa zdarzenia w odpowiednim zasobniku czasu w usłudze Azure Blob lub Azure Data Lake Store z czasem zdarzenia. Nie ma znaczenia, jak późno nadejdzie wydarzenie, nigdy nie zostanie porzucone. Zawsze ląduje w odpowiednim zasobniku czasu. Podczas odzyskiwania możliwe jest ponowne przetworzenie zarchiwizowanych zdarzeń i wypełnienie wyników do wybranego magazynu. Jest to podobne do sposobu implementowania wzorców lambda.

Proces wypełniania należy wykonać przy użyciu systemu przetwarzania wsadowego w trybie offline, który najprawdopodobniej ma inny model programowania niż usługa Azure Stream Analytics. Oznacza to, że trzeba ponownie zaimplementować całą logikę przetwarzania.

W przypadku wypełniania kopii zapasowych nadal ważne jest, aby przynajmniej tymczasowo aprowizować więcej zasobów ujściom danych wyjściowych w celu obsługi wyższej przepływności niż potrzeby związane z przetwarzaniem stanu stałego.

Scenariusze	Uruchom ponownie tylko teraz	Ponowne uruchamianie z czasu ostatniego zatrzymania	Uruchom ponownie od teraz + wypełnianie zarchiwizowanych zdarzeń
Pulpit nawigacyjny	Tworzy lukę	OK w przypadku krótkiej awarii	Używanie do długiej awarii
Alerty	Akceptowalne	OK w przypadku krótkiej awarii	Nie jest to konieczne
Aplikacja do określania źródła zdarzeń	Akceptowalne	OK w przypadku krótkiej awarii	Używanie do długiej awarii
Magazynowanie danych	Utrata danych	Akceptowalne	Nie jest to konieczne
Analiza w trybie offline	Utrata danych	Akceptowalne	Nie jest to konieczne

Zebranie wszystkich elementów

Nie trudno sobie wyobrazić, że wszystkie wymienione wcześniej wzorce rozwiązań można połączyć ze sobą w złożonym kompleksowym systemie. Połączony system może obejmować pulpity nawigacyjne, alerty, aplikację do określania źródła zdarzeń, magazynowanie danych i możliwości analizy offline.

Kluczem jest zaprojektowanie systemu w wzorcach komponowalnych, dzięki czemu każdy podsystem może być zbudowany, przetestowany, uaktualniony i odzyskany niezależnie.

Następne kroki

Teraz przedstawiono różne wzorce rozwiązań przy użyciu usługi Azure Stream Analytics. Teraz możesz utworzyć pierwsze zadanie w usłudze Stream Analytics:

• Tworzenie zadania usługi Stream Analytics przy użyciu witryny Azure Portal.
• Tworzenie zadania usługi Stream Analytics przy użyciu programu Azure PowerShell.
• Tworzenie zadania usługi Stream Analytics przy użyciu programu Visual Studio.