Real-Time Intelligence w Fabric: od zdarzenia do reakcji

Raport pokazuje opóźnione zamówienie dopiero po zakończeniu zmiany. Kierownik widzi problem, ale nie może już przeplanować wysyłki. Real-Time Intelligence w Microsoft Fabric ma sens wtedy, gdy wcześniejsza informacja pozwala wykonać inne działanie. Częstsze odświeżanie wykresu samo w sobie nie tworzy wartości. Najpierw ustal, kto reaguje na zdarzenie i ile czasu ma na decyzję.

Do czego służy Real-Time Intelligence

Real-Time Intelligence łączy obsługę danych napływających w czasie, ich analizę, wizualizację i reakcję na określone warunki. Może służyć do pracy z telemetrią urządzeń, logami aplikacji lub zdarzeniami biznesowymi. Microsoft podkreśla, że zastosowanie nie wymaga ogromnego wolumenu: znaczenie ma również reagowanie na zdarzenia zamiast oczekiwania na harmonogram. Opis Real-Time Intelligence przedstawia te scenariusze.

Z perspektywy właściciela procesu rozdziel trzy chwile: wystąpienie zdarzenia, zauważenie go przez system oraz faktyczną reakcję człowieka lub aplikacji. Jeżeli skrócisz drugą część z godziny do minuty, lecz zgłoszenie nadal czeka do następnego dnia, efekt operacyjny będzie ograniczony. Dlatego wymaganie powinno dotyczyć całej drogi do działania.

Nie zaczynaj od hasła „wszystko na żywo”. Wybierz konkretną stratę, której wcześniejsza informacja może zapobiec: przekroczenie terminu, narastającą kolejkę albo nieskuteczne wykonanie zadania. Opisz również sytuacje, w których alarm byłby zbędny.

Jak układają się elementy Fabric

Real-Time hub pomaga odnajdywać i udostępniać strumienie. Eventhouse służy przechowywaniu i analizie zdarzeń, między innymi za pomocą języka KQL. Real-Time dashboards przedstawiają wyniki analizy. To różne zadania w jednym rozwiązaniu, a nie zamienne nazwy tej samej funkcji. Ich połączenie opisuje dokumentacja przeglądowa Microsoft.

Eventstreams umożliwiają przyjmowanie zdarzeń, przekształcanie ich i kierowanie do obsługiwanych miejsc docelowych. Edytor wizualny obejmuje między innymi filtrowanie i agregacje. Dostępność konkretnego konektora oraz jego status sprawdź przed zaprojektowaniem przepływu; lista zawiera również funkcje preview. Obecność podobnego źródła na slajdzie nie potwierdza obsługi Twojej konfiguracji.

W praktycznej rozmowie projektowej użyj poniższego podziału:

Pytanie biznesowe	Element rozwiązania do oceny	Dowód przy odbiorze
Skąd przychodzi zdarzenie?	Źródło i eventstream	Zdarzenie testowe dociera z poprawnym identyfikatorem
Co wydarzyło się wcześniej?	Eventhouse i zapytanie	Można odtworzyć przebieg przypadku
Co powinien zobaczyć kierownik?	Dashboard	Widzi problem wraz z czasem danych
Kto ma podjąć działanie?	Reguła i kanał reakcji	Właściwa osoba otrzymuje jedno użyteczne zgłoszenie

Nie każdy projekt wymaga wszystkich elementów. Zakres ustal na podstawie pytania i danych, które już istnieją w firmie.

Reguła alarmu jest częścią procesu

Fabric Activator pozwala reagować na warunki w danych, na przykład uruchamiając powiadomienie lub przepływ. Sama możliwość wywołania akcji nie określa, czy akcja jest właściwa. Potrzebujesz reguły biznesowej oraz osoby odpowiedzialnej za jej utrzymanie.

