Aggiornamento incrementale e dati in tempo reale per i modelli semantici

L'aggiornamento incrementale e i dati in tempo reale per i modelli semantici in Power BI offrono modi efficienti per gestire i dati dinamici e migliorare le prestazioni di aggiornamento del modello. Automatizzando la creazione e la gestione delle partizioni, l'aggiornamento incrementale riduce la quantità di dati che devono essere aggiornati e consente l'inclusione di dati in tempo reale. Questo articolo illustra come configurare e usare le funzionalità di aggiornamento incrementale in Power BI per acquisire dati in rapida evoluzione e migliorare le prestazioni.

L'aggiornamento incrementale estende le operazioni di aggiornamento pianificate consentendo 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 aumentare in modo esponenziale, ad esempio una tabella dei fatti in uno schema di database relazionale o star. Un criterio di aggiornamento incrementale per creare partizioni della tabella, che aggiorna solo le partizioni di importazione più recenti e, facoltativamente, usa 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 delle query.

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

• Sono necessari meno cicli di aggiornamento per i dati in rapida evoluzione. La modalità DirectQuery consente di ottenere 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 sull'origine dei dati vengono eseguite più velocemente, riducendo il rischio che i problemi di rete interferiscano.
• Il consumo di risorse risulta ridotto. Una quantità inferiore di dati da aggiornare riduce il consumo complessivo di memoria e di altre risorse sia in Power BI che nei sistemi dell'origine dati.
• Vengono abilitati i modelli semantici di grandi dimensioni. I modelli semantici che possono avere 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 esegue partizioni in modo dinamico e separa i dati che devono essere aggiornati di frequente 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 riservati, con distinzione tra maiuscole e minuscole, RangeStart 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 un aggiornamento incrementale, 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 le righe nel periodo di aggiornamento definito in modo dinamico dai parametri. Le 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. Per entrambi i periodi di aggiornamento e cronologico viene eseguito il roll forward. Man mano che vengono create nuove partizioni di aggiornamento incrementale, le partizioni di aggiornamento che non rientrano più nel periodo di aggiornamento diventano partizioni cronologiche. Nel corso del tempo, le partizioni cronologiche diventano meno granulari man mano che vengono unite. Quando una partizione cronologica non rientra più nel periodo cronologico definito dai criteri, viene rimossa completamente dal modello. Questo comportamento è noto come modello di finestra mobile.

Il vantaggio 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, per migliorare significativamente le prestazioni di aggiornamento del modello basta un criterio di aggiornamento incrementale ben definito. Tuttavia, la partizione DirectQuery in tempo reale è supportata solo per i modelli nelle capacità Premium. Power BI Premium consente anche scenari di partizioni 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 strutturate e relazionali, ad esempio il database SQL e Azure Synapse, ma possono essere usati anche per altre origini dati. In ogni caso, l'origine dati deve supportare quanto segue:

Filtri di 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 del tipo di dati data/ora o integer nella tabella di destinazione. I parametri RangeStart e RangeEnd, che devono essere il tipo di dati data/ora, filtrano i dati della tabella in base alla colonna data. Per le colonne della 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 corrisponda alle chiavi surrogate Integer della colonna della data. Per altre informazioni, vedere Configurare l'aggiornamento incrementale e i dati in tempo reale - Convertire DateTime in integer.

Per altre origini dati, i parametri RangeStart e RangeEnd devono essere passati all'origine dati in qualche modo che consenta l'applicazione dei filtri. 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 query finale supporti la riduzione. Nell'espressione seguente, ad esempio, viene usata una nativeQuery non di riduzione, ma si integrano i parametri RangeStart e RangeEnd direttamente 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 senza riduzione. Se si tratta di un criterio di modalità importazione puro 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 nel servizio Power BI o in un gateway dati locale, sconfiggendo efficacemente lo scopo dell'aggiornamento incrementale.

Poiché il supporto per la query folding è 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 il database SQL, Azure Synapse, Oracle e Teradata, questa verifica è affidabile. Altre origini dati, tuttavia, possono essere in grado di effettuare la verifica solo se eseguono la traccia delle query. Se Power BI Desktop non è in grado di confermare le query, viene visualizzato un avviso nella finestra di dialogo di configurazione dei criteri di aggiornamento incrementale.

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

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

