Aggregazioni automatiche

Le aggregazioni automatiche usano Machine Learning (ML) all'avanguardia per ottimizzare continuamente i set di dati DirectQuery per ottenere prestazioni massime delle query del report. Le aggregazioni automatiche sono basate sull'infrastruttura di aggregazioni definite dall'utente esistente introdotta per la prima volta con i 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 set di dati di qualsiasi livello di competenza di migliorare le prestazioni delle query, offrendo visualizzazioni dei report più veloci anche per i set di dati più grandi.

Con le aggregazioni automatiche:

  • Le visualizzazioni dei report sono più veloci: una percentuale ottimale di query del report viene restituita da una cache delle aggregazioni in memoria gestita automaticamente anziché da sistemi di origine dati back-end. Le query outlier che non possono essere restituite dalla cache in memoria vengono passate direttamente all'origine dati tramite 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 creazione di report di picco può essere notevolmente ridotto, il che significa una maggiore scalabilità nel back-end dell'origine dati.
  • Configurazione semplificata: i proprietari dei set di dati possono abilitare il training automatico delle aggregazioni e pianificare uno o più aggiornamenti per il set di dati. Con il primo training e l'aggiornamento, le aggregazioni automatiche iniziano a creare un framework di aggregazioni e aggregazioni ottimali. Il sistema si ottimizza automaticamente nel tempo.
  • Ottimizzazione: con un'interfaccia utente semplice e intuitiva nelle impostazioni del set di dati, è 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 Power BI Premium per capacità, Premium per utente e set di dati Power BI Embedded.

Origini dati supportate

Le aggregazioni automatiche sono supportate per le origini dati seguenti:

  • Database SQL di Azure
  • Azure Synapse pool SQL dedicato
  • Google BigQuery
  • Snowflake
  • Databricks
  • Amazon Redshift

Modalità supportate

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

Autorizzazioni

Per abilitare e configurare le aggregazioni automatiche, è necessario essere il proprietario del set di dati. Gli amministratori dell'area di lavoro possono assumere il controllo di un set di dati come proprietario per configurare le impostazioni di aggregazioni automatiche.

Configurazione delle aggregazioni automatiche

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

Vantaggi

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

Se abilitata per un set di dati DirectQuery, le aggregazioni automatiche possono migliorare le prestazioni delle query del report evitando round trip delle query sull'origine dati. I risultati delle query preaggregati vengono restituiti automaticamente da una cache delle aggregazioni in memoria anziché essere inviati e restituiti 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 dei 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.

Automatic aggregations diagram

Gestione automatica di query e aggregazioni

Anche se le aggregazioni automatiche eliminano la necessità di creare tabelle di aggregazioni definite dall'utente e semplificare 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 aggregazioni automatiche.

Log di query

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

Operazioni di training

Nell'ambito della prima operazione di aggiornamento del set di dati pianificata per la frequenza selezionata (giorno o settimana), Power BI avvia prima di tutto un'operazione di training che valuta il log di query per garantire che le aggregazioni nella cache delle aggregazioni in memoria si adattino ai modelli di query modificati. Le tabelle delle aggregazioni 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, caricati durante l'operazione di aggiornamento successiva.

Ad esempio, se si sceglie una frequenza giorno e pianificare gli aggiornamenti alle 4:00, alle 9:00, alle 2:00 e alle 17:00, solo l'aggiornamento delle 4:00 di ogni giorno includerà sia un'operazione di training che un'operazione di aggiornamento. Le successive 9:00, 2:00 e le 17:00 pianificate per quel giorno sono operazioni di aggiornamento che aggiornano le aggregazioni esistenti nella cache.

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 vengano trattate le query future. Non esiste alcuna garanzia, tuttavia, che le query future vengano 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 per tali query 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 set di dati e il training riprende al successivo 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 nuovi e aggiornati 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 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.

Refresh only operations

Aggiornamenti pianificati regolarmente durante il giorno (o la settimana) assicurano che le aggregazioni dei dati nella cache siano più aggiornate con i dati nell'origine dati back-end. Tramite le impostazioni del set di dati, è possibile pianificare fino a 48 aggiornamenti al giorno per garantire che le query del 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 un processo e un uso intensivo delle 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 automatico delle aggregazioni su richiesta facendo clic su Train and Refresh Now (Esegui training e aggiorna adesso nelle impostazioni del set di dati). L'uso di Train and Refresh Now attiva sia un'operazione di training che un'operazione di aggiornamento. Controllare la cronologia di aggiornamento del set di dati per verificare se l'operazione corrente è stata completata prima di eseguire un'operazione aggiuntiva di training e aggiornamento su richiesta, se necessario.

