Co to jest Fabric Activator? Przekształcanie strumieni danych w zautomatyzowane akcje

Fabric Activator to silnik wykrywania zdarzeń bez kodowania i o niskim opóźnieniu, który automatycznie wyzwala akcje po wykryciu określonych wzorców lub warunków w źródłach danych. Najważniejsze możliwości to:

Stale monitoruje te źródła danych z opóźnieniem podrzędnym i inicjuje akcje po osiągnięciu progów lub wykryciu określonych wzorców. Te akcje mogą obejmować wysyłanie wiadomości e-mail lub powiadomień usługi Teams, uruchamianie przepływów usługi Power Automate lub integrowanie z systemami innych firm.

Architektura podstawowa

Activator to silnik wykrywania zdarzeń i reguł w sercu stosu inteligencji Fabric Real-Time. Architektura działa jako inteligentny obserwator — przetwarza strumienie danych o dużej szybkości, ocenia warunki reguły niemal w czasie rzeczywistym i inicjuje zautomatyzowane działania następcze na podstawie zmian w stanach zdarzeń.

Pasuje do reaktywnej architektury opartej na zdarzeniach, w której dane przepływają stale, a decyzje są podejmowane na podstawie stanowych ocen danych zdarzeń niemal w czasie rzeczywistym.

• źródła zdarzeń

  Aktywator łączy się bezpośrednio ze strumieniami zdarzeń, które pozyskują dane od różnych producentów (Azure Event Hubs, urządzenia IoT, niestandardowe punkty końcowe itp.). Strumienie te służą jako źródło zdarzeń, a aktywator może subskrybować co najmniej jeden strumień zdarzeń w celu obserwowania zmian danych. Inne źródła zdarzeń mogą obejmować zdarzenia Fabric lub platformy Azure albo aktywator nasłuchujący raportu Power BI lub pulpit nawigacyjny Real-Time.

• Zdarzenia i obiekty

  Zdarzenia to pojedyncze rekordy (na przykład sygnał telemetryczny lub upuszczanie pliku) odebrane za pośrednictwem strumienia zdarzeń. Te zdarzenia są grupowane w obiekty na podstawie identyfikatora współużytkowanego (na przykład bikepoint_id, device_id). Reguły są następnie oceniane dla każdego obiektu, co pozwala na szczegółowe wykrywanie (na przykład dla każdego czujnika lub zasobu).

• Reguły i warunki

  Każdy aktywator zawiera co najmniej jedną regułę, która jest stale oceniana. Te reguły mogą być prostymi porównaniami (value < threshold) lub wyrażeniami stanowymi, takimi jak BECOMES, DECREASES, INCREASES, , EXIT RANGElub brak danych (puls). Aktywator zapewnia śledzenie stanu dla każdego obiektu, co umożliwia wykrywanie złożonych wzorców w czasie.

• Akcje

  Gdy warunek reguły jest spełniony, aktywacja może wyzwalać:

  • potoki, notesy, funkcje lub definicje zadań platformy Spark w usłudze Fabric.

  • Akcje zewnętrzne za pośrednictwem usługi Power Automate.

  • Wysyłanie wiadomości usługi Teams do osoby, grupy lub kanału

  • Wyślij wiadomość e-mail

• Zarządzanie alertami i testowanie reguł

  Narzędzie aktywatora zapewnia podgląd i oszacowania wpływu przed włączeniem reguł, pokazując, jak często dana reguła byłaby uruchamiana na danych z przeszłości. Te funkcje pomagają zapobiegać spamowi powiadomień i zbyt częstemu uruchamianiu alertów. Przejścia stanu są wewnętrznie zarządzane w celu tłumienia szumu (na przykład wartość musi przekroczyć próg, a nie tylko pozostać pod nim).

• Monitorowanie i kontrola kosztów

  Koszty są naliczane tylko wtedy, gdy aktywatory są aktywnie uruchomione. Wystąpienia aktywatora są ograniczone do pojemności Fabric i mogą być monitorowane w obszarze roboczym. Dzienniki środowiska uruchomieniowego i dane telemetryczne są dostępne za pośrednictwem strumieni zdarzeń i danych wyjściowych potoku.

Model wdrażania

Wystąpienia aktywatora są wdrażane w ramach każdego obszaru roboczego oraz powiązane z określonymi źródłami danych. Wiele aktywatorów może monitorować ten sam strumień, umożliwiając ocenę reguł w sposób równoległy dla różnych funkcji biznesowych. Ponieważ aktywator jest powiązany z pojemnością, model płatności zgodnie z użyciem ma zastosowanie tylko wtedy, gdy reguły są aktywnie uruchomione — zapewniając efektywność kosztową dla scenariuszy wykrywania o charakterze przerywanym.

