Aggiornamento incrementale e dati in tempo reale per i modelli semantici

Articolo
11/10/2023

L'aggiornamento incrementale estende le operazioni di aggiornamento pianificate fornendo la creazione e la gestione automatizzate delle partizioni per le tabelle del modello semantico che caricano spesso dati nuovi e aggiornati. Per la maggior parte dei modelli, una o più tabelle contengono dati delle transazioni che cambiano spesso e possono crescere in modo esponenziale, ad esempio una tabella dei fatti in uno schema di database relazionale o star. Un criterio di aggiornamento incrementale per partizionare la tabella, aggiornare solo le partizioni di importazione più recenti e, facoltativamente, l'uso di un'altra partizione DirectQuery per i dati in tempo reale può ridurre significativamente la quantità di dati da aggiornare. Allo stesso tempo, questo criterio garantisce che le modifiche più recenti nell'origine dati siano incluse nei risultati della query.

Con l'aggiornamento incrementale e i dati in tempo reale:

Sono necessari meno cicli di aggiornamento per i dati a modifica rapida. La modalità DirectQuery ottiene gli aggiornamenti dei dati più recenti durante l'elaborazione delle query, senza richiedere una frequenza di aggiornamento elevata.
Gli aggiornamenti sono più veloci. È necessario aggiornare solo i dati più recenti modificati.
Gli aggiornamenti sono più affidabili. Le connessioni a esecuzione prolungata a origini dati volatili non sono necessarie. Le query per l'origine dei dati vengono eseguite più velocemente, riducendo il rischio che i problemi di rete interferiscano.
Il consumo delle risorse è ridotto. Meno dati da aggiornare riduce il consumo complessivo di memoria e altre risorse sia in Power BI che nei sistemi di origine dati.
I modelli semantici di grandi dimensioni sono abilitati. I modelli semantici con potenziali miliardi di righe possono aumentare senza la necessità di aggiornare completamente l'intero modello con ogni operazione di aggiornamento.
La configurazione è semplice. I criteri di aggiornamento incrementale sono definiti in Power BI Desktop con poche attività. Quando Power BI Desktop pubblica il report, il servizio applica automaticamente tali criteri a ogni aggiornamento.

Quando si pubblica un modello di Power BI Desktop nel servizio, ogni tabella nel nuovo modello ha una singola partizione. La singola partizione contiene tutte le righe per la tabella. Se la tabella è grande, ad esempio con decine di milioni di righe o più, un aggiornamento per tale tabella può richiedere molto tempo e utilizzare una quantità eccessiva di risorse.

Con l'aggiornamento incrementale, il servizio partiziona dinamicamente e separa i dati che devono essere aggiornati frequentemente dai dati che possono essere aggiornati meno frequentemente. I dati della tabella vengono filtrati usando i parametri di data/ora di Power Query con i nomi RangeStart riservati, con distinzione tra maiuscole e minuscole e RangeEnd. Quando si configura l'aggiornamento incrementale in Power BI Desktop, questi parametri vengono usati per filtrare solo un piccolo periodo di dati caricati nel modello. Quando Power BI Desktop pubblica il report nel servizio Power BI, con la prima operazione di aggiornamento il servizio crea partizioni cronologiche e aggiornamenti incrementali e facoltativamente una partizione DirectQuery in tempo reale in base alle impostazioni dei criteri di aggiornamento incrementale. Il servizio esegue quindi l'override dei valori dei parametri per filtrare ed eseguire query sui dati per ogni partizione in base ai valori di data/ora per ogni riga.

Con ogni aggiornamento successivo, i filtri di query restituiscono solo tali righe all'interno del periodo di aggiornamento in modo dinamico definito dai parametri. Tali righe con data/ora entro il periodo di aggiornamento vengono aggiornate. Le righe con data/ora non più entro il periodo di aggiornamento diventano quindi parte del periodo cronologico, che non viene aggiornato. Se una partizione DirectQuery in tempo reale viene inclusa nei criteri di aggiornamento incrementale, il filtro viene aggiornato in modo che rilevi le modifiche apportate dopo il periodo di aggiornamento. Entrambi i periodi di aggiornamento e cronologici vengono distribuiti in avanti. Man mano che vengono create nuove partizioni di aggiornamento incrementale, le partizioni di aggiornamento non più nel periodo di aggiornamento diventano partizioni cronologiche. Nel corso del tempo, le partizioni cronologiche diventano meno granulari man mano che vengono unite insieme. Quando una partizione cronologica non è più nel periodo cronologico definito dai criteri, viene rimossa completamente dal modello. Questo comportamento è noto come modello di finestra mobile.

