Offline BI in asapBI: Docker und ClickHouse

Offline-BI-Entwicklung in asapBI: Lokaler Stack und visuelle Ansichten

asapBI bietet vollständige Offline-Unterstützung für die BI-Entwicklung. Das System nutzt einen lokalen Docker-Stack mit PostgreSQL und ClickHouse, visuelle SQL-Ansichten als JSON-Dateien und Git-Versionierung. So können Abfragen erstellt, Daten experimentell bearbeitet und Logik dokumentiert werden – alles ohne Abhängigkeit von Remote-Servern und damit ohne Ausfallzeiten durch instabile Internetverbindungen.

Die lokale Umgebung gewährleistet Datenisolation, sichere Experimente und Versionskontrolle. Entwickler haben volle Kontrolle über Container-Volumes, CPU und Speicherzuweisung.

Vorteile des lokalen Stacks

Der lokale Entwicklungsumzug löst zentrale Herausforderungen bei der Teamzusammenarbeit:

• Datenisolation: Docker-Volumes sind vor externen Änderungen geschützt. Kein Risiko, Testtabellen durch Migrationen oder Bereinigungsaktionen zu verlieren.
• Sichere Experimente: Aufwändige JOINs oder komplexe Ansichten wirken nur auf den lokalen Container, nicht auf den gemeinsam genutzten Cluster.
• Git-Versionierung: Visuelle Ansichten werden als JSON-Dateien gespeichert und ermöglichen Diffs, Code-Reviews und Rückgängigmachungen.
• Digitales Zwilling der Datenbank: Schema-Änderungen, Datentypen und Beziehungen können getestet werden, ohne die Produktion zu beeinträchtigen.

Einrichtung der Offline-Umgebung

Die Einrichtung erfolgt in drei Schritten.

1. Projekt aus Git klonen

Laden Sie das Projekt in einen lokalen Ordner herunter. Die Projektstruktur folgt Geschäftsdomänen wie Finanzen, Vertrieb usw. Ansichtsdateien und dbcopy-json-Dateien sind im Repository gespeichert.

2. BI-Stack über Docker Compose starten

Verwenden Sie docker-compose.yml, um PostgreSQL und ClickHouse zu starten. Beispielkonfiguration:

services:
  asapbi-postgres:
    image: postgres:15-alpine
    container_name: asapbi-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: admin
      POSTGRES_DB: demo
      PGDATA: /var/lib/postgresql/data/pgdata
    ports:
      - "15432:5432"
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U admin -d demo"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 10s
    networks:
      - asapbi-net

  asapbi-clickhouse:
    image: clickhouse/clickhouse-server:24.8-alpine
    container_name: asapbi-clickhouse
    restart: unless-stopped
    environment:
      CLICKHOUSE_USER: admin
      CLICKHOUSE_PASSWORD: admin
      CLICKHOUSE_DB: analytics
    ports:
      - "18123:8123"   # HTTP
      - "19000:9000"   # Native
    volumes:
      - clickhouse-data:/var/lib/clickhouse
      - clickhouse-logs:/var/log/clickhouse-server
    healthcheck:
      test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider http://localhost:8123/ping || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    networks:
      - asapbi-net

volumes:
  postgres-data:
    driver: local
  clickhouse-data:
    driver: local
  clickhouse-logs:
    driver: local

networks:
  asapbi-net:
    driver: bridge

Starten Sie über die asapBI-Oberfläche oder CLI. Docker zieht die benötigten Images automatisch nach.

3. Datenbank mit Testdaten füllen

Verwenden Sie *.dbcopy-json-Dateien, um Testdatensätze zu kopieren. Beispiel:

{
  "description": "Kopieren von Kunden mit Vorbereitung und Aufräumen",
  "beforeSQL": [
    "BEGIN;",
    "SET session_replication_role = replica;",
    "CREATE TEMP TABLE IF NOT EXISTS _copy_log (ts timestamptz, msg text);"
  ],
  "afterSQL": [
    "SET session_replication_role = DEFAULT;",
    "INSERT INTO _copy_log VALUES (now(), 'Kopie abgeschlossen');",
    "COMMIT;"
  ],
  "tables": [
    {
      "schema": "reference",
      "table": "clients",
      "where": "is_active = true AND created_at >= '2024-01-01'",
      "beforeSQL": [
        "DROP INDEX IF EXISTS idx_clients_region_id",
        "DELETE FROM reference.clients WHERE created_at >= '2024-01-01'"
      ],
      "afterSQL": [
        "CREATE INDEX IF NOT EXISTS idx_clients_region_id ON reference.clients (region_id)",
        "ANALYZE reference.clients"
      ]
    },
    {
      "schema": "sales",
      "table": "orders",
      "where": "order_date >= '2024-01-01'",
      "beforeSQL": "ALTER TABLE sales.orders DISABLE TRIGGER ALL",
      "afterSQL": "ALTER TABLE sales.orders ENABLE TRIGGER ALL"
    },
    {
      "schema": "analytics",
      "table": "user_sessions",
      "where": "",
      "beforeSQL": null,
      "afterSQL": null
    }
  ]
}

Wählen Sie Quell- und Ziel-Datenbank in der Oberfläche aus. Nutzen Sie ausschließlich Testdaten aus Dev-Servern.

Visuelle SQL-Ansichten

Stellen Sie eine Verbindung zum lokalen ClickHouse-Instanz her und erstellen Sie visuelle Ansichten. Diese sind JSON-Dateien mit Versionskontrolle und Unterstützung für Code-Reviews. Ansichten sind von Dashboards entkoppelt und garantieren eine einheitliche Quelle für Berechnungen.

Vorteile:

• Zentralisierte Speicherung von Berechnungslogik.
• Wiederverwendbarkeit über mehrere Dashboards hinweg.
• Änderungstracking via Git-Diff.

Dokumentationsintegration

Hängen Sie Dokumentationsdateien (MD, draw.io) direkt im selben Ordner wie die Ansicht an. Dokumentation wird automatisch aktualisiert, wenn sich das Modell ändert. Textdateien eignen sich ideal für KI-Verarbeitung und automatisierte Dokumentenerstellung.

Schlüsselbotschaften

• Ein lokaler Docker-Stack mit persistierenden Volumes sorgt für Datenisolation und Zuverlässigkeit.
• Visuelle Ansichten als JSON-Dateien ermöglichen Git-Versionierung und Peer-Review für analytische Arbeit.
• *.dbcopy-json automatisiert sichere, wiederholbare Kopien von Testdaten.
• Dokumentation (MD, draw.io) im Projektordner hält sie aktuell.
• Vollständiger Sandbox-Modus für Experimente ohne Risiko für die Produktivstabilität.

— Editorial Team