Aggregazioni automatiche

Le aggregazioni automatiche usano Machine Learning (ML) all'avanguardia per ottimizzare continuamente i modelli semantici DirectQuery per ottenere prestazioni massime delle query del report. Le aggregazioni automatiche si basano sull'infrastruttura di aggregazioni definite dall'utente esistente introdotta per la prima volta con modelli compositi per Power BI. A differenza delle aggregazioni definite dall'utente, le aggregazioni automatiche non richiedono una modellazione completa dei dati e competenze di ottimizzazione delle query per configurare e gestire. Le aggregazioni automatiche sono sia auto-training che auto-ottimizzazione. Consentono ai proprietari di modelli di qualsiasi livello di competenza di migliorare le prestazioni delle query, offrendo visualizzazioni dei report più veloci per modelli di grandi dimensioni.

Con le aggregazioni automatiche:

  • Le visualizzazioni dei report sono più veloci: una percentuale ottimale di query di report viene restituita da una cache di aggregazioni in memoria gestita automaticamente anziché da sistemi di origine dati back-end. Le query outlier che non vengono restituite dalla cache in memoria vengono passate direttamente all'origine dati usando DirectQuery.
  • Architettura bilanciata: rispetto alla modalità DirectQuery pura, la maggior parte dei risultati delle query viene restituita dal motore di query di Power BI e dalla cache delle aggregazioni in memoria. Il carico di elaborazione delle query nei sistemi di origine dati nei periodi di picco di creazione di report può essere notevolmente ridotto, il che significa una maggiore scalabilità nel back-end dell'origine dati.
  • Configurazione semplificata: i proprietari dei modelli possono abilitare il training delle aggregazioni automatiche e pianificare uno o più aggiornamenti per il modello. Con il primo training e l'aggiornamento, le aggregazioni automatiche iniziano a creare un framework di aggregazioni e aggregazioni ottimali. Il sistema si tunese automaticamente nel tempo.
  • Ottimizzazione: con un'interfaccia utente semplice e intuitiva nelle impostazioni del modello, è possibile stimare i miglioramenti delle prestazioni per una percentuale diversa di query restituite dalla cache delle aggregazioni in memoria e apportare modifiche per ottenere miglioramenti ancora maggiori. Un singolo controllo barra di scorrimento consente di ottimizzare facilmente l'ambiente.

Requisiti

Piani supportati

Le aggregazioni automatiche sono supportate per i modelli Power BI Premium per capacità, Premium per utente e Power BI Embedded.

Origini dati supportate

Le aggregazioni automatiche sono supportate per le origini dati seguenti:

  • Database SQL di Microsoft Azure
  • Pool SQL dedicato di Azure Synapse
  • SQL Server 2019 o versione successiva
  • Google BigQuery
  • Snowflake
  • Databricks
  • Amazon Redshift

Modalità supportate

Le aggregazioni automatiche sono supportate per i modelli in modalità DirectQuery. Sono supportati modelli compositi con tabelle di importazione e connessioni DirectQuery. Le aggregazioni automatiche sono supportate solo per la connessione DirectQuery.

Autorizzazioni

Per abilitare e configurare le aggregazioni automatiche, è necessario essere il proprietario del modello. Gli amministratori dell'area di lavoro possono assumere il ruolo di proprietario per configurare le impostazioni delle aggregazioni automatiche.

Configurazione delle aggregazioni automatiche

Le aggregazioni automatiche vengono configurate nel modello Impostazioni. La configurazione è semplice: abilitare il training delle aggregazioni automatiche e pianificare uno o più aggiornamenti. Prima di configurare le aggregazioni automatiche per il modello, leggere completamente questo articolo. Offre una buona comprensione del funzionamento delle aggregazioni automatiche e consente di decidere se le aggregazioni automatiche sono appropriate per l'ambiente in uso. Quando si è pronti per istruzioni dettagliate su come abilitare il training delle aggregazioni automatiche, configurare una pianificazione dell'aggiornamento e ottimizzare l'ambiente, vedere Configurare le aggregazioni automatiche.

Vantaggi

