Ottimizzare il rendimento di Looker

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

Ottimizza le prestazioni delle query

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

• Crea esplorazioni utilizzando i join many_to_one ogni volta che è possibile. L'unione delle visualizzazioni dal livello più granulare al livello di dettaglio più elevato (many_to_one) in genere offre le migliori prestazioni delle query.
• Massimizza la memorizzazione nella cache per sincronizzarla con i criteri ETL, ove possibile, per ridurre il traffico delle query del database. Per impostazione predefinita, Looker memorizza le query nella cache per un'ora. Puoi controllare la policy di memorizzazione nella cache e sincronizzare gli aggiornamenti dei dati di Looker con il processo ETL applicando i gruppi di dati all'interno di Explore, 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 obsoleti. I criteri di memorizzazione nella cache denominati possono essere applicati a un intero modello e/o a singole esplorazioni e tabelle derivate permanenti (PDT).
• Utilizza la funzionalità di aggregate awareness di Looker per creare tabelle di aggregazione o di riepilogo che Looker può utilizzare per le query, se possibile, in particolare per le query comuni di database di grandi dimensioni. Puoi anche sfruttare l'awareness aggregata per migliorare drasticamente le prestazioni di intere dashboard. Per ulteriori informazioni, consulta il tutorial sull'awareness aggregata.
• Utilizza le PDT per query più rapide. Converti in PDT le esplorazioni con molti join complessi o con prestazioni scadenti oppure le dimensioni con subquery o subselect, in modo che le visualizzazioni siano pre-unite e pronte prima del runtime.
• Se il dialetto del database supporta le PDT incrementali, configura le PDT incrementali per ridurre il tempo impiegato da Looker per ricostruire le PDT.
• Evita di unire le visualizzazioni in Explore su 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 vista come PDT con la chiave primaria concatenata predefinita nella definizione SQL della tabella, anziché nel LookML di una vista.
• Utilizza lo strumento Spiega in SQL Runner per il benchmarking. EXPLAIN genera una panoramica del piano di esecuzione delle query del tuo database per una determinata query SQL, consentendoti di rilevare i componenti della query che possono essere ottimizzati. Scopri di più nel post per la community How to optimize SQL with 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 migliorerà le prestazioni di quasi tutte le query. Questo vale anche per le 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 con risorse di provisioning necessarie (come AWS) per l'elaborazione di set di dati di grandi dimensioni, in modo da migliorare le prestazioni delle query.

Ottimizza le prestazioni del server 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 si aggiorni 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 sottoposte a pivot, maggiore è la memoria consumata quando vengono caricati i contenuti (un'esplorazione, un Look o una dashboard).
• Utilizza con parsimonia funzionalità come i campi personalizzati e i calcoli tabulari. Queste funzionalità sono destinate a essere utilizzate come proof of concept per aiutarti a progettare il tuo modello. La best practice consiste nell'impostare come hardcoded i calcoli e le funzioni di uso frequente in LookML, che genererà l'SQL da elaborare nel database. I calcoli eccessivi possono competere per la memoria Java nell'istanza di Looker, rallentando la risposta dell'istanza.
• Per le query sui risultati uniti, utilizza le query di unione nel database, se possibile. Le query di unione nel database vengono elaborate nel database, anziché nella memoria di Looker.
• 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 le prestazioni. Quando in un progetto è presente un numero elevato di visualizzazioni, valuta la possibilità di includere solo i file di visualizzazione necessari all'interno di ogni modello. Valuta la possibilità di utilizzare convenzioni di denominazione strategiche per i nomi file delle viste, in modo da consentire l'inclusione di gruppi di viste 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 all'interno dei riquadri della dashboard e dei Look. Le query che restituiscono migliaia di punti dati consumano più memoria. Assicurati che i dati siano limitati, ove possibile, applicando filtri di 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 le query utilizzando l'opzione Tutti i risultati con parsimonia, poiché alcune query possono essere molto grandi e sovraccaricare il server Looker durante l'elaborazione.
• Comprendere l'impatto delle prestazioni della connessione sull'intera istanza di Looker. Looker utilizza risorse condivise per elaborare le query di tutte le connessioni al database. Queste risorse includono pod Kubernetes, code di query e pool di thread. A causa di questa infrastruttura condivisa, una singola connessione al database lenta o sovraccarica può influire negativamente sulle prestazioni delle query su tutte le altre connessioni. Se noti un peggioramento generale delle prestazioni, esamina lo stato di tutte le connessioni al database, non solo di quelle direttamente correlate alle dashboard o alle esplorazioni lente.
• Distribuisci le pubblicazioni pianificate ed evita l'esecuzione simultanea dei job. Quando l'esecuzione di più Look o dashboard è pianificata esattamente nello stesso minuto (in particolare all'inizio dell'ora), l'improvviso aumento delle richieste di query simultanee può sovraccaricare le risorse dell'istanza, aumentare la profondità della coda ed esaurire i pool di connessioni al database. Questo collo di bottiglia della concorrenza può causare il blocco sia delle pubblicazioni pianificate sia delle query di esplorazione interattive durante la fase di inizializzazione delle query. Utilizza le seguenti strategie per evitare colli di bottiglia della concorrenza:
  • Scagliona i job pianificati a intervalli di 15 o 30 minuti (o minuti non all'inizio dell'ora, come :15, :30 o :45) anziché pianificare tutte le pubblicazioni all'inizio dell'ora.
  • Quando possibile, utilizza i gruppi di dati per attivare le pubblicazioni basate sul completamento dell'ETL anziché su pianificazioni basate sul tempo, evitando query non necessarie su dati non aggiornati.
  • Esegui in batch o limita gli script esterni e le chiamate API automatiche che eseguono query o attivano le pubblicazioni.
  • Se un improvviso picco di query causa l'interruzione della risposta dell'istanza o l'esecuzione indefinita delle query, puoi cancellare le attività in corso riavviando l'istanza (consulta Riavvia un'istanza di Looker (Google Cloud core) per le istanze di Looker (Google Cloud core)).

Per ulteriore assistenza nell'identificazione dell'origine dei problemi di prestazioni, consulta la pagina delle best practice Panoramica delle prestazioni.