Singola origine dati

Quando si configurano l'aggiornamento incrementale e i dati in tempo reale usando 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 di importazione o DirectQuery, devono eseguire query sui dati da una singola origine.

Altri tipi di origine dati

Usando funzioni di query e una 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 i file della cartella di lavoro di Excel archiviati in una cartella, i file in SharePoint e i 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 unici.

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 è cinque ore. Le operazioni di aggiornamento sono a elevato utilizzo di elaborazione e memoria. Un'operazione di aggiornamento completo può usare il doppio della quantità di memoria richiesta dal solo modello, 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, con una notevole quantità 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 misura di sicurezza per limitare il consumo eccessivo delle risorse disponibili.

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 si usi l'endpoint XMLA, le operazioni di aggiornamento sono legate 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 essere limitate anche dal limite di tempo predefinito per l'origine dati. La maggior parte delle origini dati relazionali consente di eseguire 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 due ore. Ogni periodo definito dagli intervalli dei criteri invia una query osservando l'impostazione di 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 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 né elabora i dati nelle partizioni. Usando SQL Server Management Studio, è possibile impostare l'elaborazione singola, in sequenza o in parallelo delle partizioni, per ridurre la quantità di dati restituiti in una singola query e ignorare il limite di cinque ore. Per altre informazioni, vedere Aggiornamento incrementale avanzato - Impedire i timeout nell'aggiornamento completo iniziale.

Data e ora corrente

Per impostazione predefinita, la data e l'ora correnti vengono determinate in base all'ora UTC (Coordinated Universal Time) al momento dell'aggiornamento. Per gli aggiornamenti dell'API REST e pianificati su richiesta, è possibile configurare un fuso orario diverso in "Aggiorna" che verrà preso in considerazione quando si determina la data e l'ora correnti. Ad esempio, un aggiornamento che si verifica alle ore 20:00 del Pacifico (Stati Uniti e Canada) con il fuso orario configurato determina la data e l'ora corrente in base all'ora del Pacifico, e non all'ora UTC, che altrimenti sarebbe il giorno successivo.

Le operazioni di aggiornamento non richiamate tramite il servizio Power BI, ad esempio il comando di aggiornamento TMSL XMLA XMLA, non considerano la configurazione del fuso orario e il valore predefinito è UTC.

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, vedere Configurare l'aggiornamento incrementale e i dati in tempo reale.

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 esistenti e i dati già presenti nel modello. Se si pubblica in un livello con 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 dei soli metadati.
• Dopo la pubblicazione nel servizio Power BI, non è possibile scaricare nuovamente il modello come .pbix in Power BI Desktop. Poiché i modelli nel servizio possono aumentare notevolmente, è poco pratico scaricarli e aprirli in un computer desktop comune.
• 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 riservati, con distinzione tra maiuscole e minuscole, RangeStart e RangeEnd. Questi parametri, definiti nella finestra di dialogo Gestisci parametri nell'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 la prima e RangeEnd rappresenta la data/ora più recente o l'ultima. Dopo la pubblicazione del modello nel servizio, il servizio esegue automaticamente l'override di RangeStart e RangeEnd 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 ha in media 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.

Filtro dei dati

Una volta definiti i parametri RangeStart e RangeEnd, è possibile applicare filtri di data personalizzati nella colonna della data della tabella. I filtri applicati selezionano un sottoinsieme di dati caricati nel modello quando si seleziona Applica.

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

Definire criterio

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

Tabella

La casella a discesa Selezionare tabella si imposta di default sulla tabella che hai selezionato nella visualizzazione Tabella. 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 parametri RangeStart e RangeEnd, l'interruttore non è disponibile.

Impostazioni obbligatorie

L'impostazione Archivia dati a partire dalla data di aggiornamento determina il periodo cronologico in cui le righe con data/ora in tale periodo sono incluse nel modello, più le righe per il periodo cronologico incompleto corrente, più le righe del periodo di aggiornamento fino alla data e all'ora correnti.

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

Per i modelli nei livelli con capacità Premium, le partizioni cronologiche retrodatate 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 a partire dalla 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 parametri RangeStart e RangeEnd per creare una query per le righe con 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 ha 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 i criteri per più tabelle, è necessario usare gli stessi parametri RangeStart e RangeEnd anche se sono definiti periodi di archiviazione e aggiornamento diversi per ogni tabella.

