Inkrementelle Aktualisierung und Echtzeitdaten für Datasets

Die inkrementelle Aktualisierung erweitert geplante Aktualisierungsvorgänge, indem sie die automatische Erstellung und Verwaltung von Partitionen für Datasettabellen ermöglicht, die häufig neue und aktualisierte Daten laden. Bei den meisten Datasets handelt es sich um eine oder mehrere Tabellen, die Transaktionsdaten enthalten, die sich häufig ändern und exponentiell wachsen können, wie z. B. eine Faktentabelle in einem relationalen oder Sterndatenbankschema. Eine Richtlinie für die inkrementelle Aktualisierung zum Partitionieren der Tabelle, durch die nur die neuesten Importpartitionen aktualisiert werden, und optional die Nutzung einer zusätzlichen DirectQuery-Partition für Echtzeitdaten können die Menge der zu aktualisierenden Daten erheblich reduzieren und gleichzeitig sicherstellen, dass auch die neuesten Änderungen der Datenquelle in die Abfrageergebnisse einbezogen werden.

Inkrementelle Aktualisierung und Echtzeitdaten bieten folgende Vorteile:

  • Weniger Aktualisierungszyklen für sich schnell ändernde Daten: Im DirectQuery-Modus werden bei der Verarbeitung von Abfragen die neuesten Datenupdates abgerufen, ohne dass dafür ein kurzes Aktualisierungsintervall erforderlich ist.
  • Schnellere Aktualisierungen: Nur die letzten Daten, die geändert wurden, müssen aktualisiert werden.
  • Zuverlässigere Aktualisierungen: Langanhaltende Verbindungen mit flüchtigen Datenquellen sind nicht erforderlich. Abfragen an Quelldaten werden schneller ausgeführt, wodurch die Gefahr von Netzwerkproblemen verringert wird.
  • Reduzierter Ressourcenverbrauch: Weniger zu aktualisierende Daten reduzieren den Gesamtverbrauch an Speicher und anderen Ressourcen sowohl in Power BI als auch in den Datenquellsystemen.
  • Ermöglicht große Datasets: Datasets mit potenziell Milliarden von Zeilen können wachsen, ohne dass das gesamte Dataset bei jedem Aktualisierungsvorgang vollständig aktualisiert werden muss.
  • Einfache Einrichtung:Richtlinien für inkrementelle Aktualisierung werden in Power BI Desktop mit nur wenigen Aufgaben definiert. Nach der Veröffentlichung wendet der Dienst diese Richtlinien automatisch bei jeder Aktualisierung an.

Wenn Sie ein Power BI Desktop-Modell im Dienst veröffentlichen, verfügt jede Tabelle im neuen Dataset über eine einzelne Partition. Diese einzelne Partition enthält alle Zeilen für diese Tabelle. Wenn die Tabelle groß ist, z. B. mit Millionen von Zeilen oder sogar mehr, kann eine Aktualisierung für diese Tabelle sehr lange dauern und eine übermäßige Menge an Ressourcen verbrauchen.

Bei der inkrementellen Aktualisierung teilt der Dienst Daten, die häufig aktualisiert werden müssen, dynamisch auf und trennt sie von Daten, die weniger häufig aktualisiert werden können. Tabellendaten werden unter Verwendung von Datums- und Uhrzeitparametern von Power Query, mit den reservierten Namen RangeStart und RangeEnd mit Berücksichtigung von Groß- und Kleinschreibung, gefiltert. Bei der Erstkonfiguration der inkrementellen Aktualisierung in Power BI Desktop werden die Parameter verwendet, um nur einen kleinen Zeitraum von Daten zu filtern, die in das Modell geladen werden sollen. Bei der Veröffentlichung im Dienst erstellt der Dienst mit dem ersten Aktualisierungsvorgang basierend auf den Einstellungen der Richtlinie für die inkrementelle Aktualisierung inkrementelle Aktualisierungs- und Verlaufspartitionen sowie optional eine DirectQuery-Echtzeitpartition und überschreibt dann die Parameterwerte, um Daten für die einzelnen Partitionen basierend auf den Datums-/Uhrzeitwerten für jede Zeile zu filtern und abzufragen.

