Inkrementelle Aktualisierung in Power BI: Effizienter Umgang mit großen Datensätzen

Irgendwann stößt jede Power BI-Implementierung auf dieselbe Hürde: Der Datensatz wird so groß, dass vollständige Aktualisierungen zu lange dauern, zu viele Ressourcen verbrauchen und die verfügbaren Zeitfenster überschreiten, bevor Benutzer die Daten benötigen.

Eine Transaktionstabelle mit 50 Millionen Zeilen, die alle 4 Stunden vollständig aktualisiert wird, nimmt nicht nur viel Zeit in Anspruch, sondern verschwendet auch Ressourcen durch das erneute Laden von Daten, die sich nicht geändert haben. Die inkrementelle Aktualisierung löst dieses Problem, indem nur neue und geänderte Datensätze geladen werden, während die historischen Daten, die sich nicht ändern, erhalten bleiben. Bei richtiger Durchführung kann ein Datensatz, dessen Aktualisierung zuvor 3 Stunden dauerte, in weniger als 10 Minuten auf den neuesten Stand gebracht werden.

Dieser Leitfaden behandelt die inkrementelle Aktualisierung in Power BI von den ersten Prinzipien bis zur erweiterten Konfiguration – einschließlich der häufigsten Fehler, die Implementierungen zum Scheitern bringen, und der Best Practices, die sie produktionszuverlässig machen.

Wichtige Erkenntnisse

– Inkrementelle Aktualisierung partitioniert Datensätze nach Datum und lädt bei jedem Aktualisierungszyklus nur aktuelle Daten – Erfordert eine Datetime-Spalte in der Faktentabelle und zwei Power Query-Parameter (RangeStart, RangeEnd) – Historische Daten bleiben in älteren Partitionen erhalten, die nach dem ersten Laden nie erneut abgefragt werden – Power BI Premium (oder Fabric) ist für die inkrementelle Aktualisierung mit mehr als 10 Partitionen erforderlich – Die Option „Datenänderungen erkennen“ reduziert die Verarbeitung weiter, indem nur Partitionen aktualisiert werden, in denen sich Daten geändert haben – Hybridtabellen (die Import und DirectQuery kombinieren) ermöglichen Echtzeitdaten neben historischen Importpartitionen – Für die richtige Konfiguration ist das Verständnis der Power Query-Faltung erforderlich – nicht faltbare Abfragen unterbrechen die inkrementelle Aktualisierung – Die Überwachung des Partitionszustands über den XMLA-Endpunkt und Tools von Drittanbietern verhindert stille Fehler

---

So funktioniert die inkrementelle Aktualisierung

Um die inkrementelle Aktualisierung zu verstehen, müssen Sie zunächst verstehen, wie Power BI Daten partitioniert.

In einem Standardimportmodell befindet sich der gesamte Datensatz in einer einzigen Partition. Bei jeder Aktualisierung wird diese Partition vollständig ersetzt. Für kleine Datensätze ist dies in Ordnung. Bei großen Tabellen kommt es zu den oben beschriebenen Problemen.

Durch die inkrementelle Aktualisierung wird die Faktentabelle in mehrere Partitionen aufgeteilt, die jeweils einen bestimmten Datumsbereich abdecken:

• Partition 1: 01.01.2020 bis 31.12.2020 (historisch, nie aktualisiert)
• Partition 2: 01.01.2021 bis 31.12.2021 (historisch, nie aktualisiert)
• Partition 3: 01.01.2022 bis 31.12.2022 (historisch, nie aktualisiert)
• Partition 4: 01.01.2023 bis 31.12.2023 (historisch, nie aktualisiert)
• Partition 5: 01.01.2024 bis 31.12.2024 (monatlich aktualisiert)
• Partition 6: 01.01.2025 bis 31.03.2025 (täglich aktualisiert)
• Partition 7: 01.04.2025 bis aktuell (stündlich oder auf Anfrage aktualisiert)

Bei jeder geplanten Aktualisierung werden nur die neuesten Partitionen (in diesem Beispiel 5, 6 und 7) verarbeitet. Die historischen Partitionen bleiben seit dem ersten Laden erhalten. Dies bedeutet, dass ein Aktualisierungszyklus nur einen Bruchteil der Gesamtdaten verarbeitet – was Zeit, Speicher und Quellsystemlast drastisch reduziert.

---

Voraussetzungen und Anforderungen

Überprüfen Sie vor der Konfiguration der inkrementellen Aktualisierung, ob diese Voraussetzungen erfüllt sind:

Lizenzierung: Inkrementelle Aktualisierung ist in Power BI Pro (mit Einschränkungen) und Power BI Premium/Fabric (voller Funktionsumfang) verfügbar. Mit Pro können Sie bis zu 10 Aktualisierungsperioden konfigurieren. Premium hebt diese Beschränkung auf und fügt die Funktion „Datenänderungen erkennen“ hinzu.

Datetime-Spalte: Die Faktentabelle muss eine Datetime-Spalte (keine Datumsschlüssel-Ganzzahl – es muss ein tatsächlicher Datetime-Typ sein) enthalten, die Power BI zum Partitionieren der Daten verwendet. Dies ist normalerweise das Transaktionsdatum, der Ereigniszeitstempel oder die Spalte „Erstellt am“.

Abfragefaltung: Die Power Query-Abfrage, die die Faktentabelle lädt, muss die Abfragefaltung unterstützen – die Fähigkeit, Power Query-Transformationsschritte in eine Quellabfrage (SQL usw.) zu übersetzen, die das Quellsystem ausführt. Wenn die Abfragefaltung unterbrochen wird, schlägt die inkrementelle Aktualisierung stillschweigend fehl – ​​sie lädt alle Daten bei jeder Aktualisierung und verfehlt damit den Zweck.

Unterstützung des Quellsystems: Die Quelle muss die Datumsbereichsfilterung effizient unterstützen. Eine Quelltabelle ohne einen Index für die Spalte „Datum/Uhrzeit“ führt selbst bei konfigurierter inkrementeller Aktualisierung zu langsamen Aktualisierungen, da bei jeder Partitionsaktualisierung ein vollständiger Tabellenscan durchgeführt wird, um Datensätze im Datumsbereich zu finden.

---

Schritt-für-Schritt-Konfiguration

Schritt 1: Erstellen Sie die erforderlichen Power Query-Parameter

Öffnen Sie in Power BI Desktop den Power Query-Editor. Gehen Sie zu Parameter verwalten → Neuer Parameter.

Erstellen Sie zwei Parameter genau wie folgt (bei Namen wird die Groß-/Kleinschreibung beachtet und sie müssen genau übereinstimmen):

Diese Parameter müssen vom Typ Datum/Uhrzeit und nicht vom Typ Datum sein. Sie werden zur Laufzeit von der Aktualisierungs-Engine von Power BI überschrieben, benötigen jedoch gültige Standardwerte für Entwicklung und Tests.

Schritt 2: Filtern Sie die Faktentabelle anhand dieser Parameter

Wählen Sie im Power Query-Editor Ihre Faktentabelle aus. Wenden Sie mithilfe der folgenden Parameter einen Filter auf die Spalte „Datum/Uhrzeit“ an:

= Table.SelectRows(Source, each [TransactionDate] >= RangeStart and [TransactionDate] < RangeEnd)

Dieser Filterschritt ist von entscheidender Bedeutung: Er muss sich auf die Datenquelle beziehen. Um die Faltung zu überprüfen, klicken Sie mit der rechten Maustaste auf den letzten Abfrageschritt und prüfen Sie, ob „Native Abfrage anzeigen“ verfügbar ist. Wenn es ausgegraut ist, ist die Faltung unterbrochen. Untersuchen Sie, welche Transformationsschritte darüber die Faltungskette unterbrechen.

Schritt 3: Abfragefaltung überprüfen

Die Abfragefaltung bricht am häufigsten aus folgenden Gründen ab: – Benutzerdefinierte Funktionen, die nicht in SQL übersetzt werden können

• Zusammenführen (Verbinden) zweier Abfragen, bei denen eine oder beide nicht funktionieren
• Bestimmte Texttransformationsfunktionen (Text.Upper, Text.PadStart)
• Verwenden von Listenoperationen (List.Contains)
• Hinzufügen einer Indexspalte
• Bestimmte Typkonvertierungsvorgänge

Wenn die Faltung unterbrochen wird, überarbeiten Sie die Abfrage, um die problematischen Vorgänge in einen späteren Schritt nach dem Datumsfilter zu verschieben – oder führen Sie die Transformation in einer Ansicht in der Quelldatenbank statt in Power Query durch.

Schritt 4: Konfigurieren Sie die inkrementelle Aktualisierungsrichtlinie

Klicken Sie in Power BI Desktop mit der rechten Maustaste auf die Faktentabelle im Bereich „Felder“ → „Inkrementelle Aktualisierung“.

