Saltearse al contenido
Saiku Cloud

Auto-alojar Saiku

Saiku entrega un build auto-alojado bajo Apache 2.0 + EPL — el mismo build que ejecutamos en Saiku Cloud. Cada funcionalidad que está en el repositorio OSS está en el binario auto-alojado. Sin SKUs empresariales, sin nivel MCP con puerta, sin conector de Excel solo-Cloud.

La compensación es la responsabilidad operacional: usted ejecuta la caja, usted maneja las actualizaciones, usted es dueño de los backups. Esta sección es el manual de operador actual.

Qué build coger

DistribuciónCuándo usarla
ghcr.io/spiculedata/saiku:developmentSigue la rama development — las nuevas funcionalidades aterrizan aquí primero. Mejor para evaluación y despliegues no críticos.
ghcr.io/spiculedata/saiku:4.6.2 (fijar a una versión)Apunte a un tag inmutable. Recomendado para cualquier cosa que corra en producción.
saiku-dist-<version>.zip de ReleasesFat-JAR ejecutable de Java 21 + envoltorios run.sh/run.bat. Para equipos que no ejecutan Docker.

Todo lo de abajo asume la imagen Docker; el flujo del fat-JAR es las mismas variables de entorno + los mismos montajes de volumen, menos el contenedor.

Primer arranque

  1. Descargue la imagen y arránquela con un volumen persistente saiku-home y una contraseña de admin. Saiku se negará a servir mientras las credenciales por defecto admin/admin estén sin cambiar, así que establezca su contraseña en el primer arranque con SAIKU_ADMIN_PASSWORD:

    Ventana de terminal
    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

    En el primer arranque, Saiku la hashea con bcrypt en saiku-home/users.properties en el volumen. La variable de entorno solo hace falta la primera vez — persiste entre reinicios, así que puede quitarla después (o dejarla; volver a definirla simplemente reaplica la misma contraseña).

  2. Abra http://localhost:8080/ui/ e inicie sesión como admin con la contraseña que estableció.

  3. Añada su primer datasource en Admin → Connections. Postgres, MySQL, BigQuery, Snowflake, ClickHouse, DuckDB, MotherDuck, y H2 están cableados de fábrica.

Dimensionamiento

Reglas generales, extraídas de despliegues reales. Cada dimensión escala independientemente — la mayoría de los cuellos de botella aparecen en la capa del warehouse, no en el contenedor de Saiku.

Forma del despliegueRAMCPUHeap de la JVM (-Xmx)
Evaluación / demo2 GB1 vCPU1 GB (por defecto)
Equipo pequeño (< 20 usuarios)4 GB2 vCPU2 GB
Mediano (20-100 usuarios)8 GB4 vCPU4 GB
Grande (100+ usuarios)16 GB+8 vCPU8 GB
Carga de IA pesada+50% RAM sobre la base+2 vCPU sobre la baseIguala la base

Disco: /app/saiku-home crece con su recuento de workbooks y la retención del historial de consultas. 20 GB es cómodo para la mayoría de los despliegues de un solo tenant; escale a 100 GB+ si está guardando años de historial de auditoría.

Heap de la JVM: defina mediante -e JAVA_OPTS="-Xmx4g" en la línea de docker run. El heap por defecto es intencionalmente conservador — súbalo si ve OutOfMemoryError en saiku-home/logs/.

Actualizaciones

Saiku sigue semver: 4.5.2 → 4.5.3 es patch, 4.5 → 4.6 es minor, 4.x → 5.x es major. Las actualizaciones minor y patch son drop-in — descargue la nueva imagen, reinicie el contenedor, su volumen saiku-home lleva cada workbook y conexión a través.

  1. Haga primero un snapshot del volumen (vea Backups abajo — haga esto antes de cada actualización).

  2. Detenga el contenedor en ejecución.

    Ventana de terminal
    docker stop saiku && docker rm saiku

  3. Descargue el nuevo tag y arránquelo contra el mismo volumen.

    Ventana de terminal
    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. Consulte el changelog por cualquier nota de migración de la versión que acaba de aterrizar. La mayoría de las releases no tienen ninguna; las que son de carga se destacan explícitamente al principio de la entrada.

Hacer rollback es lo inverso: docker pull de un tag más antiguo, reinicie contra el mismo volumen. Compatible mientras no haya cruzado una versión major — el changelog marca las incompatibles.

Backups

saiku-home contiene todo lo que vale la pena respaldar: conexiones, workbooks, consultas guardadas, usuarios, historial de auditoría, metadatos de tenant. Respáldelo en la misma cadencia que cualquier otra cosa en su plataforma de datos.

Snapshot de volumen Docker (simple):

Ventana de terminal
# 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

Backups programados (cron de Linux):

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

Donde saiku-backup.sh ejecuta el comando docker run --rm ... alpine tar ... de arriba y rota los archivos antiguos (find /backup -mtime +30 -delete).

Almacenamiento fuera de la caja. El snapshot del volumen es un tarball plano — hágale rsync a S3, wasabi, o cualquier almacén de objetos en un horario. Replicación entre regiones si la necesita.

