Der Incremental Refresh ermöglicht es, große Datenanwendungen im Power BI Cloud Service "wachsen" zu lassen mit dennoch kurzen (bspw. täglichen) Aktualisierungsvorgängen. Neben der kurzen Aktualisierungszeit spielt aber auch die Schonung von (Cloud-)Ressourcen an der Datenquelle ein Rolle, da beim (täglichen oder mehrfach täglichen) Full Load massiv Ressourcen verschwendet werden.

Voraussetzungen

Für die Nutzung des Incremental Refresh müssen folgende Voraussetzungen erfüllt sein:

• Power BI Cloud Service (Pro oder Premium)
  Der Incremental Refresh ist nur im PBI Cloud Service, nicht in PBI Desktop und nicht im PBI Report Server verfügbar.
  Voraussetzung ist eine Pro Lizenz. Die Premium (per User) Lizenz ermöglicht über den XMLA Endpoint zwar den Zugriff auf die Partitionen, die durch den Incremental Refresh erzeugt werden, ist aber keine Voraussetzung für die Nutzung.
  
  
• Tabelle kommt aus einer einzigen Datenquelle
  Der Incremental Refresh wird auf Tabellenebene aktiviert. Die Tabelle muß aus einer einzigen Datenquelle geladen werden, Append Queries aus mehreren Datenquellen werden nicht unterstützt.
  
  
• Tabelle hat geeignete Datumsspalte
  Der Incremental Refresh benötigt eine (geeignete) Datumsspalte, auf die der Refresh referenziert wird.
  
  
• Tabelle wird mit Query Folding geladen (Relationale Datenquelle)
  Der Incremental Refresh kann grundsätzlich nur auf relationale Datenquellen (SQL, Oracle, usw.) aktiviert werden. Der Zeitfilter für den Incremental Refresh muß an einer Stelle in der Query eingesetzt werden, an dem das Query Folding jedenfalls noch aktiv sein muß. Ansonsten würde der Effekt eines kurzen Refresh-Vorgangs verloren gehen. Als "Hack" ist der Incremental Report auch iVm dem Folder Import (von Files) anwendbar, man verlässt damit aber den offiziell unterstützten Pfad.
  
  

Weiters spielen die Time Limits für den Refresh im Cloud Service eine große Rolle, die gleichermaßen auch beim normalen Full Load gelten: ein Refreshvorgang kann mit der Pro Lizenz derzeit maximal 2 h und mit einer Premium (per User) Lizenz maximal 5 h dauern.

Ausgangssituation

Angewendet werden soll der Incremental Refresh in einer PBI Anwendung für die Auswertung von Log Daten einer Anwendung, die laufend neue Datensätze generiert. Konkret geht es um die Aktualisierung der Tabelle FACT Process Log:

Schritt 1: Parametrisierung der Query (PBI Desktop)

Im ersten Schritt werden für die zugrundeliegende Power Query zwei standardisierte Parametern im Date/Time Format angelegt:

• RangeStart
• RangeEnd

Die Current Values spielen für die spätere Aktualisierung im laufenden Betrieb keine Rolle, bestimmen aber den Umfang des Datenbestand in der PBI Desktop Anwendung. Die Werte werden daher in der Praxis so gewählt, daß in PBI Desktop überschaubare Ladezeiten resultieren und die Datenmenge repräsentativ genug ist, um die Anwendung weiterentwickeln zu können:

Im nächsten Schritt wird die Stelle identifiziert, an der der Zeitfilter für den Incremental Refresh eingesetzt werden kann. Grundsätzlich sollte der Filter so weit oben in der Applied Steps Liste angesiedelt werden wie möglich, jedenfalls muß aber das Query Folding aktiv sein - zu erkennen an einem aktiven Eintrag View Native Query im Kontextmenü des jeweiligen Steps:

Der neu eingefügte Zeitfilter auf die relevante Datumsspalte wird auf die beiden Parameter RangeStart und RangeEnd referenziert:

Für die Nachvollziehbarkeit des Incremental Refresh wird noch eine Last Refreshed Spalte mit dem Ausführungsdatum des Imports eingefügt:

Nach der Ausführung des Imports in PBI Desktop resultiert ein Datenstand, der aus den Current Values der beiden Importparameter resultieren:

Schritt 2: Aktivierung im Datenmodell (PBI Desktop)

Im nächsten Schritt wird im Datenmodell auf Tabellenebene die Konfiguration des Incremental Refresh aufgerufen:

Der Incremental Refresh wird für die ausgewählte Tabelle durch Betätigung des Schiebereglers aktiviert:

Mit den folgenden 5 Parametern wird der Incremental Refresh konfiguriert:

1. Anzahl der historischen Perioden vor dem aktuellen Refresh Date
   Das bedeutet, daß der Incremental Refresh automatisch mit einem rollierenden Datenimport verbunden ist. Werden bspw. 36 Monate eingestellt, dann wird beim Monatswechsel das älteste Monat entfernt und das neue Monat begonnen.
   
2. Inkrement, das bei einem Refresh aktualisiert wird
   Werden bspw. 10 Tage eingestellt, dann werden bei jedem Refresh die Datensätze der letzten 10 Tage aktualisiert.
   
3. Option für aktuellste Daten im Direct Query Modus
   Das Feature ist nur mit einer Premium (per User) Lizenz möglich. Die Tabelle wird mit dieser Option zum "Hybrid Table", eine sehr interessante Option zur Nutzung von Direct Query.
   
4. Option für Aktualisierung nur vollständiger Perioden
   Die Option bezieht sich auf das definierte Inkrement und führt dazu, daß die Daten nicht bis heute sonder nur bspw. bis zum letzten Monatsultimo eingelesen werden.
   
5. Option für Data Changes
   Mit dieser Option wird der (zeitgesteuerte) Refresh nur ausgeführt, wenn am hinterlegten Measure Änderungen des Wertes festgestellt werden.

In unserem Fall definieren wir 5 historische Jahre und 1 Monat Inkrement:

Schritt 3: Upload in den PBI Service und Einsehen mit dem XMLA-Endpoint

Die Definition des Incremental Refresh ist abgeschlossen, jetzt wir die PBIX-Datei hochgeladen in den PCI Cloud Service:

Am Datenstand hat sich dadurch noch nichts geändert:

Der sogenannte XMLA Endpoint ist im Menüpunkt Servereinstellungen in den Dataset Settings zu finden, allerdings nur bei aktiver Premium (per User) Lizenz. Der Connection String kann hier kopiert werden ...

... und im SQL Server Management Studio im Modul Analysis Services eingefügt und mit den eigenen Credentials angemeldet:

Der XMLA Endpoint ermöglicht die Betrachtung der Partitionen der Tabellen des Datenmodells. Zum jetztigen Zeitpunkt - das Dataset wurde durch Upload im PBI Cloud Service erzeugt aber noch nicht aktualisiert - verfügt die Tabelle FACT Process Log nur über eine einzige Partition:

Schritt 4: Initialer Refresh im PBI Service

Jetzt wird das Dataset erstmalig im PBI Cloud Service aktualisiert ...

... und die Konfiguration des Incremental Refresh wird aktiv. Die 5 historischen Jahre werden jetzt eingelesen und anhand des Last Refreshed Timestamps ist erkennbar, daß die Jahre, die ganzen Quartale des lfd. Jahres sowie die beiden aktuellsten Monate in getrennten Inkrementen eingelesen wurden:

Der Incremental Refresh hat im Hintergrund die Tabelle partitioniert, die erzeugten Partitionen sind über den XMLA Endpoint einsehbar:

Schritt 5: Täglicher Refresh im PBI Service

Beim Refresh am ersten Tag nach dem initialen Refresh wird nur noch das laufende Monat aktualisiert, die vorangehenden Perioden bleiben unverändert stehen:

Zur Bestätigung die Sicht auf die Partitionen:

Und auch noch die Sicht nach der Aktualisieurng am zweiten Tag nach dem initialen Refresh:

Zur Bestätigung wiederum die Sicht auf die Partitionen:

Fazit und Ausblick

Der Incremental Refresh ist wirklich sehr einfach in Betrieb zu nehmen und unkompliziert zu verwenden.

Die Besonderheiten, die sich im Praxisbetrieb ergeben, werden Inhalt des zweiten Teils dieser Blogserie sein.

Quellen

https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview

https://radacad.com/all-you-need-to-know-about-the-incremental-refresh-in-power-bi-load-changes-only