Bei allen weiteren Aktualisierungen geben die Abfragefilter nur die Zeilen innerhalb des Aktualisierungszeitraums zurück, der dynamisch durch die Parameter definiert wird. Diese Zeilen mit einem Datum/einer Uhrzeit innerhalb des Aktualisierungszeitraums werden aktualisiert. Zeilen mit einem Datum/einer Uhrzeit, die nicht mehr innerhalb des Aktualisierungszeitraums liegen, werden dann Teil des Verlaufszeitraums, der nicht aktualisiert wird. Wenn in der Richtlinie für die inkrementelle Aktualisierung eine DirectQuery-Echtzeitpartition enthalten ist, wird der zugehörige Filter ebenfalls aktualisiert, sodass alle Änderungen berücksichtigt werden, die nach dem Aktualisierungszeitraum aufgetreten sind. Sowohl für die Aktualisierungszeiträume als auch für die Verlaufszeiträume wird ein Rollforward ausgeführt. Bei der Erstellung neuer Partitionen für die inkrementelle Aktualisierung werden Aktualisierungspartitionen, die sich nicht mehr im Aktualisierungszeitraum befinden, zu Verlaufspartitionen. Im Laufe der Zeit werden Verlaufspartitionen weniger präzise, da sie zusammengeführt werden. Wenn sich eine Verlaufspartition nicht mehr im durch die Richtlinie definierten Verlaufszeitraum befindet, wird sie vollständig aus dem Dataset entfernt. Dies wird als Muster des rollierenden Zeitfensters bezeichnet.

Grafik: Muster des rollierenden Zeitfensters

Der Vorteil der inkrementellen Aktualisierung ist, dass der Dienst all dies basierend auf den von Ihnen festgelegten Richtlinien für inkrementelle Aktualisierungen für Sie übernimmt. Tatsächlich sind der Prozess und die daraus erstellten Partitionen im Dienst nicht einmal sichtbar. In den meisten Fällen ist nur eine klar definierte Richtlinie für die inkrementelle Aktualisierung erforderlich, um die Leistung der Datasetaktualisierung erheblich zu verbessern. Die DirectQuery-Echtzeitpartition wird jedoch nur für Datasets in Premium-Kapazitäten unterstützt. Power BI Premium ermöglicht außerdem erweiterte Partitions- und Aktualisierungsszenarien über den XMLA-Endpunkt.

Anforderungen

Unterstützte Pläne

Die inkrementelle Aktualisierung wird für Power BI Premium, Premium-Einzelbenutzerlizenz, Power BI Pro und Power BI Embedded unterstützt.

Das Abrufen der neuesten Daten in Echtzeit mit DirectQuery wird nur für Datasets von Power BI Premium, Premium-Einzelbenutzerlizenzen und Power BI Embedded unterstützt.

Unterstützte Datenquellen

Die inkrementelle Aktualisierung und Echtzeitdaten eignen sich am besten für strukturierte, relationale Datenquellen wie SQL-Datenbank und Azure Synapse, sie können aber auch für andere Datenquellen verwendet werden. In jedem Fall muss Ihre Datenquelle Folgendes unterstützen:

Datumsspalte: Die Tabelle muss eine Datumsspalte vom Datentyp „Datum/Uhrzeit“ oder „Integer“ enthalten. Die Parameter RangeStart und RangeEnd (die vom Datentyp „Datum/Zeit“ sein müssen) filtern die Tabellendaten basierend auf der Datumsspalte. Für Datumsspalten mit Integer-Ersatzschlüsseln im Format yyyymmdd können Sie eine Funktion erstellen, die den Datums-/Uhrzeitwert in den Parametern „RangeStart“ und „RangeEnd“ so konvertiert, dass er dem Integer-Ersatzschlüssel der Datumsspalte entspricht. Weitere Informationen finden Sie unter Konfigurieren inkrementeller Aktualisierungen – Konvertieren von DateTime in Integer.

Query Folding: Die inkrementelle Aktualisierung ist für Datenquellen gedacht, die Query Folding unterstützen. Hierbei handelt es sich um die Fähigkeit von Power Query, einen einzigen Abfrageausdruck zu generieren, um Quelldaten abzurufen und zu transformieren – insbesondere beim Abrufen der neuesten Daten in Echtzeit mit DirectQuery. Die meisten Datenquellen, die SQL-Abfragen unterstützen, unterstützen auch die Abfragefaltung. Bei Datenquellen wie Flatfiles, Blobs und einigen Webfeeds ist dies oft nicht der Fall.

