Power BI: Dataflow, Dataset i Datamart — czym się różnią i kiedy używać każdego z nich?

Microsoft Power BI oferuje co najmniej trzy ścieżki przygotowywania i przechowywania danych na potrzeby raportowania: dataflow, dataset oraz datamart. Na pierwszy rzut oka wszystkie trzy służą do podobnego celu — dostarczenia ustrukturyzowanych danych do wizualizacji. W praktyce jednak każdy z tych komponentów pełni odrębną rolę w architekturze analitycznej, a pomylenie ich funkcji prowadzi do zbędnej redundancji, problemów z wydajnością i chaosu w zarządzaniu.

W tym artykule szczegółowo porównujemy dataflow, dataset i datamart w Power BI — od definicji, przez architekturę i przypadki użycia, aż po reguły decyzyjne, które pomogą Ci wybrać właściwe narzędzie w zależności od scenariusza.

Czym jest Dataflow w Power BI?

Dataflow to niskokodowy mechanizm ekstrakcji, transformacji i ładowania danych (ETL) osadzony w usłudze Power BI. Jego zadaniem jest pobranie surowych danych ze źródeł zewnętrznych, oczyszczenie ich, ujednolicenie i zapisanie w postaci gotowych tabel w usłudze Azure Data Lake Storage Gen2, a następnie udostępnienie tych tabel jako źródła dla datasetów.

Dataflow operuje na jednostkach zwanych encji (entities), które odpowiadają pojedynczym tabelom wynikowym. Logikę transformacji definiuje się w edytorze Power Query Online — tym samym, który znasz z Power BI Desktop — co oznacza, że nie musisz pisać kodu SQL ani znać szczegółów infrastruktury chmurowej. W 2026 roku edytor ten obsługuje ponad 150 natywnych łączników, w tym do baz SQL, usług SaaS, plików w SharePoint i danych strumieniowych, a dodatkowo pozwala na wykorzystanie diagramu zależności (dependency diagram), który wizualizuje przepływ danych między poszczególnymi krokami transformacji.

Kluczowe cechy dataflow:

• Separacja warstwy ETL od raportowania — zespół inżynierów danych może przygotować i certyfikować tabele, które następnie analitycy wykorzystują w wielu różnych raportach bez ponownego łączenia się ze źródłem.
• Przechowywanie w Common Data Model (CDM) — encje dataflow zapisywane są w ustandaryzowanym formacie CDM, co umożliwia ich współdzielenie nie tylko między datasetami Power BI, ale także z Azure Data Factory, Dataverse i Dynamics 365.
• Linked entities (encje połączone) — jeden dataflow może odwoływać się do encji z innego dataflow, co pozwala budować wielopoziomowe potoki transformacji bez kopiowania logiki.
• Odświeżanie przyrostowe (incremental refresh) — od 2025 roku dataflow Premium obsługują odświeżanie przyrostowe z partycjonowaniem czasowym, co radykalnie skraca czas ładowania dużych wolumenów danych historycznych.
• Computed entities (encje obliczeniowe) — encje definiowane nie przez ładowanie ze źródła, lecz przez transformację innych encji w ramach tego samego dataflow. Przetwarzane są na poziomie magazynu (lake), a nie w silniku Power Query w trakcie odświeżania datasetu.

Model licencjonowania dataflow opiera się na pojemnościach Power BI Premium (lub Premium na użytkownika — PPU). Współdzielone pojemności (shared capacity) w licencjach Pro pozwalają na tworzenie dataflow, ale z ograniczeniami co do częstotliwości odświeżania i wolumenu danych. W 2026 roku Microsoft wprowadził warstwę Fabric capacity, która ujednolica rozliczanie jednostek CU (Capacity Units) dla dataflow, datasetów i data martów, upraszczając zarządzanie kosztami.

Czym jest Dataset w Power BI?