Graphic representing a rolling window pattern.

La bellezza dell'aggiornamento incrementale è che il servizio gestisce tutto in base ai criteri di aggiornamento incrementale definiti. Infatti, il processo e le partizioni create da esso non sono visibili nel servizio. Nella maggior parte dei casi, un criterio di aggiornamento incrementale ben definito è tutto ciò che è necessario per migliorare significativamente le prestazioni di aggiornamento del modello. Tuttavia, la partizione DirectQuery in tempo reale è supportata solo per i modelli nelle capacità Premium. Power BI Premium consente anche scenari di partizione e aggiornamento più avanzati tramite l'endpoint XML for Analysis (XMLA).

Requisiti

Le sezioni successive descrivono i piani e le origini dati supportati.

Piani supportati

L'aggiornamento incrementale è supportato per i modelli Power BI Premium, Premium per utente, Power BI Pro e Power BI Embedded.

Il recupero dei dati più recenti in tempo reale con DirectQuery è supportato solo per i modelli Power BI Premium, Premium per utente e Power BI Embedded.

Origini dati supportate

L'aggiornamento incrementale e i dati in tempo reale funzionano meglio per origini dati relazionali strutturate, ad esempio database SQL e Azure Synapse, ma possono funzionare anche per altre origini dati. In ogni caso, l'origine dati deve supportare quanto segue:

Filtro data: l'origine dati deve supportare un meccanismo per filtrare i dati in base alla data. Per un'origine relazionale si tratta in genere di una colonna data di tipo data/ora o integer nella tabella di destinazione. I parametri RangeStart e RangeEnd, che devono essere di tipo di dati di data/ora, filtrano i dati della tabella in base alla colonna data. Per le colonne di data delle chiavi surrogate integer sotto forma di yyyymmdd, è possibile creare una funzione che converte il valore di data/ora nei parametri RangeStart e RangeEnd in modo che corrispondano alle chiavi surrogate integer della colonna data. Per altre informazioni, vedere Configurare l'aggiornamento incrementale - Convertire DateTime in integer.

Per altre origini dati, i parametri RangeStart e RangeEnd devono essere passati all'origine dati in qualche modo che consenta il filtro. Per le origini dati basate su file in cui i file e le cartelle sono organizzati per data, i parametri RangeStart e RangeEnd possono essere usati per filtrare i file e le cartelle per selezionare i file da caricare. Per le origini dati basate sul Web, i parametri RangeStart e RangeEnd possono essere integrati nella richiesta HTTP. Ad esempio, la query seguente può essere usata per l'aggiornamento incrementale delle tracce da un'istanza di AppInsights:

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

Quando viene configurato l'aggiornamento incrementale, un'espressione di Power Query che include un filtro di data/ora basato sui parametri RangeStart e RangeEnd viene eseguita sull'origine dati. Se il filtro viene specificato in un passaggio di query dopo la query di origine iniziale, è importante che la riduzione della query combina il passaggio di query iniziale con i passaggi che fanno riferimento ai parametri RangeStart e RangeEnd. Nell'espressione di query seguente, ad esempio, Table.SelectRows verrà piegata perché segue immediatamente il passaggio e SQL Server supporta la Sql.Database riduzione:

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

Non è necessario che la riduzione della query finale supporti la riduzione. Nell'espressione seguente, ad esempio, viene usata una classe NativeQuery non di riduzione, ma si integrano direttamente i parametri RangeStart e RangeEnd in SQL:

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

