Déploiement de Trino sur Kubernetes via Ambari

Tech Preview — ODP 1.3.2.0

Cette fonctionnalité sera incluse dans ODP 1.3.2.0 en Tech Preview, actuellement en phase de qualification. Elle est disponible pour les tests entreprise en accès anticipé.

Intéressé par un accès anticipé ? Contactez notre équipe pour rejoindre le programme d'accès anticipé entreprise.

Pourquoi Trino sur Kubernetes

Trino est un moteur de requêtes SQL distribué conçu pour l'analytique interactive à grande échelle. Bien qu'ODP inclue Hive et Impala pour les charges de travail SQL sur le cluster, Trino sur Kubernetes répond à un ensemble distinct de besoins :

Mise à l'échelle élastique : Kubernetes facilite la mise à l'échelle horizontale des workers Trino en fonction de la charge de requêtes. Vous pouvez exécuter 2 workers en dehors des heures de pointe et 20 lors des pics de charges analytiques, sans provisionner de nœuds de cluster dédiés.

Isolation des charges de travail : Trino s'exécute dans des conteneurs séparés des nœuds du cluster Hadoop, empêchant les requêtes analytiques lourdes de concurrencer les jobs YARN pour les ressources sur les mêmes machines.

Fédération : Trino peut interroger des données provenant de plusieurs sources simultanément — tables Iceberg dans HDFS, bases de données PostgreSQL, topics Kafka — dans une seule requête. Cette capacité de fédération en fait un hub naturel pour l'analytique exploratoire sur des données hétérogènes.

Intégration Superset : Apache Superset, également déployable via Ambari, se connecte à Trino via JDBC. Exécuter Trino et Superset sur Kubernetes et les connecter aux données ODP crée une pile BI complète, native conteneurs, adossée à un stockage Hadoop gouverné.

Chart Helm Trino géré par Ambari

Ambari déploie Trino en utilisant le chart Helm officiel de Trino, avec des valeurs générées à partir de la configuration du cluster ODP. Le chart crée :

• Coordinateur Trino : 1 pod (configurable) — reçoit les requêtes, planifie l'exécution, gère les workers
• Workers Trino : N pods (configurable) — exécutent les fragments de requêtes en parallèle
• ConfigMaps : config.properties, jvm.config, log.properties, node.properties pour le coordinateur et les workers
• Secrets : keytab Kerberos, configuration du plugin Ranger, certificats TLS (si configurés)
• Service : service ClusterIP pour l'accès interne ; optionnellement un LoadBalancer ou Ingress pour l'accès JDBC externe

Déploiement de Trino depuis Ambari

Étape 1 : Ouvrir la vue Kubernetes

Dans Ambari, naviguez vers Views > Kubernetes Manager (ou le nom que vous avez donné à votre instance de vue). Le catalogue d'applications apparaît.

Étape 2 : Sélectionner Trino et cliquer sur Déployer

Cliquez sur Deploy à côté de Trino. L'assistant de configuration s'ouvre.

Étape 3 : Configurer le déploiement

Onglet Général :

Paramètre	Description	Par défaut
Nom de la release Helm	Nom de la release Helm	trino
Namespace	Namespace Kubernetes	odp-apps
Réplicas coordinateur	Nombre de pods coordinateurs	1
Réplicas workers	Nombre de pods workers	3
CPU Request worker	Demande CPU par worker	2
CPU Limit worker	Limite CPU par worker	4
Memory Request worker	Demande mémoire par worker	8Gi
Memory Limit worker	Limite mémoire par worker	16Gi
Mémoire coordinateur	Mémoire pour le pod coordinateur	4Gi

Onglet Connectivité (pré-rempli depuis le cluster ODP) :

Paramètre	Source	Exemple
URI Hive Metastore	Config Hive dans Ambari	thrift://master02.example.com:9083,thrift://master03.example.com:9083
FS HDFS par défaut	Config HDFS dans Ambari	hdfs://mycluster
URL REST Ranger	Config Ranger dans Ambari	https://master01.example.com:6182

