Kurs Power BI: Odświeżanie przyrostowe (incremental refresh)

W skrócieOdświeżanie przyrostowe (incremental refresh) dzieli tabelę faktów na partycje po dacie i odświeża tylko najświeższe, zamiast za każdym razem przetwarzać wszystkie wiersze. Na danych Nordvelli z SQL Server ustawiamy RangeStart i RangeEnd, politykę archiwum, wykrywanie zmian i bramę danych, a po publikacji sprawdzamy partycje.

Tabela faktów Nordvelli, czyli FaktSprzedaz, ma 108 675 wierszy z lat 2022 do 2026 i rośnie z każdą transakcją w sieci sklepów. Gdy opublikujesz taki model w usłudze Power BI i ustawisz codzienne odświeżanie, domyślnie za każdym razem przetwarzane są wszystkie wiersze, także sprzedaż z 2022 roku, która od dawna się nie zmienia. To marnuje czas i obciąża bazę, a przy dużych tabelach zaczyna przekraczać limity odświeżania. Odświeżanie przyrostowe (po angielsku incremental refresh) rozwiązuje ten problem: Power BI dzieli tabelę na partycje po dacie i odświeża tylko te najświeższe.

W tym rozdziale zbudujemy odświeżanie przyrostowe od zera, na bazie Nordvelli w MS SQL Server. Dodasz parametry RangeStart i RangeEnd, założysz filtr daty, który składa się do bazy, ustawisz politykę archiwum i odświeżania z wykrywaniem zmian, opublikujesz model przez bramę danych, a na koniec sprawdzisz w usłudze, które partycje powstały i które się odświeżyły.

Po co odświeżanie przyrostowe: skala danych i okno czasu

Co chcemy osiągnąć. Sprzedaży Nordvelli przybywa codziennie, a pełne odświeżanie za każdym razem czyta całą historię od 2022 roku. Chcemy, żeby model odświeżał tylko ostatni okres, a starych lat nie ruszał.

Zacznijmy od liczb, bo to one decydują, czy odświeżanie przyrostowe jest Ci potrzebne. FaktSprzedaz w Nordvelli ma 19 550 wierszy z 2022 roku, 21 747 z 2023, 26 164 z 2024, 29 545 z 2025 i 11 669 z pięciu miesięcy 2026 roku. Razem 108 675 wierszy. To model szkoleniowy. W dużej sieci sklepów taka tabela może rosnąć o dziesiątki tysięcy wierszy dziennie i po kilku latach liczyć dziesiątki milionów. Kluczowa obserwacja jest prosta: dane historyczne się nie zmieniają. Transakcja z marca 2022 roku jest zamknięta i codzienne wczytywanie jej od nowa to strata czasu.

Odświeżanie pełne za każdym razem czyta całe źródło. Odświeżanie przyrostowe czyta tylko okno czasu, w którym coś mogło się zmienić. Reszta tabeli, czyli partycje starszych okresów, zostaje z poprzedniego odświeżenia. Tabela pokazuje, co to znaczy dla FaktSprzedaz z ustawieniami z tej lekcji.

Okno odświeżania ustawiliśmy na 6 miesięcy, bo dane Nordvelli kończą się 31 maja 2026 roku, a okno liczy się wstecz od dnia odświeżenia (u nas 16 października 2026). W sklepie, w którym sprzedaż przybywa codziennie, wystarczy kilka dni, na przykład 10.

Jak to działa: partycje i składanie zapytania

Co chcemy osiągnąć. Odświeżanie przyrostowe ustawiamy w Desktopie, ale działa ono dopiero w usłudze Power BI. Chcemy rozumieć ten mechanizm przed konfiguracją, bo bez tego trudno później ocenić, czy działa poprawnie.

Power BI dzieli FaktSprzedaz na partycje, czyli osobno przechowywane kawałki tabeli. Każda partycja obejmuje jeden przedział dat. Partycje starsze niż okno odświeżania są budowane raz i potem tylko odczytywane. Partycje z okna są przy każdym odświeżeniu budowane od nowa, więc łapią świeże i poprawione wiersze. Im starszy okres, tym grubsze partycje: Power BI łączy stare miesiące w kwartały, a kwartały w lata.