Punkty integracji w ramach inteligencji Real-Time

Aktywator jako orkiestrator

Efektywne korzystanie z Aktywatora w architekturze klasy korporacyjnej czasu rzeczywistego wymaga celowej orkiestracji składników usługi Microsoft Fabric oraz dostrajania wydajności pod kątem wolumenu zdarzeń, liczebności obiektów i złożoności reguł. W tej sekcji opisano sposób organizowania aktywatora z innymi usługami oraz optymalizowania logiki wykrywania i zachowania środowiska uruchomieniowego w celu obsługi małych opóźnień i ekonomicznej automatyzacji na dużą skalę.

Activator odgrywa kluczową rolę w potokach sterowanych zdarzeniami, oceniając dane w momencie przybycia i wyzwalając akcje w dalszych etapach. Typowe wzorce aranżacji obejmują:

Podstawowe pojęcia

Aktywator usługi Microsoft Fabric działa jako wysokowydajny stanowy silnik reguł, zaprojektowany do oceny zdarzeń strumieniowych o niskich opóźnieniach. W jego rdzeniu aktywator przetwarza zdarzenia w czasie rzeczywistym emitowane za pośrednictwem strumienia zdarzeń, ocenia warunki reguły dla każdego obiektu logicznego i inicjuje akcje podrzędne w odpowiedzi na przejścia stanu. Aby zapoznać się z omówieniem Fabric Activator, zobacz Wprowadzenie do Fabric Activator.

Poniższe pojęcia służą do budowania i wyzwalania automatycznych działań i odpowiedzi w Fabric Activator.

Źródła zdarzeń i zdarzenia

Fabric Activator traktuje wszystkie źródła danych jako strumienie zdarzeń. Zdarzenie reprezentuje obserwację stanu obiektu i zazwyczaj zawiera identyfikator obiektu, znacznik czasu i wartości monitorowanych pól.

Zdarzenia wprowadzone do aktywatora pochodzą z:

• Strumień zdarzeń, który obsługuje wiele źródeł pochodzeniowych (na przykład Azure Event Hubs, IoT Hub, wyzwalacze Blob Storage). Strumień zdarzeń to określony typ elementu w usłudze Microsoft Fabric, który umożliwia pozyskiwanie, przekształcanie i kierowanie zdarzeń w czasie rzeczywistym bez konieczności pisania kodu. Aktywator Fabric monitoruje strumień zdarzeń i automatycznie podejmuje działania po wykryciu zdefiniowanych wzorców lub progów. Aktywator może również subskrybować co najmniej dwa strumienie zdarzeń w celu obserwowania zmian danych. Strumienie zdarzeń różnią się częstotliwością. Na przykład czujniki IoT emitują zdarzenia wiele razy na sekundę, a systemy logistyczne generują zdarzenia sporadycznie, na przykład gdy pakiety są skanowane w lokalizacjach wysyłki.
• Zdarzenia fabric. Na przykład zdarzenia elementu obszaru roboczego Fabric to odrębne zdarzenia tego systemu, które występują po wprowadzeniu zmian w Twoim obszarze roboczym Fabric. Te zmiany obejmują tworzenie, aktualizowanie lub usuwanie elementu Fabric.
• Zdarzenia platformy Azure. Na przykład zdarzenia usługi Azure Blob Storage są wyzwalane po utworzeniu, zastąpieniu, usunięciu obiektu blob itp.
• Raport usługi Power BI. W takim przypadku zdarzenia są okresowymi obserwacjami na podstawie harmonogramu odświeżania modelu semantycznego usługi Power BI (wcześniej znanego jako zestaw danych). Te obserwacje mogą wystąpić codziennie lub co tydzień, tworząc powolny strumień zdarzeń.
• Panel sterowania Real-Time architektury.

Każde zdarzenie zawiera:

• Znacznik czasu
• Ładunek (dane ustrukturyzowane lub częściowo ustrukturyzowane)
• Co najmniej jeden atrybut używany do identyfikacji obiektów (na przykład device_id, bikepoint_id)

Obiekty

W module Fabric Activator monitorowane jednostki są nazywane obiektami biznesowymi, które mogą być fizyczne lub koncepcyjne. Przykłady obejmują obiekty fizyczne, takie jak zamrażarki, pojazdy, pakiety i użytkowników oraz obiekty koncepcyjne, takie jak kampanie reklamowe, konta klientów, sesje użytkowników.

Aby modelować obiekt biznesowy w aktywatorze, należy połączyć co najmniej jeden strumień zdarzeń, wybrać kolumnę, która będzie służyć jako identyfikator obiektu, i określić pola, które mają być traktowane jako właściwości obiektu.