La recuperación a un punto en el tiempo requiere un backup del lado del warehouse de los datos que Saiku consulta. El estado propio de Saiku es pequeño (metadatos + consultas guardadas); perder 24 horas de él suele ser recuperable desde el último backup + los archivos de schema comprometidos en git.

Autenticación

De fábrica, Saiku se entrega con auth en memoria respaldada por users.properties — bien para evaluación, reemplácela antes de producción. Tres rutas de reemplazo, en orden creciente de esfuerzo de integración:

  1. Usuarios autoritativos respaldados por archivo. La contraseña de admin vive en saiku-home/users.properties en el volumen (el launcher la escribe ahí desde SAIKU_ADMIN_PASSWORD en el primer arranque). Edite ese archivo para añadir cuentas — las entradas son user={bcrypt}$2y$...,ROLE_USER,ROLE_ADMIN; genere un hash con htpasswd -nbBC 12 <user> '<password>'. Para rotar la contraseña de admin más tarde, vuelva a arrancar con un nuevo SAIKU_ADMIN_PASSWORD, o edite el archivo directamente y reinicie. El almacén integrado es de solo lectura para las pantallas de gestión de usuarios de la interfaz de admin.
  2. LDAP / Active Directory. Configuración estándar de Spring Security LDAP en applicationContext-security-ldap.xml. Vea la guía de cableado de LDAP (enlace próximamente).
  3. SSO SAML 2.0. Cableado a través de Spring Security SAML. Guía de cableado (enlace próximamente).
  4. OAuth 2.0 / OIDC. La misma historia mediante Spring Security OIDC. Guía de cableado (enlace próximamente).

Saiku Cloud usa la ruta SAML con Auth0 como IdP; la configuración es la misma que se entrega en el build OSS.

Observabilidad

Saiku se entrega con OpenTelemetry opt-in — ningún dato sale de la caja a menos que lo configure. Para activarlo, apunte el endpoint OTLP a su colector:

Ventana de terminal
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

El agente Java auto-instrumenta:

  • Jetty (petición / respuesta HTTP)
  • Jersey (endpoints REST)
  • JDBC (cada consulta SQL a su warehouse — cuidado con la cardinalidad)
  • java.net.http.HttpClient (llamadas al proveedor LLM, salida MCP)
  • Log4j 2 (trace_id/span_id en el MDC)
  • Métricas de la JVM (heap, GC, hilos)
  • Estadísticas del pool de conexiones DBCP2

Sin la variable de entorno, el agente nunca se carga. Cero sobrecarga cuando la observabilidad está desactivada.

Configuración

Cada ajuste es una variable de entorno estándar del SDK de OpenTelemetry — Saiku las pasa directamente al agente. Las que realmente usará:

VariablePor defectoPropósito
OTEL_EXPORTER_OTLP_ENDPOINTsin definirURL del colector OTLP. Definir esto es lo que activa el agente. gRPC (:4317) o HTTP/protobuf (:4318).
OTEL_EXPORTER_OTLP_PROTOCOLgrpcgrpc o http/protobuf — iguale su colector.
OTEL_SERVICE_NAMEsaikuIdentificador de servicio en su UI de tracing.
OTEL_RESOURCE_ATTRIBUTESsin definirp. ej. deployment.environment=prod,service.version=4.5.2.
OTEL_METRICS_EXPORTERotlpotlp / prometheus / none.
OTEL_EXPORTER_OTLP_HEADERSsin definirPara colectores SaaS que necesitan auth: api-key=….
OTEL_TRACES_SAMPLERparentbased_always_onEstrategia de muestreo — vea abajo.

Muestreo. El por defecto captura cada traza — correcto para la demo, incorrecto bajo carga. Para producción, muestree las trazas raíz:

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

Tienda al 1–5% para backends SaaS facturados por uso; un Tempo o Jaeger auto-alojado maneja el 25–100% cómodamente al volumen de consultas típico de Saiku.

Cuándo escalar al Cloud

El auto-alojamiento es la opción honesta para equipos que pueden dotarlo de personal. Umbrales aproximados donde la economía del Cloud empieza a ganar:

  • Necesita aislamiento multi-tenant. El aislamiento de tenants del Cloud (auditoría + facturación + alcance de conexión) es una capa de plataforma sustancial sobre el build OSS. Factible de construir usted mismo; no barato.
  • Necesita integración de auditoría + SIEM que no quiere ejecutar.
  • Necesita SSO con SLAs. Auto-host + Auth0 funciona, pero si no tiene ya un IdP en ejecución, el Cloud es más rápido que levantar uno.
  • Quiere SOC 2 sin hacer el trabajo de cumplimiento. El objetivo del Cloud es Q4 2026 (vea la página de postura de seguridad).

Obtener ayuda

Si está evaluando auto-alojado vs Cloud y quiere una segunda opinión, reserve una llamada de 30 minutos — respuestas honestas, sin firma de contrato.