Dataset — mimo że polska nazwa sugeruje po prostu „zestaw danych” — w terminologii Power BI oznacza semantyczny model danych, który stanowi warstwę pośrednią między surowymi danymi a wizualizacjami. Dataset zawiera tabele zaimportowane do pamięci (tryb Import), połączenie bezpośrednie (DirectQuery), tryb złożony (Composite model) lub konfigurację Direct Lake w Microsoft Fabric. Do tego dochodzą relacje między tabelami, miary w języku DAX, role bezpieczeństwa (RLS), formatowanie, hierarchie i foldery miar.

Dataset to mózg raportu — tu definiuje się całą logikę biznesową. W przeciwieństwie do dataflow czy data martu, dataset nie przechowuje danych w zewnętrznym magazynie; przechowuje je we własnym silniku VertiPaq (w trybie Import) lub odpytuje źródło na żądanie (DirectQuery/Direct Lake).

Najważniejsze cechy datasetu:

• Silnik VertiPaq — kolumnowa baza danych w pamięci, która kompresuje dane i umożliwia błyskawiczne odpowiedzi na zapytania DAX nawet na miliardach wierszy.
• Jeden dataset, wiele raportów — ten sam dataset może zasilać wiele raportów w różnych obszarach roboczych, zapewniając jedno źródło prawdy (single source of truth) dla miar i metryk.
• XMLA endpoints — dataset w pojemności Premium udostępnia endpoint zgodny z protokołem XMLA, co pozwala na zarządzanie modelem z poziomu narzędzi zewnętrznych, takich jak Tabular Editor, oraz na automatyzację wdrażania przez Azure DevOps.
• Object-level security (OLS) — poza tradycyjnym RLS, dataset obsługuje OLS, pozwalając ukryć pojedyncze tabele lub kolumny przed wybranymi użytkownikami.
• Composite models — tryb łączący tabele Import z tabelami DirectQuery, a od 2025 roku również z tabelami Direct Lake w Fabric, co daje elastyczność w łączeniu danych historycznych z danymi niemal czasu rzeczywistego.

Dataset jest obowiązkowym elementem każdego raportu Power BI — nie można utworzyć raportu bez podpięcia go do datasetu. Jednak dataset nie służy do transformacji danych typu ETL (do tego jest dataflow), ani do przechowywania danych w zarządzalnym magazynie SQL (do tego jest datamart).

Czym jest Datamart w Power BI?

Datamart, wprowadzony w 2022 roku i znacząco rozbudowany w latach 2024–2025, to najbardziej samodzielny z omawianych trzech komponentów. Datamart łączy w sobie funkcje dataflow (ETL), w pełni funkcjonalnej relacyjnej bazy danych (Azure SQL Database) oraz automatycznie generowanego datasetu — wszystko w obrębie jednego obszaru roboczego Power BI.

Pod maską datamartu działa trzywarstwowa architektura:

1. Warstwa ETL (dataflow) — zasilana przez edytor Power Query Online, pobiera i transformuje dane ze źródeł zewnętrznych.
2. Warstwa składowania (Azure SQL Database) — zarządzana baza SQL, w której dane przechowywane są w tabelach relacyjnych. Masz do dyspozycji pełny silnik T-SQL (z ograniczeniami dotyczącymi operacji administracyjnych), możesz tworzyć widoki, procedury składowane, a także definiować klucze główne, indeksy i ograniczenia integralności.
3. Warstwa semantyczna (dataset) — automatycznie tworzony i synchronizowany dataset, który odzwierciedla strukturę tabel SQL i umożliwia natychmiastowe tworzenie raportów.

Kluczowe cechy datamartu:

• Pełny dostęp do T-SQL — możesz pisać zapytania SELECT, JOIN, GROUP BY, a także tworzyć tabele tymczasowe, zmienne i CTE. To ogromna zaleta dla zespołów z kompetencjami SQL-owymi, które nie chcą uczyć się M (Power Query) ani DAX.
• Automatyczny dataset — po zdefiniowaniu tabel w datamarce, Power BI automatycznie tworzy i utrzymuje dataset, który może być używany bezpośrednio w raportach. Nie musisz ręcznie konfigurować relacji — system wykrywa je na podstawie schematu SQL.
• Współdzielenie danych — datamart udostępnia endpoint SQL, do którego mogą łączyć się narzędzia zewnętrzne, takie jak Azure Data Studio, SSMS, a nawet Excel przez ODBC.
• Row-Level Security na poziomie SQL — możesz definiować reguły bezpieczeństwa bezpośrednio w T-SQL, które są następnie dziedziczone przez dataset.
• Funkcje bring your own key (BYOK) — od 2025 roku datamarty Premium obsługują szyfrowanie kluczami zarządzanymi przez klienta, co spełnia wymogi branż regulowanych.