Onglet Sécurité :

Paramètre	Description
Principal Kerberos	Principal de service pour Trino (ex. trino/k8s-worker.example.com@REALM)
Keytab	Généré par Ambari depuis le KDC du cluster
Realm Kerberos	Pré-rempli depuis la config Kerberos du cluster
Adresse KDC	Pré-remplie depuis la config Kerberos du cluster

Étape 4 : Soumettre

Cliquez sur Deploy. Ambari crée une opération en arrière-plan. Surveillez la progression dans Background Operations. Un déploiement Trino typique prend 2 à 5 minutes.

Détails de configuration Trino

config.properties du coordinateur

Ambari génère la configuration de coordinateur suivante (abrégée) :

coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8080
query.max-memory=50GB
query.max-memory-per-node=1GB
discovery.uri=http://trino-coordinator:8080

config.properties du worker

coordinator=false
http-server.http.port=8080
discovery.uri=http://trino-coordinator:8080

Connexion de Trino à Iceberg via le Hive Metastore

Ambari configure le catalogue Hive pour Trino avec la prise en charge Iceberg :

# /etc/trino/catalog/hive.properties (à l'intérieur du conteneur)
connector.name=iceberg
hive.metastore.uri=thrift://master02.example.com:9083,thrift://master03.example.com:9083
hive.metastore.authentication.type=KERBEROS
hive.metastore.service.principal=hive/_HOST@REALM.EXAMPLE.COM
hive.metastore.client.principal=trino/k8s-worker.example.com@REALM.EXAMPLE.COM
hive.metastore.client.keytab=/etc/trino/keytabs/trino.keytab
hive.config.resources=/etc/trino/conf/core-site.xml,/etc/trino/conf/hdfs-site.xml
iceberg.file-format=PARQUET

Les fichiers core-site.xml et hdfs-site.xml sont générés par Ambari à partir de la configuration HDFS actuelle et montés en tant que ConfigMaps.

Authentification Kerberos pour Trino

Trino utilise le keytab de service provisionné par Ambari pour s'authentifier auprès de :

• Hive Metastore : pour résoudre les emplacements et schémas des tables
• HDFS : pour lire les fichiers de données directement (pour les tables stockées dans HDFS/Ozone)
• API REST Ranger : pour récupérer les politiques d'autorisation

Le keytab est stocké en tant que Secret Kubernetes :

apiVersion: v1
kind: Secret
metadata:
  name: trino-kerberos-keytab
  namespace: odp-apps
type: Opaque
data:
  trino.keytab: <keytab encodé en base64>

Et monté dans tous les pods Trino à /etc/trino/keytabs/trino.keytab.

Autorisation Ranger pour Trino

Ambari configure le plugin Ranger pour Trino au moment du déploiement. Le plugin intercepte chaque requête Trino et l'évalue par rapport aux politiques Ranger avant l'exécution.

Fonctionnement

1. Un utilisateur soumet une requête via JDBC ou le CLI Trino.
2. Le coordinateur Trino transfère la demande d'autorisation au plugin Ranger.
3. Le plugin interroge l'API REST de Ranger avec l'identité de l'utilisateur, la ressource (catalog/schéma/table/colonne) et l'action (SELECT, INSERT, etc.).
4. Ranger évalue les politiques applicables (basées sur les ressources et les tags).
5. Si l'accès est refusé, Trino retourne une erreur d'autorisation. S'il est autorisé, la requête se poursuit.

Définition du service Ranger pour Trino

Dans Ranger, Trino apparaît comme un service de type Trino (ou Presto). Créez un service Trino dans Ranger pointant vers le coordinateur Trino :

Nom du service : trino_k8s
URL Trino : http://trino-coordinator.odp-apps.svc.cluster.local:8080
Nom d'utilisateur : ranger_trino_lookup
Mot de passe : <mot de passe>