Cronologia aggiornamenti

Ogni operazione di aggiornamento viene registrata nella cronologia di aggiornamento del set di dati. Vengono visualizzate informazioni importanti su ogni aggiornamento, inclusa la quantità di aggregazioni di memoria nella cache per la percentuale di query configurata. Per visualizzare la cronologia degli aggiornamenti, nella pagina Impostazioni set di dati fare clic su Cronologia aggiornamenti. Per eseguire il drill-down più avanti, fare clic su Mostra dettagli.

Cache refresh history

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 del set di dati 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 di query entro i limiti di tempo, Power BI procederà ad aggiornare le aggregazioni esistenti (e le 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 alla successiva 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 ottenuto dovrebbe comunque essere molto migliore rispetto a un set di dati DirectQuery puro senza aggregazioni.

Refresh history partially completed

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

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

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

Aggregazioni definite dall'utente e automatiche

Le aggregazioni definite dall'utente in Power BI possono essere configurate manualmente in base a tabelle aggregate nascoste nel set di dati. La configurazione delle aggregazioni definite dall'utente è spesso complessa, richiedendo un livello maggiore di competenze di modellazione dei dati e ottimizzazione delle query. Le aggregazioni automatiche, invece, 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 pre-aggregati vengono calcolati e archiviati in memoria in base all'analisi dei modelli di query. Con aggregazioni automatiche, i set di dati sono sia auto-training che auto-ottimizzazione. Quando i modelli di query del report client cambiano, le aggregazioni automatiche vengono modificate, assegnando priorità e memorizzazione nella cache di tali aggregazioni usate più spesso.

Poiché le aggregazioni automatiche si basano sull'infrastruttura di aggregazioni definite dall'utente esistente, è possibile usare aggregazioni definite dall'utente e automatiche insieme nello stesso set di dati. I modelli di dati qualificati possono definire aggregazioni per le tabelle usando DirectQuery, Import (con o senza aggiornamento incrementale) o Modalità di archiviazione doppia, mentre contemporaneamente hanno 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 queste System aggregazioni quando vengono analizzate le query di report e vengono apportate modifiche per mantenere le aggregazioni ottimali per il set di dati. Le aggregazioni definite dall'utente e automatiche vengono aggiornate con l'aggiornamento del set di dati. Solo queste 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 mantenere 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 set di dati. Con la memorizzazione nella cache delle query, il servizio memorizza nella cache solo le query per il carico 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 di report pre-memorizzazione nella cache dei risultati delle query aggregate, incluse quelle query generate quando gli utenti interagiscono con i report. La memorizzazione nella cache delle query e le aggregazioni automatiche possono essere entrambe abilitate per un set di dati, ma probabilmente non è necessario.

Eseguire il monitoraggio con Azure Log Analytics

Azure Log Analytics (LA) è un servizio all'interno di Monitoraggio di Azure che Power BI può usare per salvare i log attività. Con la suite di Monitoraggio di Azure è possibile raccogliere, analizzare e agire sui dati di telemetria dagli ambienti azure e locali. Offre 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 riuscita delle aggregazioni automatiche. Tra le altre cose, è possibile determinare se le query del report vengono risposte dalla cache in memoria.

Per usare questa capacità, scaricare il modello PBIT da qui e connetterlo all'account di log analytics, come descritto in questo post. Nel report è possibile visualizzare i dati a tre livelli diversi: visualizzazione riepilogo, visualizzazione a livello di query DAX e visualizzazione 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 rispetto a quelle che hanno dovuto usare l'origine dati.

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) >Eseguire il drill-through> dellacronologia delle query.

Log analytics query history

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

Log analytics query history drill through

Application Lifecycle Management

Da sviluppo a test e da test a produzione, i set di dati con aggregazioni automatiche abilitate hanno requisiti speciali per le soluzioni ALM.

Pipeline di distribuzione

