Servizio gateway dati locale

Questo articolo è destinato agli amministratori di Power BI che devono installare e gestire il gateway dati locale.

Il gateway è necessario ogni volta che Power BI deve accedere a dati non accessibili direttamente tramite Internet. Può essere installato in un server locale o in un’infrastruttura distribuita come servizio (IaaS) ospitata da macchine virtuali.

Carichi di lavoro del gateway

Il gateway dati locale supporta due carichi di lavoro. È importante comprendere questi carichi di lavoro prima di illustrare il ridimensionamento del gateway con relative raccomandazioni.

Carico di lavoro dei dati memorizzati nella cache

Il carico di lavoro Dati memorizzati nella cache recupera e trasforma i dati di origine per il caricamento in modelli semantici di Power BI. Questa operazione viene eseguita in tre passaggi:

1. Connessione: il gateway si connette ai dati di origine.
2. Recupero e trasformazione dati: i dati vengono recuperati e, quando necessario, trasformati. Quando possibile, il motore mashup di Power Query esegue il push dei passaggi di trasformazione nell'origine dati, operazione nota come riduzione delle query. Quando non è possibile, le trasformazioni devono essere eseguite dal gateway. In questo caso, il gateway utilizzerà più risorse di CPU e memoria.
3. Trasferimento: i dati vengono trasferiti al servizio Power BI; una connessione Internet affidabile e veloce è importante, soprattutto per volumi di dati di grandi dimensioni.

Carico di lavoro di connessione dinamica e DirectQuery

Il carico di lavoro di connessione dinamica e DirectQuery funziona principalmente in modalità pass-through. Il servizio Power BI invia query e il gateway risponde con i risultati delle query. In genere, i risultati delle query hanno dimensioni ridotte.

• Per altre informazioni sulla connessione dinamica, vedere Modelli semantici nel servizio Power BI (modelli ospitati esternamente).
• Per altre informazioni su DirectQuery, vedere modalità del modello semantico nel servizio Power BI (modalità DirectQuery).

Questo carico di lavoro richiede risorse della CPU per il routing delle query e dei risultati delle query. In genere, la richiesta di CPU è molto inferiore rispetto al carico di lavoro dei dati memorizzati nella cache, soprattutto quando è necessario trasformare i dati per la memorizzazione nella cache.

Una connettività affidabile, veloce e costante è importante per assicurare esperienze reattive agli utenti del report.

Considerazioni sul ridimensionamento

Determinare le dimensioni corrette per il computer del gateway può dipendere dalle variabili seguenti:

• Per i carichi di lavoro dei dati memorizzati nella cache:
  • Numero di aggiornamenti simultanei del modello semantico
  • Tipi di origini dati (database relazionale, database analitico, feed di dati o file)
  • Volume dei dati da recuperare dalle origini dati
  • Tutte le trasformazioni che devono essere eseguite dal motore mashup di Power Query
  • Volume dei dati da trasferire al servizio Power BI
• Per i carichi di lavoro DirectQuery e di connessione dinamica:
  • Numero di utenti di report simultanei
  • Numero di oggetti visivi nelle pagine del report (ogni oggetto visivo invia almeno una query)
  • Frequenza degli aggiornamenti della cache delle query del dashboard di Power BI
  • Numero di report in tempo reale che usano la funzionalità Aggiornamento pagina automatico
  • Se i modelli semantici applicano la Sicurezza a livello di riga

In genere, i carichi di lavoro di connessione dinamica e DirectQuery richiedono risorse CPU sufficienti, mentre i carichi di lavoro dei dati memorizzati nella cache richiedono più CPU e memoria. Entrambi i carichi di lavoro dipendono da una buona connettività con il servizio Power BI e le origini dati.

Nota

Le capacità di Power BI impongono limiti al parallelismo di aggiornamento e alla velocità effettiva di connessione dinamica e DirectQuery. Non ha senso ridimensionare il gateway per offrire capacità maggiori rispetto a quelle supportate dal servizio Power BI. I limiti differiscono in base allo SKU Premium (e allo SKU A di dimensioni equivalenti). Per altre informazioni, vedere licenze di capacità di Microsoft Fabric e Che cos'è Power BI Premium? (nodi delle capacità).

Importante

A volte questo articolo si riferisce a Power BI Premium o alle relative sottoscrizioni di capacità (SKU P). Tenere presente che Microsoft sta attualmente consolidando le opzioni di acquisto e ritirando gli SKU di Power BI Premium per capacità. I clienti nuovi ed esistenti devono invece prendere in considerazione l'acquisto di sottoscrizioni con capacità Fabric (SKU F).