Cały ten podział napędza jedno zapytanie z filtrem daty. Dlatego parametry RangeStart i RangeEnd są sercem mechanizmu: usługa podstawia pod nie granice kolejnych partycji i wykonuje Twoje zapytanie osobno dla każdej partycji, którą buduje.

Jest jeden warunek, o którym trzeba wiedzieć od razu. Filtr RangeStart i RangeEnd musi zostać wykonany w bazie, a nie po pobraniu całej tabeli do Power BI. Takie przekazanie kroków do źródła to składanie zapytania (po angielsku query folding). Bez niego usługa i tak ściągnęłaby całą tabelę dla każdej partycji i dopiero potem ją przefiltrowała. Dla bazy SQL składanie działa, dla arkusza Excel go nie ma, dlatego w tej lekcji czytamy dane z SQL Server.

Składania nie trzeba przyjmować na wiarę. W edytorze Power Query kliknij prawym przyciskiem ostatni krok zapytania FaktSprzedaz i wybierz Wyświetl zapytanie natywne. Power BI pokaże SQL, który naprawdę wyśle do bazy. Jeśli w klauzuli where widzisz granice okna, filtr wykonuje się na serwerze. Jeśli ta pozycja menu jest wyszarzona, składanie urwało się wcześniej.

Źródło: baza SQL z kolumną daty i znacznikiem modyfikacji

Co chcemy osiągnąć. Odświeżanie przyrostowe potrzebuje w tabeli faktów kolumny typu data i godzina, po której da się dzielić dane, a wykrywanie zmian dodatkowo kolumny ze znacznikiem ostatniej modyfikacji. Chcemy przygotować obie w bazie Nordvelli, zanim połączymy się z nią w Power BI.

Odtwórz bazę z pliku Nordvella.bak.gz z bloku Pliki do tej lekcji (rozpakuj go i użyj polecenia RESTORE DATABASE w SQL Server). FaktSprzedaz ma w niej tylko klucz DataID w postaci liczby RRRRMMDD, wskazujący na DimKalendarz. Filtr po kluczu z wymiaru nie wystarczy, dlatego kolumnę daty dokładamy w bazie, jako kolumnę obliczaną i utrwaloną:

ALTER TABLE dbo.FaktSprzedaz
    ADD DataSprzedazy AS
        CONVERT(datetime, CAST(DataID AS char(8)), 112) PERSISTED;

Styl 112 w CONVERT jest tu obowiązkowy. Sprawdziliśmy to na naszym serwerze: bez niego SQL Server odmawia z błędem 4936 („Computed column ... cannot be persisted because the column is non-deterministic”), bo konwersja bez jawnego stylu zależy od ustawień językowych sesji. Kolumnę daty można też zbudować w Power Query, scalając tabelę z DimKalendarz, ale wtedy filtr okna czasu nie złoży się do zapytania SQL. Dlatego robimy to w źródle.

Druga kolumna, OstatniaModyfikacja, posłuży do wykrywania zmian. Ma rosnąć przy każdej zmianie wiersza. Dla istniejących danych ustawiamy ją na datę zwrotu (bo zwrot to zmiana sprzedaży), a gdy zwrotu nie było, na datę sprzedaży. Nowe wiersze dostaną bieżący czas z wartości domyślnej, a każda późniejsza zmiana wiersza zaktualizuje znacznik przez wyzwalacz:

ALTER TABLE dbo.FaktSprzedaz
    ADD OstatniaModyfikacja datetime2(0) NULL;
GO

UPDATE f
SET OstatniaModyfikacja = COALESCE(z.OstatniZwrot, f.DataSprzedazy)
FROM dbo.FaktSprzedaz AS f
LEFT JOIN (
    SELECT SprzedazID,
           MAX(CONVERT(datetime2(0),
               CAST(DataZwrotu AS char(8)), 112)) AS OstatniZwrot
    FROM dbo.FaktZwroty
    GROUP BY SprzedazID
) AS z ON z.SprzedazID = f.SprzedazID;