Die Konfigurationsmöglichkeiten:

• Zeilen in den letzten N Kalenderjahren/-monaten/-tagen speichern: Dies definiert das gesamte historische Fenster, das im Modell beibehalten wird. Ältere Daten werden automatisch aus dem Modell entfernt (verworfene Partitionen).

• Nur Zeilen in den letzten N Kalenderjahren/Monaten/Tagen aktualisieren: Dies definiert das fortlaufende Fenster, das in jedem Zyklus neu aktualisiert wird. Daten, die älter als dieses Fenster sind, werden als historisch (unveränderlich) behandelt und nie wieder aktualisiert.

• Datenänderungen erkennen: (nur Premium) Verwendet eine separate Datums-/Uhrzeitspalte (normalerweise eine „Zuletzt geändert“-Spalte), um zu erkennen, welche historischen Partitionen Daten geändert haben, und verarbeitet nur diese Partitionen erneut.

Beispielkonfiguration für eine Transaktionsdatenbank mit 5 Jahren Historie:

• Speichern Sie die Zeilen der letzten 5 Jahre
• Nur Zeilen der letzten 3 Tage aktualisieren

Dadurch werden Partitionen erstellt, die Daten von 5 Jahren abdecken, aber nur die Partitionen der letzten 3 Tage werden in jedem Zyklus aktualisiert.

Schritt 5: Veröffentlichen und validieren

Veröffentlichen Sie den Bericht im Power BI-Dienst. Die erste Aktualisierung nach der Veröffentlichung dauert länger als nachfolgende Aktualisierungen – alle historischen Daten werden geladen und alle Partitionen werden zum ersten Mal erstellt. Dies wird erwartet.

---

Erweiterte Konfiguration: Datenänderungen erkennen

Die Option „Datenänderungen erkennen“ in Premium sorgt für eine weitere Effizienzebene. Dabei wird eine bestimmte Spalte (normalerweise eine last_modified_date-Spalte) abgefragt, um festzustellen, ob Datensätze in einer historischen Partition aktualisiert wurden. Es werden nur Partitionen aktualisiert, in denen sich tatsächlich Daten geändert haben.

Ohne Datenänderungen zu erkennen: Das 3-Tages-Rolling-Fenster wird immer aktualisiert, auch wenn sich in den letzten 3 Tagen keine Daten geändert haben.

Bei der Erkennung von Datenänderungen prüft die Aktualisierungs-Engine, ob Datensätze im Rollfenster geändert wurden, bevor sie entscheidet, ob die einzelnen Partitionen verarbeitet werden sollen. Wenn die Daten vom Montag am Montagabend aktualisiert wurden und seitdem keine Datensätze geändert wurden, wird bei der Aktualisierung am Dienstagabend die Montagpartition übersprungen.

Dies ist besonders wertvoll für Szenarien, in denen:

• Quelldaten werden einmal geschrieben und selten aktualisiert (unveränderliche Nur-Anhänge-Ereignisse) – Das rollierende Fenster ist groß (z. B. 30 Tage), aber an den meisten Tagen gibt es keine Änderungen
• Die Abfragekapazität des Quellsystems ist begrenzt

Die Spalte „Datenänderungen erkennen“ muss in der Quelldatenbank indiziert sein – die Aktualisierungs-Engine fragt diese Spalte bei jedem Aktualisierungszyklus für jede Partition ab.

---

Hybridtabellen: Echtzeit- und historische Daten

Power BI Fabric/Premium führt Hybridtabellen ein – eine leistungsstarke Kombination aus Importmodus (historische Partitionen) und DirectQuery-Modus (Daten des aktuellen Tages). Dies ermöglicht Dashboards, die neben historischen Importdaten auch minutenaktuelle Daten anzeigen.

In einer Hybridtabellenkonfiguration:

• Historische Partitionen (gestern und älter) befinden sich im Importmodus – schnell, zwischengespeichert und vollständig aggregierbar – Die aktuelle Partition befindet sich im DirectQuery-Modus – Abfragen werden live für die Quelldatenbank ausgeführt

Das Benutzererlebnis ist nahtlos – Abfragen erstrecken sich transparent über beide Modi. Eine Abfrage nach „Verkäufe diese Woche vs. letzte Woche“ ruft die gestrigen Daten aus der Importpartition und die heutigen Daten über DirectQuery ab und kombiniert sie zu einem einzigen Ergebnis.

Überlegungen zu Hybridtabellen: – Die Leistung von DirectQuery hängt vollständig von der Leistung der Quelldatenbank ab – eine langsame Datenbank bedeutet langsame Abfragen für den aktuellen Tag – Die DirectQuery-Partition profitiert nicht von Optimierungen des Importmodus (keine VertiPaq-Komprimierung, keine Voraggregationen).

• Erfordert einen Premium- oder Fabric-Arbeitsbereich

---

Überwachung des Zustands der inkrementellen Aktualisierung

Inkrementelle Aktualisierungsfehler bleiben oft unbemerkt – das Modell wird als „erfolgreich aktualisiert“ angezeigt, selbst wenn einige Partitionen fehlgeschlagen sind oder auf die vollständige Aktualisierung zurückgefallen sind. Die Überwachung ist für die Produktionssicherheit unerlässlich.

XMLA-Endpunktprüfung: Power BI Premium stellt einen XMLA-Endpunkt bereit, mit dem Tools wie SQL Server Management Studio (SSMS), Tabular Editor oder Azure Analysis Services eine Verbindung herstellen können. Von dort aus können Sie die Partitionsmetadaten abfragen, um die letzte Aktualisierungszeit für jede Partition anzuzeigen und festzustellen, ob sich Partitionen in einem Fehlerzustand befinden.

Tabular Editor 2 (kostenlos): Stellen Sie über XMLA eine Verbindung zum Premium-Arbeitsbereich her und überprüfen Sie die Partitionstabelle im Modell. Für jede Partition werden Name, Datumsbereich, Zeitstempel der letzten Aktualisierung und Status angezeigt. Dies ist das praktischste Tool zur Diagnose von Problemen mit der inkrementellen Aktualisierung.

Power BI-Aktivitätsprotokoll: Das Administratoraktivitätsprotokoll zeichnet Aktualisierungsvorgänge auf, einschließlich der verarbeiteten Partitionen und etwaiger Fehler. Verfügbar über die Power BI REST API.

Häufige Fehlermuster:

---

Überprüfung der Abfragefaltung in der Praxis

Das Falten von Abfragen ist der häufigste Grund dafür, dass die inkrementelle Aktualisierung nicht die versprochenen Leistungssteigerungen liefert. Hier erfahren Sie, wie Sie häufig auftretende Faltbrüche diagnostizieren und beheben.

Test 1: Native Abfrage anzeigen. Nachdem Sie den Filterschritt „RangeStart/RangeEnd“ in Power Query hinzugefügt haben, klicken Sie mit der rechten Maustaste auf den Schritt. Wenn „Native Abfrage anzeigen“ verfügbar ist und eine SQL-Abfrage mit einer WHERE-Klausel zum Filtern des Datumsbereichs anzeigt, funktioniert die Faltung.

Test 2: Überprüfen Sie das generierte SQL. Die native Abfrage sollte etwa Folgendes enthalten:

WHERE [TransactionDate] >= @RangeStart AND [TransactionDate] < @RangeEnd

Wenn die WHERE-Klausel fehlt, ist die Faltung fehlerhaft und der Filter wird in der Power Query-Engine angewendet, nachdem alle Daten aus der Quelle geladen wurden.

Faltung wird wiederhergestellt: Wenn eine benutzerdefinierte Transformation die Faltung unterbrochen hat, verschieben Sie sie nach dem Datumsfilterschritt oder führen Sie die Transformation in einer SQL-Ansicht in der Quelldatenbank durch und verbinden Sie Power BI mit der Ansicht statt mit der Tabelle.

---

Häufig gestellte Fragen

Funktioniert die inkrementelle Aktualisierung mit allen Datenquellen?

Die inkrementelle Aktualisierung funktioniert mit jeder Datenquelle, die Abfragefaltung und Datumsbereichsfilterung unterstützt, einschließlich SQL Server, Azure SQL, PostgreSQL, Snowflake, BigQuery, Azure Synapse und Databricks. Es funktioniert nicht gut mit Quellen, die das Falten von Abfragen nicht unterstützen (Excel-Dateien, flache CSV-Dateien, einige REST-APIs) – in diesen Fällen ist dennoch eine vollständige Aktualisierung erforderlich. Für nicht faltbare Quellen ist die Bereitstellung von Daten in einer SQL-Datenbank vor der Power BI-Verbindung die empfohlene Problemumgehung.

Welche Power BI-Lizenz ist für die inkrementelle Aktualisierung erforderlich?

