Jak odebrać potok danych w Fabric Data Engineering

Zadanie zakończyło się zielonym statusem, a raport nadal pomija zamówienia z jednego oddziału. Odbiór potoku Data Engineering w Fabric musi obejmować wynik biznesowy, ponowne uruchomienie i zachowanie przy błędzie. Status wykonania potwierdza przebieg programu w określonych warunkach. Nie zastępuje uzgodnienia, czy otrzymane dane odpowiadają temu, co miało trafić do analizy.

Jeżeli masz zatwierdzić wdrożenie jako właściciel procesu, poproś o dowody z kilku zaplanowanych prób. Nie musisz czytać każdej linii kodu. Potrzebujesz zrozumiałych danych wejściowych, oczekiwanego wyniku i osoby odpowiedzialnej za wyjaśnienie rozbieżności.

Jeżeli zamiast kryteriów odbioru szukasz wprowadzenia — czym Data Engineering w Fabric w ogóle jest i od czego zacząć — zacznij tutaj.

Dwie części odbioru

Fabric udostępnia monitorowanie aplikacji Spark uruchamianych z notebooków, definicji zadań i potoków. Można przeglądać uruchomienia, statusy, szczegóły wykonania oraz informacje pomocne przy diagnozie błędów. Dokumentacja monitorowania Spark opisuje dostępne miejsca kontroli. To dobry początek odbioru technicznego.

Drugą częścią jest sprawdzenie danych. Czy tabela zawiera właściwy okres? Czy korekta faktury zmieniła wynik? Czy ponowione pobranie nie dopisało drugi raz tych samych pozycji? Te pytania wynikają z procesu firmy. Trzeba zamienić je w warunki, które zespół potrafi sprawdzić i udokumentować.

Rozdzielenie obu części pozwala uniknąć sporu o znaczenie słowa „działa”. Inżynier może poprawnie stwierdzić, że zadanie wykonało wszystkie polecenia. Kontroler może równie poprawnie zauważyć, że suma jest niezgodna. Potrzebujecie wspólnego kryterium zakończenia pracy.

Przygotuj próbkę z oczekiwanym wynikiem

Wybierz mały zestaw przypadków, który da się policzyć ręcznie. Powinien zawierać zwykłe rekordy oraz sytuacje graniczne występujące w Twoim procesie. Dane testowe oznacz i oddziel od produkcyjnych, żeby próba nie zmieniła raportów używanych przez firmę.

Poniższa tabela jest propozycją scenariuszy odbioru, a nie listą automatycznych kontroli wbudowanych w Fabric.

Przypadek	Co przygotować	Oczekiwany dowód
Poprawna dostawa	Mały zbiór o znanej sumie	Wynik zgodny z ręcznym obliczeniem
Powtórzona dostawa	Ten sam zakres uruchomiony ponownie	Brak nieuzasadnionego podwojenia danych
Korekta	Zmieniona wartość istniejącego dokumentu	Zastosowana uzgodniona reguła aktualizacji
Brak pola	Rekord bez obowiązkowego identyfikatora	Jawne odrzucenie lub obsługa wyjątku
Przerwa	Kontrolowane zatrzymanie przed końcem	Znany stan i bezpieczny sposób wznowienia

Dla każdej próby zapisz wynik przed uruchomieniem. Gdy opis powstaje dopiero po obejrzeniu tabeli końcowej, łatwo dopasować kryterium do tego, co akurat zrobił program. Odbiorca biznesowy powinien potwierdzić oczekiwania, a wykonawca wyjaśnić różnice.

Zwróć uwagę na czas. Data dokumentu, data jego modyfikacji i chwila pobrania to różne informacje. Jeżeli korekta dotyczy poprzedniego miesiąca, filtr po dacie wystawienia może jej nie uwzględnić. Zasada obsługi korekt musi być jawna.

Ponowienie nie może pogarszać wyniku

