Trino¶

Fait partie du lakehouse (vue d'ensemble et schéma des interactions).

Le modèle Trino (catégorie Traitement) déploie un coordinateur et des workers Trino avec un catalogue lakehouse pré-câblé sur l'instance Apache Iceberg choisie.

Trino n'est pas une base de données : c'est un moteur SQL sans stockage. Trois rôles se partagent le travail — le catalogue Apache Iceberg sait quelles tables existent et quels fichiers les composent, le bucket S3 contient les données en Parquet, et Trino exécute le SQL en mémoire, réparti sur ses workers. D'où l'ordre de déploiement : le catalogue d'abord, Trino ensuite, dans le même namespace et sur le même bucket.

Options de déploiement¶

Champ	Rôle
Catalogue Apache Iceberg (Polaris) (requis)	Instance Apache Iceberg du même namespace. Fixé à la création.
Catalogue Iceberg (warehouse)	Nom du catalogue côté Polaris (`lakehouse` par défaut).
Bucket S3 du warehouse (onglet Stockage)	Le même bucket que celui du catalogue : sélectionnez-le pour remplir endpoint, région et clés.
Endpoint S3, Région S3, Access Key ID, Secret Access Key (onglet Stockage)	Remplis par le sélecteur de bucket, modifiables après coup — saisie manuelle pour un S3 externe. `us-east-1` par défaut pour la région.
Nombre de workers (onglet Capacité)	`1` par défaut.
Mémoire du coordinateur, Mémoire par worker (onglet Capacité)	`3Gi` chacune par défaut. Rester ≥ 3 Gi : le heap JVM est fixé à 1400M, le reste est du hors-heap — un OOM a été observé à 2 Gi sous charge.

Se connecter¶

La connexion se fait avec votre compte de la plateforme (OpenID Connect), et l'accès est accordé depuis Accès aux utilisateurs ou groupes voulus — voir Accès et permissions. Trois portes d'entrée :

L'interface web, https://<nom>-<namespace>.<domaine>/ui/ : une console de supervision — requêtes en cours et passées, état du cluster. Ce n'est pas un éditeur SQL, elle ne sert pas à écrire des requêtes ;
Un client SQL : trino --server https://… --external-authentication, qui ouvre le navigateur pour la connexion ; en JDBC avec externalAuthentication=true, pour DBeaver ou un outil de restitution tiers ;
Un notebook JupyterHub du même namespace : la variable TRINO_HOST y est déjà renseignée (nom:8080, accès interne au namespace), de quoi brancher trino-python-client sans sortir du cluster.

Interroger le lakehouse¶

CREATE SCHEMA lakehouse.ventes;
CREATE TABLE lakehouse.ventes.commandes AS SELECT 1 AS id, 'test' AS libelle;
SELECT * FROM lakehouse.ventes.commandes;

Les fichiers Parquet et les métadonnées Iceberg apparaissent dans le bucket sous <schéma>/<table>-<uuid>/.

C'est le même catalogue que Spark Connect, PyIceberg et les jobs Spark : une table écrite par un traitement Spark est lisible par Trino dans la foulée, et inversement. Une seule copie des données, plusieurs moteurs — c'est tout l'intérêt du lakehouse.

Ce que Trino ne fait pas ici¶

Pas de fédération de sources : un seul catalogue est configuré, lakehouse, sur l'instance Apache Iceberg choisie. Les catalogues de démonstration du chart amont (tpch, tpcds) sont retirés, et aucun connecteur vers une base applicative (PostgreSQL, MySQL…) n'est exposé dans le formulaire. Interroger une telle base depuis Trino demanderait d'ajouter un catalogue dans les valeurs du chart.
Pas de transformation lourde et longue : pour les traitements distribués coûteux, Spark Connect pour l'interactif et les jobs Spark pour le batch.

Premier démarrage

Comptez 3 à 4 minutes avant la première requête, le temps de démarrer la JVM et de charger les plugins. La carte passe en Running avant que Trino réponde.

Suppression¶

Supprimer une instance Trino retire aussi son client OpenID de la plateforme.