Tuttavia, se i criteri di aggiornamento incrementale includono il recupero di dati in tempo reale con DirectQuery, non è possibile usare trasformazioni non di riduzione. Se si tratta di criteri in modalità di importazione pura senza dati in tempo reale, il motore mashup di query potrebbe compensare e applicare il filtro in locale, che richiede il recupero di tutte le righe per la tabella dall'origine dati. Questo può causare un rallentamento dell'aggiornamento incrementale e il processo può esaurire le risorse nella servizio Power BI o in un gateway dati locale, sconfiggendo in modo efficace lo scopo dell'aggiornamento incrementale.

Poiché il supporto per la riduzione delle query è diverso per i diversi tipi di origini dati, è necessario eseguire la verifica per assicurarsi che la logica di filtro sia inclusa nelle query eseguite sull'origine dati. Nella maggior parte dei casi, Power BI Desktop tenta di eseguire questa verifica quando si definiscono i criteri di aggiornamento incrementale. Per le origini dati basate su SQL, ad esempio database SQL, Azure Synapse, Oracle e Teradata, questa verifica è affidabile. Tuttavia, altre origini dati potrebbero non essere in grado di verificare senza tracciare le query. Se Power BI Desktop non è in grado di confermare le query, viene visualizzato un avviso nella finestra di dialogo Configurazione dei criteri di aggiornamento incrementale.

Screenshot of the query folding warning

Se viene visualizzato questo avviso e si vuole verificare che si verifichi la riduzione della query necessaria, usare la funzionalità diagnostica di Power Query o eseguire query di traccia usando uno strumento supportato dall'origine dati, ad esempio SQL Profiler. Se la riduzione delle query non si verifica, verificare che la logica del filtro sia inclusa nella query passata all'origine dati. In caso contrario, è probabile che la query includa una trasformazione che impedisce la riduzione.

Prima di configurare la soluzione di aggiornamento incrementale, leggere e comprendere attentamente le linee guida per la riduzione delle query in Power BI Desktop e riduzione delle query di Power Query. Questi articoli consentono di determinare se l'origine dati e le query supportano la riduzione delle query.

Singola origine dati

Quando si configurano l'aggiornamento incrementale e i dati in tempo reale tramite Power BI Desktop o si configura una soluzione avanzata usando TMSL (Tabular Model Scripting Language) o TOM (Tabular Object Model) tramite l'endpoint XMLA, tutte le partizioni, sia importate che DirectQuery, devono eseguire query sui dati da una singola origine.

Altri tipi di origine dati

Usando funzioni di query e logica di query più personalizzate, è possibile usare l'aggiornamento incrementale con altri tipi di origini dati se i filtri basati su RangeStart e RangeEnd possono essere passati in una singola query, ad esempio con origini dati come file di cartelle di lavoro di Excel archiviati in una cartella, file in SharePoint e feed RSS. Tenere presente che si tratta di scenari avanzati che richiedono ulteriore personalizzazione e test oltre a quanto descritto qui. Assicurarsi di controllare la sezione Community più avanti in questo articolo per suggerimenti su come trovare altre informazioni sull'uso dell'aggiornamento incrementale per scenari univoci.

Limiti di tempo

Indipendentemente dall'aggiornamento incrementale, i modelli di Power BI Pro hanno un limite di tempo di aggiornamento di due ore e non supportano il recupero di dati in tempo reale con DirectQuery. Per i modelli in una capacità Premium, il limite di tempo è di cinque ore. Le operazioni di aggiornamento sono un processo e un utilizzo intensivo della memoria. Un'operazione di aggiornamento completo può usare il doppio della quantità di memoria richiesta dal modello da solo, perché il servizio mantiene uno snapshot del modello in memoria fino al completamento dell'operazione di aggiornamento. Le operazioni di aggiornamento possono anche essere a elevato utilizzo di processi, consumando una quantità significativa di risorse della CPU disponibili. Le operazioni di aggiornamento devono anche basarsi su connessioni volatili alle origini dati e sulla possibilità di tali sistemi di origine dati di restituire rapidamente l'output delle query. Il limite di tempo è una salvaguardia per limitare il consumo eccessivo delle risorse disponibili.

Nota