Wyobraź sobie syntetyczną próbę: pierwsze uruchomienie zapisuje 100 zamówień o łącznej wartości 50 000 PLN. Drugie dostarcza identyczne dane. Oczekujesz nadal 100 zamówień i 50 000 PLN, jeżeli umówiony wynik reprezentuje aktualny zbiór zamówień. Otrzymanie 200 rekordów i 100 000 PLN oznacza błąd dla takiego modelu, mimo że oba uruchomienia mogły zakończyć się poprawnym statusem.

Nie zawsze jednak powtórzony identyfikator jest duplikatem. W historii zmian dwa wiersze mogą reprezentować dwa różne stany tego samego zamówienia. Dlatego przed testem ustal znaczenie pojedynczego rekordu i klucz, który odróżnia przypadki. Mechaniczne usuwanie powtórzeń może skasować potrzebną historię.

Podobnie zaplanuj wznowienie po częściowym zapisie. Zespół powinien pokazać, skąd wie, które dane zostały już przetworzone i co wolno wykonać ponownie. W instrukcji utrzymania zapisz wymagane sprawdzenia. Sam przycisk ponownego uruchomienia nie rozstrzyga, czy operacja jest bezpieczna dla tabel wynikowych.

Sprawdź, czy błąd będzie widoczny

Odbiór obejmuje również zachowanie odbiorców danych. Jeśli zadanie nie skończyło się na czas, raport nie powinien sugerować, że pokazuje dzisiejszy stan. Ustal, czy zachowujecie ostatni poprawny wynik, zatrzymujecie publikację, czy dopuszczacie dane częściowe z wyraźnym oznaczeniem.

Obszar	Pytanie przy odbiorze	Odpowiedzialność do przypisania
Aktualność	Skąd użytkownik zna czas danych?	Właściciel raportu
Niekompletność	Kiedy blokujemy udostępnienie?	Właściciel procesu
Awaria	Kto dostaje informację i ją potwierdza?	Zespół utrzymania
Zmiana reguł	Kto zatwierdza nową interpretację?	Właściciel danych
Odtworzenie	Jak wracamy do poprawnego stanu?	Wykonawca i utrzymanie

W szczegółach aplikacji Spark można sprawdzać między innymi zadania, logi i informacje o wykonaniu. Opis monitorowania szczegółowego pomaga wskazać materiał do diagnozy. Do protokołu dołącz identyfikator uruchomienia oraz wynik kontroli danych, aby później połączyć objaw biznesowy z konkretną próbą.

Koszt i czas też wymagają próby

Po poprawności sprawdź reprezentatywną wielkość danych. Wynik na kilkunastu rekordach nie potwierdza, że proces zdąży przed poranną odprawą. Uzgodnij okno wykonania i zanotuj zużycie zasobów dla normalnego obciążenia oraz okresu wzmożonej pracy.

Nie przenoś pojedynczego pomiaru na cały rok. Kolejne zadania mogą współdzielić zasoby, a źródło może odpowiadać inaczej w godzinach szczytu. Zapisz warunki pomiaru i dopuszczalne odchylenie. Jeśli próba przekracza limit, decyzja powinna dotyczyć konkretnej poprawki albo zmiany wymagania.

Do próby odtworzenia dołącz wersję reguł oraz zakres danych wejściowych. Pozwoli to rozstrzygnąć, czy różnica wynika z poprawki kodu, czy z późniejszej zmiany źródła.

Co podpisać na koniec

Protokół odbioru powinien wskazywać sprawdzone przypadki, pozostałe ograniczenia i właściciela utrzymania. Brak krytycznych błędów nie oznacza, że przetestowano każdą możliwą sytuację. Zapisany zakres pozwala później świadomie rozszerzać rozwiązanie.

W poniedziałek wybierz jedną tabelę i przygotuj próbę ponowienia oraz korekty. Jeśli potrzebujesz uporządkować zależności między pobraniem i przetwarzaniem, przeczytaj o Data Factory w Fabric. Powiązanie odbioru z odpowiedzialnością opisuje podejście do systemu firmy. Zatwierdzaj proces, którego wynik można sprawdzić, wyjaśnić i bezpiecznie odtworzyć.