Déploiement d'Apache Superset 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.

Vue d'ensemble

Apache Superset est une plateforme de business intelligence open source qui offre l'exploration interactive de données, la visualisation et la création de tableaux de bord. Dans l'intégration Kubernetes d'ODP, Ambari déploie Superset 4.1.4 sur Kubernetes en utilisant le chart Helm officiel de Superset, connecté à vos services de données ODP (Trino, Hive, Impala) et sécurisé avec l'authentification OIDC.

Superset sur Kubernetes complète le reste de la pile ODP : vos données résident dans HDFS ou Ozone, gouvernées par Ranger et cataloguées par Atlas, interrogeables via Trino (sur Kubernetes) ou Hive et Impala (sur le cluster). Superset fournit la couche de visualisation par-dessus, sans duplication des données.

Chart Helm Superset géré par Ambari

Ambari déploie Superset via le chart Helm de Superset. Le déploiement inclut :

• Superset Web : le serveur d'application principal (1 ou plusieurs réplicas)
• Superset Worker : worker Celery pour le rendu asynchrone des graphiques et les alertes (1 ou plusieurs réplicas)
• Superset Beat : scheduler Celery pour les tâches périodiques
• Redis : cache en cluster et broker de messages pour Celery (déployé en tant que subchart)
• PostgreSQL : base de données de métadonnées interne de Superset — stocke les tableaux de bord, graphiques, utilisateurs et connexions (déployé en tant que subchart, ou vous pouvez pointer vers un PostgreSQL externe)

Tous ces composants sont créés et gérés par Ambari via le cycle de vie du chart Helm.

Déploiement de Superset depuis Ambari

Étape 1 : Prérequis — Déployer Trino d'abord

Superset se connecte aux données ODP via des moteurs SQL. Nous recommandons de déployer Trino sur Kubernetes en premier, car il offre la capacité de requêtes la plus large sur les tables Iceberg et Hive. Superset peut également se connecter directement à Hive et Impala via leurs interfaces JDBC/ODBC.

Étape 2 : Ouvrir la vue Kubernetes et sélectionner Superset

Dans Ambari, naviguez vers Views > Kubernetes Manager. Cliquez sur Deploy à côté d'Apache Superset.

É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	superset
Namespace	Namespace Kubernetes	odp-apps
Réplicas Web	Nombre de pods web Superset	1
Réplicas Worker	Nombre de pods worker Celery	1
CPU Request Web	Demande CPU par pod web	0.5
CPU Limit Web	Limite CPU par pod web	2
Memory Request Web	Mémoire par pod web	2Gi
Memory Limit Web	Mémoire par pod web	4Gi
Secret Key	Clé secrète Flask (auto-générée si vide)	auto

Onglet Base de données :