Con DirectQuery, ogni volta che un utente del modello apre un report o interagisce con una visualizzazione del report, le query DAX (Data Analysis Expressions) vengono passate al motore di query e quindi all'origine dati back-end come query SQL. L'origine dati deve calcolare e restituire i risultati per ogni query. Rispetto ai modelli in modalità di importazione archiviati in memoria, i round trip dell'origine dati DirectQuery possono essere sia tempo che utilizzo intensivo del processo, causando spesso tempi di risposta lenti delle query nelle visualizzazioni dei report.

Se abilitata per un modello DirectQuery, le aggregazioni automatiche possono migliorare le prestazioni delle query del report evitando round trip delle query dell'origine dati. I risultati delle query preaggregati vengono restituiti automaticamente da una cache di aggregazioni in memoria anziché essere inviate e restituite dall'origine dati. La quantità di dati preaggregati nella cache delle aggregazioni in memoria è una piccola frazione della quantità di dati mantenuti in realtà e tabelle di dettaglio nell'origine dati. Il risultato non è solo migliorare le prestazioni delle query del report, ma anche ridurre il carico nei sistemi di origine dati back-end. Con le aggregazioni automatiche, solo una piccola parte di report e query ad hoc che richiedono aggregazioni non incluse nella cache in memoria vengono passate all'origine dati back-end, proprio come con la modalità DirectQuery pura.

Diagram that shows automatic aggregation processing.

Gestione automatica di query e aggregazioni

Anche se le aggregazioni automatiche eliminano la necessità di creare tabelle di aggregazione definite dall'utente e semplificano notevolmente l'implementazione di una soluzione di dati preaggregata, una maggiore familiarità con i processi e le dipendenze sottostanti è utile per comprendere il funzionamento delle aggregazioni automatiche. Power BI si basa sulle operazioni seguenti per creare e gestire le aggregazioni automatiche.

Log di query

Power BI tiene traccia delle query di modello e report utente in un log di query. Per ogni modello, Power BI mantiene sette giorni di dati di log delle query. I dati del log delle query vengono distribuiti ogni giorno. Il log delle query è sicuro e non è visibile agli utenti o tramite l'endpoint XMLA.

Operazioni di training

Come parte della prima operazione di aggiornamento pianificato del modello per la frequenza selezionata (giorno o settimana), Power BI avvia prima un'operazione di training che valuta il log delle query per garantire che le aggregazioni nella cache delle aggregazioni in memoria si adattino ai modelli di query modificati. Le tabelle di aggregazione in memoria vengono create, aggiornate o eliminate e le query speciali vengono inviate all'origine dati per determinare le aggregazioni da includere nella cache. I dati delle aggregazioni calcolate, tuttavia, non vengono caricati nella cache in memoria durante il training, ma vengono caricati durante l'operazione di aggiornamento successiva.

Ad esempio, se si sceglie una frequenza giorno e la pianificazione viene aggiornata alle 4:00, alle 9:00, alle 2:00 e alle 17:00, solo l'aggiornamento delle 4:00 am ogni giorno includerà sia un'operazione di training che un'operazione di aggiornamento. Gli aggiornamenti pianificati delle 9:00, delle 2:00 e delle 17:00 per quel giorno sono operazioni di aggiornamento solo che aggiornano le aggregazioni esistenti nella cache.

Diagram of the training and refresh operation.

Mentre le operazioni di training valutano le query passate dal log di query, i risultati sono sufficientemente accurati per garantire che le query future vengano trattate. Non esiste alcuna garanzia, tuttavia, che le query future verranno restituite dalla cache delle aggregazioni in memoria perché tali nuove query potrebbero essere diverse da quelle derivate dal log di query. Tali query non restituite dalla cache delle aggregazioni in memoria vengono passate all'origine dati tramite DirectQuery. A seconda della frequenza e della classificazione delle nuove query, le aggregazioni possono essere incluse nella cache delle aggregazioni in memoria con l'operazione di training successiva.

L'operazione di training ha un limite di tempo di 60 minuti. Se il training non è in grado di elaborare l'intero log di query entro il limite di tempo, viene registrata una notifica nella cronologia di aggiornamento del modello e il training riprende alla successiva avvio. Il ciclo di training viene completato e sostituisce le aggregazioni automatiche esistenti quando viene elaborato l'intero log di query.