Wenn die inkrementelle Aktualisierung konfiguriert ist, wird ein Power Query Ausdruck, der einen Datums-/Uhrzeitfilter basierend auf den Parametern „RangeStart“ und „RangeEnd“ enthält, für die Datenquelle ausgeführt. Der Filter ist in Wirklichkeit eine Transformation, die in der Abfrage enthalten ist und eine WHERE-Klausel auf der Basis der Parameter definiert. Wenn Filter nicht von der Datenquelle unterstützt wird, kann er nicht in den Abfrageausdruck aufgenommen werden. Wenn die Richtlinie für die inkrementelle Aktualisierung das Abrufen von Echtzeitdaten mit DirectQuery beinhaltet, können keine Transformationen ohne Folding verwendet werden. Wenn es sich um eine reine Importmodusrichtlinie ohne Echtzeitdaten handelt, kann die Query-Mashup-Engine dies ggf. ausgleichen und den Filter lokal anwenden. Hierzu müssen allerdings alle Zeilen für die Tabelle aus der Datenquelle abgerufen werden. Dies kann dazu führen, dass die inkrementelle Aktualisierung langsam ist und dem Prozess entweder im Power BI-Dienst oder in einem lokalen Datengateway die Ressourcen ausgehen – wodurch der Zweck der inkrementellen Aktualisierung effektiv nicht erfüllt wird.

Da die Unterstützung für Query Folding für verschiedene Arten von Datenquellen unterschiedlich ist, sollte eine Überprüfung durchgeführt werden, um sicherzustellen, dass die Filterlogik in den Abfragen enthalten ist, die für die Datenquelle ausgeführt werden. In den meisten Fällen versucht Power BI Desktop, diese Überprüfung für Sie durchzuführen, wenn Sie die Richtlinie für inkrementelle Aktualisierung definieren. Für SQL-basierte Datenquellen wie SQL Database, Azure Synapse, Oracle und Teradata ist diese Überprüfung zuverlässig. Andere Datenquellen können jedoch möglicherweise nicht verifiziert werden, ohne die Abfragen nachzuverfolgen. Wenn Power BI Desktop nicht bestätigen kann, wird im Dialogfeld der Richtlinienkonfiguration für inkrementelle Aktualisierung eine Warnung angezeigt.

Query Folding-Warnung

Wenn diese Warnung angezeigt wird und Sie überprüfen möchten, ob das erforderliche Query Folding erfolgt, verwenden Sie die Power Query-Diagnosefunktion oder Ablaufverfolgungsabfragen, indem Sie ein von der Datenquelle unterstütztes Tool wie SQL Profiler verwenden. Wenn kein Query Folding stattfindet, überprüfen Sie, ob die Filterlogik in der Abfrage enthalten ist, die an die Datenquelle übergeben wird. Wenn dies nicht der Fehler ist, enthält die Abfrage wahrscheinlich eine Transformation, die ein Folding verhindert.

Bevor Sie Ihre Lösung für die inkrementelle Aktualisierung konfigurieren, sollten Sie die Query Folding-Anleitungen für Power BI Desktop und Query Folding in Power Query gründlich lesen und verstehen. Diese Artikel können Ihnen helfen festzustellen, ob Ihre Datenquelle und Abfragen das Query Folding unterstützen.

Einzelne Datenquelle

Bei der Konfiguration von inkrementellen Aktualisierungen und Echtzeitdaten mit Power BI Desktop oder beim Konfigurieren einer erweiterten Lösung mit Tabular Model Scripting Language (TMSL) oder Tabular Object Model (TOM) über den XMLA-Endpunkt müssen alle Partitionen – ob Import oder DirectQuery – Daten aus einer einzigen Quelle abfragen.

Andere Datenquellentypen

Durch die Verwendung zusätzlicher benutzerdefinierter Abfragefunktionen und Abfragelogik kann die inkrementelle Aktualisierung mit anderen Arten von Datenquellen verwendet werden, sofern Filter auf Basis von RangeStart und RangeEnd in einer einzigen Abfrage übergeben werden können. Beispiel: Excel-Arbeitsmappendateien, die in einem Ordner gespeichert sind, Dateien in SharePoint oder RSS-Feeds. Denken Sie daran, dass dies erweiterte Szenarien sind, die zusätzliche Anpassungen und Tests über das hier Beschriebene hinaus erfordern. Lesen Sie unbedingt den Abschnitt Community weiter unten in diesem Artikel, um Vorschläge dazu zu erhalten, wie Sie weitere Informationen zur Verwendung der inkrementellen Aktualisierung für einzigartige Szenarien wie diese finden.

Zeitlimits