Paramètre	Description
Utiliser PostgreSQL embarqué	Déployer PostgreSQL en tant que subchart (recommandé pour l'évaluation)
Hôte PostgreSQL externe	Hôte d'une instance PostgreSQL externe
Port PostgreSQL externe	Port (par défaut : 5432)
Base de données PostgreSQL externe	Nom de la base de données (ex. superset)
Utilisateur PostgreSQL externe	Utilisateur de la base de données
Mot de passe PostgreSQL externe	Mot de passe de la base de données (stocké chiffré)

Pour la production, utilisez une instance PostgreSQL externe avec une configuration de sauvegarde et HA appropriée plutôt que le subchart embarqué.

Onglet Authentification (OIDC) :

Paramètre	Description
Méthode d'authentification	DATABASE (utilisateurs locaux) ou OIDC
URL du fournisseur OIDC	ex. https://keycloak.example.com/realms/myrealm
Client ID	ID client OIDC enregistré pour Superset
Secret client	Secret client OIDC (stocké chiffré)
Rôles autorisés	Rôles/groupes accordant l'accès à Superset
Rôles admin	Rôles/groupes accordant l'accès admin Superset

Onglet Ingress :

Paramètre	Description
Activer Ingress	Exposer Superset via Kubernetes Ingress
Nom d'hôte	ex. superset.example.com
Secret TLS	Nom du Secret Kubernetes TLS pour HTTPS
Classe Ingress	Classe du contrôleur Ingress (ex. nginx)

Étape 4 : Soumettre

Cliquez sur Deploy. Surveillez le déploiement dans Background Operations. L'initialisation de Superset (incluant les migrations de base de données) prend typiquement 3 à 8 minutes lors de la première installation.

Connexion de Superset aux sources de données ODP

Après le déploiement, configurez des connexions de base de données dans Superset pour que les utilisateurs puissent explorer les données ODP.

Connexion à Trino (recommandé)

Trino offre la couverture SQL la plus large pour les données ODP, incluant les tables Iceberg, et est la connexion recommandée pour Superset.

Dans Superset, naviguez vers Settings > Database Connections > + Database.

Sélectionnez Trino comme type de base de données et saisissez la chaîne de connexion SQLAlchemy :

trino://<user>@trino-coordinator.odp-apps.svc.cluster.local:8080/hive

Puisque Superset et Trino s'exécutent dans le même namespace Kubernetes, ils peuvent communiquer via le DNS interne Kubernetes sans exposer Trino à l'extérieur.

Paramètres de connexion :

Paramètre	Valeur
URI SQLAlchemy	trino://superset_svc@trino-coordinator.odp-apps.svc.cluster.local:8080/hive
Nom d'affichage	ODP - Trino (Iceberg/Hive)
Exposer dans SQL Lab	Activé
Autoriser DML	Désactivé (recommandé — Superset devrait être en lecture seule)

Avec Trino sécurisé par Kerberos, le compte de service Superset a besoin d'un principal Kerberos. Ambari provisionne ce keytab et configure automatiquement la connexion Superset-Trino pour l'utiliser lorsque OIDC n'est pas la seule méthode d'authentification.

Connexion à Hive via HiveServer2

Pour une connectivité Hive directe (pour les tables natives Hive non couvertes par Trino) :

hive://<hiveserver2-host>:10000/default

Avec Kerberos :

# Dans la config Superset (injectée par les valeurs Helm Ambari)
SQLALCHEMY_CUSTOM_PASSWORD_STORE = ...
# Chaîne de connexion avec paramètres Kerberos
hive://hiveserver2.example.com:10000/default?auth=KERBEROS&kerberos_service_name=hive

Connexion à Impala

impala://<impala-host>:21050/default

Avec Kerberos :

impala://impala.example.com:21050/default?auth_mechanism=GSSAPI&kerberos_service_name=impala

Authentification et gestion des utilisateurs

Authentification par base de données locale

Par défaut (lorsque OIDC n'est pas configuré), Superset utilise sa propre base de données d'utilisateurs interne. Les utilisateurs sont créés dans Settings > List Users.

Rôles dans Superset :

• Admin : accès complet à la plateforme, peut gérer les connexions et les utilisateurs
• Alpha : peut créer et modifier des graphiques et tableaux de bord
• Gamma : accès en lecture seule aux tableaux de bord accordés
• sql_lab : accès à SQL Lab pour les requêtes ad hoc
• Public : accès anonyme (si activé — non recommandé pour les environnements sécurisés)

Authentification OIDC

Lorsqu'Ambari déploie Superset avec OIDC configuré, il injecte les éléments suivants dans le superset_config.py de Superset :

from flask_appbuilder.security.manager import AUTH_OAUTH

AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
    {
        "name": "oidc",
        "icon": "fa-openid",
        "token_key": "access_token",
        "remote_app": {
            "client_id": "<client-id>",
            "client_secret": "<client-secret>",
            "api_base_url": "<provider-url>",
            "server_metadata_url": "<provider-url>/.well-known/openid-configuration",
            "client_kwargs": {"scope": "openid email profile groups"},
        },
    }
]
AUTH_USER_REGISTRATION = True
AUTH_USER_REGISTRATION_ROLE = "Gamma"

Le mapping groupe-rôle est également configurable, de sorte que les groupes LDAP/AD soient automatiquement mappés aux rôles Superset lors de la connexion.

Synchronisation avec LDAP

Superset peut être configuré pour s'authentifier directement contre LDAP (sans OIDC), en utilisant le même serveur LDAP configuré dans ODP. Lorsqu'Ambari déploie Superset, il peut injecter les paramètres LDAP depuis la configuration du cluster ODP (lus depuis la configuration LDAP stockée dans Ambari).

Création de tableaux de bord sur les données ODP

SQL Lab pour l'exploration

SQL Lab est l'éditeur SQL interactif de Superset. Utilisez-le pour explorer les données ODP avant de créer des graphiques :

1. Naviguez vers SQL Lab > SQL Editor.
2. Sélectionnez la base de données ODP - Trino et le schéma cible.
3. Écrivez et exécutez du SQL. Les résultats apparaissent en ligne.
4. Enregistrez une requête en tant que Dataset virtuel pour l'utiliser comme base d'un graphique.

Exemple : exploration de l'historique d'une table Iceberg via Trino :

SELECT
  committed_at,
  snapshot_id,
  operation,
  summary['added-records'] AS added_records,
  summary['deleted-records'] AS deleted_records
FROM hive.iceberg_demo."my_table$snapshots"
ORDER BY committed_at DESC
LIMIT 20;

Création de graphiques

1. Naviguez vers Charts > + Chart.
2. Sélectionnez un dataset (table physique ou dataset virtuel depuis SQL Lab).
3. Choisissez un type de graphique (Barres, Lignes, Tableau, Carte, etc.).
4. Configurez les dimensions, métriques et filtres.
5. Enregistrez le graphique.

Assemblage de tableaux de bord

1. Naviguez vers Dashboards > + Dashboard.
2. Glissez des graphiques depuis le sélecteur de graphiques sur la grille de mise en page.
3. Configurez des filtres qui s'appliquent à tous les graphiques du tableau de bord.
4. Définissez l'intervalle d'actualisation du tableau de bord si vous souhaitez une actualisation automatique pour les données quasi-temps-réel.
5. Publiez le tableau de bord et partagez-le avec les rôles Superset appropriés.

Recommandations de dimensionnement des ressources

Les recommandations de dimensionnement suivantes s'appliquent aux déploiements ODP typiques. Ajustez en fonction du nombre d'utilisateurs simultanés et de la complexité des tableaux de bord.

Scénario	Pods Web	Pods Worker	Mémoire Web	Mémoire Worker
Développement / Évaluation	1	1	2Gi	1Gi
Petite équipe (< 20 utilisateurs)	1	2	4Gi	2Gi
Équipe moyenne (20–100 utilisateurs)	2	2	4Gi	2Gi
Grande équipe (100+ utilisateurs)	3+	3+	8Gi	4Gi

PostgreSQL : allouez au minimum 5 Go de stockage persistant pour la base de données de métadonnées de Superset. Pour les équipes avec de nombreux graphiques et tableaux de bord sauvegardés, 20 à 50 Go est plus approprié.

Redis : la configuration par défaut du subchart (limite mémoire 256 Mo) est suffisante pour la plupart des déploiements. Augmentez si vous utilisez intensivement les fonctionnalités d'alertes et de rapports de Superset.

Mise à l'échelle horizontale

Les pods web Superset sont sans état (état de session dans Redis). L'ajout de réplicas web nécessite un Ingress Kubernetes ou un LoadBalancer avec sessions persistantes, ou un stockage de session adossé à Redis (configuré automatiquement par les valeurs Helm d'Ambari).

Supervision de Superset depuis Ambari

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

• Statut des pods : état des pods web, worker, beat, Redis et PostgreSQL
• Statut de la release Helm : révision actuelle et statut de réconciliation Flux
• Événements récents : événements Kubernetes pour les ressources Superset

Pour la supervision au niveau Superset, utilisez la section Superset > Logs intégrée pour voir l'historique d'exécution des requêtes et les erreurs.

Mise à niveau de Superset

Pour mettre à niveau vers une version plus récente de Superset :

1. Dans la vue Kubernetes, sélectionnez le déploiement Superset.
2. Cliquez sur Upgrade.
3. Examinez le diff de configuration.
4. Cliquez sur Confirm Upgrade.

Ambari exécute automatiquement les migrations de base de données dans le cadre de la mise à niveau (le chart Helm inclut un init container pour les migrations). Les tableaux de bord et graphiques existants sont préservés.

Si la mise à niveau échoue, utilisez Rollback dans la vue Kubernetes pour revenir à la révision Helm précédente.