Con le capacità Premium, le operazioni di aggiornamento eseguite tramite l'endpoint XMLA non prevedono limiti di tempo. Per altre informazioni, vedere Aggiornamento incrementale avanzato con l'endpoint XMLA.

Poiché l'aggiornamento incrementale ottimizza le operazioni di aggiornamento a livello di partizione nel modello, l'utilizzo delle risorse può essere notevolmente ridotto. Allo stesso tempo, anche con l'aggiornamento incrementale, a meno che non attraversino l'endpoint XMLA, le operazioni di aggiornamento sono associate agli stessi limiti di due ore e cinque ore. Un criterio di aggiornamento incrementale efficace non solo riduce la quantità di dati elaborati con un'operazione di aggiornamento, ma riduce anche la quantità di dati cronologici non necessari archiviati nel modello.

Le query possono anche essere limitate da un limite di tempo predefinito per l'origine dati. La maggior parte delle origini dati relazionali consente l'override dei limiti di tempo nell'espressione M di Power Query. Ad esempio, l'espressione seguente usa la funzione di accesso ai dati di SQL Server per impostare CommandTimeout su 2 ore. Ogni periodo definito dagli intervalli di criteri invia una query osservando l'impostazione del timeout del comando:

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"

Per i modelli molto grandi nelle capacità Premium che probabilmente contengono miliardi di righe, è possibile eseguire il bootstrap dell'operazione di aggiornamento iniziale. Il bootstrap consente al servizio di creare oggetti tabella e partizione per il modello, ma non carica ed elabora i dati in una delle partizioni. Usando SQL Server Management Studio, è possibile impostare le partizioni da elaborare singolarmente, in sequenza o in parallelo, per ridurre la quantità di dati restituiti in una singola query e ignorare anche il limite di cinque ore. Per altre informazioni, vedere Aggiornamento incrementale avanzato - Impedisci timeout all'aggiornamento completo iniziale.

Data e ora corrente

La data e l'ora correnti si basano sulla data di sistema al momento dell'aggiornamento. Se l'aggiornamento pianificato è abilitato per il modello nel servizio, il fuso orario specificato viene preso in considerazione quando si determina la data e l'ora correnti. Sia gli aggiornamenti individuali che pianificati tramite il servizio osservano il fuso orario, se disponibile. Ad esempio, un aggiornamento che si verifica alle 18:00 ora pacifico (Stati Uniti e Canada) con un fuso orario specificato determina la data e l'ora correnti in base all'ora Pacifico, non all'ora UTC (Coordinated Universal Time), che restituirà il giorno successivo. Le operazioni di aggiornamento non richiamate tramite il servizio Power BI, ad esempio il comando di aggiornamento TMSL, non considerano il fuso orario di aggiornamento pianificato.

Screenshot of Scheduled refresh dialog showing the Time zone input field

Configurare l'aggiornamento incrementale e i dati in tempo reale

Questa sezione descrive i concetti importanti relativi alla configurazione dell'aggiornamento incrementale e dei dati in tempo reale. Quando si è pronti per istruzioni dettagliate dettagliate, vedere Configurare l'aggiornamento incrementale e i dati in tempo reale per i modelli semantici.

La configurazione dell'aggiornamento incrementale viene eseguita in Power BI Desktop. Per la maggior parte dei modelli, sono necessarie solo alcune attività. Tuttavia, tenere presente quanto segue:

Dopo la pubblicazione nel servizio Power BI, non è possibile pubblicare di nuovo lo stesso modello da Power BI Desktop. La ripubblicazione rimuove tutte le partizioni e i dati esistenti già presenti nel modello. Se si pubblica in una capacità Premium, è possibile apportare modifiche successive allo schema dei metadati con strumenti come ALM Toolkit open source o tramite TMSL. Per altre informazioni, vedere Aggiornamento incrementale avanzato - Distribuzione solo metadati.
Dopo la pubblicazione nel servizio Power BI, non è possibile scaricare nuovamente il modello come file con estensione pbix in Power BI Desktop. Poiché i modelli nel servizio possono crescere così grandi, è poco pratico scaricarli e aprirli in un computer desktop tipico.
Quando si ottengono dati in tempo reale con DirectQuery, non è possibile pubblicare il modello in un'area di lavoro non Premium. L'aggiornamento incrementale con dati in tempo reale è supportato solo con Power BI Premium.