Datamart jest dostępny wyłącznie w pojemnościach Premium i Fabric — nie można go utworzyć w licencji Pro ani PPU. To naturalne, biorąc pod uwagę, że pod spodem działa instancja Azure SQL Database, która generuje rzeczywisty koszt infrastrukturalny.

Porównanie architektoniczne

Aby zrozumieć, kiedy wybrać które narzędzie, warto zestawić je wprost według kluczowych osi:

Ta tabela uwidacznia fundamentalną różnicę: dataflow to warstwa ETL, dataset to warstwa semantyczna, a datamart to samodzielne, wielowarstwowe rozwiązanie łączące obie te funkcje pod jednym dachem.

Przypadki użycia: kiedy wybrać Dataflow

Dataflow sprawdza się najlepiej, gdy organizacja chce scentralizować logikę transformacji danych, oddzielając ją od poszczególnych raportów. Oto konkretne scenariusze:

1. Wiele raportów korzysta z tych samych danych źródłowych — zamiast powielać tę samą logikę Power Query w każdym pliku PBIX, tworzysz jeden dataflow z certyfikowanymi tabelami i podpinasz do niego wszystkie raporty.

2. Zespół inżynierów danych przygotowuje dane, a zespół analityków tworzy raporty — dataflow stanowi czysty kontrakt między tymi dwiema grupami. Inżynierowie certyfikują encje (certified endorsement), a analitycy mają pewność, że korzystają z autoryzowanego źródła.

3. Integracja z Azure Synapse i Data Factory — ponieważ dataflow przechowuje dane w formacie CDM w Data Lake, inne usługi Azure mogą bezpośrednio czytać te dane. Przypadek: dataflow zasila jednocześnie raporty Power BI i proces uczenia maszynowego w Azure ML.

4. Transformacje wieloetapowe bez pisania kodu — mechanizm linked entities pozwala zbudować potok: dataflow A ładuje surowe dane z ERP, dataflow B czyści je i standaryzuje, dataflow C tworzy zagregowane tabele faktów.

5. Odświeżanie danych z wielu małych źródeł SaaS — gdy organizacja korzysta z dziesiątek narzędzi chmurowych (Salesforce, Google Analytics, HubSpot), dataflow pełni rolę huba integracyjnego, zbierającego dane z API tych usług.

Przypadki użycia: kiedy skoncentrować się na Datasecie

Dataset jest najlepszym wyborem (lub nawet jedynym wyborem), gdy priorytetem jest definicja logiki biznesowej i optymalizacja zapytań analitycznych:

1. Definiowanie metryk i KPI o znaczeniu korporacyjnym — dataset przechowuje miary DAX, które mają być wspólne dla całej organizacji. Dzięki funkcji shared dataset definiujesz miarę „Przychód netto” raz, a wszystkie raporty odwołują się do tego samego obliczenia.

2. Optymalizacja wydajności dużych wolumenów danych — VertiPaq potrafi kompresować dane dziesięciokrotnie i odpowiadać na zapytania w milisekundach. Jeśli potrzebujesz interaktywnego dashboardu na miliardzie wierszy, Import mode datasetu jest często jedyną realną opcją.

3. Bezpieczeństwo wierszy i obiektów — dataset oferuje najbardziej granulowaną kontrolę dostępu: RLS na poziomie wiersza, OLS na poziomie tabeli/kolumny, a w Premium także dynamiczny RLS oparty na USERPRINCIPALNAME().

