BI hors ligne dans asapBI : Docker et ClickHouse

Développement BI hors ligne dans asapBI : pile locale et vues visuelles

asapBI propose un support complet en mode hors ligne pour le développement BI. Le système utilise une pile Docker locale avec PostgreSQL et ClickHouse, des vues SQL visuelles sauvegardées sous forme de fichiers JSON, ainsi que la gestion de version Git. Cela permet de concevoir des requêtes, d'expérimenter avec les données et de documenter la logique — tout cela sans dépendre de serveurs distants, éliminant ainsi les temps d'indisponibilité dus à des connexions Internet instables.

L'environnement local garantit l'isolement des données, une expérimentation sécurisée et un contrôle de version efficace. Les développeurs ont une maîtrise totale sur les volumes de conteneurs, ainsi que sur l'allocation de CPU et de mémoire.

Avantages de la pile locale

Le développement local résout des défis clés dans la collaboration d'équipe :

• Isolement des données : les volumes Docker sont protégés contre les modifications externes. Aucun risque de perdre des tables de test lors de migrations ou d'opérations de nettoyage.
• Expérimentations sûres : les jointures complexes ou les vues lourdes n'affectent que le conteneur local, pas le cluster partagé.
• Gestion de version Git : les vues visuelles sont enregistrées sous forme de fichiers JSON, permettant des comparaisons, des revues de code et des annulations.
• Jumeau numérique de la base : les changements de schéma, les types de données et les relations peuvent être testés sans impacter la production.

Configuration de l'environnement hors ligne

La mise en place se fait en trois étapes.

1. Cloner le projet depuis Git

Téléchargez le projet dans un dossier local. La structure suit les domaines métiers — finance, ventes, etc. Les fichiers de vues et les fichiers dbcopy-json sont stockés dans le dépôt.

2. Lancer la pile BI via Docker Compose

Utilisez le fichier docker-compose.yml pour exécuter PostgreSQL et ClickHouse. Exemple de configuration :

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

Lancez via l'interface asapBI ou la ligne de commande. Docker télécharge automatiquement les images nécessaires.

3. Remplir la base de données avec des données de test

Utilisez les fichiers *.dbcopy-json pour copier des jeux de données de test. Exemple :

{
  "description": "Copie des clients avec préparation et nettoyage",
  "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(), 'Copie terminée');",
    "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
    }
  ]
}

Sélectionnez les bases source et cible dans l'interface. Utilisez uniquement des données de test provenant des serveurs de développement.

Vues SQL visuelles

Connectez-vous à l'instance ClickHouse locale et créez des vues visuelles. Ces fichiers JSON bénéficient du contrôle de version Git et supportent les revues de code. Les vues sont indépendantes des tableaux de bord, assurant une source unique de vérité pour les calculs.

Avantages :

• Stockage centralisé de la logique de calcul.
• Réutilisation sur plusieurs tableaux de bord.
• Suivi des modifications via Git diff.

Intégration de la documentation

Attachez directement des fichiers de documentation (MD, draw.io) dans le même dossier que la vue. Les mises à jour de la documentation s'effectuent automatiquement lorsque le modèle change. Les fichiers texte sont idéaux pour le traitement par IA et la génération automatisée de documents.

Points clés

• Une pile Docker locale avec volumes persistants assure l'isolement des données et une fiabilité optimale.
• Les vues visuelles sous forme de fichiers JSON permettent le contrôle de version Git et les revues entre pairs pour le travail analytique.
• Les fichiers *.dbcopy-json automatisent la copie sécurisée et reproductible de données de test.
• L'intégration de la documentation (MD, draw.io) dans le dossier du projet maintient celle-ci à jour.
• Un environnement sandbox complet pour expérimenter sans compromettre la stabilité de la production.

— Editorial Team