Creare un parametro

Per configurare l'aggiornamento incrementale in Power BI Desktop, creare prima due parametri di data/ora di Power Query con i nomi RangeStart riservati, con distinzione tra maiuscole e minuscole e RangeEnd. Questi parametri, definiti nella finestra di dialogo Gestisci parametri in editor di Power Query, vengono inizialmente usati per filtrare i dati caricati nella tabella del modello di Power BI Desktop in modo da includere solo le righe con data/ora entro tale periodo. RangeStart rappresenta la data/ora meno recente o meno recente e RangeEnd rappresenta la data/ora più recente o più recente. Dopo la pubblicazione del modello nel servizio RangeStart e RangeEnd l'override viene eseguito automaticamente dal servizio per eseguire query sui dati definiti dal periodo di aggiornamento specificato nelle impostazioni dei criteri di aggiornamento incrementale.

Ad esempio, la tabella dell'origine dati FactInternetSales calcola una media di 10.000 nuove righe al giorno. Per limitare il numero di righe inizialmente caricate nel modello in Power BI Desktop, specificare un periodo di due giorni tra RangeStart e RangeEnd.

Screenshot of the Manage Parameters dialog showing the RangeStart and RangeEnd parameters.

Filtro dei dati

Dopo aver definito i RangeStart parametri e RangeEnd , applicare filtri di data personalizzati alla colonna data della tabella. I filtri applicati selezionano un subset di dati caricati nel modello quando si seleziona Applica.

Screenshot of column context menu with Custom Filter selected

Con l'esempio FactInternetSales, dopo aver creato filtri in base ai parametri e applicando i passaggi, vengono caricati nel modello due giorni di dati (circa 20.000 righe).

Definire i criteri

Dopo l'applicazione dei filtri e il caricamento di un sottoinsieme di dati nel modello, definire un criterio di aggiornamento incrementale per la tabella. Dopo la pubblicazione del modello nel servizio, i criteri vengono usati dal servizio per creare e gestire partizioni di tabella ed eseguire operazioni di aggiornamento. Per definire i criteri, usare la finestra di dialogo Aggiornamento incrementale e dati in tempo reale per specificare le impostazioni obbligatorie e facoltative.

Screenshot of the Incremental refresh and real-time data dialog showing the Incrementally refresh this table option on.

Tabella

Per impostazione predefinita, la casella di riepilogo Seleziona tabella è la tabella selezionata in Visualizzazione dati. Abilitare l'aggiornamento incrementale per la tabella con il dispositivo di scorrimento. Se l'espressione di Power Query per la tabella non include un filtro basato sui RangeStart parametri e RangeEnd , l'interruttore non è disponibile.

Impostazioni obbligatorie

L'impostazione Archivia dati che iniziano prima della data di aggiornamento determina il periodo cronologico in cui le righe con data/ora in tale periodo vengono incluse nel modello, oltre alle righe per il periodo cronologico incompleto corrente, oltre alle righe del periodo di aggiornamento fino alla data e all'ora correnti.

Ad esempio, se si specificano cinque anni, la tabella archivia gli ultimi cinque anni di dati cronologici nelle partizioni annuali. La tabella includerà anche righe per l'anno corrente nelle partizioni trimestre, mese o giorno, fino a e includendo il periodo di aggiornamento.

Per i modelli nelle capacità Premium, le partizioni cronologiche di cui è stato eseguito il backup possono essere aggiornate in modo selettivo in base a una granularità determinata da questa impostazione. Per altre informazioni, vedere Aggiornamento incrementale avanzato - Partizioni.

L'impostazione Aggiornamento incrementale dei dati che iniziano prima della data di aggiornamento determina il periodo di aggiornamento incrementale in cui tutte le righe con data/ora in tale periodo vengono incluse nelle partizioni di aggiornamento e aggiornate con ogni operazione di aggiornamento.