4. Tryb Direct Lake w Fabric — dataset w trybie Direct Lake łączy zalety Importu (szybkość) i DirectQuery (aktualność), odczytując dane bezpośrednio z plików Parquet w OneLake bez konieczności odświeżania. To przełom dla raportów czasu niemal rzeczywistego.

5. Rozwój zespołowy z kontrolą wersji — dzięki XMLA endpoints i narzędziom takim jak Tabular Editor, zespół może pracować nad datasetem w modelu gitowym, z gałęziami, pull requestami i ciągłą integracją (CI/CD).

Przypadki użycia: kiedy warto postawić na Datamart

Datamart to najlepszy wybór, gdy zespół potrzebuje samodzielności i chce uniknąć rozpraszania logiki między wiele komponentów Power BI, a jednocześnie posiada kompetencje SQL-owe:

1. Samoobsługowa hurtownia dla działu biznesowego — zespół finansowy chce zbudować własną bazę analityczną bez angażowania IT. Datamart daje im pełne środowisko: ETL (Power Query), bazę SQL i raporty — wszystko z poziomu przeglądarki.

2. Zespół z silnymi kompetencjami SQL — analitycy wolą pisać SELECT ... GROUP BY niż klikać w edytorze Power Query? Datamart pozwala im tworzyć widoki, procedury składowane i złożone agregacje w znanym dialekcie.

3. Prototypowanie i proof-of-concept — chcesz szybko zweryfikować hipotezę analityczną bez konfiguracji pełnego stosu Azure? Datamart uruchamia się w minutę i oferuje natychmiastowe wyniki.

4. Integracja z narzędziami zewnętrznymi — endpoint SQL datamartu umożliwia połączenie z Excela, Azure Data Studio, a nawet niestandardowych aplikacji przez standardowe sterowniki ODBC/JDBC. To pomost między światem Power BI a klasycznym SQL.

5. Automatyczna synchronizacja modelu — dodajesz tabelę w datamarce, a dataset aktualizuje się automatycznie. Nie musisz ręcznie odświeżać schematu ani przebudowywać relacji.

Najczęstsze błędy przy wyborze architektury

Z doświadczeń wdrożeniowych na setkach środowisk Power BI wyłania się kilka powtarzających się pułapek, których warto unikać:

• Traktowanie datasetu jako warstwy ETL — próby wykonywania złożonych transformacji w edytorze Power Query Desktop, zwłaszcza gdy ten sam kod jest kopiowany do dziesiątek plików PBIX, to przepis na koszmar utrzymaniowy. Wydziel logikę ETL do dataflow lub datamartu.

• Używanie datamartu do raportów na miliardach wierszy bez optymalizacji — Azure SQL Database pod datamartem ma limit 100 GB. Dla bardzo dużych wolumenów lepszym wyborem będzie dataflow z incremental refresh i dataset w trybie Import lub Direct Lake.

• Nadużywanie DirectQuery w datasecie dla wygody — DirectQuery jest kuszące (brak odświeżania), ale każde kliknięcie użytkownika generuje zapytanie do źródła, co przy większej liczbie użytkowników przeciąża bazę i spowalnia raporty.

• Brak certyfikacji i promocji encji — jeśli nie oznaczysz encji dataflow jako certified lub promoted, użytkownicy w organizacji nie będą wiedzieli, które tabele są autoryzowane, co prowadzi do proliferacji nieoficjalnych kopii.

• Tworzenie osobnych dataflow dla każdego raportu — dataflow ma sens przy współdzieleniu. Jeśli każdy raport ma swój własny dataflow, tracisz główną zaletę — centralizację. W takim scenariuszu lepiej zostać przy Power Query w Desktop.

Częste pytania

Czy dataflow może zastąpić hurtownię danych?