ALTER TABLE dbo.FaktSprzedaz
    ALTER COLUMN OstatniaModyfikacja datetime2(0) NOT NULL;

ALTER TABLE dbo.FaktSprzedaz
    ADD CONSTRAINT DF_FaktSprzedaz_OstatniaModyfikacja
    DEFAULT SYSDATETIME() FOR OstatniaModyfikacja;
GO

CREATE TRIGGER dbo.TR_FaktSprzedaz_OstatniaModyfikacja
ON dbo.FaktSprzedaz AFTER UPDATE AS
BEGIN
    SET NOCOUNT ON;
    IF UPDATE(OstatniaModyfikacja) RETURN;
    UPDATE f SET OstatniaModyfikacja = SYSDATETIME()
    FROM dbo.FaktSprzedaz AS f
    JOIN inserted AS i ON i.SprzedazID = f.SprzedazID;
END;

Uruchom skrypt w całości, na przykład w SQL Server Management Studio. Słowo GO dzieli go na partie i jest tu potrzebne. Bez GO po pierwszym poleceniu SQL Server zgłasza błąd 207 „Invalid column name 'OstatniaModyfikacja'”, bo kompiluje całą partię, zanim doda kolumnę. Sprawdziliśmy oba warianty na kopii tabeli. Z podziałem na partie znacznik późniejszy niż data sprzedaży dostało 2 713 transakcji, czyli te, przy których był zwrot później niż w dniu zakupu (zwrotów jest 2 714, jeden ma datę zakupu). Liczba wierszy (108 675) i suma sprzedaży (467 775 009,17 zł) przed zmianą i po niej były takie same, bo kolumny dochodzą obok danych.

Zobacz też: Szkolenie Power BI - Desktop, DAX i Online + Copilot

Teraz połączenie. W nowym, pustym pliku Power BI Desktop kliknij na karcie Narzędzia główne SQL Server. W polu Serwer wpisz adres swojego serwera, w polu Baza danych wpisz Nordvella, zostaw tryb Importuj i kliknij OK.

W oknie Nawigator zaznacz FaktSprzedaz, DimSklepy i DimKalendarz. Zanim klikniesz dalej, sprawdź w podglądzie, czy FaktSprzedaz ma obie nowe kolumny. Podgląd bywa zapamiętany z wcześniejszego połączenia, więc odśwież go ikoną w prawym górnym rogu. Potem kliknij Przekształć dane, nie Załaduj: filtr założymy, zanim do modelu trafi cała tabela.

Parametry RangeStart i RangeEnd w Power Query

Co chcemy osiągnąć. Usługa Power BI musi wiedzieć, od której do której daty odświeżać dane Nordvelli. Chcemy przygotować dwa parametry, przez które przekaże zapytaniu te granice.

W edytorze Power Query kliknij na karcie Narzędzia główne strzałkę przycisku Zarządzaj parametrami i wybierz Nowy parametr. Utworzysz dwa parametry o dokładnie tych nazwach: RangeStart i RangeEnd. Power BI rozpoznaje je po nazwie, więc literówka typu RangeStar sprawi, że polityka odświeżania nie będzie dostępna.

Dla każdego ustaw w oknie: Typ Data/godzina, Sugerowane wartości Dowolna wartość i niepustą Wartość bieżącą. Pole Wymagane zostaw zaznaczone. Wartość bieżąca służy tylko do podglądu w Desktopie, w usłudze silnik odświeżania podstawi własne granice. Ustaw RangeStart na 01.01.2026 00:00:00, a RangeEnd na 01.02.2026 00:00:00: w edytorze zobaczysz wtedy jeden miesiąc danych. Drugi parametr dodasz linkiem Nowy nad listą, bez zamykania okna.

Okno parametru zapisuje parametry jako zapytania w języku M. W naszym pliku wyglądają tak (rekord meta rozbiliśmy na linie, w pliku jest w jednej):

