Microsoft Fabric czy klasyczna hurtownia

Czym różnią się oba podejścia

Klasyczna hurtownia w ekosystemie Microsoftu to zwykle baza SQL Server lub Azure SQL, procesy ładujące w SSIS albo Azure Data Factory, model analityczny w Analysis Services lub Power BI oraz uprawnienia zarządzane osobno w każdej z tych warstw. Każdy element kupuje się, wdraża i utrzymuje oddzielnie, ale każdy jest też dobrze znany, opisany w dokumentacji i obsadzony kompetencjami na rynku pracy.

Microsoft Fabric jest usługą w modelu SaaS, która łączy te warstwy w jednym środowisku. Dane trafiają do OneLake, wspólnego magazynu opartego na formacie Delta Parquet, a pracują na nich lakehouse, magazyn danych (warehouse), potoki Data Factory, notatniki Spark, analityka czasu rzeczywistego i Power BI. Rozliczenie opiera się na pojemności, czyli jednostkach SKU F, które współdzielą wszystkie obciążenia w przypisanych do niej obszarach roboczych.

Ważną konsekwencją tej architektury jest ograniczenie liczby kopii danych. Tabele zapisane w OneLake mogą być czytane przez różne silniki bez przenoszenia, a modele semantyczne Power BI w trybie Direct Lake odczytują je bezpośrednio, bez osobnego importu do modelu. W klasycznej hurtowni te same dane zwykle istnieją w kilku miejscach: w obszarze przejściowym, w hurtowni i w modelu analitycznym, a każda kopia wymaga osobnego procesu odświeżania.

Różnica nie sprowadza się więc do silnika bazy danych. Zmienia się model operacyjny: kto zarządza platformą, jak liczony jest koszt, ile pracy wymaga integracja kolejnych elementów i jak szybko zmienia się samo narzędzie. Te cztery pytania warto mieć w głowie przy każdym porównaniu, bo zestawienie funkcji na slajdzie odpowiada tylko na pierwsze z nich.

Jak liczyć koszt utrzymania

Samo porównanie cennika pojemności Fabric z ceną bazy Azure SQL niewiele mówi. Koszt utrzymania składa się z kilku warstw, które w obu modelach rozkładają się inaczej:

• platforma - w hurtowni osobne opłaty za bazę, narzędzie do ładowania danych, serwer modeli i magazyn plików, w Fabric jedna pojemność, którą można skalować, a w rozliczeniu za użycie także wstrzymywać, gdy nie jest potrzebna,
• licencje użytkowników - przy mniejszych pojemnościach odbiorcy raportów nadal potrzebują licencji Power BI Pro, a dopiero od pojemności F64 mogą korzystać z udostępnionych treści z bezpłatną licencją,
• praca zespołu - w hurtowni integracja, monitoring, aktualizacje i obsługa błędów między narzędziami, w Fabric nauka nowej platformy i zarządzanie obciążeniem współdzielonej pojemności,
• ryzyko zmian - Fabric rozwija się szybko i część funkcji udostępniana jest najpierw w wersji zapoznawczej, co dla jednych zespołów jest zaletą, a dla organizacji z restrykcyjnym procesem zmian oznacza dodatkowe testy.

W Fabric szczególnie ważne jest planowanie pojemności. Wszystkie obciążenia korzystają z tej samej puli jednostek obliczeniowych, więc ciężki notatnik albo źle zaprojektowany przepływ danych może spowolnić raporty, z których korzysta zarząd. Mechanizmy wygładzania i ograniczania obciążenia pomagają przy krótkich skokach, ale nie zastępują decyzji, które zadania i kiedy mają działać, na jakiej pojemności i z jakim monitoringiem.

Sposób rozliczenia też wpływa na wynik porównania. Pojemność w rozliczeniu za użycie można wstrzymać poza godzinami pracy, co obniża koszt środowisk rozwojowych i testowych, ale wstrzymana pojemność przestaje udostępniać raporty. Dla stałego obciążenia produkcyjnego Microsoft oferuje rezerwację pojemności z niższą stawką w zamian za zobowiązanie czasowe. Obie opcje warto policzyć osobno dla produkcji i dla pozostałych środowisk.