Operazioni di aggiornamento

Come descritto in precedenza, dopo il completamento dell'operazione di training come parte del primo aggiornamento pianificato per la frequenza selezionata, Power BI esegue un'operazione di aggiornamento che esegue query e carica i dati delle aggregazioni nuove e aggiornate nella cache delle aggregazioni in memoria e rimuove tutte le aggregazioni che non classificano più sufficientemente elevate (come determinato dall'algoritmo di training). Tutti gli aggiornamenti successivi per la frequenza giorno o settimana scelta sono operazioni di aggiornamento solo che eseguono query sull'origine dati per aggiornare i dati delle aggregazioni esistenti nella cache. Usando l'esempio precedente, gli aggiornamenti pianificati delle 9:00, delle 2:00 e delle 17:00 per quel giorno sono operazioni di sola aggiornamento.

Diagram showing refresh only operations and refresh queries related to the data source.

Gli aggiornamenti pianificati regolarmente durante il giorno (o la settimana) assicurano che le aggregazioni nella cache siano più aggiornate con i dati nell'origine dati back-end. Tramite il modello Impostazioni, è possibile pianificare fino a 48 aggiornamenti al giorno per garantire che le query di report restituite dalla cache delle aggregazioni ottengano risultati in base ai dati aggiornati più recenti dall'origine dati back-end.

Attenzione

Le operazioni di training e aggiornamento sono a elevato utilizzo di processi e risorse sia per i sistemi di servizio Power BI che per i sistemi di origine dati. Aumentando la percentuale di query che usano aggregazioni, è necessario eseguire query e calcolare più aggregazioni dalle origini dati durante le operazioni di training e aggiornamento, aumentando la probabilità di un uso eccessivo delle risorse di sistema e causando potenzialmente timeout. Per altre informazioni, vedere Ottimizzazione.

Formazione su richiesta

Come accennato in precedenza, un ciclo di training potrebbe non essere completato entro i limiti di tempo di un singolo ciclo di aggiornamento dati. Se non si vuole attendere fino al successivo ciclo di aggiornamento pianificato che include il training, è anche possibile attivare il training delle aggregazioni automatiche su richiesta selezionando Training e Aggiorna ora nel modello Impostazioni. L'uso di Train and Refresh Now attiva sia un'operazione di training che un'operazione di aggiornamento. Controllare la cronologia di aggiornamento del modello per verificare se l'operazione corrente è stata completata prima di eseguire un'altra operazione di training e aggiornamento su richiesta, se necessario.

Cronologia aggiornamenti

Ogni operazione di aggiornamento viene registrata nella cronologia di aggiornamento del modello. Vengono visualizzate informazioni importanti su ogni aggiornamento, incluso il numero di aggregazioni di memoria nella cache per la percentuale di query configurata. Per visualizzare la cronologia degli aggiornamenti, nella pagina del modello Impostazioni selezionare Cronologia aggiornamenti. Per eseguire il drill-down più avanti, selezionare Mostra dettagli.

Screenshot of the refresh history window showing the scheduled history details.

Controllando regolarmente la cronologia degli aggiornamenti, è possibile assicurarsi che le operazioni di aggiornamento pianificate vengano completate entro un periodo accettabile. Assicurarsi che le operazioni di aggiornamento vengano completate correttamente prima dell'inizio dell'aggiornamento pianificato successivo.

Errori di training e aggiornamento

Mentre Power BI esegue operazioni di training e aggiornamento come parte del primo aggiornamento pianificato per la frequenza di giorno o settimana scelta, queste operazioni vengono implementate come transazioni separate. Se un'operazione di training non è in grado di elaborare completamente il log delle query entro i limiti di tempo, Power BI procederà all'aggiornamento delle aggregazioni esistenti (e delle tabelle regolari in un modello composito) usando lo stato di training precedente. In questo caso, la cronologia degli aggiornamenti indicherà che l'aggiornamento è riuscito e il training riprenderà l'elaborazione del log delle query al successivo avvio del training. Le prestazioni delle query potrebbero essere meno ottimizzate se i modelli di query del report client sono stati modificati e le aggregazioni non sono state ancora modificate, ma il livello di prestazioni raggiunto dovrebbe essere ancora molto migliore rispetto a un modello DirectQuery puro senza aggregazioni.

Screenshot of the refresh history screen showing an item that was partially completed.

Se un'operazione di training richiede troppi cicli per completare l'elaborazione del log delle query, è consigliabile ridurre la percentuale di query che usano la cache delle aggregazioni in memoria nel modello Impostazioni. In questo modo si ridurrà il numero di aggregazioni create nella cache, ma sarà possibile completare più tempo per il training e l'aggiornamento delle operazioni. Per altre informazioni, vedere Ottimizzazione.

Se il training ha esito positivo ma l'aggiornamento ha esito negativo, l'intero aggiornamento viene contrassegnato come Non riuscito perché il risultato è una cache delle aggregazioni in memoria non disponibile.

Quando si pianifica l'aggiornamento, è possibile specificare notifiche tramite posta elettronica in caso di errori di aggiornamento.

Aggregazioni automatiche e definite dall'utente

Le aggregazioni definite dall'utente in Power BI possono essere configurate manualmente in base alle tabelle aggregate nascoste nel modello. La configurazione delle aggregazioni definite dall'utente è spesso complessa e richiede un livello maggiore di competenze di modellazione dei dati e ottimizzazione delle query. Le aggregazioni automatiche, d'altra parte, eliminano questa complessità come parte di un sistema basato sull'intelligenza artificiale. A differenza delle aggregazioni definite dall'utente che rimangono statiche, Power BI gestisce continuamente i log delle query e da tali log determina i modelli di query basati su algoritmi di modellazione predittiva di Machine Learning (ML). I dati preaggregati vengono calcolati e archiviati in memoria in base all'analisi dei criteri di query. Con le aggregazioni automatiche, i modelli sono sia auto-training che auto-ottimizzazione. Man mano che i modelli di query del report client cambiano, le aggregazioni automatiche regolano, assegnano priorità e memorizzano nella cache tali aggregazioni usate più spesso.

Poiché le aggregazioni automatiche si basano sull'infrastruttura di aggregazioni definite dall'utente esistenti, è possibile usare aggregazioni sia definite dall'utente che automatiche nello stesso modello. I modelli di dati qualificati possono definire aggregazioni per le tabelle usando DirectQuery, Import (con o senza aggiornamento incrementale) o modalità di archiviazione duale, contemporaneamente con i vantaggi delle aggregazioni più automatiche per le query sulle connessioni DirectQuery che non raggiungono le tabelle di aggregazione definite dall'utente. Questa flessibilità consente architetture bilanciate che possono ridurre i carichi di query ed evitare colli di bottiglia.

Le aggregazioni create nella cache in memoria dall'algoritmo di training delle aggregazioni automatiche vengono identificate come System aggregazioni. L'algoritmo di training crea ed elimina solo tali System aggregazioni quando vengono analizzate le query di report e vengono apportate modifiche per mantenere le aggregazioni ottimali per il modello. Le aggregazioni definite dall'utente e automatiche vengono aggiornate con l'aggiornamento. Solo le aggregazioni create dalle aggregazioni automatiche e contrassegnate come aggregazioni generate dal sistema sono incluse nell'elaborazione automatica delle aggregazioni.

Memorizzazione nella cache delle query e aggregazioni automatiche

Power BI Premium supporta anche la memorizzazione nella cache delle query in Power BI Premium/Embedded per gestire i risultati delle query. La memorizzazione nella cache delle query è una funzionalità diversa dalle aggregazioni automatiche. Con la memorizzazione nella cache delle query, Power BI Premium usa il servizio di memorizzazione nella cache locale per implementare la memorizzazione nella cache, mentre le aggregazioni automatiche vengono implementate a livello di modello. Con la memorizzazione nella cache delle query, il servizio memorizza nella cache solo le query per il caricamento iniziale della pagina del report, pertanto le prestazioni delle query non vengono migliorate quando gli utenti interagiscono con un report. Al contrario, le aggregazioni automatiche ottimizzano la maggior parte delle query del report pre-memorizzazione nella cache dei risultati delle query aggregate, incluse quelle generate quando gli utenti interagiscono con i report. La memorizzazione nella cache delle query e le aggregazioni automatiche possono essere entrambe abilitate per un modello, ma probabilmente non è necessario.

Eseguire il monitoraggio con Azure Log Analytics

Azure Log Analytics (LA) è un servizio in Monitoraggio di Azure che Power BI può usare per salvare i log attività. Con la famiglia di prodotti Monitoraggio di Azure è possibile raccogliere, analizzare e agire sui dati di telemetria dagli ambienti Azure e locali. Offre l'archiviazione a lungo termine, un'interfaccia di query ad hoc e l'accesso alle API per consentire l'esportazione e l'integrazione dei dati con altri sistemi. Per altre informazioni, vedere Uso di Azure Log Analytics in Power BI.

Se Power BI è configurato con un account Azure LA, come descritto in Configurazione di Azure Log Analytics per Power BI, è possibile analizzare la frequenza di successo delle aggregazioni automatiche. Tra le altre cose, è possibile determinare se le query del report vengono risposte dalla cache in memoria.

Per usare questa funzionalità, scaricare il modello PBIT e connetterlo all'account di Log Analytics, come descritto in questo post di blog di Power BI. Nel report è possibile visualizzare i dati a tre livelli diversi: visualizzazione riepilogo, vista a livello di query DAX e vista a livello di query SQL.

L'immagine seguente mostra la pagina di riepilogo per tutte le query. Come si può notare, il grafico contrassegnato mostra la percentuale di query totali soddisfatte dalle aggregazioni e quelle che dovevano usare l'origine dati.

Screenshot with log analytics queries by aggregations stage.

Il passaggio successivo per approfondire l'analisi consiste nell'esaminare l'uso delle aggregazioni a livello di query DAX. Fare clic con il pulsante destro del mouse su una query DAX dall'elenco (in basso a sinistra) >Drill-through>Cronologia query.

Screenshot that shows log analytics query history.

Verrà fornito un elenco di tutte le query pertinenti. Eseguire il drill-through al livello successivo per visualizzare altri dettagli di aggregazione.

Screenshot that shows log analytics query history drill through.

Application Lifecycle Management

Dallo sviluppo al test e dal test alla produzione, i modelli con aggregazioni automatiche abilitate hanno requisiti speciali per le soluzioni ALM.

Pipeline di distribuzione

Con le pipeline di distribuzione, Power BI può copiare i modelli con la configurazione del modello dalla fase corrente alla fase di destinazione. Tuttavia, le aggregazioni automatiche devono essere reimpostate nella fase di destinazione perché le impostazioni non vengono trasferite dalla fase corrente alla fase di destinazione. È anche possibile distribuire il contenuto a livello di codice usando le API REST delle pipeline di distribuzione. Per altre informazioni su questo processo, vedere Automatizzare la pipeline di distribuzione usando le API e DevOps.

Soluzioni ALM personalizzate

Se si usa una soluzione ALM personalizzata basata su endpoint XMLA, tenere presente che la soluzione potrebbe essere in grado di copiare le tabelle di aggregazioni generate dal sistema e create dall'utente come parte dei metadati del modello. Tuttavia, è necessario abilitare manualmente le aggregazioni automatiche dopo ogni passaggio della distribuzione nella fase di destinazione. Power BI manterrà la configurazione se si sovrascrive un modello esistente.

Nota

Se si carica o ripubblica un modello come parte di un file di Power BI Desktop (con estensione pbix), le tabelle di aggregazione create dal sistema vengono perse perché Power BI sostituisce il modello esistente con tutti i metadati e i dati nell'area di lavoro di destinazione.

Modifica di un modello

Dopo aver modificato un modello con aggregazioni automatiche abilitate tramite endpoint XMLA, ad esempio l'aggiunta o la rimozione di tabelle, Power BI mantiene tutte le aggregazioni esistenti che possono essere e rimuove quelle che non sono più necessarie o pertinenti. Le prestazioni delle query potrebbero essere interessate fino a quando non viene attivata la fase di training successiva.

Elementi di metadati

I modelli con aggregazioni automatiche abilitate contengono tabelle di aggregazioni univoche generate dal sistema. Le tabelle delle aggregazioni non sono visibili agli utenti negli strumenti di creazione di report. Sono visibili tramite l'endpoint XMLA usando gli strumenti con le librerie client di Analysis Services versione 19.22.5 e successive. Quando si utilizzano modelli con aggregazioni automatiche abilitate, assicurarsi di aggiornare gli strumenti di modellazione e amministrazione dei dati alla versione più recente delle librerie client. Per SQL Server Management Studio (SSMS), eseguire l'aggiornamento a SSMS versione 18.9.2 o successiva. Le versioni precedenti di SSMS non sono in grado di enumerare tabelle o creare script per questi modelli.

Le tabelle delle aggregazioni automatiche sono identificate da una SystemManaged proprietà di tabella, una novità del modello a oggetti tabulare (TOM) nelle librerie client di Analysis Services versione 19.22.5 e successive. Il frammento di codice seguente mostra la SystemManaged proprietà impostata su true per le tabelle di aggregazioni automatiche e false per le tabelle regolari.

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.AnalysisServices.Tabular;

namespace AutoAggs
{
    class Program
    {
        static void Main(string[] args)
        {
            string workspaceUri = "<Specify the URL of the workspace where your model resides>";
            string datasetName = "<Specify the name of your dataset>";

            Server sourceWorkspace = new Server();
            sourceWorkspace.Connect(workspaceUri);
            Database dataset = sourceWorkspace.Databases.GetByName(datasetName);

            // Enumerate system-managed tables.
            IEnumerable<Table> aggregationsTables = dataset.Model.Tables.Where(tbl => tbl.SystemManaged == true);


            if (aggregationsTables.Any())
            {
                Console.WriteLine("The following auto aggs tables exist in this dataset:");
                foreach (Table table in aggregationsTables)
                {
                    Console.WriteLine($"\t{table.Name}");
                }
            }
            else
            {
                Console.WriteLine($"This dataset has no auto aggs tables.");
            }

            Console.WriteLine("\n\rPress [Enter] to exit the sample app...");
            Console.ReadLine();
        }
    }
}

L'esecuzione di questo frammento di codice genera tabelle di aggregazioni automatiche attualmente incluse nel modello in una console.

Screenshot of the output the snippet showing auto aggs tables that exist in the model.

Tenere presente che le tabelle delle aggregazioni cambiano costantemente quando le operazioni di training determinano le aggregazioni ottimali da includere nella cache delle aggregazioni in memoria.

Importante

Power BI gestisce completamente gli oggetti tabella generati dal sistema. Non eliminare o modificare manualmente queste tabelle. Questa operazione può causare prestazioni ridotte.

Power BI gestisce la configurazione del modello all'esterno del modello. La presenza di una tabella delle aggregazioni gestite dal sistema in un modello non significa necessariamente che il modello sia abilitato per il training automatico delle aggregazioni. In altre parole, se si crea uno script per una definizione di modello completa per un modello con aggregazioni automatiche abilitate e si crea una nuova copia del modello (con un nome/area di lavoro/capacità diverso), il nuovo modello risultante non è abilitato per il training delle aggregazioni automatiche. È comunque necessario abilitare il training delle aggregazioni automatiche per il nuovo modello nel modello Impostazioni.

Considerazioni e limitazioni

Quando si usano le aggregazioni automatiche, tenere presente quanto segue:

  • Le aggregazioni non supportano i parametri di query M dinamici.
  • Le query SQL generate durante la fase di training iniziale possono generare un carico significativo per il data warehouse. Se il training rimane incompleto e è possibile verificare sul lato data warehouse che le query riscontrino un timeout, valutare la possibilità di aumentare temporaneamente il data warehouse per soddisfare la domanda di training.
  • Le aggregazioni archiviate nella cache delle aggregazioni in memoria potrebbero non essere calcolate sui dati più recenti nell'origine dati. A differenza di DirectQuery puro e più simile alle normali tabelle di importazione, esiste una latenza tra gli aggiornamenti nell'origine dati e i dati delle aggregazioni archiviati nella cache delle aggregazioni in memoria. Anche se ci sarà sempre un certo grado di latenza, può essere mitigato tramite una pianificazione efficace dell'aggiornamento.
  • Per ottimizzare ulteriormente le prestazioni, impostare tutte le tabelle delle dimensioni su Modalità doppia e lasciare le tabelle dei fatti in modalità DirectQuery.
  • Le aggregazioni automatiche non sono disponibili con Power BI Pro, Azure Analysis Services o SQL Server Analysis Services.
  • Power BI non supporta il download di modelli con aggregazioni automatiche abilitate. Se è stato caricato o pubblicato un file di Power BI Desktop (con estensione pbix) in Power BI e quindi sono state abilitate le aggregazioni automatiche, non è più possibile scaricare il file PBIX. Assicurarsi di mantenere una copia del file PBIX in locale.
  • Le aggregazioni automatiche con tabelle esterne in Azure Synapse Analytics non sono supportate. È possibile enumerare tabelle esterne in Synapse usando la query SQL seguente: SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name FROM sys.external_tables.
  • Le aggregazioni automatiche sono disponibili solo per i modelli che usano metadati avanzati. Se si desidera abilitare le aggregazioni automatiche per un modello meno recente, aggiornare prima il modello ai metadati avanzati. Per altre informazioni, vedere Uso di metadati del modello avanzati.
  • Non abilitare le aggregazioni automatiche se l'origine dati DirectQuery è configurata per l'accesso Single Sign-On e usa visualizzazioni dati dinamiche o controlli di sicurezza per limitare i dati a cui un utente può accedere. Le aggregazioni automatiche non sono a conoscenza di questi controlli a livello di origine dati, il che rende impossibile garantire che i dati corretti vengano forniti in base all'utente. Il training registra un avviso nella cronologia di aggiornamento in cui è stata rilevata un'origine dati configurata per l'accesso Single Sign-On e le tabelle che usano questa origine dati. Se possibile, disabilitare l'accesso Single Sign-On per queste origini dati per sfruttare appieno le aggregazioni automatiche delle prestazioni delle query ottimizzate.
  • Non abilitare le aggregazioni automatiche se il modello contiene solo tabelle ibride per evitare un sovraccarico di elaborazione non necessario. Una tabella ibrida usa sia le partizioni di importazione che una partizione DirectQuery. Uno scenario comune è l'aggiornamento incrementale con dati in tempo reale in cui una partizione DirectQuery recupera le transazioni dall'origine dati che si è verificata dopo l'ultimo aggiornamento dei dati. Tuttavia, Power BI importa le aggregazioni durante l'aggiornamento. Le aggregazioni automatiche non possono includere transazioni che si sono verificate dopo l'ultimo aggiornamento dei dati. Il training registra un avviso nella cronologia di aggiornamento che ha rilevato e ignorato le tabelle ibride.
  • Le colonne calcolate non vengono considerate per le aggregazioni automatiche. Se si usa una colonna calcolata in modalità DirectQuery, ad esempio usando la COMBINEVALUES funzione DAX per creare una relazione basata su più colonne di due tabelle DirectQuery, le query di report corrispondenti non raggiungeranno la cache delle aggregazioni in memoria.
  • Le aggregazioni automatiche sono disponibili solo nella servizio Power BI. Power BI Desktop non crea tabelle di aggregazioni generate dal sistema.
  • Se si modificano i metadati di un modello con aggregazioni automatiche abilitate, le prestazioni delle query potrebbero peggiorare fino a quando non viene attivato il processo di training successivo. Come procedura consigliata, è consigliabile eliminare le aggregazioni automatiche, apportare le modifiche e quindi ripetere il training.
  • Non modificare o eliminare tabelle di aggregazioni generate dal sistema, a meno che non siano disabilitate le aggregazioni automatiche e che il modello venga pulito. Il sistema assume la responsabilità di gestire questi oggetti.

Community

Power BI ha una vivace community in cui MVP, professionisti bi e peer condividono competenze in gruppi di discussione, video, blog e altro ancora. Quando si apprendono informazioni sulle aggregazioni automatiche, assicurarsi di controllare queste altre risorse: