Как установить и настроить Apache Superset на VPS

MAATRIX

Когда Excel и Google Data Studio перестают справляться с объёмом данных, а покупать лицензии Tableau не хочется ни по деньгам, ни по принципу, разумной альтернативой становится Apache Superset — open-source BI-платформа, которую использует сам Airbnb, где она и родилась. Она умеет строить десятки типов визуализаций, собирать их в интерактивные дашборды и подключаться почти к любой SQL-базе через SQLAlchemy. Ниже — рабочий способ поднять Superset на своём VPS через Docker Compose, без танцев с бубном вокруг Python-зависимостей.

Почему Superset и чем он отличается от Metabase и Redash

Superset — это не облачный SaaS, а полноценное приложение на Flask с фронтендом на React, которое вы разворачиваете сами. Ключевое отличие от Metabase — глубина возможностей: Superset поддерживает более 40 типов графиков (от простых линейных до Sankey-диаграмм и географических карт), SQL Lab для произвольных запросов с автодополнением, ролевую модель доступа на уровне строк (Row Level Security) и кастомные метрики через собственный DSL.

Цена этой мощности — сложность настройки и порог входа. Metabase запускается «из коробки» за пять минут и подходит для небольших команд без выделенного аналитика. Superset — выбор, когда у вас уже есть человек, разбирающийся в BI, и данные, которые нужно резать под разными углами: воронки, когорты, geo-аналитика, кросс-табы с условным форматированием.

По ресурсам Superset прожорливее конкурентов: под продакшн стоит закладывать от 4 ГБ RAM и 2 vCPU только под сам сервис, плюс отдельно ресурсы под базу метаданных и Redis для кэша и очереди задач. Для тестового стенда хватит и 2 ГБ, но с оговоркой — первая сборка образов и прогрев кэша будут заметно медленнее.

Требования к серверу и подготовка окружения

Минимальная конфигурация под продакшн-нагрузку с несколькими пользователями и парой источников данных:

Superset хорошо чувствует себя на выделенном VPS в европейской или американской локации — задержки для веб-интерфейса аналитики не критичны, а вот скорость диска важна для кэша Redis и локальной базы метаданных.

Устанавливаем Docker и Docker Compose plugin:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
sudo apt install -y docker-compose-plugin

Перелогиньтесь или выполните newgrp docker, чтобы группа применилась без перезагрузки сессии.

Разворачиваем Superset через Docker Compose

Официальный образ apache/superset есть на Docker Hub, но для продакшна удобнее собрать связку из трёх контейнеров: сам Superset, PostgreSQL под метаданные и Redis под кэш и очередь Celery (без неё не работают асинхронные запросы и алерты).

Создаём структуру проекта:

mkdir -p /opt/superset && cd /opt/superset
mkdir -p pythonpath

Файл .env:

SUPERSET_SECRET_KEY=замените_на_случайную_строку_минимум_42_символа
POSTGRES_DB=superset
POSTGRES_USER=superset
POSTGRES_PASSWORD=замените_на_надёжный_пароль
DATABASE_DIALECT=postgresql
DATABASE_HOST=superset-db
DATABASE_PORT=5432
DATABASE_DB=superset
DATABASE_USER=superset
DATABASE_PASSWORD=замените_на_надёжный_пароль
REDIS_HOST=superset-redis
REDIS_PORT=6379

Сгенерировать SUPERSET_SECRET_KEY можно так: openssl rand -base64 42.

Файл docker-compose.yml:

services:
  superset-db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - superset_db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5

  superset-redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - superset_redis:/data

  superset:
    image: apache/superset:latest
    restart: unless-stopped
    depends_on:
      - superset-db
      - superset-redis
    env_file: .env
    ports:
      - "127.0.0.1:8088:8088"
    volumes:
      - superset_home:/app/superset_home
      - ./pythonpath:/app/pythonpath_docker
    command: >
      sh -c "superset db upgrade &&
             superset init &&
             gunicorn --bind 0.0.0.0:8088 --workers 4 --timeout 120 'superset.app:create_app()'"

  superset-worker:
    image: apache/superset:latest
    restart: unless-stopped
    depends_on:
      - superset-db
      - superset-redis
    env_file: .env
    command: celery --app=superset.tasks.celery_app:app worker --pool=prefork -O fair -c 2

  superset-beat:
    image: apache/superset:latest
    restart: unless-stopped
    depends_on:
      - superset-db
      - superset-redis
    env_file: .env
    command: celery --app=superset.tasks.celery_app:app beat --pidfile /tmp/celerybeat.pid --schedule /app/superset_home/celerybeat-schedule

volumes:
  superset_db:
  superset_redis:
  superset_home:

Порт 8088 сознательно привязан к 127.0.0.1 — наружу его отдаст reverse-proxy с TLS (об этом ниже).

Для Celery нужен конфиг с настройками очереди — кладём его в pythonpath/superset_config.py:

from celery.schedules import crontab

class CeleryConfig:
    broker_url = "redis://superset-redis:6379/0"
    result_backend = "redis://superset-redis:6379/1"
    imports = ("superset.sql_lab",)
    task_annotations = {
        "sql_lab.get_sql_results": {"rate_limit": "100/s"},
    }
    beat_schedule = {
        "reports.scheduler": {
            "task": "reports.scheduler",
            "schedule": crontab(minute="*", hour="*"),
        },
    }

CELERY_CONFIG = CeleryConfig

FEATURE_FLAGS = {
    "ALERT_REPORTS": True,
}