Unabhängig von der inkrementellen Aktualisierung gilt für Power BI Pro-Datasets ein Aktualisierungszeitlimit von zwei Stunden, und das Abrufen von Echtzeitdaten mit DirectQuery wird von ihnen nicht unterstützt. Für Datasets in einer Premium-Kapazität beträgt das Zeitlimit fünf Stunden. Aktualisierungsvorgänge sind prozess- und arbeitsspeicherintensiv. Ein vollständiger Aktualisierungsvorgang kann bis zu doppelt so viel Speicher wie das Dataset selbst benötigen, da der Dienst einen Schnappschuss des Datasets im Speicher behält, bis der Aktualisierungsvorgang abgeschlossen ist. Aktualisierungsvorgänge können auch prozessintensiv sein und einen erheblichen Teil der verfügbaren CPU-Ressourcen verbrauchen. Aktualisierungsvorgänge müssen sich auch auf flüchtige Verbindungen zu Datenquellen und die Fähigkeit dieser Datenquellensysteme verlassen, Abfrageausgaben schnell zurückzugeben. Das Zeitlimit ist eine Schutzmaßnahme, um die Überbeanspruchung Ihrer verfügbaren Ressourcen zu begrenzen.

Hinweis

Bei Premium-Kapazitäten gilt für Aktualisierungsvorgänge, die über den XMLA-Endpunkt ausgeführt werden, kein Zeitlimit. Weitere Informationen finden Sie unter Erweiterte inkrementelle Aktualisierung mit dem XMLA-Endpunkt.

Da die inkrementelle Aktualisierung die Aktualisierungsvorgänge auf Partitionsebene im Dataset optimiert, kann der Ressourcenverbrauch erheblich reduziert werden. Gleichzeitig sind Aktualisierungsvorgänge auch bei der inkrementellen Aktualisierung, sofern sie nicht über den XMLA-Endpunkt erfolgen, an dieselben Zeitlimits von zwei und fünf Stunden gebunden. Eine effektive Richtlinie für inkrementelle Aktualisierung reduziert nicht nur die Datenmenge, die bei einem Aktualisierungsvorgang verarbeitet wird, sondern verringert auch die Menge unnötiger Verlaufsdaten, die in Ihrem Dataset gespeichert sind.

Abfragen können auch durch ein standardmäßiges Zeitlimit für die Datenquelle eingeschränkt werden. Bei den meisten relationalen Datenquellen können Zeitlimits im Power Query M-Ausdruck überschrieben werden. Beispielsweise wird im folgenden Ausdruck die SQL Server-Datenzugriffsfunktion verwendet, um „CommandTimeout“ auf zwei Stunden festzulegen. Jeder durch die Richtlinienbereiche definierte Zeitraum sendet eine Abfrage unter Einhaltung der Einstellung für die Befehlszeitüberschreitung.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

Für sehr große Datasets in Premium-Kapazitäten, die wahrscheinlich Milliarden von Zeilen enthalten, kann der anfängliche Aktualisierungsvorgang per Bootstrapping durchgeführt werden. Durch Bootstrapping kann der Dienst Tabellen- und Partitionsobjekte für das Dataset erstellen, aber keine Daten in eine der Partitionen laden und verarbeiten. Mithilfe von SQL Server Management Studio können Partitionen dann einzeln, sequenziell oder parallel verarbeitet werden, wodurch sowohl die in einer einzigen Abfrage zurückgegebene Datenmenge reduziert als auch das Zeitlimit von fünf Stunden umgangen werden kann. Weitere Informationen finden Sie unter Erweiterte inkrementelle Aktualisierung – Verhindern von Timeouts bei der ersten vollständigen Aktualisierung.

Aktuelles Datum und aktuelle Uhrzeit

Das aktuelle Datum und die Uhrzeit basieren auf dem Systemdatum zum Zeitpunkt der Aktualisierung. Wenn die geplante Aktualisierung für das Dataset im Dienst aktiviert ist, wird die angegebene Zeitzone bei der Ermittlung des aktuellen Datums und der Uhrzeit berücksichtigt. Sowohl individuelle als auch geplante Aktualisierungen durch den Dienst beachten die Zeitzone, falls diese verfügbar ist. Wenn beispielsweise um 20 Uhr in der Zeitzone Pacific Standard Time (USA und Kanada) eine Aktualisierung durchgeführt wird und die Zeitzone angegeben ist, werden das aktuelle Datum und die Uhrzeit anhand der Pacific Standard Time-Zone anstatt GMT (in diesem Fall der nächste Tag) ermittelt. Aktualisierungsvorgänge, die nicht über den Dienst aufgerufen werden, wie z. B. der TMSL-Aktualisierungsbefehl, berücksichtigen die Zeitzone für die geplante Aktualisierung nicht.

