Auto-héberger Saiku

Saiku fournit un build auto-hébergé sous Apache 2.0 + EPL — le même build que nous faisons tourner dans Saiku Cloud. Chaque fonctionnalité présente dans le dépôt OSS est dans le binaire auto-hébergé. Pas de SKU enterprise, pas de niveau MCP restreint, pas de connecteur Excel réservé au Cloud.

Le compromis, c’est la responsabilité opérationnelle : vous faites tourner la machine, vous gérez les mises à jour, vous êtes propriétaire des sauvegardes. Cette section est le manuel opérateur actuel.

Vous l'essayez d'abord ?

Pour un coup d’œil de cinq minutes, lancez docker run -e SAIKU_DEMO=true ghcr.io/spiculedata/saiku:latest et connectez-vous avec admin/admin, ou allez sur la démo en ligne. Le mode démo est ce qui active la connexion admin/admin intégrée ; un démarrage normal refuse le mot de passe par défaut (voir Premier démarrage). La démo fait tourner la même image.

Quel build récupérer

Distribution	Quand l’utiliser
ghcr.io/spiculedata/saiku:development	Suit la branche development — les nouvelles fonctionnalités atterrissent ici en premier. Idéal pour l’évaluation et les déploiements non critiques.
ghcr.io/spiculedata/saiku:4.6.2 (épinglé à une version)	Pointe vers un tag immuable. Recommandé pour tout ce qui tourne en production.
saiku-dist-<version>.zip depuis les Releases	Fat-JAR exécutable Java 21 + wrappers run.sh/run.bat. Pour les équipes qui ne font pas tourner Docker.

Tout ce qui suit suppose l’image Docker ; le flux fat-JAR utilise les mêmes variables d’environnement + les mêmes montages de volume, moins le conteneur.

Premier démarrage

1. Récupérez l’image et démarrez-la avec un volume saiku-home persistant et un mot de passe administrateur. Saiku refuse de servir tant que les identifiants admin/admin par défaut sont inchangés, alors définissez votre mot de passe dès le tout premier démarrage avec SAIKU_ADMIN_PASSWORD :

   docker volume create saiku-home
   docker run -d --name saiku \
     --restart unless-stopped \
     -p 8080:8080 \
     -v saiku-home:/app/saiku-home \
     -e SAIKU_HOME=/app/saiku-home \
     -e SAIKU_ADMIN_PASSWORD='a-strong-password' \
     ghcr.io/spiculedata/saiku:4.6.2

   Au premier démarrage, Saiku le hache en bcrypt dans saiku-home/users.properties sur le volume. La variable d’environnement n’est nécessaire que la première fois — elle persiste entre les redémarrages, vous pouvez donc la retirer ensuite (ou la laisser ; la redéfinir réapplique simplement le même mot de passe).

2. Ouvrez http://localhost:8080/ui/ et connectez-vous en tant que admin avec le mot de passe que vous avez défini.

3. Ajoutez votre premier datasource dans Admin → Connections. Postgres, MySQL, BigQuery, Snowflake, ClickHouse, DuckDB, MotherDuck et H2 sont câblés d’emblée.

Dimensionnement

Des règles empiriques, tirées de déploiements réels. Chaque dimension évolue indépendamment — la plupart des goulots d’étranglement apparaissent au niveau de l’entrepôt, pas sur le conteneur Saiku.

Forme de déploiement	RAM	CPU	Heap JVM (-Xmx)
Évaluation / démo	2 GB	1 vCPU	1 GB (défaut)
Petite équipe (< 20 utilisateurs)	4 GB	2 vCPU	2 GB
Moyenne (20-100 utilisateurs)	8 GB	4 vCPU	4 GB
Grande (100+ utilisateurs)	16 GB+	8 vCPU	8 GB
Charge de travail IA lourde	+50 % de RAM sur la base	+2 vCPU sur la base	Alignez sur la base

Disque : /app/saiku-home grandit avec votre nombre de classeurs et la rétention de l’historique des requêtes. 20 GB sont confortables pour la plupart des déploiements mono-tenant ; montez à 100 GB+ si vous conservez des années d’historique d’audit.

