Inkrementelle Aktualisierung 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. Durch das Partitionieren der Tabelle und das Aktualisieren nur der neuesten Partition(en) wird die Menge der zu aktualisierenden Daten erheblich reduziert.

Mit inkrementeller Aktualisierung:

  • 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 inkrementelle Aktualisierungs- und Verlaufspartitionen basierend auf den Richtlinieneinstellungen für inkrementelle Aktualisierung und überschreibt dann die Parameterwerte, um Daten für jede Partition basierend auf den Datums-/Zeitwerten für jede Zeile zu filtern und abzufragen.

Bei allen nachfolgenden Aktualisierungen filtert und gibt die Abfrage 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. 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.

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. Für Datasets in Premium-Kapazitäten werden jedoch erweiterte Partitions- und Aktualisierungsszenarien über den XMLA-Endpunkt unterstützt.

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.

Unterstützte Datenquellen

Die inkrementelle Aktualisierung funktioniert am besten für strukturierte, relationale Datenquellen wie SQL-Datenbank und Azure Synapse, kann aber auch für andere Datenquellen funktionieren. 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 Datum-/Uhrzeitwert in den Parametern so konvertiert, dass er mit dem Integer-Ersatzschlüssel der Datenquellentabelle übereinstimmt. 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, d. h. die Fähigkeit von Power Query, einen einzigen Abfrageausdruck zu generieren, um Quelldaten abzurufen und zu transformieren. 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. Die Mashup-Engine der Abfrage gleicht den Filter lokal aus und wendet ihn an. Dazu müssen 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.

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. 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. Die meisten relationalen Datenquellen lassen das Überschreiben des Zeitlimits im Power Query M-Ausdruck zu. 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 inkrementeller Aktualisierungen

Wir gehen hier auf wichtige Konzepte der Konfiguration der inkrementellen Aktualisierung ein. Wenn Sie für ausführlichere Schritt-für-Schritt-Anweisungen bereit sind, lesen Sie Konfigurieren inkrementeller Aktualisierungen für 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 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.

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.

Zum Definieren der Richtlinie gibt es drei erforderliche und zwei optionale Einstellungen:

Dialogfeld „Richtlinie definieren“

1 – Tabelle

Im Listenfeld „Tabelle“ wird standardmäßig die Tabelle verwendet, 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.

2 – Zeilen speichern in den letzten

Diese erforderliche Einstellung bestimmt den Verlaufszeitraum, in dem Zeilen mit einem Datum/einer Uhrzeit in diesem Zeitraum im Dataset enthalten sind, sowie Zeilen für den aktuellen unvollständigen Verlaufszeitraum sowie Zeilen im Aktualisierungszeitraum bis zum aktuellen Datum und zur aktuellen Uhrzeit.

Wenn wir beispielsweise 5 Jahre angeben, 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.

3 – Zeilen aktualisieren in den letzten

Diese erforderliche Einstellung bestimmt den inkrementellen Aktualisierungszeitraum, in dem alle Zeilen mit einem Datum/einer Uhrzeit in diesem Zeitraum in die Aktualisierungspartitionen aufgenommen und bei jedem Aktualisierungsvorgang aktualisiert werden.

Wenn wir z. B. einen Aktualisierungszeitraum von 10 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 zehn 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 10 Tagen bis zur aktuellen Aktualisierungsvorgangszeit werden aktualisiert. Bei dieser Art von Richtlinie können wir davon ausgehen, dass die Datasettabelle „FactInternetSales“ im Dienst, die durchschnittlich 10.000 neue Zeilen pro Tag enthält, bei jedem Aktualisierungsvorgang ungefähr 100.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.

4 – Datenänderungen erkennen

Diese Einstellung ist optional. Eine inkrementelle Aktualisierung der Daten von 10 Tagen ist effizienter als eine vollständige Aktualisierung von fünf Jahren. Die Aktualisierung kann jedoch noch selektiver erfolgen. Mit der Option „Datenänderungen erkennen“ können Sie eine Datum-/Uhrzeit-Spalte auswählen, um nur die Tage zu bestimmen 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. In diesem Beispiel kann dies potenziell die Anzahl der Tage, die inkrementell aktualisiert werden, von 10 auf etwa zwei weiter 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.

5 – Nur vollständige Tage aktualisieren

Diese Einstellung ist optional. Angenommen, Ihre Aktualisierung ist für 4:00 Uhr morgens geplant. Wenn in diesen vier Stunden zwischen Mitternacht und 4:00 Uhr neue Datenzeilen in der Datenquellentabelle erscheinen, möchten Sie diese vielleicht nicht berücksichtigen. 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.

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.

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.

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