Zeitzone

Konfigurieren von inkrementeller Aktualisierung und Echtzeitdaten

Hier finden Sie Informationen zu wichtigen Konzepten der Konfiguration für die inkrementelle Aktualisierung und für Echtzeitdaten. Eine ausführlichere Schritt-für-Schritt-Anleitung finden Sie unter Konfigurieren der inkrementellen Aktualisierung sowie von Echtzeitdaten für Power BI-Datasets.

Das Konfigurieren der inkrementellen Aktualisierung erfolgt in Power BI Desktop. Für die meisten Modelle sind nur wenige Aufgaben erforderlich. Beachten Sie jedoch Folgendes:

  • Wenn Sie es im Dienst veröffentlicht haben, können Sie dasselbe Modell nicht erneut über Power BI Desktop veröffentlichen. Bei einer erneuten Veröffentlichung würden alle vorhandenen Partitionen und Daten entfernt, die sich bereits im Dataset befinden. Wenn Sie in einer Premium-Kapazität veröffentlichen, können nachträgliche Änderungen am Metadatenschema mit Tools wie dem Open-Source-ALM-Toolkit oder mit der Tabular Model Scripting Language (TMSL) vorgenommen werden. Weitere Informationen finden Sie unter Erweiterte inkrementelle Aktualisierung – Reine Metadatenbereitstellung.
  • Wenn Sie das Dataset im Dienst veröffentlicht haben, können Sie ihn nicht als PBIX wieder in Power BI Desktop zurückladen. Da Datasets im Dienst so groß werden können, ist es unpraktisch, sie zurückzuladen und auf einem typischen Desktopcomputer zu öffnen.
  • Wenn Sie Echtzeitdaten mit DirectQuery abrufen, kann das Dataset nicht in einem Premium-fremden Arbeitsbereich veröffentlicht werden. Die inkrementelle Aktualisierung mit Echtzeitdaten wird nur mit Power BI Premium unterstützt.

Erstellen von Parametern

Bei der Konfiguration der inkrementellen Aktualisierung in Power BI Desktop erstellen Sie zunächst zwei Datums- und Uhr in Power Query mit den reservierten Namen RangeStart und RangeEnd, bei denen die Groß-/Kleinschreibung beachtet wird. Diese Parameter, die im Power Query-Editor im Dialogfeld „Parameter verwalten“ definiert sind, werden zunächst verwendet, um die in die Power BI Desktop-Modelltabelle geladenen Daten so zu filtern, dass nur die Zeilen mit einem Datum/einer Uhrzeit innerhalb dieses Zeitraums enthalten sind. Nachdem das Modell im Dienst veröffentlicht wurde, werden „RangeStart“ und „RangeEnd“ automatisch vom Dienst überschrieben, um Daten abzufragen, die durch den Aktualisierungszeitraum definiert sind, der in den Richtlinieneinstellungen für inkrementelle Aktualisierungen angegeben ist.

Unsere Datenquellentabelle „FactInternetSales“ hat zum Beispiel durchschnittlich 10.000 neue Zeilen pro Tag. Um die Anzahl der anfänglich in das Modell geladenen Zeilen in Power BI Desktop zu begrenzen, legen wir einen Zeitraum von zwei Tagen zwischen „RangeStart“ und „RangeEnd“ fest.

Dialogfeld „Parameter verwalten“

Filtern von Daten

Wenn die Parameter „RangeStart“ und „RangeEnd“ definiert sind, wenden Sie benutzerdefinierte Datumsfilter auf die Datumsspalte Ihrer Tabelle an. Die angewendeten Filter wählen eine Teilmenge der Daten aus, die in das Modell geladen werden, wenn Sie auf Anwenden klicken.

Benutzerdefinierter Filter

Anhand unseres FactInternetSales-Beispiels werden nach dem Erstellen von Filtern basierend auf den Parametern und dem Anwenden von Schritten zwei Tage an Daten, also etwa 20.000 Zeilen, in unser Modell geladen.

Definieren einer Richtlinie

