--- title: "Real-Time Intelligence w Fabric: od zdarzenia do reakcji" url: "https://majchrzycki.com/blog/co-to-jest-real-time-intelligence-w-microsoft-fabric" description: "Sprawdź, jak ocenić Real-Time Intelligence. Poznaj kryteria decyzji, ograniczenia i praktyczny sposób sprawdzenia wyniku." --- # Real-Time Intelligence w Fabric: od zdarzenia do reakcji 30 czerwca 2024· Aktualizacja: 18 września 2026·3 min czytania·Krzysztof Majchrzycki Temat: [Microsoft AI](https://majchrzycki.com/blog/filar/microsoft-ai) 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](https://learn.microsoft.com/en-us/fabric/real-time-intelligence/overview) 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](https://learn.microsoft.com/en-us/fabric/real-time-intelligence/event-streams/overview) 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](https://learn.microsoft.com/en-us/fabric/real-time-intelligence/data-activator/activator-introduction) 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](https://majchrzycki.com/blog/co-to-jest-data-factory-integracja-danych-w-microsoft-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](https://majchrzycki.com/system). Wybierz szybkość, którą zespół potrafi wykorzystać. - Dane i analityka - Zarządzanie zmianą - Strategia ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [Microsoft Fabric: jak ocenić platformę danych dla firmy](https://majchrzycki.com/blog/co-to-jest-microsoft-fabric-poradnik-dla-firm) - [Jak odebrać integrację danych w Fabric Data Factory](https://majchrzycki.com/blog/jak-odebrac-integracje-danych-data-factory-w-microsoft-fabric) - [Jak odebrać potok danych w Fabric Data Engineering](https://majchrzycki.com/blog/jak-odebrac-potok-danych-data-engineering-w-microsoft-fabric) - [Architektura danych w Fabric: od źródła do decyzji](https://majchrzycki.com/blog/nowoczesna-architektura-danych-z-platformą-microsoft-fabric)