Architektura danych w Fabric: od źródła do decyzji

Architektura danych w Microsoft Fabric powinna opisywać drogę od zdarzenia w systemie źródłowym do decyzji odbiorcy. Każdy etap potrzebuje zadania, właściciela i warunku odbioru. Schemat wypełniony wszystkimi modułami platformy nie jest jeszcze projektem, jeśli nie wiadomo, skąd bierze się wynik, kiedy jest kompletny i kto naprawia błąd.

Dobrym punktem wyjścia jest jeden proces, na przykład codzienna ocena rentowności projektów. Dopiero po ustaleniu potrzebnych danych, definicji i częstotliwości warto dobierać sposób integracji, magazyn analityczny oraz raport. Taka kolejność ogranicza złożoność i pomaga sprawdzić, które elementy rzeczywiście są potrzebne.

Opisz decyzję i wymagania odbiorcy

Zacznij od pytania, co ma zrobić osoba korzystająca z wyniku. Kierownik może potrzebować wskazania projektów zagrożonych przekroczeniem kosztu. Zarząd może porównywać marżę między miesiącami. Te potrzeby korzystają z części wspólnych danych, ale nie muszą wymagać identycznej szczegółowości i aktualności.

Zapisz czas, w którym informacja zachowuje wartość. Jeśli decyzja zapada raz w tygodniu, przetwarzanie każdej zmiany w ciągu sekund może być niepotrzebne. Jeżeli reakcja musi nastąpić podczas zdarzenia, nocny raport nie spełni wymagania niezależnie od jakości wizualizacji.

Ustal miary oraz zasady interpretacji. Co jest kosztem projektu? Jak traktować korektę i dokument bez przypisania? Kiedy wynik uznaje się za kompletny? Te decyzje powinny być zatwierdzone przez właściciela biznesowego, zanim zostaną zapisane w transformacji.

Nie pomijaj informacji o niepewności. Odbiorca powinien wiedzieć, czy dane są kompletne, wstępne czy opóźnione. Architektura musi przewidywać dostarczenie takiego statusu, zamiast pokazywać ostatnią dostępną liczbę bez kontekstu.

Narysuj przepływ i kontrakty między etapami

Dla każdego źródła określ strukturę, klucz rekordu, sposób wykrywania zmian oraz dostępność. Następnie opisz, jaki wynik przekazuje ono do kolejnego etapu. Taki kontrakt pomaga ustalić, czy błąd powstał przed pobraniem danych, podczas przetwarzania czy w warstwie raportowej.

Etap	Zadanie	Przykładowy warunek odbioru
Źródło	Dostarczenie uzgodnionych danych	Dostępny identyfikator i informacja o zmianie
Pozyskanie	Pobranie lub udostępnienie danych	Znany zakres oraz kompletność dostawy
Przygotowanie	Typy, klucze, duplikaty i reguły jakości	Przejście kontroli lub jawny wyjątek
Model biznesowy	Uzgodnione miary i relacje	Wynik zgodny z zatwierdzonym przykładem
Udostępnienie	Dostęp dla właściwych odbiorców	Poprawny raport na docelowej roli
Działanie	Wykorzystanie wyniku w procesie	Zidentyfikowany właściciel decyzji

Przy kontrakcie zapisz również zmianę i awarię. Co się dzieje, gdy źródło doda kolumnę, zmieni typ albo przestanie zwracać rekord? Kto otrzymuje informację i czy można publikować wcześniejsze dane? Brak tych odpowiedzi zwykle ujawnia się dopiero po pierwszym problemie produkcyjnym.

Kontrakty nie muszą być rozbudowanymi dokumentami. Ważniejsze jest, aby były jednoznaczne, dostępne dla zespołu i powiązane z testami. Prosty opis z przykładem wejścia oraz oczekiwanego wyniku może być bardziej użyteczny niż ogólny diagram bez reguł.

Dobierz sposób pozyskania do źródła

Dane można pobierać okresowo, przetwarzać przyrostowo lub udostępniać bez tworzenia pełnej kolejnej kopii. Wybór zależy od możliwości źródła, wymaganego opóźnienia i potrzeby zachowania historii. Nie każda aplikacja udostępnia zmiany w sposób pozwalający zbudować taką samą integrację.

Przy odczycie przyrostowym ustal, jak rozpoznawane są korekty i usunięcia. Sam filtr po dacie utworzenia może pomijać późniejsze zmiany. Sprawdź też strefy czasowe oraz sytuację, w której rekord pojawia się z opóźnieniem po zakończeniu wcześniejszego odczytu.

OneLake shortcuts są odwołaniami do danych w innych lokalizacjach. Mogą ograniczyć kopiowanie, ale nie zastępują planu historii i odtwarzania. Przeniesienie lub usunięcie wskazanego celu może przerwać dostęp, dlatego taka zależność musi być widoczna w projekcie.

Nie zapisuj wymagania „wszystko w czasie rzeczywistym” bez konkretnej potrzeby. Określ dopuszczalne opóźnienie dla każdego wyniku. Część danych może docierać częściej, a inne po zamknięciu okresu. Architektura powinna pokazać, jak te różne rytmy łączą się w spójny obraz.

Oddziel dane źródłowe, przygotowane i biznesowe

Wzorzec medallion w Fabric rozróżnia warstwy bronze, silver i gold. Odpowiadają one etapom od danych surowych przez przygotowane do danych przeznaczonych do wykorzystania biznesowego. To sposób uporządkowania odpowiedzialności za przekształcenia, a nie magiczna gwarancja jakości.

W warstwie wejściowej ważna jest możliwość ustalenia, co rzeczywiście otrzymano. Na etapie przygotowania kontrolujesz formaty, klucze i duplikaty. W warstwie biznesowej wprowadzasz zatwierdzone definicje oraz struktury potrzebne odbiorcom. Błąd powinien dać się zlokalizować między tymi etapami.

Nie usuwaj niepoprawnych rekordów bez śladu. Jeśli wiersz nie ma wymaganego przypisania, określ miejsce jego obsługi oraz osobę odpowiedzialną. Ciche pominięcie może dać technicznie poprawny raport z niepełną wartością sprzedaży lub kosztu.

Podział logiczny przełóż na fizyczną konfigurację zgodną z potrzebami dostępu i utrzymania. Nie twórz dodatkowych kopii jedynie po to, żeby diagram miał trzy kolory. Każda zachowana wersja powinna mieć cel, okres przechowywania i sposób odtworzenia.

Wybierz Warehouse lub Lakehouse według pracy zespołu

Przewodnik Microsoft po Warehouse i Lakehouse wskazuje między innymi styl tworzenia rozwiązania, typ danych i potrzebę transakcji obejmujących wiele tabel. Warehouse jest ukierunkowany na T-SQL, a Lakehouse na pracę z danymi i przetwarzanie Spark. Oba korzystają z danych w OneLake.

Ważne rozróżnienie dotyczy endpointu SQL lakehouse: jego rola odczytowa nie jest tożsama z pełnym zapisem i przetwarzaniem T-SQL w Warehouse. Jeśli projekt wymaga określonej operacji, sprawdź ją w dokumentacji i próbie, zamiast opierać decyzję wyłącznie na tym, że oba elementy udostępniają SQL.

Możliwa jest architektura łącząca różne elementy, ale musi mieć uzasadnienie. Jeśli jeden zespół przygotowuje dane, a drugi buduje model biznesowy, granica może być przydatna. Jeśli dwa elementy wykonują tę samą transformację bez potrzeby, rośnie koszt i ryzyko rozbieżności.

Uwzględnij kompetencje oraz plan utrzymania. Wybór technologii, której nikt poza wykonawcą nie potrafi obsługiwać, wymaga jawnego planu przekazania wiedzy. Nie jest to argument przeciw nowym narzędziom, lecz część odpowiedzialnej decyzji o architekturze.

Model semantyczny łączy dane z językiem firmy

Tabela zawierająca kwoty i daty nie wyjaśnia jeszcze, czym jest przychód w konkretnym raporcie. Model biznesowy powinien określać relacje, miary, kalendarz i zasady filtrowania. Odbiorcy muszą rozumieć, które pytanie dana liczba rzeczywiście odpowiada.

Uzgodnij jedno miejsce odpowiedzialne za definicję ważnej miary. Jeśli każdy raport liczy ją samodzielnie, wspólna platforma może nadal dostarczać kilka sprzecznych wyników. Zmiana definicji powinna mieć właściciela, wersję i ocenę wpływu na istniejące raporty.

Przygotuj mały przykład referencyjny obejmujący przypadki typowe i wyjątki. Ręcznie zatwierdzony wynik na takim zbiorze pozwala testować kolejne zmiany. Nie chodzi o ręczne liczenie całej produkcji, lecz o dowód, że podstawowe reguły działają zgodnie z ustaleniem.

Opisz także jednostkę i zakres czasu. Kwota netto, brutto, narastająco i za miesiąc to różne wartości. Brak takiego opisu bywa źródłem nieporozumień nawet wtedy, gdy wszystkie obliczenia technicznie wykonano bez błędu.

Bezpieczeństwo przechodzi przez wszystkie warstwy

Zaprojektuj role dla administratora, autora przetwarzania, analityka i odbiorcy. Określ, kto widzi dane szczegółowe, kto może zmieniać model oraz kto publikuje wynik. Uprawnienia powinny odpowiadać zadaniu, a nie wygodzie pierwszego uruchomienia.

Sprawdź wszystkie dopuszczone drogi odczytu. Raport z ograniczeniem nie wystarczy, jeśli użytkownik może pobrać pełne dane inną metodą. Przy skrótach i połączeniach ustal również, jaka tożsamość jest używana na każdym etapie oraz gdzie egzekwowane są reguły.