CACHE_CONFIG = {
    "CACHE_TYPE": "RedisCache",
    "CACHE_DEFAULT_TIMEOUT": 300,
    "CACHE_KEY_PREFIX": "superset_",
    "CACHE_REDIS_HOST": "superset-redis",
    "CACHE_REDIS_PORT": 6379,
    "CACHE_REDIS_DB": 2,
}

В docker-compose.yml добавьте переменную SUPERSET_CONFIG_PATH=/app/pythonpath_docker/superset_config.py в .env, чтобы Superset подхватил файл.

Запускаем:

docker compose up -d
docker compose logs -f superset

Первый старт займёт пару минут — superset db upgrade накатывает схему в PostgreSQL, superset init создаёт роли и права по умолчанию.

Создаём администратора и заходим в веб-интерфейс

По умолчанию образ apache/superset не создаёт пользователя автоматически (в отличие от dev-версии apache/superset:latest-dev), поэтому делаем это вручную:

docker compose exec superset superset fab create-admin \
  --username admin \
  --firstname Admin \
  --lastname Admin \
  --email admin@example.com \
  --password замените_на_надёжный_пароль

После этого проверьте, что приложение отвечает локально:

curl -I http://127.0.0.1:8088

Ожидаемый ответ — HTTP/1.1 302 FOUND (редирект на страницу логина). Если вместо этого ошибка соединения — смотрите логи контейнера superset, чаще всего дело в незавершённой миграции базы.

Настраиваем HTTPS через reverse-proxy

Открывать 8088 напрямую в интернет не стоит — ставим Caddy перед Superset, он сам получит сертификат Let's Encrypt. Подробный разбор установки описан в статье про настройку Caddy с автоматическим SSL, здесь — минимальный конфиг под конкретно Superset:

sudo apt install -y caddy

/etc/caddy/Caddyfile:

bi.example.com {
    reverse_proxy 127.0.0.1:8088 {
        header_up X-Forwarded-Proto https
        flush_interval -1
    }
}

flush_interval -1 отключает буферизацию ответов — важно для стриминга результатов длинных SQL-запросов в SQL Lab, иначе интерфейс может «зависать» в ожидании первого чанка.

sudo systemctl reload caddy

Не забудьте настроить фаервол — открыть 80/443 и закрыть прямой доступ к 8088 извне. Если ещё не делали это на сервере, шаги описаны в статье про настройку UFW.

Подключаем источники данных

Superset подключается к базам через SQLAlchemy-драйверы. В образ apache/superset из коробки встроены драйверы для PostgreSQL, MySQL, SQLite и ещё нескольких СУБД; для остальных (ClickHouse, BigQuery, Snowflake) драйвер нужно установить дополнительно — это самая частая причина ошибки «Could not load database driver».

Пример: подключение к PostgreSQL. В интерфейсе Superset — Settings → Database Connections → + Database, выбираете PostgreSQL и указываете строку подключения:

postgresql://readonly_user:password@your-postgres-host:5432/analytics_db

Если PostgreSQL стоит на отдельном сервере — см. статью про установку и настройку PostgreSQL на VPS. Для аналитики критично создать отдельного read-only пользователя, а не пускать BI-инструмент под суперпользователем:

CREATE ROLE superset_reader WITH LOGIN PASSWORD 'надёжный_пароль';
GRANT CONNECT ON DATABASE analytics_db TO superset_reader;
GRANT USAGE ON SCHEMA public TO superset_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO superset_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO superset_reader;

Для подключения к ClickHouse понадобится драйвер clickhouse-connect — добавьте его в кастомную сборку образа (создайте Dockerfile на основе apache/superset с RUN pip install clickhouse-connect и соберите локально через docker compose build).

После подключения источника Superset может либо работать напрямую с таблицами через SQL Lab, либо вы описываете «датасеты» (Datasets → + Dataset) — виртуальные представления с заданными метриками и вычисляемыми колонками, которые потом используются в чартах.

Настраиваем права доступа и роли

Ролевая модель Superset — то, что отличает его от более простых инструментов. По умолчанию доступны роли Admin, Alpha, Gamma, Public и sql_lab. На практике для команды с несколькими отделами этого недостаточно, и стоит создавать кастомные роли через Settings → List Roles.

Типичная схема для компании с отделами продаж и маркетинга:

• Admin — только 1-2 человека, полный доступ, управление подключениями к базам.
• Analyst (кастомная, на основе Alpha) — может создавать датасеты и дашборды, но без доступа к настройкам БД.
• Sales Viewer (кастомная Gamma-роль) — доступ только к дашбордам с конкретными Row Level Security фильтрами.

Row Level Security (Settings → Row Level Security) автоматически подставляет условие вида WHERE department = 'sales' в запросы для пользователей с определённой ролью — без дублирования дашбордов под каждый отдел.

Нюанс: права считаются пересечением разрешений роли и явных грантов на конкретный дашборд/чарт. Если пользователь видит пустой список дашбордов при «правильной» роли — почти всегда дело в отсутствии прав на датасет, а не в самой роли.

Резервное копирование и обновление

Все настройки, дашборды и подключения Superset хранит в своей PostgreSQL-базе метаданных (не путать с базами-источниками данных). Бэкапить нужно именно её:

docker compose exec superset-db pg_dump -U superset superset > superset_backup_$(date +%F).sql

Разумно вынести это в cron с ротацией и хранением копий вне сервера — принцип 3-2-1 тут работает так же, как для любой продакшн-базы.

Обновление до новой версии образа:

docker compose pull
docker compose up -d
docker compose exec superset superset db upgrade

Перед обновлением стоит проверить changelog проекта — между релизами иногда меняются форматы конфигов (особенно FEATURE_FLAGS).

Частые вопросы