Przejdź do głównej zawartości
Saiku Cloud

Self-hosting Saiku

Saiku dostarcza build self-hosted na licencji Apache 2.0 + EPL — ten sam build, który uruchamiamy w Saiku Cloud. Każda funkcja, która jest w repozytorium OSS, jest w binarce self-hosted. Żadnych SKU enterprise, żadnego bramkowanego poziomu MCP, żadnego konektora Excel tylko-dla-Cloud.

Kompromisem jest odpowiedzialność operacyjna: ty prowadzisz box, ty obsługujesz aktualizacje, ty posiadasz kopie zapasowe. Ta sekcja to aktualny podręcznik operatora.

Który build wziąć

DystrybucjaKiedy jej użyć
ghcr.io/spiculedata/saiku:developmentŚledzi gałąź development — nowe funkcje lądują tu najpierw. Najlepsze do ewaluacji i niekrytycznych wdrożeń.
ghcr.io/spiculedata/saiku:4.6.2 (przypnij do wersji)Wskaż na niezmienny tag. Zalecane dla czegokolwiek działającego na produkcji.
saiku-dist-<version>.zip z ReleasesUruchamialny fat-JAR Java 21 + wrappery run.sh/run.bat. Dla zespołów, które nie uruchamiają Dockera.

Wszystko poniżej zakłada obraz Docker; przepływ fat-JAR to te same zmienne środowiskowe + te same montowania wolumenów, minus kontener.

Pierwszy start

  1. Pobierz obraz i uruchom go z trwałym wolumenem saiku-home oraz hasłem admina. Saiku odmówi serwowania, dopóki domyślne poświadczenia admin/admin są niezmienione, więc ustaw swoje hasło już przy pierwszym starcie za pomocą SAIKU_ADMIN_PASSWORD:

    Okno terminala
    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

    Przy pierwszym starcie Saiku hashuje je bcryptem do saiku-home/users.properties na wolumenie. Zmienna środowiskowa jest potrzebna tylko za pierwszym razem — przetrwa restarty, więc możesz ją potem usunąć (albo zostawić; ponowne ustawienie po prostu nakłada to samo hasło jeszcze raz).

  2. Otwórz http://localhost:8080/ui/ i zaloguj się jako admin hasłem, które ustawiłeś.

  3. Dodaj swój pierwszy datasource w Admin → Connections. Postgres, MySQL, BigQuery, Snowflake, ClickHouse, DuckDB, MotherDuck i H2 są podłączone od ręki.

Dobór rozmiaru

Reguły kciuka, wywiedzione z realnych wdrożeń. Każdy wymiar skaluje się niezależnie — większość wąskich gardeł pojawia się w warstwie hurtowni, nie na kontenerze Saiku.

Kształt wdrożeniaRAMCPUSterta JVM (-Xmx)
Ewaluacja / demo2 GB1 vCPU1 GB (domyślnie)
Mały zespół (< 20 użytkowników)4 GB2 vCPU2 GB
Średni (20-100 użytkowników)8 GB4 vCPU4 GB
Duży (100+ użytkowników)16 GB+8 vCPU8 GB
Ciężkie obciążenie AI+50% RAM nad bazę+2 vCPU nad bazęDopasuj do bazy

Dysk: /app/saiku-home rośnie z liczbą twoich workbooków i retencją historii zapytań. 20 GB jest komfortowe dla większości wdrożeń jednonajemcowych; skaluj do 100 GB+, jeśli trzymasz lata historii audytu.

Sterta JVM: ustawiana przez -e JAVA_OPTS="-Xmx4g" w linii docker run. Domyślna sterta jest celowo konserwatywna — podbij ją, jeśli widzisz OutOfMemoryError w saiku-home/logs/.

Aktualizacje

Saiku podąża za semver: 4.5.2 → 4.5.3 to patch, 4.5 → 4.6 to minor, 4.x → 5.x to major. Aktualizacje minor i patch są drop-in — pobierz nowy obraz, zrestartuj kontener, twój wolumen saiku-home przenosi każdy workbook i połączenie.

  1. Zrób snapshot wolumenu najpierw (zobacz Kopie zapasowe niżej — rób to przed każdą aktualizacją).

  2. Zatrzymaj działający kontener.

    Okno terminala
    docker stop saiku && docker rm saiku

  3. Pobierz nowy tag i uruchom go względem tego samego wolumenu.

    Okno terminala
    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. Sprawdź changelog pod kątem wszelkich notatek migracyjnych na wersji, którą właśnie wylądowałeś. Większość wydań ich nie ma; te nośne są jawnie wskazane na górze wpisu.

Wycofanie to odwrotność: docker pull starszego tagu, restart względem tego samego wolumenu. Kompatybilne, dopóki nie przekroczyłeś wersji major — changelog flaguje te niekompatybilne.

Kopie zapasowe

saiku-home trzyma wszystko warte backupu: połączenia, workbooki, zapisane zapytania, użytkowników, historię audytu, metadane najemcy. Backupuj to w tym samym rytmie co cokolwiek innego w twojej platformie danych.

Snapshot wolumenu Docker (prosty):

Okno terminala
# 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

Zaplanowane kopie zapasowe (Linux cron):

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

Gdzie saiku-backup.sh uruchamia powyższe polecenie docker run --rm ... alpine tar ... i rotuje stare archiwa (find /backup -mtime +30 -delete).

Przechowywanie poza boxem. Snapshot wolumenu to zwykły tarball — rsync go do S3, wasabi lub dowolnego magazynu obiektów wg harmonogramu. Replikacja międzyregionalna, jeśli jej potrzebujesz.