Termin instancja obiektu odnosi się do konkretnego przykładu obiektu biznesowego, takiego jak zamrażarka, pojazd lub sesja użytkownika. Natomiast obiekt zazwyczaj odnosi się do ogólnej definicji lub klasy (na przykład zamrażarki jako typu). Termin populacja jest używany do pełnego zestawu monitorowanych wystąpień obiektów.

Tworzenie obiektu jest niejawne: Aktywator grupuje zdarzenia przy użyciu wyznaczonego klucza obiektu. Reguły są ograniczone do obiektów, co oznacza, że cała logika oceny jest świadoma obiektów i niezależna od wystąpień. Na przykład reguła monitorowania bikepoint_id tworzy odrębne oceny logiczne dla każdej unikatowej stacji rowerowej.

Reguły

Reguły definiują warunki, które mają być wykrywane w obiektach, oraz akcje, które mają zostać wykonane po spełnieniu tych warunków. Na przykład reguła dotycząca obiektu zamrażarki może wykrywać sytuacje, gdy temperatura wzrasta powyżej bezpiecznego progu i automatycznie wysyłać alert e-mail do przypisanego technika.

Reguły w aktywatorze mogą być bezstanowe lub stanowe:

• Reguły bezstanowe oceniają każde zdarzenie w izolacji (na przykład wartość < 50).
• Reguły stanowe utrzymują pamięć między zdarzeniami dla obiektu (na przykład wartość ZMNIEJSZA SIĘ, STAJE SIĘ, OPUSZCZA ZAKRES)

Ocena stanowa opiera się na:

• Wykrywanie różnic: śledzi zmiany między poprzednimi i bieżącymi wartościami zdarzeń.
• Sekwencjonowanie czasowe: ocenia warunki oparte na czasie, takie jak brak zdarzeń (wykrywanie pulsu)
• Przejścia stanów: Reguły uruchamiają się tylko podczas wchodzenia do nowego stanu, zapobiegając wielokrotnemu uruchamianiu się w niezmienionych warunkach

Każdy warunek reguły jest kompilowany w graf wykonawczy, który jest oceniany na bieżąco, w pamięci i niemal natychmiastowo. System jest zoptymalizowany pod kątem opóźnienia podejmowania decyzji podrzędnych po nadejściu zdarzenia.

Czynności

Gdy warunki reguły zostaną spełnione i zainicjowano akcję, mówi się, że reguła ma zostać aktywowana. Obsługiwane cele działania obejmują:

• Infrastrukturę przepływów danych (do przenoszenia danych, wzbogacania)
• Notesy Fabric (do oceniania w uczeniu maszynowym, diagnostyki)
• Zadania Spark Fabric (dla prac wsadowych i przesyłania strumieniowego)
• Funkcje Fabric (do tworzenia niestandardowej logiki biznesowej przy użyciu kodu)
• Przepływy usługi Power Automate (na potrzeby integracji procesów biznesowych)
• Powiadomienia usługi Teams (przy użyciu wiadomości opartych na szablonach)
• Powiadomienia e-mail

Aktywator emituje komunikat wyzwalający z bieżącym stanem obiektu i metadanymi reguły, a akcje są nieblokujące, to znaczy, że aktywator nie czeka na ukończenie akcji, aby umożliwić skalowalne przepływy asynchroniczne.

Właściwości

Właściwości to określone pola lub atrybuty obiektu biznesowego, który chcesz monitorować. Mogą to być cechy fizyczne lub koncepcyjne, takie jak:

• Temperatura pakietu
• Stan przesyłki
• Saldo konta klienta
• Wynik zaangażowania sesji użytkownika

Pochodzą one z strumieni zdarzeń, które są ciągłymi przepływami danych ze źródeł, takich jak czujniki IoT, raporty usługi Power BI lub inne systemy.

Podczas definiowania obiektu biznesowego w aktywatorze łączy się co najmniej jeden strumień zdarzeń, wybierz kolumnę, która będzie służyć jako identyfikator obiektu, i wybierz inne kolumny, które mają być traktowane jako właściwości tego obiektu. Możesz utworzyć reguły dotyczące tych właściwości, aby śledzić zmiany w czasie, wykrywać, kiedy właściwość przekracza próg lub wykracza poza zakres lub wyzwalać akcje, takie jak alerty, przepływy pracy lub powiadomienia.