Quando si usano le pipeline di distribuzione, Power BI può copiare i set di dati con la configurazione del set di dati 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 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 API e DevOps.

Soluzioni ALM personalizzate

Se si usa una soluzione ALM personalizzata basata sugli 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 set di dati. Tuttavia, è necessario abilitare le aggregazioni automatiche dopo ogni passaggio della distribuzione nella fase di destinazione manualmente. Power BI manterrà la configurazione se si sovrascrive un set di dati esistente.

Nota

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

Modifica di un set di dati

Quando si modifica un set di dati 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 rimuovere 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 set di dati con aggregazioni automatiche abilitate contengono tabelle di aggregazioni univoche generate dal sistema. Le tabelle di aggregazioni non sono visibili agli utenti negli strumenti di creazione di report. Sono tuttavia visibili tramite l'endpoint XMLA usando strumenti con librerie client di Analysis Services versione 19.22.5 e successive. Quando si utilizzano set di dati 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 scriptare questi set di dati.

Le tabelle di aggregazioni automatiche vengono identificate da una SystemManaged proprietà di tabella, che è nuova al modello a oggetti tabulari (TOM) nelle librerie client di Analysis Services versione 19.22.5 e successiva. Illustrato nel frammento di codice seguente, 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 dataset 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 set di dati in una console.

Auto aggs code

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 queste tabelle autonomamente. In questo modo può causare prestazioni ridotte.

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

Considerazioni e limitazioni

Quando si usano aggregazioni automatiche, tenere presente quanto segue:

  • 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 riscontrano un timeout, considerare temporaneamente il ridimensionamento temporaneo del 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 tabelle di importazione regolari, 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 un aggiornamento efficace pianificare.
  • Per ottimizzare ulteriormente le prestazioni, impostare tutte le tabelle delle dimensioni su Doppia modalità 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 set di dati con aggregazioni automatiche abilitate. Se è stato caricato o pubblicato un file Power BI Desktop (con estensione pbix) in Power BI e quindi sono state abilitate 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 ancora supportate. È possibile enumerare tabelle esterne in Synapse usando la query SQL seguente: SELECT SCHEMA_NAME(schema_id) AS schema_name, nome AS table_name FROM sys.external_tables.
  • Le aggregazioni automatiche sono disponibili solo per i set di dati usando metadati avanzati. Se si desidera abilitare le aggregazioni automatiche per un set di dati precedente, aggiornare prima il set di dati ai metadati avanzati. Per altre informazioni, vedere Uso di metadati del set di dati avanzati.
  • Non abilitare le aggregazioni automatiche se l'origine dati DirectQuery è configurata per l'accesso Single Sign-On e usa viste dati dinamiche o controlli di sicurezza per limitare i dati a cui un utente può accedere. Le aggregazioni automatiche non sono consapevoli di questi controlli a livello di origine dati, che rende impossibile garantire che i dati corretti vengano forniti su base utente. Il training registra un avviso nella cronologia degli aggiornamenti che ha rilevato un'origine dati configurata per l'accesso Single Sign-On e ha ignorato le tabelle che usano questa origine dati. Se possibile, disabilitare l'accesso SSO per queste origini dati per sfruttare al meglio le aggregazioni automatiche delle prestazioni delle query ottimizzate.
  • Non abilitare le aggregazioni automatiche se il set di dati 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 è un 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 aggregazioni durante l'aggiornamento. Le aggregazioni automatiche non possono pertanto includere transazioni che si sono verificate dopo l'ultimo aggiornamento dei dati. Il training registra un avviso nella cronologia degli aggiornamenti rilevati e ignorati.
  • Le colonne calcolate non vengono considerate per le aggregazioni automatiche. Se si usa una colonna calcolata in modalità DirectQuery, ad esempio usando la funzione DAX COMBINEVALUES per creare una relazione basata su più colonne da 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 set di dati con aggregazioni automatiche abilitate, le prestazioni delle query potrebbero degradare 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 le tabelle di aggregazioni generate dal sistema, a meno che non si disponga di aggregazioni automatiche disabilitate e di pulire il set di dati. Il sistema si occupa della gestione di questi oggetti.

Community

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

Vedi anche

Configurare le aggregazioni automatiche
Aggregazioni definite dall'utente
DirectQuery in Power BI
Librerie client di Analysis Services