Firma bez hurtowni, z raportami na eksportach

Pierwszy typ to organizacja średniej wielkości, w której raportowanie opiera się na eksportach z ERP i CRM, arkuszach kalkulacyjnych i kilku modelach Power BI budowanych przez analityków w działach. Hurtowni nie ma, zespół danych liczy kilka osób, a największym problemem jest czas potrzebny na przygotowanie danych do każdego nowego raportu.

Tutaj Fabric zwykle skraca drogę najbardziej. Zamiast projektować, kupować i łączyć kilka usług, zespół dostaje jedno środowisko, w którym może pobrać dane z systemów źródłowych, uporządkować je w lakehouse lub magazynie danych i udostępnić przez model semantyczny w Power BI, które już zna. Do tego dochodzi wspólne zarządzanie uprawnieniami oraz widok pochodzenia danych, który pokazuje, z jakich źródeł powstał dany raport.

Warunek powodzenia jest jeden: nawet na wspólnej platformie trzeba zaprojektować warstwy danych, nazewnictwo i odpowiedzialność za poszczególne obszary. Fabric ułatwia start, ale nie podejmuje decyzji o strukturze. Bez nich po roku powstaje ten sam chaos co w arkuszach, tylko w nowym miejscu i z rachunkiem za pojemność.

Drugim warunkiem są kompetencje. Analitycy, którzy dobrze znają Power BI, zwykle szybko odnajdują się w potokach danych i magazynie, ale projektowanie modelu danych, obsługa błędów ładowania i zarządzanie uprawnieniami to umiejętności, które trzeba zbudować albo pozyskać z zewnątrz. W takiej firmie sensowny plan na pierwsze miesiące obejmuje jeden obszar biznesowy, na przykład sprzedaż, doprowadzony od źródła do raportu, i dopiero potem kolejne obszary według tego samego wzorca.

Firma z dojrzałą hurtownią SQL Server

Drugi typ to firma, która od lat ma hurtownię na SQL Server, sprawdzone procesy ładowania w SSIS i modele, którym ufa zarząd. Dane pochodzą głównie z systemów relacyjnych, wolumen rośnie w przewidywalnym tempie, a zespół zna narzędzia i ma ustalone procedury zmian, testów i wydań.

W takim przypadku klasyczna hurtownia często pozostaje tańsza w utrzymaniu, zwłaszcza gdy działa na posiadanych licencjach albo została przeniesiona do Azure SQL Managed Instance z wykorzystaniem Azure Hybrid Benefit. Pełna migracja do Fabric oznaczałaby przepisanie procesów ładowania, ponowne testy wszystkich raportów i okres utrzymywania dwóch platform równolegle, podczas gdy efekt dla użytkownika końcowego mógłby być niewielki.

Rozsądną drogą jest podejście stopniowe. Fabric można wprowadzić tam, gdzie wnosi nowe możliwości: dla nowych źródeł danych, analiz na danych półstrukturalnych albo zespołu, który potrzebuje notatników do pracy eksploracyjnej. Mechanizmy takie jak skróty w OneLake czy odzwierciedlanie (mirroring) wybranych baz pozwalają korzystać z istniejących danych bez budowania kolejnych procesów kopiujących. Decyzja o pełnej zmianie może poczekać do momentu, w którym obecna platforma i tak będzie wymagała dużej modernizacji.

Sygnałów, że warto wrócić do tematu, jest kilka: kończy się wsparcie dla używanej wersji SQL Server, serwer modeli wymaga wymiany sprzętu, pojawiają się źródła danych, których hurtownia relacyjna nie obsługuje dobrze, albo zespół traci osoby znające stare procesy ładowania. Każde z tych zdarzeń zmienia rachunek kosztów, więc decyzję podjętą dziś warto zapisać razem z warunkami, przy których zostanie ponownie sprawdzona.