Des politiques sont ensuite créées dans ce service pour contrôler l'accès aux catalogues, schémas et tables Trino.

Relation avec les politiques Hive Ranger

Les utilisateurs pouvant accéder à une table Hive via Ranger n'obtiennent pas automatiquement l'accès à la même table via Trino. Trino et Hive sont des services Ranger distincts. Vous devez accorder l'accès dans les deux services, ou utiliser les politiques basées sur les tags Ranger pour accorder l'accès via les tags Atlas, qui s'appliquent à tous les services.

Politiques basées sur les tags pour la cohérence

Pour éviter de maintenir des politiques dupliquées pour Hive et Trino, utilisez Atlas pour tagger vos tables sensibles (ex. PII, RESTRICTED) et créez des politiques basées sur les tags dans Ranger qui s'appliquent à tous les services. Cela garantit un contrôle d'accès cohérent quel que soit le moteur par lequel un utilisateur interroge les données.

Accès à Trino

JDBC

Le driver JDBC Trino se connecte au service coordinateur. Le format de l'URL de connexion :

jdbc:trino://<trino-coordinator-host>:<port>/<catalog>/<schema>

Si Trino est exposé via un LoadBalancer ou NodePort Kubernetes :

jdbc:trino://trino.example.com:8080/hive/default

Avec l'authentification Kerberos (depuis un client avec un ticket Kerberos valide) :

jdbc:trino://trino.example.com:8080/hive/default?KerberosRemoteServiceName=trino&KerberosPrincipal=user@REALM.EXAMPLE.COM&KerberosConfigPath=/etc/krb5.conf&KerberosKeytabPath=/home/user/user.keytab&SSL=true&SSLTrustStorePath=/etc/ssl/certs/truststore.jks

CLI Trino

trino \
  --server https://trino.example.com:8080 \
  --krb5-remote-service-name trino \
  --krb5-principal user@REALM.EXAMPLE.COM \
  --krb5-config-path /etc/krb5.conf \
  --catalog hive \
  --schema default

Vérification de l'accès aux données ODP

Une fois connecté, vérifiez que les tables Iceberg sur ODP sont accessibles :

-- Lister les schémas disponibles
SHOW SCHEMAS FROM hive;

-- Interroger une table Iceberg
SELECT * FROM hive.iceberg_demo.my_table LIMIT 10;

-- Consulter l'historique de la table Iceberg depuis la vue Trino
SELECT * FROM hive.iceberg_demo."my_table$snapshots";

Supervision de Trino depuis Ambari

La vue Kubernetes affiche les informations suivantes pour le déploiement Trino :

• Statut des pods : état des pods coordinateur et worker (Running, Pending, CrashLoopBackOff)
• Nombre de réplicas : nombre de workers réels vs désiré
• Statut de la release Helm : révision actuelle et statut de réconciliation Flux
• Événements récents : événements Kubernetes pour le namespace Trino

Pour une supervision Trino plus approfondie, accédez à l'interface web Trino à http://<trino-coordinator>:8080. Elle affiche :

• Les requêtes actives et en attente
• Le statut des nœuds workers et l'utilisation des ressources
• Les plans d'exécution des requêtes et les détails des étapes

Mise à l'échelle des workers

Pour ajuster le nombre de workers Trino après le déploiement initial :

1. Dans la vue Kubernetes, sélectionnez le déploiement Trino.
2. Cliquez sur Configure.
3. Mettez à jour le champ Worker Replicas.
4. Cliquez sur Upgrade. Ambari effectue un helm upgrade avec la nouvelle valeur.

Kubernetes met à l'échelle le Deployment de workers vers le nouveau nombre de réplicas. Les requêtes existantes continuent de s'exécuter sur les workers actuels ; les nouveaux workers deviennent disponibles pour les nouvelles requêtes en une à deux minutes.