Ad esempio, se si specifica un periodo di aggiornamento di tre giorni, con ogni operazione di aggiornamento, il servizio esegue l'override dei RangeStart parametri e RangeEnd per creare una query per le righe con una data/ora entro un periodo di tre giorni, con l'inizio e la fine dipendenti dalla data e dall'ora correnti. Le righe con data/ora negli ultimi tre giorni fino all'ora dell'operazione di aggiornamento corrente vengono aggiornate. Con questo tipo di criteri, è possibile prevedere la tabella del modello FactInternetSales nel servizio, che calcola in media 10.000 nuove righe al giorno, per aggiornare circa 30.000 righe con ogni operazione di aggiornamento.

Specificare un punto che includa solo il numero minimo di righe necessarie per garantire la creazione di report accurati. Quando si definiscono criteri per più tabelle, è necessario usare gli stessi RangeStart parametri e RangeEnd anche se per ogni tabella vengono definiti periodi di archiviazione e aggiornamento diversi.

Impostazioni facoltative

L'impostazione Recupera i dati più recenti in tempo reale con DirectQuery (solo Premium) consente di recuperare le modifiche più recenti dalla tabella selezionata nell'origine dati oltre il periodo di aggiornamento incrementale usando DirectQuery. Tutte le righe con data/ora successive al periodo di aggiornamento incrementale vengono incluse in una partizione DirectQuery e recuperate dall'origine dati con ogni query del modello.

Ad esempio, se questa impostazione è abilitata, con ogni operazione di aggiornamento, il servizio esegue comunque l'override dei RangeStart parametri e RangeEnd per creare una query per le righe con una data/ora dopo il periodo di aggiornamento, con l'inizio dipendente dalla data e dall'ora correnti. Sono incluse anche righe con data/ora dopo l'ora dell'operazione di aggiornamento corrente. Con questo tipo di criterio, la tabella del modello FactInternetSales nel servizio include gli aggiornamenti dei dati più recenti.

L'impostazione Solo aggiornamento giorni completi garantisce che tutte le righe per l'intero giorno siano incluse nell'operazione di aggiornamento. Questa impostazione è facoltativa a meno che non si abiliti l'impostazione Recupera i dati più recenti in tempo reale con DirectQuery (solo Premium). Ad esempio, si supponga che l'aggiornamento sia pianificato per l'esecuzione alle 4:00 ogni mattina. Se le nuove righe di dati vengono visualizzate nella tabella dell'origine dati durante queste quattro ore tra la mezzanotte e le 4:00, non è consigliabile tener conto di tali righe. Alcune metriche aziendali come barili al giorno nell'industria petrolifera e del gas non hanno senso con giorni parziali. Un altro esempio è l'aggiornamento dei dati da un sistema finanziario in cui i dati per il mese precedente vengono approvati il dodicesimo giorno di calendario del mese. È possibile impostare il periodo di aggiornamento su un mese e pianificare l'aggiornamento per l'esecuzione nel dodicesimo giorno del mese. Con questa opzione selezionata, ad esempio, aggiornare i dati di gennaio il 12 febbraio.

Tenere presente che, a meno che l'aggiornamento pianificato non sia configurato per un fuso orario non UTC, le operazioni di aggiornamento nel servizio vengono eseguite in base all'ora UTC, che può determinare la data di validità e i periodi di completamento.

L'impostazione Rileva modifiche ai dati consente un aggiornamento ancora più selettivo. È possibile selezionare una colonna di data/ora usata per identificare e aggiornare solo i giorni in cui i dati sono stati modificati. Questa impostazione presuppone che tale colonna esista nell'origine dati, che in genere è a scopo di controllo. Questa colonna non deve essere la stessa colonna usata per partizionare i dati con i RangeStart parametri e RangeEnd . Il valore massimo di questa colonna viene valutato per ogni punto nell'intervallo incrementale. Se non è stato modificato dall'ultimo aggiornamento, non è necessario aggiornare il periodo, che potrebbe potenzialmente ridurre ulteriormente i giorni aggiornati in modo incrementale da tre a uno.

La progettazione corrente richiede che la colonna per rilevare le modifiche ai dati sia persistente e memorizzata nella cache in memoria. Per ridurre la cardinalità e l'utilizzo della memoria, è possibile usare le tecniche seguenti:

Rendere persistente solo il valore massimo della colonna al momento dell'aggiornamento, ad esempio usando una funzione di Power Query.
Ridurre la precisione a un livello accettabile, in base ai requisiti di frequenza di aggiornamento.
Definire una query personalizzata per rilevare le modifiche ai dati usando l'endpoint XMLA ed evitare di rendere persistente completamente il valore della colonna.

In alcuni casi, l'abilitazione dell'opzione Rileva modifiche ai dati* può essere ulteriormente migliorata. Ad esempio, è possibile evitare di rendere persistente una colonna dell'ultimo aggiornamento nella cache in memoria o di abilitare scenari in cui una tabella di configurazione/istruzioni viene preparata dai processi ETL (Extract-Transform-Load) per contrassegnare solo le partizioni che devono essere aggiornate. In casi come questi, per le capacità Premium, usare TMSL e/o TOM per eseguire l'override del comportamento di rilevamento delle modifiche dei dati. Per altre informazioni, vedere Aggiornamento incrementale avanzato - Query personalizzate per rilevare le modifiche ai dati.

Pagina

Dopo aver configurato i criteri di aggiornamento incrementale, pubblicare il modello nel servizio. Al termine della pubblicazione, è possibile eseguire l'operazione di aggiornamento iniziale sul modello.

Nota

I modelli semantici con criteri di aggiornamento incrementale per ottenere i dati più recenti in tempo reale con DirectQuery possono essere pubblicati solo in un'area di lavoro Premium.

Per i modelli pubblicati nelle aree di lavoro assegnate alle capacità Premium, se si ritiene che il modello crescerà oltre 1 GB, è possibile migliorare le prestazioni dell'operazione di aggiornamento e assicurarsi che il modello non limiti di dimensioni massime abilitando il formato di archiviazione del modello di grandi dimensioni prima di eseguire la prima operazione di aggiornamento nel servizio. Per altre informazioni, vedere Modelli di grandi dimensioni in Power BI Premium.

Importante

Dopo che Power BI Desktop pubblica il modello nel servizio, non è possibile scaricare nuovamente il file con estensione pbix .

Refresh

Dopo la pubblicazione nel servizio, eseguire un'operazione di aggiornamento iniziale sul modello. Questo aggiornamento deve essere un singolo aggiornamento (manuale) in modo da poter monitorare lo stato di avanzamento. Il completamento dell'operazione di aggiornamento iniziale può richiedere molto tempo. Le partizioni devono essere create, dati cronologici caricati, oggetti quali relazioni e gerarchie compilate o ricompilate e oggetti calcolati ricalcolati.

Le operazioni di aggiornamento successive, singole o pianificate, sono molto più veloci perché vengono aggiornate solo le partizioni di aggiornamento incrementale. Altre operazioni di elaborazione devono comunque verificarsi, ad esempio l'unione di partizioni e ricalcolo, ma in genere richiede molto meno tempo rispetto all'aggiornamento iniziale.

Aggiornamento automatico dei report

Per i report che usano un modello con criteri di aggiornamento incrementale per ottenere i dati più recenti in tempo reale con DirectQuery, è consigliabile abilitare l'aggiornamento automatico della pagina a un intervallo fisso o in base al rilevamento delle modifiche in modo che i report includano i dati più recenti senza ritardi. Per altre informazioni, vedere Aggiornamento pagina automatico in Power BI.

Aggiornamento incrementale avanzato

Se il modello si trova in una capacità Premium con un endpoint XMLA abilitato, l'aggiornamento incrementale può essere ulteriormente esteso per scenari avanzati. Ad esempio, è possibile usare SQL Server Management Studio per visualizzare e gestire partizioni, eseguire il bootstrap dell'operazione di aggiornamento iniziale o aggiornare le partizioni cronologiche backdated. Per altre informazioni, vedere Aggiornamento incrementale avanzato con l'endpoint XMLA.

Community

Power BI offre una vivace community in cui MVP, professionisti bi e peer condividono competenze in gruppi di discussione, video, blog e altro ancora. Per informazioni sull'aggiornamento incrementale, vedere queste risorse: