Automatyzacja odświeżania danych w Microsoft Fabric. Pipeline'y, harmonogramy i alerty

Automatyzację odświeżania danych w Microsoft Fabric realizuje pipeline: potok, który wykonuje operacje we właściwej kolejności, od odświeżenia transformacji, przez synchronizację danych, po odświeżenie modelu semantycznego, a w razie błędu wysyła powiadomienie, na przykład na Microsoft Teams. Potok uruchamia się według harmonogramu, z dokładnością co do minuty, albo zdarzeniowo, na przykład po wgraniu pliku do źródła. To ostatni element układanki, którą budowaliśmy na naszym webinarze o hurtowni danych 2.0: bez niego hurtownia jest zautomatyzowana tylko na papierze.

‍

Hurtownia jest tak dobra, jak świeże są jej dane

W poprzednich artykułach cyklu pokazaliśmy, jak zbudować transformacje, model semantyczny i raporty. Cała ta konstrukcja ma jednak sens tylko wtedy, gdy działa cyklicznie, bez człowieka przy każdym uruchomieniu. Transformacja zdefiniowana raz musi wykonywać się sama; inaczej zamieniliśmy ręczne podklejanie plików w Excelu na ręczne klikanie Refresh w Fabric, czyli zmieniliśmy narzędzie, ale nie proces.

Automatyzacja odświeżania to właśnie ten krok, który odróżnia zbudowane rozwiązanie od działającego rozwiązania.

‍

Pipeline jako orkiestrator, czyli dlaczego harmonogram na Dataflow to za mało

Najprostsza forma automatyzacji jest dostępna od ręki: harmonogram można ustawić bezpośrednio na transformacji Dataflow. Dla prostych scenariuszy to wystarczy. Problem w tym, że w realnej hurtowni odświeżenie to nie jedna operacja, tylko sekwencja, w której kolejność ma znaczenie.

Najpierw musi wykonać się transformacja, czyli załadowanie świeżych danych do Lakehouse. Potem trzeba odczekać na synchronizację: dane załadowane do Lakehouse nie są dostępne dla warstwy zapytań w tej samej sekundzie, synchronizacja endpointu potrafi zająć minutę lub dwie. Dopiero na końcu można odświeżyć model semantyczny, jeśli pracuje w trybie wymagającym odświeżenia, na przykład Import. Odpalenie tych operacji niezależnie, każdej na własnym harmonogramie, prędzej czy później skończy się modelem odświeżonym na starych danych.

Pipeline rozwiązuje ten problem z definicji: to orkiestrator, który wykonuje kroki po kolei, czeka tam, gdzie trzeba czekać, i rozgałęzia się w zależności od wyniku każdego kroku.

‍

Budowa pipeline'u krok po kroku

Potok z naszego webinaru składał się z czterech elementów, które można traktować jako wzorzec dla typowej hurtowni.

Krok 1: odświeżenie Dataflow. Pierwsza aktywność uruchamia transformację, czyli całą logikę łączenia i czyszczenia danych opisaną w artykule o budowie hurtowni krok po kroku. To najdłuższy i najbardziej newralgiczny etap potoku.

Krok 2: synchronizacja endpointu. Po załadowaniu danych do Lakehouse potok czeka na ich pełną dostępność. Można to zrealizować prostym odczekaniem, na przykład bezpiecznych stu dwudziestu sekund, ale lepszym rozwiązaniem jest dedykowana aktywność odświeżenia endpointu, która czeka dokładnie tyle, ile trzeba. Na webinarze pokazaliśmy tę drugą opcję jako nowszą funkcjonalność platformy.

Krok 3: odświeżenie modelu semantycznego. Ostatnia aktywność w ścieżce sukcesu odświeża warstwę semantyczną. Uwaga praktyczna: w trybie Direct Lake ten krok bywa zbędny, bo model czyta aktualne dane z OneLake bez odświeżania; szczegóły opisujemy w artykule o Direct Lake i Import. Wzorzec z odświeżeniem modelu obejmuje jednak także scenariusze z trybem Import, więc warto go znać.

Krok 4: rozgałęzienie sukces-błąd. Każda aktywność ma dwie ścieżki wyjścia: zieloną dla poprawnego wykonania i czerwoną dla błędu. Ścieżka sukcesu prowadzi do kolejnego kroku, ścieżka błędu do powiadomienia. To rozgałęzienie zamienia potok z sekwencji zadań w proces, który sam informuje o swoim stanie.

‍

Powiadomienia o błędach na Microsoft Teams

Ścieżka błędu w naszym wzorcu kończy się wiadomością na Microsoft Teams, wysyłaną przez skonfigurowany konektor. Efekt w praktyce: jeżeli nocne odświeżenie się wysypie, odpowiedzialna osoba dowiaduje się o tym rano z powiadomienia, a nie w południe od użytkownika, który zauważył stare dane w raporcie.

Ta różnica jest większa, niż się wydaje. Proces, który potrafi zawieść po cichu, wymaga codziennej ręcznej kontroli, czyli podważa sens automatyzacji. Proces, który sam zgłasza problemy, można zostawić w spokoju i reagować wyłącznie na alerty. Zaufanie do danych w organizacji buduje się właśnie na tej przewidywalności.

‍

Harmonogramy: od raz dziennie po co minutę

Gotowy potok podpinamy pod harmonogram. Fabric daje tu dokładność co do minuty, a wybór częstotliwości to decyzja praktyczna, nie techniczna: potok powinien uruchamiać się w rytmie, w jakim pojawiają się nowe dane źródłowe.

Jeżeli system ERP generuje eksporty raz dziennie, odświeżanie co godzinę niczego nie przyspieszy, a jedynie zużyje zasoby. W naszym scenariuszu webinarowym wystarczyło jedno odświeżenie dziennie, ustawione w porze, gdy wszystkie źródła miały już komplet danych za poprzedni dzień. Dobrą praktyką jest też uwzględnienie pory pracy użytkowników: odświeżenie powinno zakończyć się przed godziną, o której ludzie otwierają raporty.

‍

Odświeżanie zdarzeniowe: gdy harmonogram to za mało

Na webinarze padło pytanie, czy odświeżenie można wyzwolić dynamicznie, na przykład po wgraniu pliku do Blob Storage albo po aktualizacji pliku Excel. Można, i to na kilka sposobów.

Wyzwalacze zdarzeniowe. Dla źródeł takich jak Blob Storage można ustawić trigger reagujący na zdarzenie: pojawienie się nowego pliku uruchamia potok. Dane są przetwarzane natychmiast po ich dostarczeniu, bez czekania na najbliższy termin harmonogramu.

Uruchomienie przez API. Potok można też wywołać programowo, co pozwala wpiąć odświeżenie hurtowni w dowolny zewnętrzny proces: na przykład system, który kończy własny eksport danych, może od razu uruchomić ich przetworzenie w Fabric.

Kiedy harmonogram, a kiedy trigger? Reguła jest prosta. Harmonogram sprawdza się, gdy dane spływają w przewidywalnym rytmie: nocne eksporty, dzienne partie. Trigger wygrywa, gdy dane pojawiają się nieregularnie albo gdy liczy się czas od dostarczenia danych do ich widoczności w raporcie. Oba podejścia można łączyć: codzienny harmonogram jako podstawa plus trigger dla nadzwyczajnych dostaw danych.

‍

Copilot jako asystent budowy potoku

Szkielet opisanego wyżej potoku nie powstał na webinarze ręcznie. Poprosiliśmy Copilota, poleceniem w języku naturalnym, o potok odświeżający Dataflow, wysyłający wiadomość na Teams w razie błędu, czekający na synchronizację i odświeżający model semantyczny. Copilot wygenerował strukturę z poprawnym rozgałęzieniem sukces-błąd, a praca ręczna sprowadziła się do podpięcia klocków pod konkretne obiekty środowiska i konfiguracji konektora Teams.

Po zbudowaniu potoku Copilot oddał jeszcze jedną przysługę: na polecenie podsumował, co potok robi, dostarczając gotowy opis do dokumentacji. Więcej takich zastosowań zebraliśmy w artykule o Copilocie w Microsoft Fabric.

‍

Podsumowanie: pełna automatyzacja od źródła po raport

Ten artykuł domyka cykl o hurtowni danych 2.0. Złożone w całość elementy dają proces, w którym dane płyną od źródeł do raportu bez udziału człowieka: shortcuty i konektory dostarczają dane, Dataflow je transformuje, pipeline pilnuje kolejności i harmonogramu, model semantyczny udostępnia dane raportom i Excelowi, a alerty na Teams czuwają nad całością. Praca, którą kiedyś wykonywało się ręcznie po każdym okresie, została wykonana raz, przy budowie.

Zespół Power Center w ANEGIS projektuje takie procesy end-to-end: od architektury źródeł, przez transformacje i model, po orkiestrację i alerty. Jeśli Wasza hurtownia wciąż wymaga codziennej ręcznej obsługi, zapraszamy do kontaktu; pokażemy, jak wygląda ta sama praca wykonana raz.

‍