Audyt Microsoft Fabric

Audyt Microsoft Fabric to przegląd sposobu wykorzystania platformy: od konfiguracji pojemności obliczeniowej (capacity), przez organizację danych w OneLake i niezawodność procesów, po dostęp użytkowników i warstwę Power BI. Nie chodzi wyłącznie o wyszukanie błędów konfiguracyjnych. Równie ważne jest sprawdzenie, czy przyjęte rozwiązania nadal odpowiadają skali i potrzebom organizacji.

Inaczej ocenia się środowisko z jedną hurtownią i kilkoma raportami, a inaczej platformę, na której równolegle działają potoki Data Factory, notebooki Spark i dziesiątki modeli semantycznych. Zakres audytu powinien uwzględniać faktycznie używane usługi oraz zależności między nimi.

Pojemność Fabric - gdzie zużywane są zasoby?

Microsoft Fabric wykorzystuje pojemność obliczeniową wyrażaną w jednostkach Capacity Units (CU). W ramach danej pojemności różne zadania współdzielą zasoby. Dlatego pojedynczy wolny raport nie musi oznaczać problemu z samym raportem. Przyczyną może być obciążenie wywołane przez inne procesy.

Podstawowym narzędziem analizy jest Microsoft Fabric Capacity Metrics. Dane z aplikacji pozwalają zbadać wykorzystanie zasobów przez poszczególne elementy, obciążenie w czasie i sytuacje prowadzące do ograniczania wykonywania operacji (throttling). Należy przy tym uwzględniać mechanizmy bursting i smoothing, ponieważ chwilowy wzrost wykorzystania nie przekłada się automatycznie na potrzebę zwiększenia rozmiaru pojemności.

Podczas audytu sprawdza się między innymi:

• które elementy i typy operacji odpowiadają za największe zużycie CU,
• czy w podobnych godzinach uruchamiają się kosztowne zadania przetwarzania i odświeżania,
• czy występuje throttling, wydłużenie czasu zapytań lub odrzucanie operacji,
• czy obecną pojemność da się wykorzystać efektywniej przed decyzją o jej zwiększeniu.

Koszty warto rozpatrywać łącznie z rzeczywistym obciążeniem, organizacją pojemności i wymaganym czasem dostępności usług. Samo zestawienie ceny wariantów licencyjnych nie daje pełnego obrazu.

OneLake i architektura danych - porządek czy kolejne silosy?

Wspólna warstwa przechowywania nie oznacza automatycznie spójnych danych. W OneLake można utrzymywać kilka kopii podobnych zbiorów, tworzyć niezależne transformacje i uzyskiwać rozbieżne wyniki w raportach. Audyt powinien prześledzić, skąd pochodzą dane, jak są przetwarzane i które zbiory są wykorzystywane dalej.

W architekturze Lakehouse jednym z często stosowanych podejść jest podział Bronze, Silver i Gold. Ocenia się wtedy nie tylko istnienie warstw, lecz także ich rzeczywistą rolę: czy surowe dane pozostają odtwarzalne, gdzie odbywa się walidacja i które dane udostępnia się użytkownikom biznesowym.

Osobnej uwagi wymagają shortcuts w OneLake. Pozwalają odwoływać się do danych bez ich fizycznego kopiowania, ale dostęp do wskazywanych zasobów zależy od konfiguracji uprawnień i sposobu uwierzytelniania. Podczas przeglądu trzeba zatem odróżnić problem duplikowania danych od problemu ich udostępniania.

Praktycznym wynikiem tej części audytu może być mapa przepływu danych: źródła, Lakehouse lub Warehouse, transformacje, właściciele zbiorów i raporty, które z nich korzystają. Taka mapa ułatwia znalezienie zbędnych kopii oraz zależności trudnych do utrzymania.

Data Factory i notebooki - czy procesy są odporne na błędy?

Pipeline zakończony statusem „Succeeded” nie dowodzi jeszcze poprawności danych. Proces może wykonać wszystkie kroki technicznie prawidłowo, a jednocześnie przetworzyć niekompletny zestaw rekordów albo pozostawić dane z poprzedniego dnia. Dlatego audyt obejmuje zarówno przebieg zadań, jak i kontrole ich rezultatów.

Warto sprawdzić harmonogramy, zależności między etapami, parametryzację, obsługę ponowień i powiadomienia o błędach. Istotne jest również, co stanie się po ponownym uruchomieniu zadania: czy dane zostaną poprawnie uzupełnione, czy powstaną duplikaty. W przypadku notebooków należy ocenić zależności od bibliotek, sposób zapisywania wyników oraz to, czy cały proces można odtworzyć bez ręcznych czynności.