Nie w pełni. Dataflow przechowuje dane w Azure Data Lake w formacie CDM, co przypomina architekturę Data Lakehouse, ale brakuje mu zaawansowanych funkcji hurtowni: kluczy obcych, ograniczeń integralności, ACID, indeksów kolumnowych czy wsparcia dla złożonych zapytań SQL. Dataflow to raczej warstwa stagingowa i transformacyjna, a nie docelowe repozytorium analityczne. Jeśli potrzebujesz prawdziwej hurtowni w obrębie Power BI, wybierz datamart. Jeśli potrzebujesz hurtowni korporacyjnej, rozważ Azure Synapse Analytics lub Fabric Warehouse.

Czy mogę używać datamartu z licencją Pro?

Nie. Datamart wymaga pojemności Premium (P1-P5), Premium na użytkownika (PPU) lub pojemności Fabric (F SKU). Pod spodem działa instancja Azure SQL Database, która generuje koszty infrastrukturalne, więc Microsoft ogranicza dostępność do płatnych pojemności. Jeśli posiadasz tylko licencję Pro, rozważ alternatywę: dataflow (ETL) + dataset (model).

Kiedy wybrać dataflow, a kiedy datamart — skoro oba robią ETL?

Kluczowe pytanie brzmi: co chcesz zrobić z danymi po transformacji?

• Jeśli dane mają trafić do wielu różnych datasetów i być współdzielone na poziomie Data Lake — wybierz dataflow.
• Jeśli dane mają trafić do relacyjnej bazy SQL, gdzie będą dalej przetwarzane przez zapytania T-SQL, widoki i procedury — wybierz datamart.
• Jeśli zespół nie zna SQL, a zna Power Query — wybierz dataflow.
• Jeśli zespół preferuje SQL i chce mieć jedną spójną platformę — wybierz datamart.

Czy dataset może działać bez dataflow i datamartu?

Tak. Dataset może łączyć się bezpośrednio ze źródłami danych (bazy SQL, pliki, API) i zawierać całą logikę transformacji w Power Query Desktop. To najprostszy, ale najmniej skalowalny wzorzec — sprawdza się w małych projektach i szybkich proof-of-concept, ale prowadzi do problemów przy skalowaniu na wiele raportów i wielu twórców.

Jak wygląda ścieżka migracji z osobnych plików PBIX do architektury dataflow + dataset?

Rekomendowana ścieżka: (1) Zidentyfikuj tabele, które są kopiowane między wieloma plikami PBIX. (2) Wyeksportuj logikę Power Query dla tych tabel do dataflow. (3) W plikach PBIX zastąp zapytania do źródła odwołaniem do encji dataflow. (4) Wydziel wspólne miary DAX do współdzielonego datasetu. (5) Raporty przenieś na cienkiego klienta (thin report), który jedynie wizualizuje dane z datasetu. Całość można przeprowadzić iteracyjnie, raport po raporcie.

Czy datamart obsługuje incremental refresh?

Tak, ale z pewnymi zastrzeżeniami. Datamart używa dataflow jako warstwy ETL, a dataflow obsługuje odświeżanie przyrostowe w pojemnościach Premium. Oznacza to, że konfigurujesz politykę incremental refresh na poziomie dataflow, a datamart dziedziczy tę konfigurację. W przypadku tabel tworzonych bezpośrednio przez T-SQL (a nie przez Power Query), musisz samodzielnie zarządzać logiką przyrostowego ładowania, np. przez procedurę składowaną z parametrem daty.

Jaka jest różnica między datamartem a Fabric Warehouse?

Oba działają na SQL i są dostępne w ramach Fabric. Różnice: Fabric Warehouse to pełnoprawna hurtownia danych klasy korporacyjnej z pełną transakcyjnością ACID, automatycznym indeksowaniem i obsługą otwartego formatu Delta-Parquet w OneLake. Datamart Power BI to rozwiązanie lżejsze, samoobsługowe, zintegrowane wyłącznie z ekosystemem Power BI. Warehouse lepiej nadaje się do dużych wdrożeń korporacyjnych; datamart — do samoobsługi działowej i prototypowania.

Czy mogę użyć T-SQL w datasecie?

