Zum Inhalt springen
Saiku Cloud

Saiku selbst hosten

Saiku liefert einen selbst gehosteten Build unter Apache 2.0 + EPL — derselbe Build, den wir in Saiku Cloud betreiben. Jedes Feature, das im OSS-Repository ist, ist im selbst gehosteten Binary. Keine Enterprise-SKUs, keine gegatete MCP-Stufe, kein Excel-Connector, der nur in der Cloud ist.

Der Kompromiss ist operative Verantwortung: Sie betreiben die Box, Sie handhaben Updates, Sie besitzen Backups. Dieser Abschnitt ist das aktuelle Operator-Playbook.

Welchen Build man nimmt

DistributionWann man ihn verwendet
ghcr.io/spiculedata/saiku:developmentVerfolgt den development-Branch — neue Features landen hier zuerst. Am besten für Evaluation und nicht-kritische Deployments.
ghcr.io/spiculedata/saiku:4.6.2 (auf eine Version pinnen)Zeigt auf ein immutables Tag. Empfohlen für alles, was in der Produktion läuft.
saiku-dist-<version>.zip von ReleasesJava-21-lauffähiges Fat-JAR + run.sh/run.bat-Wrapper. Für Teams, die kein Docker betreiben.

Alles unten setzt das Docker-Image voraus; der Fat-JAR-Flow ist dieselben Env-Vars + dieselben Volume-Mounts, minus den Container.

Erster Boot

  1. Ziehen Sie das Image und starten Sie es mit einem persistenten saiku-home-Volume und einem Admin-Passwort. Saiku weigert sich zu servieren, solange die Standard-admin/admin-Anmeldedaten unverändert sind — setzen Sie Ihr Passwort daher gleich beim allerersten Boot mit SAIKU_ADMIN_PASSWORD:

    Terminal-Fenster
    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

    Beim ersten Boot hasht Saiku es per bcrypt in saiku-home/users.properties auf dem Volume. Die Env-Var wird nur beim ersten Mal benötigt — sie überlebt Neustarts, Sie können sie danach also weglassen (oder stehen lassen; ein erneutes Setzen wendet einfach dasselbe Passwort erneut an).

  2. Öffnen Sie http://localhost:8080/ui/ und melden Sie sich als admin mit dem von Ihnen gesetzten Passwort an.

  3. Fügen Sie Ihre erste Datasource hinzu unter Admin → Connections. Postgres, MySQL, BigQuery, Snowflake, ClickHouse, DuckDB, MotherDuck und H2 sind out of the box verdrahtet.

Sizing

Faustregeln, aus realen Deployments gezogen. Jede Dimension skaliert unabhängig — die meisten Bottlenecks zeigen sich auf der Warehouse-Ebene, nicht auf dem Saiku-Container.

Deployment-FormRAMCPUJVM-Heap (-Xmx)
Evaluation / Demo2 GB1 vCPU1 GB (Standard)
Kleines Team (< 20 Nutzer)4 GB2 vCPU2 GB
Mittel (20–100 Nutzer)8 GB4 vCPU4 GB
Groß (100+ Nutzer)16 GB+8 vCPU8 GB
Schwere AI-Last+50 % RAM über Basis+2 vCPU über BasisDer Basis entsprechen

Disk: /app/saiku-home wächst mit Ihrer Workbook-Anzahl und der Aufbewahrung der Abfragehistorie. 20 GB sind für die meisten Single-Tenant-Deployments komfortabel; skalieren Sie auf 100 GB+, wenn Sie jahrelange Audit-Historie aufbewahren.

JVM-Heap: gesetzt via -e JAVA_OPTS="-Xmx4g" auf der docker-run-Zeile. Der Standard-Heap ist bewusst konservativ — erhöhen Sie ihn, wenn Sie OutOfMemoryError in saiku-home/logs/ sehen.

Upgrades

Saiku folgt Semver: 4.5.2 → 4.5.3 ist Patch, 4.5 → 4.6 ist Minor, 4.x → 5.x ist Major. Minor- und Patch-Upgrades sind Drop-in — ziehen Sie das neue Image, starten Sie den Container neu, Ihr saiku-home-Volume trägt jedes Workbook und jede Verbindung durch.

  1. Snapshotten Sie zuerst das Volume (siehe Backups unten — tun Sie dies vor jedem Upgrade).

  2. Stoppen Sie den laufenden Container.

    Terminal-Fenster
    docker stop saiku && docker rm saiku

  3. Ziehen Sie das neue Tag und starten Sie es gegen dasselbe Volume.

    Terminal-Fenster
    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. Prüfen Sie den Changelog auf Migrationsnotizen zur gerade gelandeten Version. Die meisten Releases haben keine; die tragenden werden explizit oben im Eintrag hervorgehoben.

Rollback ist das Umgekehrte: docker pull ein älteres Tag, Neustart gegen dasselbe Volume. Kompatibel, solange Sie keine Major-Version überschritten haben — der Changelog markiert die inkompatiblen.

Backups

saiku-home hält alles Sicherungswürdige: Verbindungen, Workbooks, gespeicherte Abfragen, Nutzer, Audit-Historie, Tenant-Metadaten. Sichern Sie es in derselben Kadenz wie alles andere in Ihrer Datenplattform.

Docker-Volume-Snapshot (einfach):

Terminal-Fenster
# 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

Geplante Backups (Linux-Cron):

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

Wobei saiku-backup.sh den obigen docker run --rm ... alpine tar ...-Befehl ausführt und alte Archive rotiert (find /backup -mtime +30 -delete).

Off-Box-Storage. Der Volume-Snapshot ist ein einfacher Tarball — rsyncen Sie ihn nach S3, Wasabi oder einem beliebigen Object-Store nach Zeitplan. Cross-Region-Replikation, falls Sie sie brauchen.