Nachdem Filter angewendet wurden und eine Teilmenge der Daten in das Modell geladen wurde, definieren Sie eine Richtlinie für die inkrementelle Aktualisierung für die Tabelle. Nachdem das Modell im Dienst veröffentlicht wurde, wird die Richtlinie vom Dienst verwendet, um Tabellenpartitionen zu erstellen und zu verwalten und Aktualisierungsvorgänge auszuführen. Verwenden Sie zum Definieren der Richtlinie das Dialogfeld Inkrementelle Aktualisierung und Echtzeitdaten, um sowohl erforderliche als auch optionale Einstellungen anzugeben.

Dialogfeld „Richtlinie definieren“

Tabelle

Das Listenfeld Tabelle auswählen enthält standardmäßig die Tabelle, die Sie in der Datenansicht ausgewählt haben. Aktivieren Sie die inkrementelle Aktualisierung für die Tabelle mit dem Schieberegler. Wenn der Power Query-Ausdruck für die Tabelle keinen Filter enthält, der auf den Parametern „RangeStart“ und „RangeEnd“ basiert, ist die Umschaltfläche deaktiviert.

Erforderliche Einstellungen

Die Einstellung Archivdaten, beginnend X vor dem Aktualisierungsdatum bestimmt den Verlaufszeitraum, in dem Zeilen mit einem Datum/einer Uhrzeit in diesem Zeitabschnitt in das Dataset aufgenommen werden, plus Zeilen für den aktuellen unvollständigen Verlaufszeitraum sowie Zeilen im Aktualisierungszeitraum bis zum aktuellen Datum und zur aktuellen Uhrzeit.

Wenn wir beispielsweise 5 Jahreangeben, speichert unsere Tabelle die Verlaufsdaten der letzten fünf Jahre in Jahrespartitionen sowie Zeilen für das aktuelle Jahr in Quartals-, Monats- oder Tagespartitionen bis einschließlich des Aktualisierungszeitraums.

Für Datasets in Premium-Kapazitäten können Verlaufspartitionen rückwirkend selektiv mit einer von dieser Einstellung festgelegten Granularität aktualisiert werden. Weitere Informationen finden Sie unter Erweiterte inkrementelle Aktualisierung – Partitionen.

Die Einstellung Daten der inkrementellen Aktualisierung, beginnend X vor dem Aktualisierungsdatum bestimmt den inkrementellen Aktualisierungszeitraum, in dem alle Zeilen mit einem Datum/einer Uhrzeit in diesem Zeitabschnitt in die Aktualisierungspartition(en) aufgenommen und bei jedem Aktualisierungsvorgang aktualisiert werden.

Wenn wir z. B. einen Aktualisierungszeitraum von 3 Tagen angeben, überschreibt der Dienst bei jedem Aktualisierungsvorgang die Parameter „RangeStart“ und „RangeEnd“, um eine Abfrage für Zeilen mit einem Datum/einer Uhrzeit innerhalb eines Zeitraums von drei Tagen zu erstellen, wobei Beginn und Ende vom aktuellen Datum und der aktuellen Uhrzeit abhängen. Zeilen mit einem Datum/einer Uhrzeit in den letzten 3 Tagen bis zum aktuellen Aktualisierungszeitpunkt werden aktualisiert. Bei dieser Art von Richtlinie kann davon ausgegangen werden, dass die Datasettabelle „FactInternetSales“ im Dienst, die durchschnittlich 10.000 neue Zeilen pro Tag aufweist, bei jedem Aktualisierungsvorgang ungefähr 30.000 Zeilen aktualisiert.

Geben Sie unbedingt einen Zeitraum an, der nur die Mindestanzahl von Zeilen enthält, die erforderlich sind, um eine genaue Berichterstellung sicherzustellen. Wenn Sie Richtlinien für mehr als eine Tabelle definieren, müssen die gleichen RangeStart- und RangeEnd-Parameter verwendet werden, auch wenn für jede Tabelle unterschiedliche Speicher- und Aktualisierungszeiträume definiert sind.

Optionale Einstellungen

Die Einstellung Abrufen der neuesten Daten in Echtzeit mit DirectQuery (nur Premium) ermöglicht das Abrufen der neuesten Änderungen aus der aktuellen Tabelle in der Datenquelle über den Zeitraum der inkrementellen Aktualisierung hinaus mithilfe von DirectQuery. Alle Zeilen, deren Datum/Uhrzeit nach dem inkrementellen Aktualisierungszeitraum liegt, werden in eine DirectQuery-Partition aufgenommen und mit jeder Datasetabfrage aus der Datenquelle abgerufen.