// RangeStart
#datetime(2026, 1, 1, 0, 0, 0) meta [
    IsParameterQuery=true,
    Type="DateTime",
    IsParameterQueryRequired=true
]

// RangeEnd
#datetime(2026, 2, 1, 0, 0, 0) meta [
    IsParameterQuery=true,
    Type="DateTime",
    IsParameterQueryRequired=true
]

Nie wpisujesz tego kodu ręcznie, generuje go okno parametru, ale warto wiedzieć, co powstaje. Po kliknięciu OK w panelu Zapytania po lewej pojawią się dwie nowe pozycje.

Filtr daty na FaktSprzedaz według RangeStart i RangeEnd

Co chcemy osiągnąć. Chcemy połączyć parametry z tabelą FaktSprzedaz tak, żeby zapytanie pobierało tylko transakcje z zadanego okresu.

W panelu Zapytania kliknij FaktSprzedaz i znajdź kolumnę DataSprzedazy (jest daleko w prawo, najszybciej dojdziesz do niej poleceniem Wybieranie kolumn, Przejdź do kolumny). Kliknij strzałkę filtra w nagłówku kolumny, wybierz Filtry dat/godzin i na końcu listy Filtr niestandardowy.

W oknie Filtrowanie wierszy ustaw pierwszy warunek na jest po lub jest równe. Kliknij przełącznik typu między operatorem a polem wartości, wybierz Parametr i z listy RangeStart. Drugi warunek, połączony przez Oraz, ustaw na jest przed i parametr RangeEnd. Ta asymetria, od RangeStart włącznie do RangeEnd wyłącznie, sprawia, że wiersz z granicy dwóch partycji trafi tylko do jednej z nich.

Po kliknięciu OK podgląd FaktSprzedaz skurczy się do stycznia 2026, a w panelu Zastosowane kroki dojdzie krok Przefiltrowano wiersze. Całe zapytanie FaktSprzedaz z naszego pliku wygląda tak (ostatni krok rozbiliśmy na linie, w Edytorze zaawansowanym jest w jednej):

let
    Źródło = Sql.Database("192.168.1.206,1433", "Nordvella"),
    dbo_FaktSprzedaz = Źródło{[Schema="dbo",Item="FaktSprzedaz"]}[Data],
    #"Przefiltrowano wiersze" = Table.SelectRows(
        dbo_FaktSprzedaz,
        each [DataSprzedazy] >= RangeStart and [DataSprzedazy] < RangeEnd
    )
in
    #"Przefiltrowano wiersze"

Teraz kliknij Zamknij i zastosuj. Do modelu trafi tylko styczeń 2026: u nas 2 782 wiersze FaktSprzedaz i 11 798 138,92 zł sprzedaży. Tak ma być, pełną historię zbuduje dopiero usługa po publikacji.

Polityka archiwum i odświeżania w Desktopie

Co chcemy osiągnąć. Chcemy ustalić, jak długą historię sprzedaży Nordvelli trzyma model i jaki ostatni okres ma się odświeżać przy każdym przebiegu.

W widoku raportu kliknij prawym przyciskiem tabelę FaktSprzedaz w panelu Dane i wybierz Odświeżanie przyrostowe. Obecność tej pozycji to szybki test wcześniejszych kroków: Power BI widzi parametry i filtr, który się do nich odwołuje.

W oknie Odświeżanie przyrostowe i dane w czasie rzeczywistym włącz przełącznik Odśwież przyrostowo tę tabelę. Potem ustawiasz dwie liczby, które są sercem konfiguracji. Pierwsza to Rozpoczynanie archiwizowania danych: jak długą historię model przechowuje. Dane Nordvelli zaczynają się w 2022 roku, więc 5 lat obejmie całą historię. Druga to Uruchamianie odświeżania przyrostowego danych: ile ostatniego czasu usługa przetwarza przy każdym odświeżeniu. My ustawiamy 6 miesięcy, z powodu opisanego na początku rozdziału.

Niżej, w części Wybierz ustawienia opcjonalne, są trzy pola. Pierwsze dotyczy danych w czasie rzeczywistym przez DirectQuery i jest dostępne tylko w warstwie Premium. Drugie, przy oknie w miesiącach opisane jako „Odświeżaj tylko pełne miesiący” (pisownia z okna Power BI), sprawia, że bieżący, niezakończony okres nie trafia do odświeżania, dopóki się nie skończy. Przy oknie liczonym w dniach to samo pole dotyczy pełnych dni. Trzecie to Wykryj zmiany danych: zaznacz je i z listy pod spodem wybierz kolumnę OstatniaModyfikacja.

Wykrywanie zmian danych (detect data changes)

Co chcemy osiągnąć. Nie w każdym miesiącu okna przybywa albo zmienia się sprzedaż, a usługa bez wykrywania zmian i tak przebudowuje wszystkie partycje okna. Chcemy, żeby odświeżała tylko te, w których dane naprawdę się zmieniły.

Samo okno odświeżania to już duża oszczędność, ale można pójść dalej. Wykrywanie zmian danych sprawia, że przed przebudową każdej partycji z okna Power BI pyta źródło o maksymalną wartość wybranej kolumny w tej partycji i porównuje ją z wartością zapamiętaną przy poprzednim odświeżeniu. Jeśli maksimum się nie zmieniło, partycja jest pomijana. Zapytanie sprawdzające Power BI zapisuje w modelu sam. W naszym pliku wygląda tak (w modelu jest w jednej linii, tu rozbite dla czytelności):

let
    MaxOstatniaModyfikacja = List.Max(FaktSprzedaz[OstatniaModyfikacja]),
    accountForNull =
        if MaxOstatniaModyfikacja = null
        then #datetime(1901, 01, 01, 00, 00, 00)
        else MaxOstatniaModyfikacja
in
    accountForNull

Czytaj to tak: weź największą wartość OstatniaModyfikacja w partycji, a jeśli partycja jest pusta, użyj stałej daty z 1901 roku. Puste partycje okna (u nas czerwiec-październik 2026) dają więc zawsze tę samą wartość i przy kolejnych odświeżeniach są pomijane. Wybór DataSprzedazy jako kolumny zmian nie miałby sensu: lista w oknie go dopuszcza, ale data starej transakcji się nie zmienia, więc korekta takiej transakcji nie zostałaby wykryta.

Publikacja, brama danych i pierwsze odświeżenie

Co chcemy osiągnąć. Polityka zaczyna działać dopiero w usłudze Power BI. Chcemy opublikować model Nordvelli, połączyć go z bazą przez bramę danych i uruchomić pierwsze odświeżenie, które zbuduje partycje.

Polityka jest zapisana w modelu, ale partycje jeszcze nie istnieją. Zapisz plik, kliknij na karcie Narzędzia główne Opublikuj i wybierz obszar roboczy, u nas Nordvella Zarzad. Ponieważ źródłem jest serwer w sieci firmowej, Power BI Desktop zakończy publikację takim komunikatem:

Usługa działa w chmurze i nie widzi serwera 192.168.1.206. Most między nimi to lokalna brama danych (po angielsku on-premises data gateway), program zainstalowany na komputerze w sieci firmy. Instalację i rejestrację bramy omawiamy w lekcji 24. U nas brama Brama-Nordvella działa na maszynie POWERBI-KURS i ma już połączenie Nordvella SQL z serwerem 192.168.1.206,1433 i bazą Nordvella.

W ustawieniach modelu semantycznego rozwiń Połączenia bramy i chmury. Zaznacz bramę na liście, a w wierszu źródła danych wybierz z listy Mapowane na połączenie z tym samym serwerem i bazą. Kliknij Zastosuj.

Sprawdź skutek, zanim przejdziesz dalej. U nas pierwsza próba odświeżenia zakończyła się komunikatem „Odświeżanie nie powiodło się, ponieważ ten model semantyczny wymaga bramy”, więc powiązanie trzeba było zapisać jeszcze raz. Po ponownym zapisie lista źródeł modelu pokazywała już identyfikator bramy.

