home Guide de l’utilisateur Prise en main Centre d’assistance Documentation Communauté Formation Certification
menu
close
settings
Looker keyboard_arrow_down
language keyboard_arrow_down
English
Français
Deutsch
日本語
search
print
Looker documentation will be moving to cloud.google.com in mid-2022!
All the information you rely on will be migrated and all docs.looker.com URLs will be redirected to the appropriate page.
Connexion de Looker à votre base de données

Une fois que vous avez sécurisé et configuré votre base de données, vous pouvez la connecter à Looker.

Création d’une nouvelle connexion de base de données

Sélectionnez Connexions dans la section Base de données du panneau Admin. Depuis la page Connexions, cliquez sur le bouton Ajouter une connexion. Looker affiche la page Paramètres de connexion. Les champs affichés par la page des paramètres de connexion dépendent de la configuration de votre dialecte.

Pour plus d’informations sur l’application d’attributs utilisateur aux paramètres de connexion, consultez la section Connexions de la page Attributs utilisateur de la documentation.

Pour plus d’informations sur l’utilisation de la colonne PDT remplace en vue de configurer des identifiants de connexion distincts pour les processus PDT, consultez la section Configuration d’identifiants de connexion distincts pour les processus PDT.

À titre d’exemple, les options suivantes peuvent être configurées lorsque vous connectez Looker à Amazon Redshift.

Nom

Le nom de la connexion tel que vous souhaitez y faire référence. Vous ne devez utiliser le nom d’aucun dossier. Cette valeur ne doit pas nécessairement correspondre à un élément de votre base de données ; il s’agit simplement d’attribuer une étiquette. Vous l’utiliserez dans le paramètre connection de votre modèle LookML.

Dialect

Le dialecte SQL correspondant à votre connexion. Il est important de choisir la valeur appropriée afin que les options de connexion pertinentes vous soient présentées et que Looker puisse convertir correctement votre LookML en langage SQL.

Serveur SSH

L’option Serveur SSH est uniquement disponible si l’instance est déployée sur l’infrastructure Kubernetes et si la possibilité d’ajouter des informations de configuration d’un serveur SSH à votre instance Looker a été activée. Si cette option n’a pas été activée sur votre instance Looker et que vous souhaitez qu’elle le soit, contactez votre responsable de compte Looker ou ouvrez une demande d’assistance dans le Centre d’assistance de Looker.

Le serveur SSH choisit automatiquement le port localhost pour vous et il est actuellement impossible de spécifier le port localhost. Si vous devez créer une connexion SSH pour laquelle vous devez spécifier un port localhost, contactez votre responsable de compte Looker ou ouvrez une demande d’assistance dans le Centre d’assistance de Looker.

Pour connecter votre base de données en utilisant un tunnel SSH, activez l’option et sélectionnez une configuration de serveur SSH dans la liste déroulante.

Remote Host:Port

Le nom d’hôte de votre base de données et le port que Looker doit utiliser pour se connecter à l’hôte de votre base de données.

Si vous avez travaillé avec un analyste Looker pour configurer un tunnel SSH avec Looker pour votre base de données, dans le champ Host, saisissez "localhost" et, dans le champ Port, saisissez le numéro de port qui redirige vers votre base de données, fourni normalement par votre analyste Looker.

Si vous appliquez un attribut utilisateur au champ Host, le niveau d’accès utilisateur ne peut pas être paramétré sur Editable.

Si vous avez configuré un tunnel SSH pour connecter votre base de données, vous ne pouvez appliquer un attribut utilisateur dans le champ Remote Host:Port.

Base de données

Le nom de la base de données de votre hôte. Par exemple, vous pouvez avoir un nom d’hôte tel que my-instance.us-east-1.redshift.amazonaws.com dans lequel se trouve une base de données nommée sales_info. Dans ce cas, vous devez saisir sales_info dans ce champ. Si vous avez plusieurs bases de données sur le même hôte, vous devrez peut-être créer plusieurs connexions pour les utiliser (à l’exception des bases de données MySQL, dans lesquelles le terme base de données a une signification légèrement différente de celle de la plupart des dialectes SQL).