Dla modelowego procesu wysyłki zapisz: „zgłoś zamówienie gotowe do wydania, które przez ustalony czas nie otrzymało potwierdzenia odbioru”. To precyzyjniejsze niż „alarmuj o opóźnieniach”. Następnie uzgodnij, co robić z anulowaniem, ponowionym komunikatem i zdarzeniem dostarczonym po czasie. Nie zakładaj, że kolejność przyjścia zawsze odpowiada kolejności zdarzeń w magazynie.

Rozdziel też informowanie i wykonywanie operacji. Zgłoszenie do koordynatora można ocenić inaczej niż automatyczną zmianę priorytetu zamówienia. Przed włączeniem tej drugiej akcji ustal warunki cofnięcia, rejestr decyzji oraz sposób zatrzymania automatyzacji. Pierwszy pilotaż może jedynie zapisywać proponowane reakcje, aby właściciel procesu porównał je z rzeczywistym przebiegiem pracy.

Jak ocenić pilotaż

Poniższe kryteria są propozycją projektową, nie deklarowanymi parametrami usługi. Wartości dopasuj do kosztu opóźnienia i możliwości zespołu.

Próba	Co mierzyć	Czego uniknąć
Zwykłe zdarzenie	Czas od wystąpienia do reakcji	Pomiaru wyłącznie czasu renderowania wykresu
Ten sam komunikat ponownie	Liczbę zgłoszeń dla jednej sprawy	Kilku zadań opisujących ten sam problem
Zdarzenie spóźnione	Poprawność interpretacji czasu	Alarmu dotyczącego dawno rozwiązanej sprawy
Przerwa w źródle	Widoczność braku danych	Zielonego statusu wynikającego z ciszy
Zwiększony ruch	Opóźnienie i zużycie zasobów	Oceny wydajności na kilku rekordach

Przykład syntetyczny: reguła wygenerowała 100 alarmów. Właściciel procesu potwierdził, że 70 wymagało interwencji, a 30 było niepotrzebnych. Udział użytecznych alarmów wynosi 70%. Ta liczba nie mówi jeszcze, ile problemów system przeoczył. Jeżeli w badanym okresie wystąpiło łącznie 90 rzeczywistych przypadków wymagających reakcji, wykryto 70 z 90, czyli około 77,8%. Obie miary są potrzebne do oceny reguły.

Porównaj te wyniki z wcześniejszym sposobem pracy. Zapisz czas obsługi fałszywego alarmu i konsekwencję przeoczenia problemu. Zwiększenie czułości może pomóc wykrywać więcej przypadków, ale przeciążyć koordynatora. Próg dobierasz do kosztów obu błędów, a nie do atrakcyjnego procentu na prezentacji.

Sprawdź również odpowiedzialność poza typowymi godzinami pracy. Powiadomienie wysłane do osoby, która nie ma dyżuru ani zastępstwa, pozostaje jedynie śladem w systemie. W karcie reguły wskaż odbiorcę, zastępcę, czas reakcji i warunek zamknięcia. Przy zmianie organizacji zaktualizuj te informacje razem z konfiguracją rozwiązania.

Przed odbiorem wskaż również osobę, która może wyłączyć wadliwą regułę. Zapisz powód wyłączenia i warunki jej ponownego uruchomienia, aby po poprawce nie przywrócić przypadkowo starego błędu.

Następny krok bez wielkiego projektu

W poniedziałek wybierz jedną kategorię zdarzeń i zapisz, jaka wcześniejsza decyzja zmieniłaby jej wynik. Uzgodnij próbkę obejmującą zwykły przebieg, opóźnienie i ponowienie. Dopiero po sprawdzeniu tych przypadków decyduj o automatycznej reakcji lub rozszerzeniu strumienia.

Jeżeli dane wystarczy przygotowywać okresowo, przeczytaj również o Data Factory w Fabric. Porównanie pomoże dopasować sposób integracji do rzeczywistego rytmu decyzji. Powiązanie odpowiedzialności, informacji i działania opisuje podejście do systemu firmy. Wybierz szybkość, którą zespół potrafi wykorzystać.