Teraz pierwsze odświeżenie. W obszarze roboczym najedź na model semantyczny nordvella_19_incremental i kliknij ikonę Odśwież teraz obok nazwy. Przy publikacji w Desktopie był jeden miesiąc danych, a pierwsze odświeżenie w usłudze zbuduje wszystkie partycje, od archiwum po okno.

Pierwsze odświeżenie trwało u nas 23 sekundy. Po nim raport w usłudze pokazuje pełną historię, choć w opublikowanym pliku był tylko styczeń 2026:

Weryfikacja partycji po publikacji

Co chcemy osiągnąć. Chcemy sprawdzić, że odświeżanie przyrostowe modelu Nordvelli naprawdę działa: że partycje powstały i że kolejne odświeżenie przebudowuje tylko to, co powinno.

Pierwszy, prosty dowód to historia odświeżania (Więcej opcji przy modelu, Historia odświeżania), którą pokazaliśmy na początku rozdziału. Dokładniejszy to lista partycji. Przy modelu kliknij Więcej opcji i wybierz Otwórz w widoku zapytania DAX. W edytorze wpisz zapytanie, które wybiera partycje tabeli FaktSprzedaz, i kliknij Uruchom. Poniżej jest w takiej postaci, w jakiej ułożył je przycisk Format:

EVALUATE
    VAR Fakt = SELECTCOLUMNS(
        FILTER(
            INFO.TABLES(),
            [Name] = "FaktSprzedaz"
        ),
        "ID", [ID]
    )
    RETURN
        SELECTCOLUMNS(
            FILTER(
                INFO.PARTITIONS(),
                [TableID] IN Fakt
            ),
            "Partycja", [Name],
            "Odświeżona", [RefreshedTime]
        )
    ORDER BY [Partycja]

Funkcje INFO.TABLES i INFO.PARTITIONS czytają metadane modelu, więc potrzebują uprawnień do jego edycji. W widoku zapytań DAX usługi zadziałały u nas od razu. To samo zapytanie wysłane przez interfejs API (executeQueries) skończyło się błędem, zadziałały tam tylko funkcje INFO.VIEW.

Teraz sprawdźmy wykrywanie zmian. W bazie zmieniamy jedną transakcję z 20 maja 2026 tak, żeby wyzwalacz zaktualizował jej znacznik, ale wartości zostały te same:

UPDATE dbo.FaktSprzedaz
SET KanalSprzedazy = KanalSprzedazy
WHERE SprzedazID = 107749;

Po tym poleceniu OstatniaModyfikacja transakcji 107749 zmieniła się z 2026-05-20 00:00:00 na 2026-10-16 19:17:21 (serwer SQL liczy czas w UTC). Drugie odświeżenie w usłudze trwało około 5 sekund (od 21:17:52 do 21:17:57 w historii odświeżania). Zapytanie o partycje uruchomione ponownie pokazuje, co zrobiła usługa:

Częste pułapki i lista kontrolna wdrożenia

Co chcemy osiągnąć. Chcemy wdrożyć odświeżanie przyrostowe w Nordvelli bez błędów, na których traci się najwięcej czasu, i mieć listę do odhaczenia przed publikacją modelu.

Odświeżanie przyrostowe działa, dopóki wszystkie elementy do siebie pasują. Najwięcej czasu zabierają powtarzalne błędy w kilku miejscach. Pierwsze z nich to składanie zapytania.

Przed publikacją modelu Nordvelli na produkcję sprawdź więc: parametry RangeStart i RangeEnd istnieją, mają typ Data/godzina i są użyte w filtrze FaktSprzedaz z operatorami większe lub równe od dołu i ostro mniejsze od góry. Okres archiwum jest dłuższy niż okno odświeżania i obejmuje historię potrzebną do porównań rok do roku. Kolumna wykrywania zmian jest osobna od kolumny podziału i rośnie przy każdej modyfikacji. Źródło to baza, która składa zapytania, a model w usłudze jest powiązany z bramą danych. Po publikacji drugie odświeżenie jest wyraźnie krótsze od pierwszego, a lista partycji potwierdza, że archiwum się nie zmienia.

✕