Use OAuth

Pour les connexions à Snowflake et à Google BigQuery, vous pouvez utiliser OAuth. Il en résulte que les utilisateurs doivent se connecter à Snowflake ou à Google, respectivement, pour émettre des requêtes à partir de Looker.

Lorsque vous sélectionnez Use OAuth, les champs OAuth Client ID et OAuth Client Secret s’affichent :

Ces valeurs sont générées par la base de données Snowflake ou par Google. Pour découvrir la procédure complète, consultez la page de la documentation qui décrit la configuration OAuth de Snowflake ou la configuration OAuth de Google BigQuery.

Username

Le nom d’utilisateur que Looker doit utiliser pour se connecter à votre base de données. Vous devez configurer l’utilisateur à l’avance conformément à nos instructions pour la configuration de la base de données.

Mot de passe

Le mot de passe que Looker doit utiliser pour se connecter à votre base de données. Vous devez configurer le mot de passe à l’avance conformément à nos instructions pour la configuration de la base de données.

Schema

Le schéma par défaut que Looker utilise lorsqu’aucun schéma n’est indiqué. Cela s’applique lorsque vous utilisez SQL Runner, au cours de la génération d’un projet LookML et que vous interrogez des tables.

Tables dérivées persistantes

Cochez cette case pour activer les tables dérivées persistantes. Cela déploie les champs PDT supplémentaires et la colonne PDT Overrides. Looker affiche cette option seulement lorsque le dialecte de base de données prend en charge l’utilisation des tables PDT.

Remarques à propos des PDT :

Temp Database

Bien que cet élément soit libellé Temp Database, vous saisirez soit le nom de la base de données, soit le nom du schéma — en fonction de votre dialecte SQL — que Looker doit utiliser pour créer des tables dérivées persistantes. Vous devez configurer cette base de données ou ce schéma à l’avance en utilisant les autorisations en écriture appropriées. Sur la page Instructions pour la configuration de la base de données de la documentation, sélectionnez le dialecte de votre base de données afin d’afficher les instructions associées à ce dialecte.

Chaque connexion doit avoir sa propre base de données temporaire ou son propre schéma ; ceux-ci ne peuvent pas être partagés sur toutes les connexions.

Max de connexions du générateur de PDT

Le paramètre Max de connexions du générateur de PDT vous permet d’indiquer le nombre de créations de tables simultanées que le régénérateur Looker peut lancer sur votre connexion de base de données. Le paramètre Max de connexions du générateur de PDT s’applique uniquement aux types de tables pour lesquels le régénérateur Looker lance des reconstructions :

Le paramètre Max PDT Builder Connections est défini par défaut sur 1, mais peut être augmenté jusqu’à 10. Toutefois, la valeur ne peut pas être supérieure à celle définie dans le champ Max Connections ou dans le champ per-user-query-limit défini dans les options de démarrage de Looker.

Vous devez configurer cette valeur attentivement. Si cette valeur est trop élevée, vous risquez de submerger votre base de données. Si cette valeur est faible, les tables PDT ou agrégées de grande taille peuvent retarder la création d’autres tables persistantes ou ralentir les autres requêtes sur la connexion. Les bases de données qui prennent en charge les environnements multi-tenant, telles que BigQuery, Snowflake et Redshift, peuvent gagner en performances lors de la gestion de créations de requêtes en parallèle.

Si vous souhaitez augmenter le paramètre Max PDT Builder Connections, nous vous recommandons de le faire par incrément de 1. En cas de comportement inattendu, revenez à la valeur par défaut, 1. Sinon, si la performance des requêtes n’est pas affectée, vous pouvez continuer à l’augmenter par incrément de 1, en vérifiant la performance à chaque fois avant de poursuivre.

Remarques à propos du paramètre Max PDT Builder Connections :

Always Retry Failed PDT Builds

Le paramètre Always Retry Failed PDT Builds détermine comment le régénérateur Looker tente de régénérer les tables persistantes à déclenchement dont la génération a échoué lors du cycle précédent. Le régénérateur Looker régénère les tables persistantes à déclenchement (tables PDT et tables agrégées) selon l’intervalle configuré dans le paramètre de connexion Planification du suivi des tables PDT et des groupes de données. Si le paramètre Toujours réessayer les générations de PDT est activé, le régénérateur Looker tentera de régénérer les tables PDT ayant échoué lors du cycle précédent, même si la condition de déclenchement n’est pas satisfaite. Lorsque ce paramètre est désactivé, le régénérateur Looker tentera de régénérer une table PDT dont la génération a échoué uniquement lorsque la condition de déclenchement de la table PDT est satisfaite. L’option Toujours réessayer les générations de PDT est désactivée par défaut.

Consultez la page Tables dérivées dans Looker de la documentation pour en savoir plus sur le régénérateur Looker.

Activer la commande API PDT

Le paramètre Activer la commande API PDT détermine si start_pdt_build, check_pdt_build, et stop_pdt_build appels d’API peuvent être utilisés pour cette connexion. Lorsque ce paramètre est désactivé, ces appels d’API échoueront lorsqu’ils font référence aux PDT sur cette connexion. L’élément Activer la commande API PDT est désactivé par défaut.

Additional Params

Vous pouvez ajouter des paramètres Java Database Connectivity (JDBC) supplémentaires à cet endroit, le cas échéant.

Si vous souhaitez utiliser un attribut utilisateur dans un paramètre JDBC, vous pouvez utiliser la fonction de création de modèles Liquid. La syntaxe est _user_attributes['name_of_your_user_attribute']. Par exemple :

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

Voici un exemple de syntaxe saisie dans le champ Additional Params de Looker :

Planification du suivi des tables PDT et des groupes de données

Cette configuration accepte une expression cron qui indique à quel moment le régénérateur Looker doit vérifier les groupes de données et les tables persistantes (les tables agrégées et les tables persistantes basées sur sql_trigger_value) et décider des tables à régénérer ou à supprimer.

La valeur par défaut de */5 * * * * signifie « vérifier toutes les 5 minutes », ce qui correspond à la fréquence de vérification maximale. Si une expression cron indique une fréquence de vérification plus élevée, les vérifications surviendront toutes les 5 minutes.

Pendant la création de tables PDT, Looker n’effectue aucune autre vérification de déclencheurs. Lorsque toutes les tables PDT depuis la dernière vérification de déclencheurs sont créées, Looker reprendra la vérification des déclencheurs des groupes de données et des tables PDT selon la planification du suivi des tables PDT et des groupes de données.

Si votre base de données n’est pas active 24 h/24 et 7 j/7, vous souhaiterez peut-être limiter les vérifications aux moments d’activité de votre base de données. Voici des expressions cron supplémentaires :

expression cron Définition
*/5 8-17 * * MON-FRI Vérifier les groupes de données et les tables PDT toutes les 5 minutes pendant les heures de travail, du lundi au vendredi
*/5 8-17 * * * Vérifier les groupes de données et les tables PDT toutes les 5 minutes pendant les heures de travail, au quotidien
0 8-17 * * MON-FRI Vérifier les groupes de données et les tables PDT toutes les heures pendant les heures de travail, du lundi au vendredi
1 3 * * * Vérifier les groupes de données et les tables PDT tous les jours à 3 h 01

Quelques points à prendre en compte lorsque vous créez une expression cron :

Voici quelques ressources qui vous aideront à créer des chaînes cron :

SSL

Choisissez si vous souhaitez, ou non, utiliser le chiffrement SSL pour protéger vos données pendant leur transition entre Looker et votre base de données. Le chiffrement SSL n’est qu’une option parmi tant d’autres pour protéger vos données ; d’autres options sécurisées sont décrites sur la page Sécurisation de l’accès à la base de données de la documentation.

Verify SSL Cert

Choisissez si vous souhaitez demander une vérification du certificat SSL utilisé par la connexion. Si la vérification est requise, l’autorité de certification (AC) SSL qui a signé le certificat SSL doit provenir de la liste des sources fiables du client. Si l’AC n’est pas une source fiable, la connexion de base de données n’est pas établie.