Heap JVM : défini via -e JAVA_OPTS="-Xmx4g" sur la ligne docker run. Le heap par défaut est intentionnellement conservateur — augmentez-le si vous voyez OutOfMemoryError dans saiku-home/logs/.

Mises à niveau

Saiku suit semver : 4.5.2 → 4.5.3 est un patch, 4.5 → 4.6 est mineure, 4.x → 5.x est majeure. Les mises à niveau mineures et de patch sont drop-in — récupérez la nouvelle image, redémarrez le conteneur, votre volume saiku-home transporte chaque classeur et chaque connexion.

1. Faites d’abord un snapshot du volume (voir Sauvegardes ci-dessous — faites-le avant chaque mise à niveau).

2. Arrêtez le conteneur en cours d’exécution.

   docker stop saiku && docker rm saiku

3. Récupérez le nouveau tag et démarrez-le contre le même volume.

   docker pull ghcr.io/spiculedata/saiku:4.5.3
   docker run -d --name saiku \
     --restart unless-stopped \
     -p 8080:8080 \
     -v saiku-home:/app/saiku-home \
     ghcr.io/spiculedata/saiku:4.5.3

4. Consultez le changelog pour d’éventuelles notes de migration sur la version que vous venez d’installer. La plupart des releases n’en ont aucune ; les critiques sont signalées explicitement en haut de l’entrée.

Le retour arrière est l’inverse : docker pull d’un tag plus ancien, redémarrage contre le même volume. Compatible tant que vous n’avez pas franchi une version majeure — le changelog signale les incompatibles.

Sauvegardes

saiku-home contient tout ce qui vaut la peine d’être sauvegardé : connexions, classeurs, requêtes sauvegardées, utilisateurs, historique d’audit, métadonnées de tenant. Sauvegardez-le à la même cadence que le reste de votre plateforme de données.

Snapshot de volume Docker (simple) :

# Once
docker run --rm \
  -v saiku-home:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/saiku-home-$(date +%F).tar.gz -C /data .

# Restore
docker run --rm \
  -v saiku-home:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/saiku-home-2026-07-10.tar.gz -C /data

Sauvegardes planifiées (cron Linux) :

0 2 * * * /usr/local/bin/saiku-backup.sh

Où saiku-backup.sh lance la commande docker run --rm ... alpine tar ... ci-dessus et fait tourner les anciennes archives (find /backup -mtime +30 -delete).

Stockage hors machine. Le snapshot de volume est un simple tarball — rsyncez-le vers S3, Wasabi ou n’importe quel object store selon un planning. Réplication cross-region si vous en avez besoin.

La récupération point-in-time nécessite une sauvegarde côté entrepôt des données que Saiku interroge. L’état propre à Saiku est petit (métadonnées + requêtes sauvegardées) ; en perdre 24 heures est généralement récupérable à partir de la dernière sauvegarde + des fichiers de schéma commités dans git.

Authentification

D’emblée, Saiku est livré avec une auth en mémoire adossée à users.properties — parfait pour l’évaluation, à remplacer avant la production. Trois voies de remplacement, par ordre croissant d’effort d’intégration :

1. Utilisateurs de référence adossés à un fichier. Le mot de passe administrateur vit dans saiku-home/users.properties sur le volume (le launcher l’y écrit depuis SAIKU_ADMIN_PASSWORD au premier démarrage). Éditez ce fichier pour ajouter des comptes — les entrées sont user={bcrypt}$2y$...,ROLE_USER,ROLE_ADMIN ; générez un hash avec htpasswd -nbBC 12 <user> '<password>'. Pour changer le mot de passe administrateur plus tard, relancez avec un nouveau SAIKU_ADMIN_PASSWORD, ou éditez le fichier directement et redémarrez. Le magasin intégré est en lecture seule pour les écrans de gestion d’utilisateurs de l’interface admin.
2. LDAP / Active Directory. Configuration LDAP Spring Security standard dans applicationContext-security-ldap.xml. Voir le guide de câblage LDAP (lien à venir).
3. SSO SAML 2.0. Câblé via Spring Security SAML. Guide de câblage (lien à venir).
4. OAuth 2.0 / OIDC. Même histoire via Spring Security OIDC. Guide de câblage (lien à venir).