Impostazioni facoltative

L'impostazione Ottieni i dati più recenti in tempo reale con DirectQuery (solo Premium) abilita il recupero delle modifiche più recenti dalla tabella selezionata nell'origine dati oltre il periodo di aggiornamento incrementale tramite DirectQuery. Tutte le righe con data/ora successive al periodo di aggiornamento incrementale sono 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 parametri RangeStart e RangeEnd per creare una query per le righe con una data/ora successiva al periodo di aggiornamento, con l'inizio dipendente dalla data e dall'ora correnti. Sono incluse anche righe con data/ora successive all'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 Aggiorna solo i giorni completi assicura 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 Ottieni i dati più recenti in tempo reale con DirectQuery (solo Premium). Si supponga, ad esempio, che l'aggiornamento sia stato pianificato per l'esecuzione ogni mattina alle 04:00. Se le nuove righe di dati vengono visualizzate nella tabella dell'origine dati durante queste quattro ore tra la mezzanotte e le 04:00, non è consigliabile tenerne conto. 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 di un sistema finanziario in cui i dati per il mese precedente vengono approvati il giorno 12 del mese. È possibile impostare il periodo di aggiornamento su un mese e pianificare l'esecuzione dell'aggiornamento nel dodicesimo giorno del mese. Con questa opzione selezionata, ad esempio, i dati di gennaio verranno aggiornati il 12 febbraio.

Tenere presente che, a meno che il fuso orario sotto "Refresh" non sia configurato per uno diverso da UTC, le operazioni di aggiornamento nel servizio vengono eseguite in base all'ora UTC, il che può determinare il tempo effettivo e i periodi di completamento.

L'impostazione Rileva le modifiche ai dati abilita 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 l'esistenza di una colonna di questo tipo, usata in genere per operazioni di controllo, nel sistema di origine. Questa colonna non deve essere la stessa colonna usata per eseguire le partizioni dei dati con i parametri RangeStart e RangeEnd. Il valore massimo di questa colonna viene valutato per ciascuno dei periodi dell'intervallo incrementale. Se non è stato modificato dall'ultimo aggiornamento, non è necessario aggiornarlo, che potrebbe potenzialmente ridurre ulteriormente i giorni aggiornati in modo incrementale da tre a uno.

La struttura corrente richiede che la colonna per il rilevamento delle modifiche ai dati sia persistente e memorizzata nella cache. 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 il valore della colonna.

In alcuni casi, l'abilitazione dell'opzione Rileva modifiche ai dati può essere ulteriormente migliorata. Ad esempio, se si desidera evitare di rendere persistente la colonna dell'ultimo aggiornamento nella cache della memoria, o abilitare scenari in cui i processi di estrazione, trasformazione e caricamento (ETL) preparano una tabella di configurazione/istruzioni allo scopo di 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.

Pubblicazione

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

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 l'impostazione Formato di archiviazione modello semantico 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.

Refresh

Dopo la pubblicazione nel servizio, si esegue 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. È necessario creare le partizioni, caricare i dati cronologici, compilare o ricompilare oggetti quali relazioni e gerarchie e ricalcolare gli oggetti calcolati.

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 il ricalcolo, ma in genere richiedono 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 automatico della pagina in Power BI.

Aggiornamento incrementale avanzato

Se il modello si trova in un livello con 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 retrodatate. Per altre informazioni, vedere Aggiornamento incrementale avanzato con l'endpoint XMLA.

Community

Power BI ha una vivace community in cui MVP, professionisti BI e colleghi condividono competenze in gruppi di discussione, video, blog e altro ancora. Quando si apprendono informazioni sull'aggiornamento incrementale, fare riferimento a queste risorse:

• Community di Power BI
• Cercare "Aggiornamento incrementale di Power BI" in Bing
• Cercare "Aggiornamento incrementale per i file" in Bing
• Cercare "Mantenere i dati esistenti usando l'aggiornamento incrementale" in Bing

Contenuto correlato

• Configurare l'aggiornamento incrementale per i modelli semantici
• Aggiornamento incrementale avanzato con l'endpoint XMLA
• Risolvere i problemi di aggiornamento incrementale
• Aggiornamento incrementale per i flussi di dati