Si cette case n’est pas cochée, le chiffrement SSL est toujours utilisé sur la connexion, mais la vérification de la connexion SSL n’est pas requise. De fait, une connexion peut être établie lorsque l’AC ne figure pas sur la liste des sources fiables du client.

Max Connections

Ici, vous pouvez configurer le nombre maximal de connexions que Looker peut établir avec votre base de données. Dans la majorité des cas, vous configurez le nombre de requêtes simultanées que Looker peut exécuter sur votre base de données. Looker consacre également jusqu’à trois connexions à la suppression des requêtes. Si le pool de connexions est de taille très restreinte, Looker consacrera moins de connexions.

Vous devez configurer cette valeur attentivement. Si cette valeur est trop élevée, vous risquez de submerger votre base de données. Si cette valeur est trop faible, les requêtes devront partager une petite quantité de connexions. Chaque requête devant attendre le retour des autres requêtes précédemment exécutées, il se peut donc que de nombreuses requêtes semblent lentes aux utilisateurs.

La valeur par défaut (qui varie en fonction de votre dialecte SQL) constitue généralement un point de départ raisonnable. Pour ce qui est du nombre maximal de connexions qu’elles acceptent, la plupart des bases de données disposent également de leur propre configuration. Si la configuration de votre base de données limite les connexions, veillez à ce que votre valeur Max Connections soit inférieure ou égale à la limite de votre base de données.

Connection Pool Timeout

Si vos utilisateurs demandent davantage de connexions que la valeur Max Connections configurée, les requêtes devront attendre la fin des requêtes précédentes avant de pouvoir s’exécuter. Le temps d’attente maximal d’une requête se configure à cet endroit. Vous devez configurer cette valeur attentivement. S’il est trop faible, il se peut que les utilisateurs voient leurs requêtes annulées, car les requêtes des autres utilisateurs n’auront pas eu le temps de s’achever. S’il est trop élevé, il se peut qu’une grande quantité de requêtes s’accumulent et que le temps d’attente soit très long pour les utilisateurs. La valeur par défaut constitue généralement un point de départ raisonnable.

Estimation des coûts

La case Estimation des coûts s’applique aux connexions Snowflake et Amazon Redshift uniquement. Cette option active les estimations de coûts pour les requêtes d’exploration et les requêtes SQL Runner sur la connexion.

Les connexions BigQuery prennent également en charge la fonction d’estimation de coûts, mais la fonctionnalité est toujours activée, ainsi il n’y a pas de case Estimation des coûts pour les connexions BigQuery.

Consultez la page Exploration de données dans Looker de la documentation pour en savoir plus.

SQL Runner Precache

Dans SQL Runner, toutes les informations de la table sont préchargées dès que vous sélectionnez une connexion et un schéma. Cela permet à SQL Runner d’afficher les colonnes de la table rapidement dès que vous cliquez sur un nom de table. Néanmoins, pour les connexions et les schémas comportant de nombreuses tables ou des tables très volumineuses, il se peut que vous ne souhaitiez pas que SQL Runner précharge l’ensemble des informations.

Si vous préférez que SQL Runner charge les informations de la table seulement lorsqu’une table est sélectionnée, vous pouvez désélectionner l’option SQL Runner Precache afin de désactiver le chargement de SQL Runner pour la connexion.

Télécharger un schéma d’informations pour l’écriture SQL

Pour certaines fonctionnalités d’écriture SQL telles que la reconnaissance d’agrégats, Looker utilise le schéma d’informations de votre base de données pour optimiser l’écriture SQL. Si le schéma d’informations n’est pas mis en cache, Looker peut être amené à bloquer l’écriture SQL sur la base de données afin de télécharger le schéma d’informations. Pour les dialectes qui utilisent Hadoop Distributed File System (HDFS), le téléchargement du schéma d’informations peut prendre un temps suffisamment long pour affecter la performance de vos requêtes Looker. Si vous savez que votre schéma d’informations est lent, vous pouvez désactiver l’option Télécharger un schéma d’informations pour l’écriture SQL pour votre connexion. La désactivation de cette fonctionnalité empêchera une partie de l’optimisation SQL de Looker pour certaines fonctionnalités, vous devriez donc activer l’option Télécharger un schéma d’informations pour l’écriture SQL sauf si vous savez que le schéma d’informations de votre connexion est particulièrement lent.

Désactiver le commentaire de contexte

L’option Désactiver le commentaire de contexte s’applique uniquement aux connexions BigQuery. Les commentaires de contexte sur les connexions BigQuery sont désactivés par défaut car ils annulent la capacité de Google BigQuery à effectuer les mises en cache et ont un impact négatif sur la performance des caches. Vous pouvez activer les commentaires de contexte pour une connexion BigQuery en désélectionnant le paramètre Désactiver le commentaire de contexte sur la page Paramètres de connexion de la documentation pour la connexion. Pour en savoir plus, consultez la page Google BigQuery de la documentation.

Database Time Zone

Le fuseau horaire dans lequel votre base de données stocke les informations temporelles. Looker doit connaître cette information afin de convertir les valeurs de date/heure pour les utilisateurs et ainsi simplifier la compréhension et l’utilisation des données temporelles. Pour plus d’informations, consultez la page Using Time Zone Settings de la documentation.

Query Time Zone

L’option Query Time Zone est visible seulement si vous avez désactivé la fonctionnalité User Specific Time Zones.

Lorsque la fonctionnalité User Specific Time Zones est désactivée, la valeur Query Time Zone correspond au fuseau horaire qui s’affiche à vos utilisateurs lorsqu’ils interrogent des données temporelles, ainsi qu’au fuseau horaire dans lequel Looker convertira les données temporelles à partir de la valeur Database Time Zone.

Pour plus d’informations, consultez la page Using Time Zone Settings de la documentation.

Configuration d’identifiants de connexion distincts pour les processus PDT

Si votre base de données prend en charge les tables dérivées persistantes et que vous avez coché la case Tables dérivées persistantes dans les paramètres de connexion, Looker affiche la colonne PDT remplace. Dans la colonne PDT Overrides, vous pouvez saisir des paramètres JDBC distincts (host, port, database, username, password, schema et additional parameters) qui sont spécifiques aux processus PDT. Cette possibilité est précieuse pour plusieurs raisons :

Par exemple, la configuration suivante illustre une connexion dans laquelle les champs « username » et « password » sont définis avec des attributs utilisateur. Chaque utilisateur peut ainsi accéder à la base de données avec ses propres identifiants. La colonne PDT Override crée un utilisateur distinct (pdt_user) possédant son propre mot de passe. Le compte pdt_user sera utilisé pour l’ensemble des processus PDT, avec des niveaux d’accès adaptés à la création et à la mise à jour de tables PDT :

Si la colonne PDT remplace vous permet de modifier l’utilisateur de la base de données ainsi que d’autres propriétés de connexion, un remplacement PDT doit lire les mêmes données que la connexion par défaut et écrire les données dans le même emplacement. Looker ne peut pas lire les données à partir d’un emplacement et les écrire dans un autre.

Test de vos paramètres de connexion

Une fois que vous avez saisi les identifiants, cliquez sur Tester ces paramètres afin de vérifier que les informations sont correctes et que la base de données est en mesure de se connecter.

Si votre connexion ne réussit pas un ou plusieurs tests :

Les connexions à une base de données utilisant OAuth, comme Snowflake et Google BigQuery, exigent que l’utilisateur se connecte. Si vous n’êtes pas connecté à votre compte utilisateur OAuth lorsque vous testez l’une de ces connexions, Looker émet un avertissement accompagné du lien Se connecter. Cliquez sur le lien pour saisir vos identifiants OAuth ou pour autoriser Looker à accéder à vos informations de compte OAuth.

Si vous rencontrez encore des difficultés, contactez le support Looker pour obtenir de l’aide.

Ajout de votre connexion de base de données

Une fois que vous avez configuré et testé les paramètres de votre connexion de base de données, cliquez sur Ajouter une connexion. Votre connexion de base de données figure désormais sur la liste de la page Connexions.

Étapes suivantes

Après avoir connecté votre base de données à Looker, vous pouvez configurer des options de connexion pour vos utilisateurs.

Top