Optimiser les performances de Looker

Ces bonnes pratiques reflètent les recommandations partagées par une équipe multifonctionnelle de Lookers expérimentés. Ces insights proviennent de nos nombreuses 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

Pour vous assurer que les requêtes sont créées et exécutées de manière optimale dans votre base de données, suivez les conseils suivants concernant le frontend 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 et des tables dérivées persistantes (PDT) individuelles.
• 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 de grandes bases de données. Vous pouvez également tirer parti de 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 sensibilisation agrégée.
• Utilisez des PDT pour accélérer les requêtes. Convertissez les explorations comportant de nombreuses jointures complexes ou peu performantes, ou des dimensions avec 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 prend en charge les PDT incrémentales, configurez les PDT incrémentales pour réduire le temps que Looker consacre à la régénération des PDT.
• Évitez de joindre des vues dans des explorations sur des clés primaires concaténées définies dans Looker. À la place, effectuez une 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 effectuer des benchmarks. EXPLAIN génère un aperçu du plan d'exécution des requêtes 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 qui peuvent être optimisés. Pour en savoir plus, consultez le post de la communauté How to optimize SQL with EXPLAIN (Optimiser SQL avec EXPLAIN).
• Déclarez les index. Vous pouvez consulter les index de chaque table directement dans Looker depuis SQL Runner. Pour ce faire, cliquez sur l'icône en forme de roue dentée dans une table, puis sélectionnez 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ée/sortie) 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 le nombre de tuiles, 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 tuiles 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 tableaux croisés de manière stratégique et évitez de les utiliser de manière excessive dans les tuiles de tableau de bord et les Looks. Les requêtes avec des dimensions pivotées consomment plus de mémoire. Plus le nombre de dimensions pivotées est élevé, plus la mémoire consommée est importante lorsque le contenu (une exploration, une présentation ou un tableau de bord) est chargé.
• Utilisez les fonctionnalités telles que Fusionner les résultats, Champs personnalisés et Calculs de tables avec parcimonie. Ces fonctionnalités sont destinées à être utilisées comme des 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, ce qui générera du code SQL à traiter dans votre base de données. Des calculs excessifs peuvent entrer en concurrence pour la mémoire Java sur l'instance Looker, ce qui ralentit la réponse de l'instance Looker.
• Limitez le nombre de vues incluses dans un modèle lorsqu'un grand nombre de fichiers de vues sont présents. Inclure toutes les vues dans un seul modèle peut ralentir les performances. Lorsqu'un projet contient un grand nombre de vues, envisagez d'inclure uniquement les fichiers de vue nécessaires dans chaque modèle. Envisagez d'utiliser des conventions de nommage 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 sur le paramètre includes.
• Évitez de renvoyer un grand nombre de points de données par défaut dans les tuiles 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 de limiter les données autant que possible en appliquant des filtres frontend 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.
• N'utilisez l'option Tous les résultats pour télécharger ou distribuer des requêtes qu'avec parcimonie, car certaines requêtes peuvent être très volumineuses et surcharger le serveur Looker lors du traitement.
• Comprendre l'impact des performances de la connexion sur l'ensemble de l'instance Looker. Looker utilise des ressources partagées pour traiter les requêtes de toutes les connexions à la 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 à une 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 à la base de données, et pas seulement celles qui sont directement liées aux tableaux de bord ou aux Explorations lents.

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