Wenn diese Einstellung aktiviert ist, überschreibt der Dienst beispielsweise bei jedem Aktualisierungsvorgang die Parameter „RangeStart“ und „RangeEnd“, um eine Abfrage für Zeilen mit einem Datum/Uhrzeit nach dem Aktualisierungszeitraum zu erstellen, wobei der Beginn vom aktuellen Datum und der aktuellen Uhrzeit abhängt. Zeilen mit einem Datum/Uhrzeit nach dem aktuellen Aktualisierungszeitpunkt werden berücksichtigt. Bei dieser Art von Richtlinie können wir davon ausgehen, dass die Datasettabelle „FactInternetSales“ im Dienst auch die neuesten Datenaktualisierungen enthält.

Die Option Nur vollständige Tage aktualisieren stellt sicher, dass alle Zeilen für den gesamten Tag in den Aktualisierungsvorgang einbezogen werden. Diese Einstellung ist optional sofern Sie nicht die Einstellung „Abrufen der neuesten Daten in Echtzeit mit DirectQuery (nur Premium)“ aktualisieren. Angenommen, Ihre Aktualisierung ist für 4:00 Uhr morgens geplant. Wenn in den vier Stunden zwischen Mitternacht und 4:00 Uhr neue Datenzeilen in der Datenquellentabelle erscheinen, sollen diese nicht berücksichtigt werden. Bei einigen Geschäftsmetriken, z. B. Barrel pro Tag in der Öl- und Gasindustrie, ist eine Verwendung von Teiltagen nicht sinnvoll. Ein weiteres Beispiel ist das Aktualisieren von Daten in einem Finanzsystem, bei dem die Daten des Vormonats am 12. Kalendertag des Monats freigegeben werden. Legen Sie in diesem Fall den Aktualisierungszeitraum auf 1 Monat fest, und planen Sie die Aktualisierung für den 12. Tag des Monats. Wenn diese Option aktiviert ist, werden z. B. die Daten vom Januar am 12. Februar aktualisiert.

Beachten Sie, dass Aktualisierungsvorgänge im Dienst unter UTC-Zeit ausgeführt werden, sofern keine geplante Aktualisierung für eine Nicht-UTC-Zeitzone konfiguriert ist. Dies kann das effektive Datum bestimmen und sich auf abgeschlossene Zeiträume auswirken.

Die Einstellung Datenänderungen erkennen ermöglicht eine noch gezieltere Aktualisierung. Sie können eine Datums-/Uhrzeitspalte auswählen, um nur die Tage zu ermitteln und zu aktualisieren, an denen sich die Daten geändert haben. Dies setzt voraus, dass eine solche Spalte in der Datenquelle vorhanden ist, die typischerweise zu Prüfzwecken dient. Hierbei darf es sich nicht um dieselbe Spalte handeln, die zum Partitionieren der Daten mit den RangeStart- und RangeEnd-Parametern verwendet wird. Der Maximalwert dieser Spalte wird für jeden der Zeiträume im Inkrementbereich ausgewertet. Wenn sie sich seit der letzten Aktualisierung nicht geändert hat, muss der Zeitraum nicht aktualisiert werden. Im vorliegenden Beispiel könnte dies die Anzahl der Tage mit einer inkrementellen Aktualisierung von 3 auf 1 verringern.

Das aktuelle Design erfordert, dass die Spalte zur Erkennung von Datenänderungen beibehalten und im Arbeitsspeicher zwischengespeichert wird. Zum Reduzieren der Kardinalität und des Arbeitsspeicherverbrauchs können die folgenden Techniken verwendet werden:

  • Behalten Sie nur den Maximalwert der Spalte zum Zeitpunkt der Aktualisierung bei, z. B. mithilfe einer Power Query-Funktion.
  • Reduzieren Sie die Genauigkeit auf ein angesichts Ihrer Anforderungen an die Aktualisierungsfrequenz vertretbares Niveau.
  • Definieren Sie mithilfe des XMLA-Endpunkts eine benutzerdefinierte Abfrage zum Erkennen von Datenänderungen. So vermeiden Sie die vollständige Beibehaltung des Spaltenwerts.

In einigen Fällen kann die Aktivierung der Option „Datenänderungen erkennen“ weiter verbessert werden. So können Sie z. B. das Beibehalten der Spalte „Letzte Aktualisierung“ im In-Memory-Cache vermeiden oder Szenarien ermöglichen, in denen eine Konfigurations-/Anweisungstabelle durch ETL-Prozesse vorbereitet wird, um nur die Partitionen zu markieren, die aktualisiert werden müssen. In Fällen wie diesen können Sie bei Premium-Kapazitäten die Tabular Model Scripting Language (TMSL) und/oder das Tabular Object Model (TOM) verwenden, um das Verhalten von „Datenänderungen erkennen“ zu überschreiben. Weitere Informationen finden Sie unter Erweiterte inkrementelle Aktualisierung – Benutzerdefinierte Abfragen zum Erkennen von Datenänderungen.

