Import, DirectQuery, Live Connection — jaki tryb Power BI wybrać i dlaczego to ma znaczenie
Dostawca BI mówi "DirectQuery" albo "Import" — i zazwyczaj nie wyjaśnia co to oznacza dla Twojego systemu ERP. To nie jest techniczna decyzja architekta IT. To decyzja o tym, czy Twój system księgowy będzie zwalniał za każdym razem, gdy ktoś kliknie w filtr w raporcie.
Trzy tryby — co widzi użytkownik, co czuje baza
Power BI kopiuje dane ze źródła do własnego modelu. Po skopiowaniu raport działa na tej kopii — baza źródłowa nie jest odpytywana przy każdym kliknięciu. Odświeżanie odbywa się cyklicznie: raz dziennie, kilka razy dziennie — zgodnie z harmonogramem. Filtry i wykresy odpowiadają natychmiastowo, niezależnie od złożoności zapytania.
Ograniczenie: dane nie są co do sekundy aktualne. Faktura wystawiona przed godziną może jeszcze nie być w raporcie. Dla raportów zarządczych — zazwyczaj bez znaczenia.
Power BI nie kopiuje danych. Każde kliknięcie w filtr, każda zmiana zakresu dat, każde otwarcie raportu generuje zapytanie SQL bezpośrednio do źródłowej bazy danych. Dane są aktualne co do sekundy. Problem: jeśli źródłem jest operacyjna baza systemu ERP, każde zapytanie analityczne trafia do tej samej instancji, na której pracuje dział księgowości.
Może mieć sens dla: dedykowanych baz analitycznych, Azure Synapse, Fabric Data Warehouse — nie dla operacyjnej bazy ERP.
Podobny do DirectQuery — brak kopii danych, zapytania na żywo. Dostępny wyłącznie dla SQL Server Analysis Services, Azure Analysis Services, Power BI Premium datasets i Microsoft Fabric Data Warehouse. Nie dotyczy standardowych baz ERP, MySQL ani Excela. Dla projektów z Fabric może być sensownym wyborem, bo Fabric DW jest zoptymalizowany pod analitykę — nie pod operacje.
Dlaczego DirectQuery do systemu ERP to zły pomysł
Weźmy konkretny scenariusz. Firma używa enova365. Pięciu menedżerów otwiera raporty rano — każdy klika w filtry, zmienia zakres dat, drąży do faktury. Jeden widok raportu z kilkoma filtrami generuje 10–20 zapytań SQL. Pięciu użytkowników jednocześnie to 50–100 zapytań na minutę — trafiających bezpośrednio do tej samej bazy, na której dział księgowości właśnie wprowadza faktury i rozlicza płatności.
System ERP nie jest zaprojektowany pod ten rodzaj obciążenia. Tabele operacyjne nie mają indeksów zoptymalizowanych pod zapytania analityczne — każde zapytanie "faktury per kategoria per miesiąc za 2 lata" wymaga przeskanowania dużej części bazy. Efekt jest odczuwalny: system zwalnia, pojawiają się timeouty, pracownicy zgłaszają, że "coś się dzieje z enova365".
To samo dotyczy każdego systemu ERP działającego on-premise — Subiekta, Symfonii, Dynamics 365 Business Central z lokalną bazą. Operacyjna baza danych to nie hurtownia danych. Projektowano ją pod szybkie transakcje, nie pod analitykę.
Import — jak to działa i dlaczego to właściwy wybór
W trybie Import ETL ładuje dane raz dziennie (lub kilka razy) do osobnej bazy analitycznej. Power BI przez cały dzień pracuje na tej kopii — system ERP nie jest odpytywany przy każdym kliknięciu użytkownika. Jedyne obciążenie bazy operacyjnej to krótkie okno odczytu podczas odświeżania ETL — zazwyczaj w nocy lub wczesnym rankiem, gdy nikt nie pracuje.
Odpowiedź na najczęstszy zarzut: "ale dane nie są aktualne co do minuty". Dla raportów zarządczych — analiza sprzedaży, aging należności, cash flow, marżowość — dane sprzed poprzedniego dnia są wystarczające do podejmowania decyzji. Faktura wystawiona przed godziną nie zmienia obrazu, który widzi CFO na rannym stand-upie. Wyjątkiem są systemy wymagające danych w czasie rzeczywistym (np. monitorowanie produkcji) — tam architektura jest inna i nie sprowadza się do Power BI z jednym odświeżeniem dziennie.
Kiedy DirectQuery ma sens
DirectQuery ma sens — ale dla właściwego rodzaju bazy danych. Konkretnie: dedykowanych platform analitycznych zaprojektowanych pod obciążenie zapytaniami. Azure Synapse Analytics, Fabric Data Warehouse, SQL Server Analysis Services — to są systemy, których zadaniem jest odpowiadanie na setki złożonych zapytań analitycznych jednocześnie. Mają pod to zasoby, indeksy i architekturę.
W projektach opartych na Microsoft Fabric możliwe jest użycie Live Connection lub DirectQuery do Fabric Data Warehouse — i to jest architektonicznie sensowne. Dane z systemu ERP zasilają Fabric przez ETL, Fabric DW obsługuje zapytania Power BI. System ERP nadal nie jest odpytywany bezpośrednio.
Zasada jest prosta: DirectQuery jest dobry, jeśli źródło jest zaprojektowane pod analitykę. Żaden system ERP on-premise nie jest.
Co zapytać dostawcę
Jedno konkretne pytanie, które warto zadać dostawcy proponującemu DirectQuery do systemu ERP:
"W jakim trybie będzie połączenie Power BI z naszym systemem ERP i jak to wpłynie na wydajność systemu w godzinach pracy działu księgowości?"
Jeśli odpowiedź jest niejasna, ogólna lub dostawca mówi "DirectQuery jest szybki i aktualny" bez słowa o wpływie na bazę operacyjną — to sygnał, że architektura nie została przemyślana. Drugi wariant do sprawdzenia: Import bez ETL (Power Query bezpośrednio do tabel operacyjnych). Brak warstwy pośredniej oznacza brak obsługi błędów, brak ładowania przyrostowego i zależność od schematu bazy ERP — cokolwiek się zmieni po aktualizacji systemu, raport przestaje działać.
Podsumowanie
Dla systemów ERP on-premise — Import z ETL to jedyna architektura, którą stosuję i rekomenduje. DirectQuery do operacyjnej bazy danych to ryzyko dla wydajności systemu, które ujawnia się dopiero gdy kilku użytkowników zacznie jednocześnie klikać w raporty. Wybór trybu połączenia to nie technikalia — to decyzja o tym, czy system BI będzie działał obok ERP, czy będzie z nim konkurował o zasoby.
Najczęstsze pytania
Jak często można odświeżać dane w trybie Import?
Z licencją Power BI Pro — do 8 razy dziennie. Z Power BI Premium lub Microsoft Fabric — do 48 razy dziennie. Dla raportów zarządczych jedno odświeżenie rano wystarczy. Jeśli potrzeba danych co godzinę — to też jest możliwe w ramach Import, bez DirectQuery.
Czy tryb Import ma ograniczenia rozmiaru danych?
Tak — model Power BI w trybie Import ma limit 1 GB (Pro) lub 25 GB (Premium/Fabric). Dla typowych danych finansowych z kilku lat działania firmy to zazwyczaj wystarczające. Przy bardzo dużych wolumenach — Fabric Data Warehouse jako warstwa pośrednia rozwiązuje problem.
Czy możliwe jest połączenie kilku trybów w jednym projekcie?
Tak. Jeden raport może korzystać z Import dla danych historycznych z ERP i DirectQuery dla danych z Fabric DW w czasie rzeczywistym. To wymaga świadomego projektu architektury — nie jest to coś, co wychodzi samo z siebie.
Powiązane
Dostałeś ofertę z DirectQuery i chcesz ją ocenić?
Opisz z jakiego systemu korzystasz i co proponuje dostawca — odpiszę czy architektura ma sens.
Porozmawiajmy