Usługa Azure Stream Analytics najczęściej kojarzy się z projektami IoT. O ile skojarzenie jest dobre to potencjalnych zastosowań jest więcej. Wszędzie tam w chmurze, gdzie macie strumień danych, różnego typu, który wymaga np. grupowania czy połączenia z danymi z innych miejsc, Stream Analytics mogą okazać się pomocne.
Zanim zaczniemy, dzięki wspierającym kolegom już wiem, że blog techniczny bez wyjaśnienia nazw własnych nie zostanie zrozumiany. Więc za radą wyjaśniamy kilka pojęć, które tu znajdziecie:
- Azure Stream Analytics (ASA) – usługa, która chętnie przyjmie różnego rodzaju dane (Input), przesyłane w postaci strumienia (np. JSON), przetworzy je (np. weź średnią wartość temp. za ostatnie 5 minut) i wyśle je tam, gdzie chcesz (Output), np. do bazy danych Azure SQL
- Input – Twoje źródło danych, np. dane z urządzenia IoT albo telemetrii, przychodzącej z Application Insights
- Output – Twoje wyjście z Stream Analytics, np. PowerBI albo Data Lake
- Job – proces w ramach Stream Analytics, które wykonuje operację na danych (np. liczy wspomnianą średnią).
- SQL – przecież wiadomo czym jest SQL 🙂 więc nie wygłupiajmy się:)
Zanim użyjecie tego komponentu w swoim projekcie, proponuję dobrze zrozumieć filozofię jego działania. Ja zwrócę Wam uwagę na dwie proste rzeczy.
- Twój projekt zakłada, że macie dwa input’y i jeden output. Twój projekt zakłada również, że jeden z tych input’ów może być niedostępny przez jakiś czas. Co wtedy stanie się z całym Job’em Stream Analytics i przetwarzanymi danymi?
Otóż, job przetworzy wszystkie dane, które są w usłudze (w inpucie), w danym oknie czasowym, wpisze do tego output’u, który jest aktywny i cały job się zatrzyma ze względu na niedostępny output.
I teraz zaczyna się „fun part” jak mawiają koledzy „zza kałuży”. Po podniesieniu output’u, który był niedostępny i wystartowaniu job’a ponownie ASA spróbuje uzupełnić dane, od momentu, kiedy wykryło niedostępność. I teraz uważaj… W Twoim output’cie, który był cały czas „up&running” pojawią się duplikaty. Dopóki umiesz je wykryć, dobra Twoja. Jeśli nie umiesz, zachęcam Cię do przeczytania tego blog i wybrania klucza, dzięki któremu tego unikniesz.
2. Error Policy czyli co zrobi Stream Analytics kiedy wykryje błędy?
Polityka błędów pojawiła się stosunkowo niedawno. I od razu okazało się, że nie do końca dobrze została opisana w samym portalu Azure. Polityka dotyczy tzw. zdarzeń na wyjściu (output) i dotyczy sytuacji błędów na wyjściach z Stream Analytics a nie na wejściach.
Jeśli ustawisz politykę na Drop i na Twoim wyjściu np. brakuje kolumny w Azure SQL to job to Job w ASA nie zatrzyma się z błędem, będzie dalej działał ale nie zapisze danych na tym wyjściu, które nie posada odpowiedniej kolumny. I dobrze, ma to sens 🙂
Jeśli jednak ustawisz politykę Retry, ASA będzie powtarzało operację, jeśli napotka błąd na wyjściu (brak kolumny) to w końca Job zostanie zatrzymany z błędem i proces nie będzie kontynuowany. Jeśli błąd zostanie naprawiony, proces puszczony, to dane zostaną załadowane na wyjście.
Ale, ale… na tym poziomy swobody się nie kończą 🙂 Jeśli Twój output nie jest dostępny, to niezależnie czy ustawisz politykę Drop czy Retry, ASA zatrzyma Job, zaraportuje błąd i nie przetworzy danych.
Tak to sobie Twórcy ASA wymyślili i już:) Dobrej zabawy z ASA Wam życzę! A jeśli macie jakieś inne obserwacje dajcie znać.