Die inkrementelle Aktualisierung ist in den Kapazitäten Power BI Pro (begrenzt auf 10 Aktualisierungsperioden), Power BI Premium pro Kapazität, Power BI Premium pro Benutzer (PPU) und Microsoft Fabric verfügbar. Für die Funktion „Datenänderungen erkennen“ und Hybridtabellen ist Premium oder Fabric erforderlich. Für die meisten Unternehmensimplementierungen mit mehr als 10 historischen Partitionen ist Premium oder Fabric erforderlich.

Wie geht die inkrementelle Aktualisierung mit verspätet eintreffenden Daten um?

Verspätet eintreffende Daten – Datensätze, die nach ihrem Transaktionsdatum eingehen (z. B. eine Dezember-Transaktion, die im Januar-Datenextrakt eintrifft) – werden behandelt, indem das rollierende Aktualisierungsfenster breit genug eingestellt wird, um verspätete Eingänge zu erfassen. Wenn Daten mit einer Verspätung von bis zu 7 Tagen eintreffen können, stellt die Einstellung des rollierenden Fensters auf 14 Tage sicher, dass verspätete Ankünfte erfasst werden, wenn die entsprechende Partition erneut aktualisiert wird. Alternativ erfasst die Option „Datenänderungen erkennen“ mit einer Spalte „Zuletzt geändert“ verspätete Ankünfte unabhängig von der Einstellung des rollierenden Fensters.

Kann die inkrementelle Aktualisierung bei Dimensionstabellen funktionieren, nicht nur bei Fakten?

Die inkrementelle Aktualisierung ist für große Faktentabellen konzipiert und erfordert eine Datum/Uhrzeit-Filterspalte. Die meisten Dimensionstabellen (Produkte, Kunden, Standorte) verfügen nicht über eine geeignete Datum/Uhrzeit-Partitionsspalte und sind klein genug, dass eine vollständige Aktualisierung sinnvoll ist. Bei sich langsam ändernden Dimensionstabellen, die groß geworden sind (Kundentabellen mit mehr als 50 Millionen Zeilen), besteht ein alternativer Ansatz darin, SQL-Ansichten in der Quelldatenbank zu verwenden, um kürzlich geänderte Datensätze zu filtern und die Verlaufsaufbewahrung in der Datenbankebene statt in Power BI zu verwalten.

Wie sehe ich, welche Partitionen in meinem inkrementellen Aktualisierungsmodell vorhanden sind?

Am einfachsten ist es, den Tabular Editor (kostenlose Version 2) über den XMLA-Endpunkt mit Ihrem Power BI Premium-Arbeitsbereich zu verbinden. Unter Tabellen → [Ihre Tabelle] → Partitionen sehen Sie alle erstellten Partitionen mit ihren Datumsbereichen und den Zeitstempeln der letzten Verarbeitung. SQL Server Management Studio (SSMS) stellt ebenfalls eine Verbindung über XMLA her und zeigt Partitionsdetails im Objekt-Explorer an.

Was passiert, wenn die inkrementelle Aktualisierung mittendrin fehlschlägt?

Wenn eine Aktualisierung auf halbem Weg fehlschlägt, versucht Power BI die fehlerhaften Partitionen erneut. Partitionen, die vor dem Fehler erfolgreich abgeschlossen wurden, werden nicht erneut verarbeitet – nur die fehlgeschlagenen Partitionen werden erneut versucht. Dieses Wiederholungsverhalten bedeutet, dass eine inkrementelle Aktualisierung widerstandsfähiger gegenüber vorübergehenden Ausfällen des Quellsystems ist als eine vollständige Aktualisierung. Wenn eine Partition dauerhaft ausfällt, bleibt die Partition in ihrem letzten erfolgreich geladenen Zustand, während neue Partitionen weiterhin normal aktualisiert werden.

---

Nächste Schritte

Die inkrementelle Aktualisierung ist für jede Power BI-Implementierung, die große Transaktionsdatensätze verarbeitet, von grundlegender Bedeutung. Wenn Sie es von Anfang an richtig machen – mit der richtigen Abfragefaltung, geeigneten rollierenden Fenstern und Überwachung –, vermeiden Sie Leistungsprobleme, die später eine kostspielige Neuarchitektur erforderlich machen.

Die Power BI-Leistungsoptimierungsdienste von ECOSIRE umfassen das inkrementelle Aktualisierungsdesign und die Implementierung für große Unternehmensdatensätze. Kontaktieren Sie uns, um Ihre aktuelle Refresh-Architektur zu bewerten und Optimierungsmöglichkeiten zu identifizieren.