Veröffentlichen

Nachdem Sie die Richtlinie für die inkrementelle Aktualisierung konfiguriert haben, veröffentlichen Sie das Modell im Dienst. Sobald die Veröffentlichung abgeschlossen ist, können Sie den ersten Aktualisierungsvorgang für das Dataset ausführen.

Hinweis

Datasets die über eine Richtlinie für die inkrementelle Aktualisierung verfügen, um mit DirectQuery die neuesten Daten in Echtzeit abzurufen, können nur in einem Premium-Arbeitsbereich veröffentlicht werden.

Wenn Sie bei Datasets, die in Arbeitsbereichen mit Premium-Kapazitäten veröffentlicht werden, davon ausgehen, dass das Dataset auf 1 GB oder mehr anwächst, können Sie die Leistung des Aktualisierungsvorgangs verbessern und sicherstellen, dass das Dataset die Größenbeschränkungen nicht überschreitet, indem Sie das Speicherformat für große Datasets aktivieren, bevor Sie den ersten Aktualisierungsvorgang im Dienst durchführen. Weitere Informationen finden Sie unter Große Datasets in Power BI Premium.

Wichtig

Nach der Veröffentlichung im Dienst können Sie die PBIX-Datei nicht mehr zurückladen.

Aktualisieren

Nach der Veröffentlichung im Dienst führen Sie einen ersten Aktualisierungsvorgang für das Dataset aus. Dies sollte eine individuelle (manuelle) Aktualisierung sein, damit Sie den Fortschritt überwachen können. Der erste Aktualisierungsvorgang kann einige Zeit in Anspruch nehmen. Partitionen müssen erstellt, Verlaufsdaten geladen, Objekte wie Beziehungen und Hierarchien erstellt oder neu erstellt und berechnete Objekte neu berechnet werden.

Nachfolgende Aktualisierungsvorgänge, entweder einzeln oder geplant, sind viel schneller, da nur die Partitionen der inkrementellen Aktualisierung aktualisiert werden. Andere Verarbeitungsvorgänge, wie das Zusammenführen von Partitionen und die Neuberechnung, müssen zwar immer noch durchgeführt werden, benötigen aber in der Regel nur einen Bruchteil der Zeit im Vergleich zur ersten Aktualisierung.

Automatische Berichtsaktualisierung

Für Berichte, die ein Dataset mit einer Richtlinie für die inkrementelle Aktualisierung verwenden, um die neuesten Daten in Echtzeit mit DirectQuery abzurufen, empfiehlt es sich, die automatische Seitenaktualisierung in einem festen Intervall oder auf Grundlage der Änderungserkennung zu aktivieren, damit in den Berichten die neuesten Daten ohne Verzögerung berücksichtigt werden. Weitere Informationen dazu finden Sie unter Automatische Seitenaktualisierung in Power BI.

Erweiterte inkrementelle Aktualisierung

Wenn sich Ihr Dataset in einer Premium-Kapazität mit aktiviertem XMLA-Endpunkt befindet, kann die inkrementelle Aktualisierung für erweiterte Szenarien nochmals erweitert werden. Beispielsweise können Sie SQL Server Management Studio verwenden, um Partitionen anzuzeigen und zu verwalten, den anfänglichen Aktualisierungsvorgang per Bootstrap zu starten oder Verlaufspartitionen rückwirkend zu aktualisieren. Weitere Informationen finden Sie unter Erweiterte inkrementelle Aktualisierung mit dem XMLA-Endpunkt.

Community

Power BI verfügt über eine dynamische Community, in der MVPs, BI-Experten und Peers Fachwissen in Diskussionsgruppen, Videos, Blogs und mehr teilen. Wenn Sie mehr über inkrementelle Aktualisierungen erfahren möchten, sollten Sie sich diese zusätzlichen Ressourcen ansehen:

Nächste Schritte

Konfigurieren der inkrementellen Aktualisierung für Datasets
Erweiterte inkrementelle Aktualisierung mit dem XMLA-Endpunkt
Problembehandlung für die inkrementelle Aktualisierung
Inkrementelle Aktualisierung für Dataflows