Per altre informazioni, vedere Aggiornamento importante disponibile per le licenze Power BI Premium e Domande frequenti su Power BI Premium.

Consigli

Le raccomandazioni per il ridimensionamento del gateway dipendono da molte variabili. In questa sezione vengono fornite raccomandazioni generali che è possibile prendere in considerazione.

Ridimensionamento iniziale

Può essere difficile stimare accuratamente le dimensioni corrette. Si consiglia di iniziare con un computer con almeno 8 core CPU, 8 GB di RAM e schede di rete da più gigabit. È quindi possibile misurare un carico di lavoro tipico del gateway registrando i contatori di sistema per CPU e memoria. Per altre informazioni, vedere Monitorare e ottimizzare le prestazioni del gateway dati locale.

Connettività

Pianificare la migliore connettività possibile tra il servizio Power BI e il gateway e il gateway e le origini dati.

• Puntare ad affidabilità, velocità molto performanti e latenze basse e coerenti.
• Eliminare o ridurre gli hop del computer tra il gateway e le origini dati.
• Rimuovere eventuali limitazioni della larghezza di banda della rete imposte dal livello proxy del firewall. Per altre informazioni sugli endpoint di Power BI, vedere l'articolo sull'aggiunta di URL di Power BI all'elenco di elementi consentiti.
• Configurare Azure ExpressRoute per stabilire connessioni private e gestite a Power BI.
• Per le origini dati nelle macchine virtuali di Azure, assicurarsi che le macchine virtuali siano colocate con il servizio Power BI.
• Per i carichi di lavoro di connessione dinamica a SQL Server Analysis Services (SSAS) che coinvolgono la Sicurezza a livello di riga dinamica, garantire una buona connettività tra il computer gateway e Active Directory locale.

Cluster

Per le distribuzioni su larga scala, è possibile creare un gateway con più membri del cluster. I cluster evitano singoli punti di guasto e possono bilanciare il carico del traffico tra i gateway. È possibile:

• Installare uno o più gateway in un cluster.
• Isolare i carichi di lavoro in gateway autonomi o cluster di server gateway.

Per altre informazioni, vedere Gestire i cluster a disponibilità elevata e il bilanciamento del carico del gateway dati locale.

Progettazione e impostazioni del modello semantico

La progettazione di modelli semantici e le relative impostazioni possono influire sui carichi di lavoro del gateway. Per ridurre il carico di lavoro del gateway, è possibile prendere in considerazione le azioni seguenti.

Per modelli semantici di importazione:

• Configurare un aggiornamento dati meno frequente.
• Configurare un aggiornamento incrementale per ridurre al minimo la quantità di dati da trasferire.
• Quando possibile, assicurarsi che venga eseguita la riduzione della query.
• In particolare, per volumi di dati di grandi dimensioni o in caso di necessità di risultati a bassa latenza, convertire la progettazione in un modello DirectQuery o composito.

Per i modelli semantici DirectQuery:

• Ottimizzare le origini dati, i modelli e le progettazioni di report. Per altre informazioni, vedere Linee guida sul modello DirectQuery in Power BI Desktop.
• Creare aggregazioni per memorizzare nella cache i risultati di livello superiore per ridurre il numero di richieste DirectQuery.
• Limitare intervalli di aggiornamento automatico delle pagine in progettazioni di report e impostazioni di capacità.
• Soprattutto quando viene applicata la Sicurezza a livello di riga dinamica, limitare la frequenza di aggiornamento della memorizzazione nella cache del dashboard.
• In particolare, per i volumi di dati più piccoli o per i dati non volatili, convertire la progettazione in un modello di importazione o composito.

Per i modelli semantici di connessione dinamica:

• Soprattutto quando viene applicata la Sicurezza a livello di riga dinamica, limitare la frequenza di aggiornamento della memorizzazione nella cache del dashboard.

Contenuto correlato

Per altre informazioni correlate a questo articolo, vedere le risorse seguenti:

• Pianificazione dell’implementazione di Power BI: gateway dati
• Indicazioni per la distribuzione di un gateway dati per Power BI
• Configurare le impostazioni proxy per il gateway dati locale
• Monitorare e ottimizzare le prestazioni del gateway dati locale
• Risolvere i problemi relativi ai gateway - Power BI
• Risolvere i problemi del gateway dati locale
• Importanza della riduzione delle query
• Domande? Contattare la community di Power BI
• inviare suggerimenti, Contribuire con idee per migliorare Power BI