Środowiska rozwojowe i produkcyjne powinny mieć kontrolowany sposób wprowadzania zmian. Integracja z Git i deployment pipelines mogą w tym pomagać, ale zakres obsługiwanych elementów trzeba sprawdzić dla konkretnego rozwiązania.

Bezpieczeństwo Fabric - kto naprawdę widzi dane?

Kontrola uprawnień nie kończy się na rolach w workspace. W Microsoft Fabric znaczenie mają także uprawnienia do poszczególnych elementów, mechanizmy dostępu do danych w OneLake oraz zabezpieczenia w warstwie SQL i modelach semantycznych Power BI. To różne poziomy dostępu, których nie należy traktować zamiennie.

Przegląd powinien odpowiedzieć na konkretne pytania: czy użytkownicy otrzymują tylko niezbędne uprawnienia, kto może udostępniać dane poza zespołem, jak zabezpieczono wrażliwe tabele i kto odpowiada za tożsamości używane przez automatyzacje? W przypadku shortcuts trzeba dodatkowo sprawdzić zasady dostępu do danych docelowych.

Sam fakt, że odbiorca widzi wyłącznie określone wiersze w raporcie, nie oznacza jeszcze, że ma równie ograniczony dostęp do danych innymi ścieżkami. Dlatego test uprawnień powinien obejmować rzeczywiste sposoby korzystania z zasobów, nie tylko ekran raportu.

Power BI i Direct Lake - czy warstwa raportowania jest wydajna?

Audyt Microsoft Fabric powinien uwzględniać również modele semantyczne i raporty Power BI. Nawet poprawnie zaprojektowany Lakehouse nie pomoże, jeśli raport wykonuje kosztowne zapytania DAX, model ma niepotrzebne kolumny albo wiele zespołów utrzymuje własne definicje tych samych wskaźników.

Szczególnej analizy wymaga tryb Direct Lake. Umożliwia on modelom semantycznym korzystanie z tabel Delta w OneLake, ale jego zachowanie zależy od wybranego wariantu i konfiguracji. W wariancie Direct Lake na punkcie końcowym SQL w określonych sytuacjach może wystąpić przejście do DirectQuery. Direct Lake on OneLake nie korzysta z tego mechanizmu. Zamiast zakładać, że Direct Lake automatycznie zapewni najlepsze wyniki, należy sprawdzić rzeczywiste czasy zapytań oraz ograniczenia konkretnego modelu.

Do przeglądu należą również odświeżanie, właściciele modeli, sposób udostępniania raportów i spójność wskaźników biznesowych. W ten sposób audyt obejmuje cały przepływ: od pobrania danych do decyzji podejmowanych na podstawie raportu.

Co powinno pozostać po audycie Microsoft Fabric?

Użyteczny audyt nie kończy się listą ustawień do zmiany. Powinien wskazać problem, jego wpływ na środowisko, dowód z analizy i rekomendowany sposób postępowania. Dobrze jest oddzielić szybkie korekty od zmian wymagających przebudowy architektury.

• Ryzyka krytyczne: nadmierne uprawnienia, procesy bez kontroli błędów lub brak możliwości odtworzenia ważnych danych.
• Problemy operacyjne: przeciążenia pojemności, nietrafione harmonogramy, niestabilne potoki i trudne do wykrycia awarie.
• Dług techniczny: zbędne kopie danych, powielone transformacje i modele utrzymywane bez jasno wskazanego właściciela.
• Plan działań: priorytety, zależności między zmianami i sposób sprawdzenia, czy poprawki przyniosły oczekiwany efekt.

Taka kolejność pozwala uniknąć sytuacji, w której zaczyna się od optymalizacji kosztów, choć większym problemem pozostaje bezpieczeństwo lub wiarygodność danych.

Najczęstsze pytania o audyt Microsoft Fabric

Dokumentacja techniczna Microsoft

Podczas analizy pojemności, uprawnień i procesów danych przydatne są następujące materiały Microsoft Learn:

• Monitorowanie wykorzystania pojemności w Fabric Capacity Metrics
• Mechanizmy throttling i smoothing w Microsoft Fabric
• Architektura danych Bronze, Silver i Gold w OneLake
• Model uprawnień i dostępu do danych w Microsoft Fabric
• Monitorowanie uruchomień potoków Data Factory
• Działanie trybu Direct Lake i przejścia do DirectQuery

Powiązane materiały