Właściwości są również przydatne, gdy chcesz ponownie użyć logiki w wielu regułach. Na przykład w obiekcie zamrażarki można zdefiniować właściwość, która oblicza średnią temperaturę w okresie jednej godziny. Po zdefiniowaniu tej właściwości można odwoływać się do wielu reguł, takich jak te, które wykrywają przegrzanie, wahania temperatury lub progi konserwacji — bez duplikowania logiki. Scentralizowanie logiki we właściwościach ułatwia zarządzanie regułami, ich spójność i łatwiejsze aktualizowanie w czasie.

Okres retrospektywny

Okres wsteczny odnosi się do zakresu danych historycznych, które Activator analizuje w celu oceny reguły. Gwarantuje to, że wystarczająca ilość wcześniejszych danych jest dostępna do dokładnego wykrywania wzorców lub agregacji obliczeniowych, takich jak średnie, nawet jeśli dane docierają późno lub nieregularnie.

Okres retrospektywny jest określany przez:

• Sposób definiowania reguły, na przykład tego, czy wymaga analizowania trendów, wykrywania anomalii czy porównywania wartości w czasie.
• Ilość danych przychodzących, takich jak liczba zdarzeń na sekundę w strumieniu zdarzeń.

Rozważmy operację logistyki farmaceutycznej transportując pakiety leków w zimnym łańcuchu. Celem jest otrzymanie alertu, gdy pakiet stanie się zbyt ciepły.

Załóżmy, że reguła jest zdefiniowana na:

• Ocena średniej temperatury każdego pakietu w oknie trzygodzinnym
• Wyzwalanie alertu, jeśli średnia temperatura przekracza 8°C

Aby dokładnie obliczyć tę regułę, Fabric Activator musi analizować szersze okno danych historycznych, w szczególności sześciogodzinny okres retrospekcji. Gwarantuje to, że wystarczająca ilość danych jest dostępna do obliczenia średniej trzygodzinnej w dowolnym momencie, nawet jeśli dane docierają z pewnym opóźnieniem lub nieregularnością.

Okres retrospekcji jest niezbędny do umożliwienia terminowego i dokładnego wykrywania warunków, zwłaszcza w scenariuszach, w których wzorce danych ewoluują w czasie.

Unikatowe, aktywne identyfikatory obiektów

Reguły oparte na atrybutach służą do monitorowania, w jaki sposób określone atrybuty obiektu zmieniają się w czasie. W przykładzie logistyki farmaceutycznej każdy pakiet leków jest reprezentowany przez unikatowy identyfikator obiektu, a system otrzymuje okresowe odczyty temperatury dla każdego pakietu.

Aby skutecznie ocenić te reguły, Mechanizm Aktywatora śledzi aktywne identyfikatory obiektów, czyli obiekty, dla których zdarzenia docierają w zdefiniowanym okresie retrospekcji. To zachowanie gwarantuje, że podczas stosowania reguł są brane pod uwagę tylko istotne, obecnie aktywne obiekty.

Na przykład stacja opłat może śledzić pojazdy (identyfikatory obiektów) podczas ich przechodzenia. Każdy pojazd generuje zdarzenia (na przykład skanowanie wejścia i wyjścia), a tylko te obiekty z ostatnim działaniem są uznawane za aktywne i oceniane przez system.

Istnieją również limity oparte na liczbie unikatowych identyfikatorów obiektów (liczbie pakietów) śledzonych w określonym oknie czasowym.

Typowe przypadki użycia

Oto kilka rzeczywistych scenariuszy, w których można użyć Fabric Activator:

• Automatyczne uruchamianie kampanii reklamowych w przypadku spadku sprzedaży w tym samym sklepie, co pomaga zwiększyć wydajność w niedostatecznych lokalizacjach.
• Powiadom menedżerów sklepów spożywczych o przeniesieniu żywności z nieprawidłowo działającej zamrażarki przed uszkodzeniem.
• Uruchomienie spersonalizowanych przepływów pracy komunikacyjnych, gdy doświadczenie klienta między aplikacjami, witrynami internetowymi lub innymi punktami kontaktowymi wskazuje na negatywne doświadczenie.
• Proaktywnie inicjuj przepływy pracy dochodzeniowej, gdy stan przesyłki nie został zaktualizowany w zdefiniowanym przedziale czasu, co ułatwia szybsze znajdowanie zaginionych paczek.
• Powiadom zespoły obsługujące konta, gdy klienci mają zaległości, używając niestandardowych progów dla czasu lub zaległych sald dla każdego klienta.
• Monitoruj stan zdrowia potoku i automatycznie uruchamiaj ponownie zadania, które zakończyły się niepowodzeniem, albo wysyłaj alerty do zespołów w przypadku wykrycia anomalii lub awarii.

Następny krok

Zobacz Samouczek: Tworzyć i aktywować regułę Fabric Activator.