Przetestuj odebranie dostępu, zmianę roli i rotację poświadczeń integracji. Architektura powinna wskazywać, które procesy zależą od danego konta i jak przywrócić działanie. Ukryta zależność od konta autora jest ryzykiem operacyjnym, które można wykryć przed produkcją.

Dane testowe powinny umożliwiać sprawdzenie logiki bez niepotrzebnego udostępniania informacji rzeczywistych osób lub klientów. Jeśli do odbioru potrzebny jest rzeczywisty zakres, ustal ograniczony dostęp i sposób jego usunięcia po zakończeniu próby.

Monitoring powinien wykrywać zły wynik, nie tylko błąd zadania

Zadanie może zakończyć się bez błędu, a mimo to dostarczyć zero rekordów albo połowę oczekiwanych danych. Obserwuj kompletność, aktualność i podstawowe miary jakości, nie tylko status uruchomienia. Dla każdej kontroli ustal próg oraz reakcję.

Nie każdy wyjątek wymaga zatrzymania wszystkiego. Brak opcjonalnego pola może trafić do kolejki poprawy, a brak całego źródła może blokować publikację. Te reguły powinien zaakceptować właściciel procesu, ponieważ określają użyteczność i ryzyko wyniku.

Zdarzenie	Kontrola	Przykładowa reakcja
Brak dostawy danych	Aktualność i zakres źródła	Wstrzymanie publikacji lub oznaczenie opóźnienia
Nietypowy spadek liczby rekordów	Porównanie z oczekiwanym zakresem	Weryfikacja kompletności
Duplikaty klucza	Test unikalności	Zatrzymanie niepoprawnego łączenia
Korekta historii	Uzgodnione reguły przeliczenia	Odtworzenie właściwego okresu
Zmiana uprawnień	Próba dostępu	Aktualizacja konfiguracji bez poszerzania zakresu
Przekroczenie czasu	Pomiar całego przepływu	Diagnoza źródła, przetwarzania i odbioru

Alert powinien wskazywać właściciela i miejsce diagnozy. Powiadomienie wysyłane do skrzynki, której nikt nie obsługuje, nie jest kontrolą operacyjną. W odbiorze przećwicz reakcję od wykrycia problemu do przywrócenia poprawnego wyniku.

Odtwarzanie i wdrażanie zmian zaprojektuj od początku

Ustal, które dane i konfiguracje trzeba zachować, żeby odtworzyć proces. Historia tabel, kopia źródła i wersja kodu spełniają różne zadania. Nie należy używać jednego z tych elementów jako domyślnego zastępstwa wszystkich pozostałych.

Próba odtworzenia powinna dotyczyć konkretnego zakresu i czasu. Na przykład zespół przywraca wynik wskazanego dnia oraz porównuje go z wartością referencyjną. Zapisz, ile to trwa i jakie czynności wymagają ręcznej decyzji. Deklaracja możliwości odtworzenia bez próby pozostaje założeniem.

Zmiany przeprowadzaj przez środowisko i proces testowy odpowiedni do projektu. Przed publikacją nowej reguły sprawdź wynik referencyjny, dostęp i zależne raporty. Ustal sposób powrotu, jeśli po uruchomieniu pojawi się nieprzewidziany problem.

Przykład: opóźnienie wynika z sumy etapów

Załóżmy modelowo, że pozyskanie danych trwa 15 minut, przygotowanie 10, kontrola 5, a udostępnienie raportu kolejne 10. Łączny czas wynosi 40 minut. Skrócenie jednego zapytania z dwóch minut do jednej nie rozwiąże wymagania, aby cały wynik był gotowy w 20 minut.

W takiej sytuacji trzeba zbadać zależności i możliwość zmiany przebiegu, a nie tylko zwiększać zasoby jednego elementu. Być może źródło dostarcza dane zbyt późno albo niepotrzebnie czeka się na niezależny etap. To przykład kalkulacyjny, nie pomiar Fabric.

Podobnie oceniaj koszt: uwzględnij cały cykl pracy, testy, retencję i utrzymanie. Architektura powinna pokazywać, które składniki rosną wraz z danymi, a które wraz z liczbą odbiorców lub częstotliwością. Dzięki temu można planować rozwój bez zgadywania.

Odbierz jeden przepływ, zanim rozszerzysz platformę

Pierwszy zakres powinien przejść próbę poprawnego działania, awarii, zmiany i odtworzenia. Odbiorca biznesowy zatwierdza wynik, a zespół utrzymania potwierdza możliwość obsługi. Dopiero wtedy warto dokładać kolejne źródła i scenariusze.

Jeśli potrzebujesz szerzej ocenić warstwę przechowywania, przeczytaj o data lake i platformie danych dla AI. Cały projekt połącz z systemem pracy firmy. Dobra architektura kończy się na sprawdzalnej decyzji i odpowiedzialności, nie na ostatniej ikonie diagramu.