Działająca hurtownia nie staje się długiem technologicznym tylko dlatego, że pojawiła się nowsza platforma.

Grupa z wieloma źródłami i analityką zaawansowaną

Trzeci typ to organizacja wielooddziałowa albo grupa kapitałowa: kilka systemów ERP odziedziczonych po przejęciach, dane z urządzeń i aplikacji internetowych, pliki od partnerów, zespół analityków i osoby budujące modele predykcyjne. Relacyjna hurtownia obsłuży tu część potrzeb, ale dane półstrukturalne, strumieniowe i duże wolumeny historyczne wymagają dodatkowych usług, z których każda ma własne uprawnienia, monitoring i rozliczenie.

W takim środowisku Fabric daje wspólny magazyn i jeden model zabezpieczeń dla wielu zespołów, co rzeczywiście skraca czas od pozyskania danych do analizy. Jednocześnie właśnie tu najłatwiej o chaos. Wiele obszarów roboczych, wiele zespołów i współdzielona pojemność bez jasnych zasad prowadzą do duplikowania danych, sporów o zasoby i kosztów, których nie da się przypisać do żadnej spółki. Przed wdrożeniem ustalamy więc:

• podział na domeny danych z właścicielami po stronie biznesu,
• zasady tworzenia obszarów roboczych i przypisywania ich do pojemności,
• standard warstw danych, na przykład dane surowe, oczyszczone i biznesowe,
• zasady certyfikacji modeli semantycznych, z których mogą korzystać inne zespoły,
• monitoring wykorzystania pojemności i sposób rozliczania kosztów między spółkami.

Osobnego projektu wymagają uprawnienia. W Fabric działają one na kilku poziomach: ról w obszarze roboczym, dostępu do pojedynczych elementów oraz zabezpieczeń na poziomie danych, takich jak ograniczenie wierszy w modelu semantycznym. W grupie kapitałowej, gdzie dane jednej spółki nie mogą trafić do pracowników innej, ten projekt trzeba przygotować przed załadowaniem pierwszych danych, a nie dopasowywać do już działających raportów.

Bez tych ustaleń platforma, która miała uprościć architekturę, stanie się kolejnym miejscem, gdzie te same dane istnieją w kilku wersjach. Z nimi Fabric może zastąpić zestaw osobnych usług i dać grupie wspólny język danych.

Jak podjąć decyzję

Zamiast pytać, która platforma jest lepsza, warto przejść przez kilka kryteriów i zapisać odpowiedzi dla własnej organizacji. Poniższe zestawienie nie zastąpi analizy, ale pomaga zobaczyć, w którą stronę przechyla się decyzja.

Odpowiedź rzadko jest zero-jedynkowa. W wielu organizacjach najlepiej sprawdza się krótki pilotaż Fabric na jednym obszarze biznesowym, z policzonym kosztem pojemności i pracy zespołu, porównany z rozbudową obecnej hurtowni o ten sam zakres. Wynik takiej próby na własnych danych jest bardziej wiarygodny niż każda prezentacja, łącznie z naszą.

Żeby pilotaż dał odpowiedź, a nie tylko wrażenia, przed startem warto ustalić, co będzie mierzone:

• czas od pojawienia się potrzeby do udostępnienia pierwszego raportu na nowych danych,
• rzeczywiste wykorzystanie pojemności w typowym dniu i w dniu zamknięcia miesiąca,
• liczba godzin pracy zespołu potrzebnych do utrzymania procesów po uruchomieniu,
• czas ładowania raportów w porównaniu z obecnym rozwiązaniem,
• łączny koszt miesięczny przeliczony na pełny zakres, który miałaby objąć platforma.

Stoicie przed wyborem platformy danych?

Porównamy oba warianty na waszych źródłach, raportach i kompetencjach zespołu, zanim zapadnie decyzja o budżecie.

Porozmawiaj z ekspertem