Odzyskiwanie do punktu w czasie wymaga backupu po stronie hurtowni danych, które Saiku odpytuje. Własny stan Saiku jest mały (metadane + zapisane zapytania); utrata 24 godzin jego zwykle jest odzyskiwalna z ostatniego backupu + zacommitowanych do gita plików schemy.

Uwierzytelnianie

Od ręki Saiku dostarczane jest z uwierzytelnianiem w pamięci wspartym przez users.properties — w porządku do ewaluacji, wymień przed produkcją. Trzy ścieżki wymiany, w rosnącej kolejności wysiłku integracji:

  1. Autorytatywni użytkownicy z pliku. Hasło admina znajduje się w saiku-home/users.properties na wolumenie (launcher zapisuje je tam z SAIKU_ADMIN_PASSWORD przy pierwszym starcie). Edytuj ten plik, aby dodać konta — wpisy mają postać user={bcrypt}$2y$...,ROLE_USER,ROLE_ADMIN; wygeneruj hash za pomocą htpasswd -nbBC 12 <user> '<password>'. Aby później zrotować hasło admina, uruchom ponownie z nowym SAIKU_ADMIN_PASSWORD albo edytuj plik bezpośrednio i zrestartuj. Wbudowany magazyn jest tylko do odczytu dla ekranów zarządzania użytkownikami w UI admina.
  2. LDAP / Active Directory. Standardowa konfiguracja LDAP Spring Security w applicationContext-security-ldap.xml. Zobacz przewodnik po podpinaniu LDAP (link nadchodzi).
  3. SAML 2.0 SSO. Podłączone przez Spring Security SAML. Przewodnik po podpinaniu (link nadchodzi).
  4. OAuth 2.0 / OIDC. Ta sama historia przez Spring Security OIDC. Przewodnik po podpinaniu (link nadchodzi).

Saiku Cloud używa ścieżki SAML z Auth0 jako IdP; konfiguracja jest tą samą, która dostarczana jest w buildzie OSS.

Obserwowalność

Saiku dostarczane jest z opcjonalnym OpenTelemetry — żadne dane nie opuszczają boxa, chyba że to skonfigurujesz. Aby to włączyć, wskaż endpoint OTLP na swój kolektor:

Okno terminala
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

Agent Java auto-instrumentuje:

  • Jetty (żądanie / odpowiedź HTTP)
  • Jersey (endpointy REST)
  • JDBC (każde zapytanie SQL do twojej hurtowni — uważaj na kardynalność)
  • java.net.http.HttpClient (wywołania dostawcy LLM, wychodzące MCP)
  • Log4j 2 (trace_id/span_id w MDC)
  • Metryki JVM (sterta, GC, wątki)
  • Statystyki puli połączeń DBCP2

Bez zmiennej środowiskowej agent nigdy nie jest ładowany. Zerowy narzut, gdy obserwowalność jest wyłączona.

Konfiguracja

Każde ustawienie to standardowa zmienna środowiskowa SDK OpenTelemetry — Saiku przekazuje je prosto do agenta. Te, po które faktycznie sięgniesz:

ZmiennaDomyślnieCel
OTEL_EXPORTER_OTLP_ENDPOINTnieustawioneURL kolektora OTLP. Ustawienie tego jest tym, co aktywuje agenta. gRPC (:4317) lub HTTP/protobuf (:4318).
OTEL_EXPORTER_OTLP_PROTOCOLgrpcgrpc lub http/protobuf — dopasuj do swojego kolektora.
OTEL_SERVICE_NAMEsaikuIdentyfikator usługi w twoim UI śledzenia.
OTEL_RESOURCE_ATTRIBUTESnieustawionenp. deployment.environment=prod,service.version=4.5.2.
OTEL_METRICS_EXPORTERotlpotlp / prometheus / none.
OTEL_EXPORTER_OTLP_HEADERSnieustawioneDla kolektorów SaaS wymagających uwierzytelnienia: api-key=….
OTEL_TRACES_SAMPLERparentbased_always_onStrategia próbkowania — zobacz niżej.

Próbkowanie. Domyślne przechwytuje każdy trace — właściwe dla demo, złe pod obciążeniem. Dla produkcji próbkuj trace-y korzeniowe:

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

Skłaniaj się ku 1–5% dla backendów SaaS rozliczanych od użycia; self-hosted Tempo lub Jaeger obsługuje 25–100% komfortowo przy typowym wolumenie zapytań Saiku.

Kiedy eskalować do Cloud

Self-hosted to uczciwa opcja dla zespołów, które mogą to obsadzić. Zgrubne progi, gdzie ekonomia Cloud zaczyna wygrywać:

  • Potrzebujesz izolacji wielonajemcowej. Izolacja najemców Cloud (audyt + rozliczenia + zakres połączeń) to znacząca warstwa platformy na wierzchu buildu OSS. Wykonalne do zbudowania samodzielnie; nie tanie.
  • Potrzebujesz audytu + integracji SIEM, których nie chcesz prowadzić.
  • Potrzebujesz SSO z SLA. Self-host + Auth0 działa, ale jeśli nie masz już działającego IdP, Cloud jest szybszy niż stawianie jednego.
  • Chcesz SOC 2 bez wykonywania pracy zgodności. Cel Cloud to Q4 2026 (zobacz stronę postawa bezpieczeństwa).

Uzyskiwanie pomocy

Jeśli oceniasz self-hosted vs Cloud i chcesz drugiej opinii, umów 30-minutową rozmowę — uczciwe odpowiedzi, bez podpisywania umowy.