Cloudera Impala 3.1 et versions ultérieures, et Cloudera Impala avec pilote natif

Dialectes utilisant ces instructions

Looker se connecte aux bases de données Impala suivantes :

  • Cloudera Impala 3.1 ou version ultérieure
  • Cloudera Impala 3.1 ou version ultérieure avec pilote natif
  • Cloudera Impala avec pilote natif

Chiffrement du trafic réseau

Il est recommandé de chiffrer le trafic réseau entre l'application Looker et votre base de données. Envisagez l'une des options décrites sur la page de documentation Activer l'accès sécurisé à la base de données.

Configurer Looker pour se connecter à Cloudera Impala

Looker se connecte aux bases de données via une connexion JDBC. Pour les bases de données Impala, Looker se connecte par défaut au serveur qui exécute le daemon impalad sur le port 21050. Pour en savoir plus, consultez la section Configure Impala to work with JDBC (Configurer Impala pour fonctionner avec JDBC) de la documentation sur le site Web de Cloudera.

Dans la section Administration de Looker, sélectionnez Connexions, puis cliquez sur Ajouter une connexion.

La configuration de la connexion Looker dépend du niveau de sécurité utilisé:

Se connecter à un cluster sans Kerberos ni authentification utilisateur

Pour configurer une connexion qui n'utilise pas Kerberos ni l'authentification utilisateur, procédez comme suit :

  1. Sur la page Connection Settings (Paramètres de connexion), laissez les champs Username (Nom d'utilisateur) et Password (Mot de passe) vides. (Le * à côté des noms de champ indique que ces champs sont obligatoires, mais ce n'est pas le cas.)
  2. Dans le champ Paramètres JDBC supplémentaires, saisissez ;auth=noSasl.

Vérifier la chaîne de connexion

Pour vérifier la chaîne de connexion JDBC dans les fichiers journaux, dans le panneau Administration de Looker, cliquez sur Journal dans le menu de gauche. Filtrez ensuite le journal sur un terme tel que jdbc ou noSasl. La ligne de journal peut se présenter comme suit :

jdbc connect using: jdbc:hive2://<HOSTNAME>/<DATABASE_NAME>;auth=noSasl

Pour en savoir plus sur la configuration des bases de données Impala afin qu'elles fonctionnent avec JDBC, consultez la documentation sur le site Web externe de Cloudera.

Se connecter à un cluster nécessitant une authentification LDAP

Pour un cluster nécessitant une authentification LDAP, y compris un cluster avec Apache Sentry et Kerberos, sur la page Paramètres de connexion, saisissez un nom d'utilisateur et un mot de passe ayant accès aux schémas auxquels Looker aura accès.

Se connecter à un cluster sécurisé avec Kerberos, mais sans Apache Sentry

L'équipe d'analystes Looker peut être amenée à vous aider à configurer correctement cette connexion.

En règle générale, l'authentification Kerberos avec les environnements Cloudera est gérée par Apache Sentry. Pour en savoir plus, consultez la documentation Cloudera.

Si vous souhaitez configurer Looker pour qu'il se connecte directement aux bases de données Impala à l'aide de l'authentification Kerberos, suivez les étapes décrites sur cette page.

Établir la configuration du client Kerberos

Tout d'abord, vous devez vous assurer que plusieurs logiciels sont installés et que plusieurs fichiers sont présents sur la machine Looker.

Client Kerberos

Vérifiez que le client Kerberos est installé sur la machine Looker en essayant d'exécuter kinit. Si le client Kerberos n'est pas installé, installez les binaires du client Kerberos.

Par exemple, sur Red Hat/CentOS, le code est le suivant:

sudo yum install krb5-workstation krb5-libs krb5-auth-dialog

Java 8

Java 8 doit être installé sur la machine Looker et dans les PATH et JAVA_HOME de l'utilisateur Looker. Si nécessaire, installez-le localement dans le répertoire looker.

Java Cryptography Extension

  1. Téléchargez et installez l'extension Java Cryptography (JCE) pour Java 8 sur le site Web d'Oracle.

    • Recherchez le répertoire jre/lib/security pour l'installation Java.
    • Supprimez les fichiers JAR suivants de ce répertoire: local_policy.jar et US_export_policy.jar.
    • Remplacez ces deux fichiers par les fichiers JAR inclus dans le téléchargement des fichiers de règles de juridiction de force illimitée JCE.

    Il est possible d'utiliser des versions antérieures à Java 8 avec le JCE installé, mais cela n'est pas recommandé.

  2. Mettez à jour JAVA_HOME et PATH dans ~looker/.bash_profile pour qu'ils pointent vers l'installation correcte de Java et source ~/.bash_profile, ou déconnectez-vous, puis reconnectez-vous.

  3. Vérifiez la version Java avec java -version.

  4. Vérifiez la variable d'environnement JAVA_HOME avec echo $JAVA_HOME.

gss-jaas.conf

Dans le répertoire looker, créez un fichier gss-jaas.conf avec le contenu suivant:

com.sun.security.jgss.initiate {
    com.sun.security.auth.module.Krb5LoginModule required
    useTicketCache=true
    doNotPrompt=true;
};

Si nécessaire pour les tests, debug=true peut être ajouté à ce fichier comme suit :

com.sun.security.jgss.initiate {
    com.sun.security.auth.module.Krb5LoginModule required
    useTicketCache=true
    doNotPrompt=true
    debug=true;
};
krb5.conf

Le serveur qui exécute Looker doit également disposer d'un fichier krb5.conf valide. Par défaut, ce fichier se trouve dans /etc/krb5.conf. Si elle se trouve à un autre emplacement, cela doit être indiqué dans l'environnement (KRB5_CONFIG dans l'environnement shell).

Vous devrez peut-être copier cet ID à partir d'une autre machine cliente Kerberos.

lookerstart.cfg

Pointez vers les fichiers gss-jaas.conf et krb5.conf en créant un fichier nommé lookerstart.cfg dans le répertoire looker (le même répertoire que celui contenant le script de démarrage looker) contenant les lignes suivantes :

  JAVAARGS="-Djava.security.auth.login.config=/path/to/gss-jaas.conf -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.krb5.conf=/etc/krb5.conf"
  LOOKERARGS=""

Si le fichier krb5.conf n'est pas à l'emplacement /etc/krb5.conf, vous devez également ajouter cette variable:

  -Djava.security.krb5.conf=/path/to/krb5.conf

Pour le débogage, ajoutez les variables suivantes:

  -Dsun.security.jgss.debug=true -Dsun.security.krb5.debug=true

Redémarrez ensuite Looker avec ./looker restart.

S'authentifier avec Kerberos

Authentification des utilisateurs

  1. Si krb5.conf ne se trouve pas dans /etc/, utilisez la variable d'environnement KRB5_CONFIG pour indiquer son emplacement.

  2. Exécutez la commande klist pour vous assurer qu'il existe un ticket valide dans le cache du ticket Kerberos.

  3. Si aucun ticket n'est créé, exécutez kinit username@REALM ou kinit username pour en créer un.

  4. Le compte utilisé avec Looker est probablement sans tête. Vous pouvez donc obtenir un fichier keytab à partir de Kerberos pour stocker les identifiants à long terme. Utilisez une commande telle que kinit -k -t looker_user.keytab username@REALM pour obtenir le ticket Kerberos.

Renouvellement automatique du billet

Configurez une job Cron qui s'exécute de temps en temps pour conserver un ticket actif dans le cache du ticket Kerberos. La fréquence d'exécution dépend de la configuration du cluster. klist devrait indiquer le délai d'expiration des billets.

Créer la connexion Looker à votre base de données

Dans la section Administration de Looker, sélectionnez Connexions, puis cliquez sur Ajouter une connexion.

Renseignez les informations de connexion comme suit (pour en savoir plus, consultez la page de documentation Connecter Looker à votre base de données) :

  • Nom : nom de la connexion. Il s'agit de la façon dont il sera fait référence à la connexion dans le modèle LookML.

  • Dialecte : Cloudera Impala 3.1 ou version ultérieure, Cloudera Impala 3.1 ou version ultérieure avec pilote natif ou Cloudera Impala avec pilote natif.

  • Hôte : nom d'hôte.

  • Port: port de base de données (21050 par défaut).

  • Base de données: schéma/base de données par défaut qui sera modélisé. Lorsqu'aucune base de données n'est spécifiée pour une table, c'est le cas.

  • Nom d'utilisateur : laissez ce champ vide.

  • Password (Mot de passe) : laissez ce champ vide.

  • Activer les PDT : utilisez cet interrupteur pour activer les tables dérivées persistantes. Lorsque les tables PDT sont activées, la fenêtre Connexion affiche des paramètres supplémentaires pour les tables PDT ainsi que la section Remplacements PDT.

  • Temp Database (Base de données temporaire) : schéma/base de données temporaire pour le stockage des tables PDT Vous devez le créer à l'avance.

  • Paramètres JDBC supplémentaires: paramètres supplémentaires pour la chaîne JDBC. Indiquez ici le compte principal Kerberos, par exemple ;principal=impala/impala.company.com@REALM. Les comptes principaux en trois parties sont standards. Le premier (impala) correspond généralement au nom du service, et le dernier (REALM) correspond généralement au domaine.

  • SSL : cochez cette case pour utiliser les connexions SSL. Si votre certificat SSL n'est pas émis par une autorité de certification largement reconnue et que vous utilisez un certificat personnalisé, vous devez :

    • Copiez le fichier de certificat sur le serveur Looker. Cette option n'est disponible que pour les déploiements Looker hébergés par un client.
    • Ajoutez les paramètres suivants au champ Paramètres JDBC supplémentaires :
  sslTrustStore=/path/to/your/trust_store.jks;trustStorePassword=yourpassword

Consultez la documentation Cloudera pour savoir comment créer les chaînes JDBC appropriées pour les bases de données Impala.

  • Database Time Zone (Fuseau horaire de la base de données) : fuseau horaire des données stockées dans votre base de données. Ce champ peut généralement être laissé vide ou défini sur UTC.

Il est recommandé d'utiliser le nom du serveur (impala.company.com dans cet exemple) comme nom canonique du serveur et d'obtenir ce nom en fonction de la résolution DNS inverse de son adresse IP. Toutefois, le nom du serveur doit correspondre à celui indiqué dans le contrôleur de domaine Kerberos :

  nslookup servername  # get canonical server name and IP address

  nslookup ipaddress  # get the canonical name back

Parfois, le nom du serveur correspond au nom d'hôte, et non au nom de domaine complet. Dans ce cas, vous devrez peut-être modifier les fichiers /etc/hosts et /etc/nsswitch.conf pour vous assurer que les recherches inverses sont résolues comme prévu.

Testez la connexion pour vous assurer qu'elle est correctement configurée.

Débogage

Ressources

Autorisations pour les PDT

L'utilisateur qui se connecte au schéma entièrement nouveau pour les tables dérivées persistantes (PDT) doit disposer d'autorisations de lecture/écriture.

Compatibilité des caractéristiques

Pour que Looker prenne en charge certaines fonctionnalités, votre dialecte de base de données doit également les prendre en charge.

Cloudera Impala avec Native Driver

Cloudera Impala avec pilote natif est compatible avec les fonctionnalités suivantes à partir de Looker 24.16 :

Caractéristique Compatibilité
Niveau d'assistance
Compatible
Looker (Google Cloud Core)
Non
Agrégations symétriques
Non
Tables dérivées
Oui
Tables dérivées SQL persistantes
Oui
Tables dérivées natives persistantes
Oui
Vues stables
Oui
Suppression des requêtes
Oui
Tableaux croisés dynamiques basés sur SQL
Oui
Fuseaux horaires
Oui
SSL
Oui
Sous-totaux
Non
Paramètres JDBC supplémentaires
Oui
Sensible à la casse
Oui
Type d'emplacement
Oui
Type de liste
Non
Centile
Non
Centile distinct
Non
Processus d'affichage de l'exécuteur SQL
Non
Table de description de SQL Runner
Oui
Index d'affichage de l'exécuteur SQL
Non
SQL Runner Select 10
Oui
Nombre d'exécuteurs SQL
Oui
Expliquer SQL
Oui
Identifiants Oauth
Non
Commentaires sur le contexte
Oui
Regroupement de connexions
Non
Résumés HLL
Non
Reconnaissance d'agrégats.
Oui
Augmentation de tables PDT
Non
Millisecondes
Oui
Microsecondes
Oui
Vues matérialisées
Non
Nombre approximatif distinct
Oui

Cloudera Impala 3.1 ou version ultérieure

Cloudera Impala 3.1+ prend en charge les fonctionnalités suivantes à partir de Looker 24.16:

Caractéristique Compatibilité
Niveau d'assistance
Compatible
Looker (Google Cloud Core)
Oui
Agrégations symétriques
Oui
Tables dérivées
Oui
Tables dérivées SQL persistantes
Oui
Tables dérivées natives persistantes
Oui
Vues stables
Oui
Suppression des requêtes
Oui
Tableaux croisés dynamiques basés sur SQL
Oui
Fuseaux horaires
Oui
SSL
Oui
Sous-totaux
Non
Paramètres JDBC supplémentaires
Oui
Sensible à la casse
Oui
Type d'emplacement
Oui
Type de liste
Non
Centile
Non
Centile distinct
Non
Processus d'affichage de l'exécuteur SQL
Non
Table de description de SQL Runner
Oui
Index d'affichage de l'exécuteur SQL
Non
SQL Runner Select 10
Oui
Nombre d'exécuteurs SQL
Oui
Expliquer SQL
Oui
Identifiants Oauth
Non
Commentaires sur le contexte
Oui
Regroupement de connexions
Non
Résumés HLL
Non
Reconnaissance d'agrégats.
Oui
Augmentation de tables PDT
Non
Millisecondes
Oui
Microsecondes
Oui
Vues matérialisées
Non
Nombre approximatif distinct
Oui

Cloudera Impala 3.1 et versions ultérieures avec pilote natif

Cloudera Impala 3.1 et versions ultérieures avec pilote natif sont compatibles avec les fonctionnalités suivantes à partir de Looker 24.16 :

Caractéristique Compatibilité
Niveau d'assistance
Compatible
Looker (Google Cloud Core)
Non
Agrégations symétriques
Oui
Tables dérivées
Oui
Tables dérivées SQL persistantes
Oui
Tables dérivées natives persistantes
Oui
Vues stables
Oui
Suppression des requêtes
Oui
Tableaux croisés dynamiques basés sur SQL
Oui
Fuseaux horaires
Oui
SSL
Oui
Sous-totaux
Non
Paramètres JDBC supplémentaires
Oui
Sensible à la casse
Oui
Type d'emplacement
Oui
Type de liste
Non
Centile
Non
Centile distinct
Non
Processus d'affichage de l'exécuteur SQL
Non
Table de description de SQL Runner
Oui
Index d'affichage de l'exécuteur SQL
Non
SQL Runner Select 10
Oui
Nombre d'exécuteurs SQL
Oui
Expliquer SQL
Oui
Identifiants Oauth
Non
Commentaires sur le contexte
Oui
Regroupement de connexions
Non
Résumés HLL
Non
Reconnaissance d'agrégats.
Oui
Augmentation de tables PDT
Non
Millisecondes
Oui
Microsecondes
Oui
Vues matérialisées
Non
Nombre approximatif distinct
Oui

Étapes suivantes

Une fois votre base de données connectée à Looker, configurez les options de connexion de vos utilisateurs.