Optimiser les performances de Looker

Ces bonnes pratiques reflètent les recommandations partagées par une équipe pluridisciplinaire d'utilisateurs chevronnés de Looker. Ces insights sont issus d'années d'expérience auprès des clients Looker, de l'implémentation à la réussite à long terme. Ces pratiques sont conçues pour fonctionner pour la plupart des utilisateurs et des situations, mais vous devez faire preuve de discernement lors de leur mise en œuvre.

Optimiser les performances des requêtes

Vous pouvez vous assurer que les requêtes sont créées et exécutées de manière optimale sur votre base de données en suivant les conseils suivants pour l'interface et le backend :

• Créez des explorations à l'aide de jointures many_to_one dans la mesure du possible. Joindre des vues du niveau le plus précis au niveau de détail le plus élevé (many_to_one) offre généralement les meilleures performances de requête.
• Maximisez la mise en cache pour vous synchroniser avec vos règles ETL, dans la mesure du possible, afin de réduire le trafic des requêtes de base de données. Par défaut, Looker met en cache les requêtes pendant une heure. Vous pouvez contrôler la règle de mise en cache et synchroniser les actualisations des données Looker avec votre processus ETL en appliquant des groupes de données dans les explorations, à l'aide du paramètre persist_with. Cela permet à Looker de s'intégrer plus étroitement au pipeline de données backend afin que l'utilisation du cache puisse être maximisée, sans risque d'analyser des données obsolètes. Les règles de mise en cache nommées peuvent être appliquées à un modèle entier et/ou à des explorations individuelles et à des tables dérivées persistantes (PDT).
• Utilisez la fonctionnalité de reconnaissance d'agrégats de Looker pour créer des tables de cumul ou de synthèse que Looker peut utiliser pour les requêtes chaque fois que cela est possible, en particulier pour les requêtes courantes sur de grandes bases de données. Vous pouvez également utiliser la reconnaissance d'agrégats pour améliorer considérablement les performances de tableaux de bord entiers. Pour en savoir plus, consultez le tutoriel sur la reconnaissance d'agrégats.
• Utilisez des PDT pour accélérer les requêtes. Convertissez les explorations comportant de nombreuses jointures complexes ou peu performantes, ou les dimensions comportant des sous-requêtes ou des sous-sélections, en PDT afin que les vues soient pré-jointes et prêtes avant l'exécution.
• Si votre dialecte de base de données accepte les PDT incrémentales, configurez des PDT incrémentales pour réduire le temps que Looker passe à régénérer les PDT.
• Évitez de joindre des vues dans des explorations sur des clés primaires concaténées définies dans Looker. À la place, effectuez la jointure sur les champs de base qui composent la clé primaire concaténée de la vue. Vous pouvez également recréer la vue en tant que PDT avec la clé primaire concaténée prédéfinie dans la définition SQL de la table, plutôt que dans le LookML d'une vue.
• Utilisez l'outil Expliquer dans l'exécuteur SQL pour l'analyse comparative. EXPLAIN génère un aperçu du plan d'exécution de votre base de données pour une requête SQL donnée, ce qui vous permet de détecter les composants de requête pouvant être optimisés. Pour en savoir plus, consultez le post de la communauté How to optimize SQL with EXPLAIN (Comment optimiser SQL avec ).
• Déclarer des index Vous pouvez consulter les index de chaque table directement dans Looker à partir de l'exécuteur SQL en cliquant sur l'icône en forme de roue dentée dans une table, puis en sélectionnant Afficher les index.
  Les colonnes les plus courantes pouvant bénéficier d'index sont les dates importantes et les clés étrangères. L'ajout d'index à ces colonnes améliorera les performances de presque toutes les requêtes. Cela s'applique également aux tables PDT. Les paramètres LookML, tels que indexes, sort keys et distribution, peuvent être appliqués de manière appropriée.
• Augmentez la mémoire, les cœurs et les E/S (entrées/sorties) des bases de données dont le matériel ou les ressources provisionnées (comme AWS) sont insuffisants pour traiter de grands ensembles de données, afin d'améliorer les performances des requêtes.

Optimiser les performances du serveur Looker

Vous pouvez également prendre des mesures pour vous assurer que le serveur et l'application Looker fonctionnent de manière optimale :

• Limitez le nombre d'éléments dans un tableau de bord individuel. Il n'existe pas de règle précise pour définir ce nombre, car la conception de chaque élément a un impact sur la consommation de mémoire en fonction de divers facteurs. Toutefois, les tableaux de bord comportant 25 cartes ou plus ont tendance à poser des problèmes de performances.
• Utilisez la fonctionnalité d'actualisation automatique du tableau de bord de manière stratégique. Si un tableau de bord utilise l'actualisation automatique, assurez-vous qu'il ne s'actualise pas plus rapidement que les processus ETL exécutés en arrière-plan.
• Utilisez les pivots de manière stratégique et évitez de les utiliser de manière excessive dans les vignettes de tableau de bord et les Looks. Les requêtes avec des dimensions pivotées consomment plus de mémoire. Plus il y a de dimensions pivotées, plus la mémoire consommée est importante lors du chargement du contenu (une exploration, un Look ou un tableau de bord).
• Utilisez des fonctionnalités telles que les champs personnalisés et les calculs de table avec parcimonie. Ces fonctionnalités sont destinées à être utilisées comme démonstrations de faisabilité pour vous aider à concevoir votre modèle. Il est recommandé de coder en dur les calculs et les fonctions fréquemment utilisés dans LookML, qui générera du code SQL à traiter dans votre base de données. Un nombre excessif de calculs peut entraîner une concurrence pour la mémoire Java sur l'instance Looker, ce qui ralentit la réponse de l'instance Looker.
• Pour les requêtes de fusion de résultats, utilisez des requêtes de fusion dans la base de données chaque fois que possible. Les requêtes de fusion dans la base de données sont traitées dans votre base de données, et non dans la mémoire de Looker.
• Limitez le nombre de vues incluses dans un modèle lorsqu'un grand nombre de fichiers de vue sont présents. L'inclusion de toutes les vues dans un seul modèle peut ralentir les performances. Lorsqu'un projet contient un grand nombre de vues, envisagez de n'inclure que les fichiers de vue nécessaires dans chaque modèle. Envisagez d'utiliser des conventions de dénomination stratégiques pour les noms de fichiers de vues, afin de permettre l'inclusion de groupes de vues dans un modèle. Un exemple est présenté dans la documentation du paramètre includes.
• Évitez de renvoyer un grand nombre de points de données par défaut dans les vignettes de tableau de bord et les Looks. Les requêtes qui renvoient des milliers de points de données consomment plus de mémoire. Assurez-vous que les données sont limitées autant que possible en appliquant des filtres d'interface aux tableaux de bord, aux Looks et aux explorations, et au niveau LookML avec les paramètres required filters, conditionally_filter et sql_always_where.
• Téléchargez ou envoyez des requêtes en utilisant l'option Tous les résultats avec parcimonie, car certaines requêtes peuvent être très volumineuses et surcharger le serveur Looker lors de leur traitement.
• Comprendre l'impact des performances de connexion sur l'ensemble de l'instance Looker. Looker utilise des ressources partagées pour traiter les requêtes de toutes les connexions de base de données. Ces ressources incluent les pods Kubernetes, les files d'attente de requêtes et les pools de threads. En raison de cette infrastructure partagée, une seule connexion de base de données lente ou surchargée peut avoir un impact négatif sur les performances des requêtes sur toutes les autres connexions. Si vous constatez une dégradation généralisée des performances, examinez l'état de toutes vos connexions de base de données, et pas seulement de celles qui sont directement liées aux tableaux de bord ou aux explorations lents.
• Répartissez les envois planifiés et évitez l'exécution simultanée de jobs. Lorsque plusieurs présentations ou tableaux de bord sont programmés pour s'exécuter exactement à la même minute (en particulier au début de l'heure), l'afflux soudain de requêtes simultanées peut surcharger les ressources de l'instance, augmenter la profondeur de la file d'attente et épuiser les pools de connexions à la base de données. Ce goulot d'étranglement de simultanéité peut entraîner le blocage des livraisons planifiées et des requêtes d'exploration interactives pendant la phase d'initialisation de la requête. Utilisez les stratégies suivantes pour éviter les goulots d'étranglement liés à la simultanéité :
  • Échelonnez les jobs planifiés à des intervalles de 15 ou 30 minutes (ou à des minutes autres que l'heure pile, comme :15, :30 ou :45) plutôt que de planifier toutes les livraisons à l'heure pile.
  • Dans la mesure du possible, utilisez des groupes de données pour déclencher des envois basés sur l'achèvement de l'ETL plutôt que sur des planifications temporelles. Cela permet d'éviter les requêtes inutiles sur des données non actualisées.
  • Traitez par lot ou limitez les scripts externes et les appels d'API automatisés qui exécutent des requêtes ou déclenchent des livraisons.
  • Si une augmentation soudaine du nombre de requêtes entraîne l'absence de réponse de votre instance ou l'exécution indéfinie des requêtes, vous pouvez effacer les tâches en cours en redémarrant l'instance (consultez Redémarrer une instance Looker (Google Cloud Core) pour les instances Looker (Google Cloud Core)).

Pour obtenir de l'aide afin d'identifier la source des problèmes de performances, consultez la page des bonnes pratiques de la présentation des performances.