Ottimizzare le prestazioni di Looker

Queste best practice riflettono i suggerimenti condivisi da un team interfunzionale di Looker esperti. Questi insight derivano da anni di esperienza nella collaborazione con i clienti di Looker, dall'implementazione al successo a lungo termine. Queste pratiche sono pensate per la maggior parte degli utenti e delle situazioni, ma quando li implementi ti consigliamo di usare il tuo buon senso.

Ottimizza le prestazioni delle query

Puoi assicurarti che le query vengano create ed eseguite in modo ottimale sul tuo database seguendo questi suggerimenti per frontend e backend:

• Crea esplorazioni utilizzando i join many_to_one quando possibile. Unire le visualizzazioni dal livello più granulare a quello dal livello più alto di dettaglio (many_to_one) in genere offre le migliori prestazioni delle query.
• Massimizza la memorizzazione nella cache per la sincronizzazione con i tuoi criteri ETL quando possibile per ridurre il traffico di 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 tuo processo ETL applicando gruppi di dati all'interno delle esplorazioni, utilizzando il parametro persist_with. Ciò consente a Looker di integrarsi in modo più stretto con la pipeline di dati di backend, in modo da massimizzare l'utilizzo della cache senza il rischio di analizzare dati inattivi. 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 consapevolezza degli aggregati di Looker per creare tabelle di riepilogo o di riepilogo che Looker può utilizzare per le query quando possibile, soprattutto per le query comuni di database di grandi dimensioni. Puoi anche sfruttare il rilevamento aggregato per migliorare drasticamente le prestazioni di intere dashboard. Per ulteriori informazioni, consulta il tutorial sull'awareness aggregata.
• Utilizza le PDT per eseguire query più rapide. Converti le esplorazioni con molti join complessi o non con prestazioni elevate, o dimensioni con sottoquery o sottoselezioni, in PDT in modo che le viste siano pre unite e pronte prima del runtime.
• Se il tuo dialetto del database supporta le PDT incrementali, configura le PDT incrementali per ridurre il tempo necessario a Looker per ricreare le tabelle PDT.
• Evita di unire le viste in esplorazioni su chiavi primarie concatenate definite in Looker. Unisci invece i campi di base che costituiscono 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 produce una panoramica del piano di esecuzione delle query del tuo database per una determinata query SQL, consentendoti di rilevare i componenti di query che possono essere ottimizzati. Scopri di più il post della scheda Community su 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à il rendimento 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 risorse di cui è stato eseguito il provisioning necessarie (come AWS) per l'elaborazione di set di dati di grandi dimensioni, in modo da aumentare le prestazioni delle query.

Ottimizza le prestazioni del server Looker

Puoi anche adottare misure per garantire che le prestazioni del server e dell'applicazione Looker siano ottimali:

• 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 della memoria in base a una varietà di fattori; tuttavia, i dashboard con 25 o più riquadri tendono a essere problematici in termini di prestazioni.
• Utilizza la funzionalità di aggiornamento automatico della dashboard in modo strategico. Se una dashboard utilizza l'aggiornamento automatico, assicurati che l'aggiornamento non avvenga prima dei processi ETL eseguiti dietro le quinte.
• Usa i pivot in modo strategico ed evita di fare un uso eccessivo di pivot nei riquadri e nei Look della dashboard. Le query con dimensioni utilizzate consumano più memoria. Maggiore è il numero di dimensioni utilizzate, maggiore è la quantità di memoria consumata quando vengono caricati i contenuti (un'esplorazione, un Look o una dashboard).
• Utilizza con parsimonia funzionalità di elaborazione post-query, come l'unione dei risultati, i campi personalizzati e i calcoli tabulari. Queste funzionalità sono pensate per essere utilizzate come proof of concept per aiutarti a progettare il tuo modello. Una best practice consiste nel codificare in modo hardcoded tutti i calcoli e le funzioni utilizzati di frequente in LookML, in modo da generare SQL da elaborare nel tuo database. Calcoli eccessivi possono competere per la memoria Java nell'istanza di Looker, causando una risposta più lenta dell'istanza di Looker.
• Limitare il numero di viste incluse in un modello quando è presente un numero elevato di file di viste. L'inclusione di tutte le viste in un singolo modello può rallentare le prestazioni. Quando in un progetto è presente un numero elevato di viste, ti consigliamo di includere solo i file di visualizzazione necessari all'interno di ogni modello. Prendi in considerazione l'utilizzo di convenzioni di denominazione strategiche per i nomi dei file delle viste al fine di consentire una facile inclusione di gruppi di viste all'interno di un modello. Nella documentazione relativa al parametro includes è riportato un esempio.
• Evita di restituire un numero elevato di punti dati per impostazione predefinita all'interno dei riquadri e dei Look della dashboard. Le query che restituiscono migliaia di punti dati consumano più memoria. Assicurati che i dati siano limitati, ove possibile, applicando i 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 pubblica query utilizzando l'opzione Tutti i risultati con parsimonia, poiché alcune query possono essere molto grandi e sovraccaricare il server Looker durante l'elaborazione.

Per ulteriore assistenza per identificare l'origine dei problemi di prestazioni, consulta la pagina Best practice sulla panoramica del rendimento.