Point-in-Time-Recovery erfordert ein warehouse-seitiges Backup der Daten, die Saiku abfragt. Saikus eigener State ist klein (Metadaten + gespeicherte Abfragen); der Verlust von 24 Stunden davon ist meist aus dem letzten Backup + git-committeten Schema-Dateien wiederherstellbar.

Authentifizierung

Out of the box liefert Saiku In-Memory-Auth, gestützt auf users.properties — in Ordnung für Evaluation, ersetzen vor der Produktion. Drei Ersatzpfade, in zunehmender Reihenfolge des Integrationsaufwands:

  1. Dateigestützte autoritative Nutzer. Bearbeiten Sie saiku-home/users.properties auf dem Volume (der Launcher schreibt es dort aus SAIKU_ADMIN_PASSWORD beim ersten Boot). Bearbeiten Sie diese Datei, um Konten hinzuzufügen — Einträge lauten user={bcrypt}$2y$...,ROLE_USER,ROLE_ADMIN; erzeugen Sie einen Hash mit htpasswd -nbBC 12 <user> '<password>'. Zum späteren Rotieren des Admin-Passworts starten Sie mit einem neuen SAIKU_ADMIN_PASSWORD neu oder bearbeiten die Datei direkt und starten neu. Der eingebaute Store ist für die Benutzerverwaltungs-Screens der Admin-UI schreibgeschützt.
  2. LDAP / Active Directory. Standard-Spring-Security-LDAP-Config in applicationContext-security-ldap.xml. Siehe den LDAP-Verdrahtungsleitfaden (Link folgt).
  3. SAML 2.0 SSO. Verdrahtet über Spring Security SAML. Verdrahtungsleitfaden (Link folgt).
  4. OAuth 2.0 / OIDC. Gleiche Story über Spring Security OIDC. Verdrahtungsleitfaden (Link folgt).

Saiku Cloud verwendet den SAML-Pfad mit Auth0 als IdP; die Config ist dieselbe, die im OSS-Build ausgeliefert wird.

Observability

Saiku liefert Opt-in-OpenTelemetry — keine Daten verlassen die Box, es sei denn, Sie konfigurieren es. Zum Einschalten zeigen Sie den OTLP-Endpunkt auf Ihren Collector:

Terminal-Fenster
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

Der Java-Agent instrumentiert automatisch:

  • Jetty (HTTP-Request / -Response)
  • Jersey (REST-Endpunkte)
  • JDBC (jede SQL-Abfrage an Ihr Warehouse — Vorsicht bei Kardinalität)
  • java.net.http.HttpClient (LLM-Provider-Aufrufe, MCP-Outbound)
  • Log4j 2 (trace_id/span_id im MDC)
  • JVM-Metriken (Heap, GC, Threads)
  • DBCP2-Connection-Pool-Statistiken

Ohne die Env-Var wird der Agent nie geladen. Null Overhead, wenn Observability aus ist.

Konfiguration

Jede Einstellung ist eine Standard-OpenTelemetry-SDK-Umgebungsvariable — Saiku reicht sie direkt an den Agenten durch. Die, nach denen Sie tatsächlich greifen werden:

VariableStandardZweck
OTEL_EXPORTER_OTLP_ENDPOINTunsetOTLP-Collector-URL. Das Setzen davon aktiviert den Agenten. gRPC (:4317) oder HTTP/protobuf (:4318).
OTEL_EXPORTER_OTLP_PROTOCOLgrpcgrpc oder http/protobuf — passend zu Ihrem Collector.
OTEL_SERVICE_NAMEsaikuService-Bezeichner in Ihrer Tracing-UI.
OTEL_RESOURCE_ATTRIBUTESunsetz. B. deployment.environment=prod,service.version=4.5.2.
OTEL_METRICS_EXPORTERotlpotlp / prometheus / none.
OTEL_EXPORTER_OTLP_HEADERSunsetFür SaaS-Collectoren, die Auth benötigen: api-key=….
OTEL_TRACES_SAMPLERparentbased_always_onSampling-Strategie — siehe unten.

Sampling. Der Standard erfasst jeden Trace — richtig für die Demo, falsch unter Last. Für die Produktion samplen Sie Root-Traces:

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

Neigen Sie zu 1–5 % für nutzungsabgerechnete SaaS-Backends; ein selbst gehostetes Tempo oder Jaeger bewältigt 25–100 % bei Saikus typischem Abfragevolumen komfortabel.

Wann man zur Cloud eskaliert

Self-Hosted ist die ehrliche Option für Teams, die es besetzen können. Grobe Schwellen, ab denen die Cloud-Ökonomie zu gewinnen beginnt:

  • Sie brauchen Multi-Tenant-Isolation. Die Tenant-Isolation der Cloud (Audit + Billing + Connection-Scope) ist eine substanzielle Plattformebene über dem OSS-Build. Selbst zu bauen machbar; nicht billig.
  • Sie brauchen Audit + SIEM-Integration, die Sie nicht betreiben wollen.
  • Sie brauchen SSO mit SLAs. Self-Host + Auth0 funktioniert, aber wenn Sie nicht bereits einen IdP am Laufen haben, ist die Cloud schneller, als einen aufzustellen.
  • Sie wollen SOC 2, ohne die Compliance-Arbeit zu tun. Das Ziel der Cloud ist Q4 2026 (siehe die Sicherheits-Posture-Seite).

Hilfe bekommen

Wenn Sie Self-Hosted vs Cloud evaluieren und eine zweite Meinung möchten, buchen Sie einen 30-minütigen Call — ehrliche Antworten, keine Vertragsunterzeichnung.