Nie bezpośrednio. Dataset nie obsługuje T-SQL jako języka zapytań do modelu. Możesz jednak pisać zapytania SQL w źródle danych — jeśli dataset korzysta z DirectQuery do SQL Server lub Azure SQL. W trybie Import transformacje definiujesz w Power Query (M), a logikę biznesową w DAX. Jeśli potrzebujesz T-SQL do transformacji, użyj datamartu lub dataflow (gdzie T-SQL dostępne jest przez endpoint datamartu).

Co ze zgodnością z RODO — gdzie dane są bezpieczniejsze?

Wszystkie trzy komponenty działają w ramach dzierżawy Microsoft 365 i podlegają tym samym certyfikatom zgodności (ISO 27001, SOC 1/2, HIPAA). Różnica leży w możliwościach kontroli:

• Dataflow: dane w Azure Data Lake — możesz zarządzać kluczami szyfrowania (BYOK) i politykami retencji.
• Dataset: dane w pamięci VertiPaq — po usunięciu datasetu dane są nieodwracalnie tracone. RLS i OLS dają szczegółową kontrolę dostępu.
• Datamart: dane w Azure SQL Database — pełna zgodność z Azure Policy, BYOK, a od 2025 roku także double encryption dla kategorii danych szczególnie chronionych.

Czy opłaca się inwestować w architekturę dataflow+dataset+datamart, jeśli mam tylko kilka raportów?

Nie zawsze. Dla małych wdrożeń (1–3 raporty, jeden twórca) prosta architektura datasetu w Power BI Desktop jest wystarczająca i nie generuje dodatkowego narzutu zarządczego. Warto jednak pamiętać o przyszłości — jeśli organizacja planuje rozwój analityki, lepiej od razu przyjąć architekturę separującą ETL od modelu semantycznego. Migracja działającego systemu jest zawsze trudniejsza niż start z dobrą architekturą.

Które rozwiązanie wybrać? Macierz decyzyjna

Poniższe drzewo decyzyjne pomaga w szybkim podjęciu decyzji:

1. Czy potrzebujesz tylko przygotować dane (ETL) do wykorzystania w wielu raportach?

   • Tak, a zespół zna Power Query → Dataflow
   • Tak, a zespół woli SQL → Datamart

2. Czy potrzebujesz tylko zdefiniować miary i logikę biznesową?

   • Tak, dane już są gotowe (np. z hurtowni) → Dataset

3. Czy potrzebujesz kompletnego środowiska: ETL + baza danych + raporty?

   • Tak, a masz licencję Premium/Fabric → Datamart
   • Tak, ale masz tylko Pro → Dataflow + Dataset (dwa komponenty)

4. Czy zespół chce pisać zapytania SQL do danych analitycznych z zewnętrznych narzędzi?

   • Tak → Datamart (udostępnia endpoint SQL)
   • Nie, tylko Power BI → Dataset lub Dataflow + Dataset

5. Czy wolumen danych przekracza 100 GB?

   • Tak → Dataflow (z incremental refresh) + Dataset (Import lub Direct Lake)
   • Nie → wszystkie opcje są dostępne

Praktyka pokazuje, że w średnich i dużych organizacjach najczęściej sprawdza się architektura trójwarstwowa: Dataflow (warstwa ETL, certyfikowane źródło) → Datamart (opcjonalna warstwa SQL dla zaawansowanych transformacji) → Dataset (model semantyczny, jeden dla całej organizacji) → raporty. Taki układ zapewnia separację odpowiedzialności, audytowalność i skalowalność na lata.

Wybór między dataflow, datasetem a datamartem to nie dylemat typu „które jest lepsze”, tylko pytanie o architekturę Twojego rozwiązania analitycznego. W dobrze zaprojektowanym środowisku Power BI te trzy komponenty nie konkurują ze sobą — uzupełniają się, tworząc spójny stos danych od źródła do dashboardu. Jeśli planujesz wdrożenie Power BI w swojej organizacji i potrzebujesz odpowiednich licencji — Premium, PPU czy Fabric — zajrzyj do oferty na KluczeSoft.pl, gdzie znajdziesz kompletny cennik i wsparcie w doborze subskrypcji.