Ottimizzare il rendimento di Looker

Queste best practice riflettono i consigli condivisi da un team interfunzionale di esperti Looker. Questi approfondimenti provengono da anni di esperienza di collaborazione con i clienti di Looker, dall'implementazione al successo a lungo termine. Le best practice sono scritte per funzionare per la maggior parte degli utenti e delle situazioni, ma devi usare il tuo buon senso durante l'implementazione.

Ottimizzare le prestazioni delle query

Puoi assicurarti che le query vengano create ed eseguite in modo ottimale nel database con i seguenti suggerimenti per frontend e backend:

• Crea esplorazioni utilizzando le unioni many_to_one, se possibile. L'unione delle visualizzazioni dal livello più granulare al livello più alto di dettaglio (many_to_one) in genere offre le migliori prestazioni di query.
• Massimizza la memorizzazione nella cache per sincronizzarti con i tuoi criteri ETL, ove possibile, per ridurre il traffico delle query del database. Per impostazione predefinita, Looker memorizza nella cache le query per un'ora. Puoi controllare il criterio di memorizzazione nella cache e sincronizzare gli aggiornamenti dei dati di Looker con il processo ETL applicando i gruppi di dati all'interno delle esplorazioni utilizzando il parametro persist_with. In questo modo, Looker può integrarsi più strettamente con la pipeline di dati di backend, in modo da massimizzare l'utilizzo della cache senza il rischio di analizzare dati non aggiornati. I criteri di memorizzazione nella cache con nome possono essere applicati a un intero modello e/o a singole esplorazioni e tabelle derivate permanenti (PDT).
• Utilizza la funzionalità di consapevolezza aggregata di Looker per creare aggregazioni o tabelle di riepilogo che Looker può utilizzare per le query, se possibile, in particolare per le query comuni di database di grandi dimensioni. Puoi anche utilizzare la consapevolezza aggregata per migliorare drasticamente il rendimento di intere dashboard. Per ulteriori informazioni, consulta il tutorial sull'awareness aggregata.
• Utilizza i PDT per query più rapide. Converti le esplorazioni con molti join complessi o con scarso rendimento o con dimensioni con sottoquery o sottoselezioni in PDT in modo che le visualizzazioni siano pre-aggregate e pronte prima del runtime.
• Se il dialetto del database supporta le tabelle PDT incrementali, configura le tabelle PDT incrementali per ridurre il tempo impiegato da Looker per ricostruire le tabelle PDT.
• Evita di unire le visualizzazioni alle esplorazioni in base a chiavi primarie concatenate definite in Looker. Esegui invece il join sui campi di base che compongono la chiave primaria concatenata dalla vista. In alternativa, ricrea la visualizzazione come PDT con la chiave primaria concatenata predefinita nella definizione SQL della tabella anziché nel codice LookML di una visualizzazione.
• Utilizza lo strumento Spiega in SQL Runner per il benchmarking. EXPLAIN genera una panoramica del piano di esecuzione delle query del database per una determinata query SQL, consentendo di rilevare i componenti delle query che possono essere ottimizzati. Scopri di più nel post della scheda Community Come ottimizzare SQL con EXPLAIN.
• Dichiara gli indici. Puoi esaminare gli indici di ogni tabella direttamente in Looker da SQL Runner facendo clic sull'icona a forma di ingranaggio in una tabella e selezionando Mostra indici.
  Le colonne più comuni che possono trarre vantaggio dagli indici sono le date importanti e le chiavi esterne. L'aggiunta di indici a queste colonne aumenterà le prestazioni per quasi tutte le query. Lo stesso vale per i PDT. I parametri LookML, come indexes, sort keys e distribution, possono essere applicati in modo appropriato.
• Aumenta la memoria, i core e l'I/O (input/output) dei database con hardware insufficiente o risorse di provisioning necessarie (come AWS) per l'elaborazione di set di dati di grandi dimensioni, in modo da migliorare le prestazioni delle query.

Ottimizzare le prestazioni del server di Looker

Puoi anche adottare misure per assicurarti che il server e l'applicazione Looker funzionino in modo ottimale:

• Limita il numero di elementi all'interno di una singola dashboard. Non esiste una regola precisa per definire il numero, perché il design di ogni elemento influisce sul consumo di memoria in base a una serie di fattori. Tuttavia, le dashboard con 25 o più riquadri tendono a essere problematiche in termini di prestazioni.
• Utilizza la funzionalità di aggiornamento automatico della dashboard in modo strategico. Se una dashboard utilizza l'aggiornamento automatico, assicurati che non venga aggiornata più velocemente dei processi ETL in esecuzione in background.
• Utilizza i pivot in modo strategico ed evita di utilizzarli eccessivamente nei riquadri della dashboard e nei look. Le query con dimensioni pivot consumano più memoria. Più dimensioni vengono pivotate, maggiore è la memoria utilizzata durante il caricamento dei contenuti (un'esplorazione, un look o una dashboard).
• Utilizza con parsimonia funzionalità come Unione dei risultati, campi personalizzati e calcoli tabulari. Queste funzionalità sono pensate per essere utilizzate come prove del concetto per aiutarti a progettare il tuo modello. È buona prassi codificare i calcoli e le funzioni di uso frequente in LookML, in modo da generare SQL da elaborare nel database. Calcoli eccessivi possono competere per la memoria Java nell'istanza di Looker, causando una risposta più lenta dell'istanza.
• Limita il numero di visualizzazioni incluse in un modello quando è presente un numero elevato di file di visualizzazione. L'inclusione di tutte le visualizzazioni in un unico modello può rallentare il rendimento. Quando in un progetto è presente un numero elevato di visualizzazioni, ti consigliamo di includere solo i file delle visualizzazioni necessari in ogni modello. Valuta la possibilità di utilizzare convenzioni di denominazione strategiche per i nomi dei file delle visualizzazioni, in modo da includere facilmente gruppi di visualizzazioni all'interno di un modello. Un esempio è descritto nella documentazione del parametro includes.
• Evita di restituire un numero elevato di punti dati per impostazione predefinita nei riquadri della dashboard e nei look. Le query che restituiscono migliaia di punti dati consumeranno più memoria. Assicurati che i dati siano limitati, ove possibile, applicando filtri frontend a dashboard, look ed esplorazioni e a livello di LookML con i parametri required filters, conditionally_filter e sql_always_where.
• Scarica o invia query utilizzando l'opzione Tutti i risultati con parsimonia, poiché alcune query possono essere molto grandi e sopraffare il server di Looker durante l'elaborazione.

Per ulteriore assistenza per identificare la fonte dei problemi di rendimento, consulta la pagina Best practice della Panoramica del rendimento.