Monitorare le prestazioni dei grafici in Microsoft Fabric

Le prestazioni dei grafici in Microsoft Fabric dipendono dalle dimensioni del grafo, dalla complessità del modello, dai modelli di query e dalla disponibilità della capacità. Scopri cosa monitorare, come identificare i colli di bottiglia e quali azioni eseguire quando le operazioni di aggiornamento sono lente o le query non restituiscono risultati come previsto.

Per il rilevamento dello stato del processo di aggiornamento di base, vedere Monitorare i carichi di lavoro dei grafici. Per le tecniche di ottimizzazione delle query GQL, vedere Ottimizzare le prestazioni delle query GQL.

Prerequisiti

Prima di iniziare, verificare che:

Fattori che influiscono sulle prestazioni del grafico

Diversi fattori interconnessi influiscono sulle prestazioni del grafico. Diagnosticare gli aggiornamenti lenti e le query rallentate comprendendo quali fattori li determinano.

Dimensioni e complessità del grafico

  • I grafici con più di 500 milioni di nodi e archi generano prestazioni instabili. Per l'elenco completo dei limiti, vedere Limitazioni correnti.
  • Ogni tipo di nodo aggiuntivo, tipo di arco e proprietà si aggiunge ai dati che il grafo elabora durante un aggiornamento. La rimozione dei tipi di nodo inutilizzati, dei tipi di arco e delle proprietà dal modello riduce il tempo di aggiornamento.
  • I grafici densi (molti bordi per nodo) aumentano i costi di attraversamento. Se la maggior parte dei nodi si connette a migliaia di altri nodi, le query che attraversano più hop diventano costose.

Caratteristiche dei dati di origine

  • Il grafico legge direttamente dalle tabelle del lakehouse in OneLake. Le tabelle di origine di grandi dimensioni con molte colonne richiedono più tempo per l'inserimento.
  • Se le tabelle di origine includono colonne non necessarie nel grafico, non aggiungere tali proprietà del tipo di nodo durante la modellazione del grafo. Ogni proprietà contribuisce ai dati letti durante l'aggiornamento e all'impatto sulla memoria del grafico interrogabile. Le proprietà del tipo nodo e del tipo di arco vengono aggiunte manualmente, quindi aggiungere solo quelle necessarie.

Modelli di query

  • Le query che attraversano molti hop, restituiscono nodi completi (RETURN *) o producono set di risultati non associati utilizzano più risorse e richiedono più tempo per l'esecuzione.
  • I filtri a livello di pattern, le proiezioni ristrette e le clausole LIMIT riducono il lavoro svolto dal motore di query. Per tecniche specifiche, vedere Ottimizzare le prestazioni delle query GQL.

Capacità e concorrenza

  • I processi di aggiornamento del grafo e le query utilizzano unità di capacità condivise del pool Fabric (CU). Altri carichi di lavoro nella stessa capacità competono per queste risorse.
  • Se i processi di aggiornamento sono costantemente lenti, verificare se altri carichi di lavoro a consumo elevato vengono eseguiti contemporaneamente usando l'app Microsoft Fabric capacity metrics.

Monitorare le prestazioni di aggiornamento

Usare l'hub di monitoraggio per tenere traccia del tempo necessario per gli aggiornamenti del grafico e se hanno esito positivo o negativo. Per istruzioni dettagliate sull'accesso all'hub di monitoraggio, vedere Monitorare i carichi di lavoro dei grafici.

Identificare gli aggiornamenti lenti

Confrontare le durate dell'aggiornamento nel tempo per stabilire una linea di base per il grafico. Un aggiornamento che richiede molto più tempo del solito può indicare:

  • Crescita dei dati di origine: le tabelle lakehouse sottostanti sono aumentate, aggiungendo altri dati per il grafico da inserire.
  • Aumento della complessità del modello: al modello sono stati aggiunti nuovi tipi di nodo, tipi di arco o proprietà.
  • Pressione della capacità: altri carichi di lavoro utilizzano una quota maggiore della capacità disponibile.

Rispondere agli errori di aggiornamento

I processi di aggiornamento grafico possono non riuscire quando superano il timeout di 20 minuti. Per grafici di grandi dimensioni, questo timeout può causare un errore fino a una volta alla settimana. Se un aggiornamento non riesce:

  1. Aprire l'hub di monitoraggio e individuare il processo di aggiornamento non riuscito.
  2. Selezionare l'attività per visualizzare i dettagli dell'errore e la tempistica.
  3. Se l'errore è stato un timeout, riprovare. L'aggiornamento successivo in genere ha esito positivo. Se i timeout vengono eseguiti ripetutamente, ridurre le dimensioni del grafo rimuovendo tipi di nodo, tipi di arco o proprietà inutilizzati.
  4. Se il problema è stato causato da un errore di configurazione, apra il modello di grafo e verifichi che le mappature dei tipi di nodo e di arco, le colonne chiave e le colonne di chiave esterna siano corrette.

Per altre informazioni sulla risoluzione dei problemi, vedere Risoluzione dei problemi e domande frequenti.

Monitorare le prestazioni delle query

Le singole metriche di query GQL non sono attualmente disponibili nell'hub di monitoraggio. Usare invece questi approcci per comprendere e migliorare le prestazioni delle query.

Osservare il comportamento delle query nell'editor di codice

Quando si esegue una query GQL nell'editor di codice, osservare:

  • Tempo di risposta: tempo impiegato dalla query per restituire i risultati. Le query lente in genere comportano attraversamenti profondi, corrispondenze non associate o set di risultati di grandi dimensioni.
  • Dimensioni dei risultati: set di risultati di grandi dimensioni (che si avvicina al limite di troncamento di 64 MB) indicano che la query richiede limiti o filtri più stretti. Se i risultati vengono troncati, aggiungere le clausole LIMIT, FILTER o WHERE per restringere l'output.
  • Risultati vuoti dopo un aggiornamento riuscito: questa situazione indica in genere che la configurazione del modello a grafo non corrisponde ai dati sottostanti. Verificare che i mapping dei tipi di nodo del sistema puntino alle tabelle e alle colonne di origine corrette.

Problemi comuni relativi alle prestazioni delle query e soluzioni

Sintomo Causa possibile Soluzione
La query richiede più di pochi secondi Attraversamento profondo (conteggio hop elevato) o filtri mancanti Aggiungere clausole a livello WHERE di modello, ridurre l'intervallo di hop e applicare LIMIT.
La query non restituisce risultati Errore di configurazione del tipo nodo o perimetrale o tabelle di origine vuote Verificare i mapping dei modelli e verificare che i dati di origine esistano.
I risultati delle query vengono troncati Il set di risultati supera i 64 MB Proiezione stretta con proprietà specifiche invece di RETURN *e aggiungere LIMIT.
Le aggregazioni sono lente o instabili Il set di risultati supera i 128 MB prima dell'aggregazione Aggiungere filtri per ridurre i risultati intermedi prima di GROUP BY.
Timeout della query (limite di 20 minuti) Attraversamento multihop senza vincoli in un grafo denso Usa TRAIL per evitare rivisitazioni dei bordi, serrare i limiti di hop e aggiungi LIMIT.

Per strategie dettagliate di ottimizzazione delle query, vedere Ottimizzare le prestazioni delle query GQL.

Tenere traccia dell'utilizzo della capacità

Usare l'app Microsoft Fabric Capacity Metrics per comprendere in che modo i carichi di lavoro grafici influiscono sul consumo complessivo della capacità. L'app consente di:

  • Confrontare l'utilizzo della capacità tra i processi di aggiornamento del grafico e altri carichi di lavoro Fabric.
  • Identificare i periodi di tempo in cui la pressione della capacità potrebbe rallentare gli aggiornamenti del grafico.
  • Decidere quando aumentare o ridurre la capacità in base alle tendenze di utilizzo.

Per altre informazioni, vedere Installare l'app Microsoft Fabric Capacity Metrics.

Riepilogo delle procedure consigliate per le prestazioni

  • Dimensioni corrette del modello: evitare di aggiungere tipi di nodo, tipi di arco e proprietà non necessari. I modelli più piccoli vengono aggiornati più velocemente e usano meno memoria.
  • Filtra in anticipo, limita il campo: usa clausole a livello di pattern WHERE e restituisci solo le proprietà necessarie. Evitare RETURN *.
  • Limita i tuoi risultati: applica LIMIT alle query a cardinalità elevata. Mantenere i risultati ben al di sotto della soglia di troncamento di 64 MB.
  • Mantieni gli attraversamenti a livello superficiale: utilizza l'intervallo di hop più stretto consentito dallo scenario. Usare TRAIL per evitare percorsi ridondanti in grafici densi.
  • Monitorare le tendenze di aggiornamento: stabilire una durata di aggiornamento di base e analizzare quando gli aggiornamenti deviano in modo significativo.
  • Controllare la capacità durante i rallentamenti: usare l'app Capacity Metrics per determinare se la pressione della capacità è la causa.