Saiku Cloud utilise la voie SAML avec Auth0 comme IdP ; la configuration est la même que celle livrée dans le build OSS.

Observabilité

Saiku est livré avec OpenTelemetry en opt-in — aucune donnée ne quitte la machine sauf si vous la configurez. Pour l’activer, pointez l’endpoint OTLP vers votre collector :

docker run -d --name saiku \
  -e OTEL_EXPORTER_OTLP_ENDPOINT="https://otel-collector:4317" \
  -e OTEL_SERVICE_NAME="saiku-prod" \
  ghcr.io/spiculedata/saiku:4.6.2

L’agent Java auto-instrumente :

• Jetty (requête / réponse HTTP)
• Jersey (endpoints REST)
• JDBC (chaque requête SQL vers votre entrepôt — attention à la cardinalité)
• java.net.http.HttpClient (appels aux fournisseurs de LLM, sorties MCP)
• Log4j 2 (trace_id/span_id dans le MDC)
• Métriques JVM (heap, GC, threads)
• Statistiques du pool de connexions DBCP2

Sans la variable d’environnement, l’agent n’est jamais chargé. Zéro surcoût quand l’observabilité est désactivée.

Configuration

Chaque réglage est une variable d’environnement standard du SDK OpenTelemetry — Saiku les passe directement à l’agent. Celles que vous utiliserez vraiment :

Variable	Défaut	Objectif
OTEL_EXPORTER_OTLP_ENDPOINT	non défini	URL du collector OTLP. La définir est ce qui active l’agent. gRPC (:4317) ou HTTP/protobuf (:4318).
OTEL_EXPORTER_OTLP_PROTOCOL	grpc	grpc ou http/protobuf — alignez sur votre collector.
OTEL_SERVICE_NAME	saiku	Identifiant de service dans votre UI de tracing.
OTEL_RESOURCE_ATTRIBUTES	non défini	par ex. deployment.environment=prod,service.version=4.5.2.
OTEL_METRICS_EXPORTER	otlp	otlp / prometheus / none.
OTEL_EXPORTER_OTLP_HEADERS	non défini	Pour les collectors SaaS nécessitant une auth : api-key=….
OTEL_TRACES_SAMPLER	parentbased_always_on	Stratégie d’échantillonnage — voir ci-dessous.

Échantillonnage. Le défaut capture chaque trace — bon pour la démo, mauvais sous charge. Pour la production, échantillonnez les traces racines :

export OTEL_TRACES_SAMPLER=parentbased_traceidratio
export OTEL_TRACES_SAMPLER_ARG=0.05   # 5% of root traces; children follow the root

Tendez vers 1 à 5 % pour les backends SaaS facturés à l’usage ; un Tempo ou un Jaeger auto-hébergé encaisse confortablement 25 à 100 % au volume de requêtes typique de Saiku.

Quand passer au Cloud

L’auto-hébergement est l’option honnête pour les équipes qui peuvent l’assumer. Seuils approximatifs où l’économie du Cloud commence à l’emporter :

• Vous avez besoin d’une isolation multi-tenant. L’isolation des tenants du Cloud (audit + facturation + périmètre des connexions) est une couche de plateforme substantielle par-dessus le build OSS. Faisable à construire soi-même ; pas bon marché.
• Vous avez besoin d’une intégration audit + SIEM que vous ne voulez pas faire tourner.
• Vous avez besoin de SSO avec des SLA. Auto-hébergement + Auth0 fonctionne, mais si vous n’avez pas déjà un IdP en place, le Cloud est plus rapide que d’en monter un.
• Vous voulez SOC 2 sans faire le travail de conformité. La cible du Cloud est T4 2026 (voir la page posture de sécurité).

Obtenir de l’aide

• GitHub Discussions — questions-réponses publiques.
• GitHub Issues — rapports de bugs.
• Support Enterprise — adossé à des SLA, échelonné par temps de réponse.

Si vous évaluez l’auto-hébergement face au Cloud et voulez un second avis, réservez un appel de 30 minutes — des réponses honnêtes, sans signature de contrat.