Redash или Apache Superset: что выгоднее и когда

MAATRIX

Когда в команде накопилось десяток SQL-запросов, которые каждый раз копируют из чата, и три версии одной и той же таблицы в Excel — пора ставить self-hosted BI. Дальше начинается развилка: Redash обещает «SQL-запрос за пять минут и дашборд из него», Superset — «настоящая BI-платформа с ролями и сорока типами графиков». Оба open-source, оба ставятся через Docker Compose на свой VPS, но требуют разных ресурсов и разного уровня вовлечённости команды. Разберём, где каждый выигрывает и во сколько это обходится по железу.

Архитектура и философия: SQL-редактор против BI-платформы

Redash изначально проектировался как «удобная обёртка над SQL» — вы пишете запрос, привязываете к нему один из десятка типов визуализации (график, таблица, счётчик, pivot), собираете виджеты на дашборд. Стек простой: веб-сервер на Flask, Celery-воркеры, которые реально исполняют запросы к внешним источникам, Redis как брокер очередей и своя Postgres-база под метаданные (пользователи, запросы, дашборды). Никакого промежуточного семантического слоя нет — что написали в SQL, то и увидели на графике.

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

Из этой разницы в философии вытекают все остальные различия — ресурсы, порог входа, состав команды, для которой инструмент подходит.

Ресурсы: сколько RAM, CPU и диска нужно каждому

Оба решения тянут за собой похожий набор зависимостей — веб-процесс, воркеры, Redis, Postgres под метаданные, — но нагрузка распределяется по-разному. У Redash тяжесть в воркерах: они забирают результат запроса к внешней базе целиком в память процесса перед тем, как отдать его в кеш и на фронтенд, поэтому память скачет вместе с объёмом ваших SQL-выборок. У Superset тяжесть смещена к самому веб-процессу и фронтенду: рендеринг сложных графиков, кэш метаданных датасетов и обработка Row Level Security съедают память ровнее, но стабильно выше на старте.

Точный расчёт по числу пользователей и дашбордов для Redash разобран отдельно в статье сколько RAM нужно для Redash — там же объяснено, почему один неаккуратный SELECT * без LIMIT может съесть память воркера целиком. Для Superset аналогичный ориентир — от 4 ГБ RAM под тестовый стенд и от 8 ГБ под продакшн с несколькими активными пользователями; на первой сборке образов и прогреве кэша расход временно выше, чем в установившемся режиме.

Установка и разворачивание через Docker Compose

Redash разворачивается быстрее и предсказуемее — официальный docker-compose.yml поднимает пять сервисов и запускается за несколько минут:

git clone https://github.com/getredash/redash.git
cd redash
docker compose run --rm server create_db
docker compose up -d

После первого запуска остаётся создать администратора через веб-мастер и добавить источники данных в UI. Подробный пошаговый разбор, включая создание .env с секретами и настройку reverse-proxy, — в статье установка и настройка Redash на VPS; там же разобраны типовые ошибки первого запуска.

Superset требует больше подготовительных шагов: нужно сгенерировать SECRET_KEY, инициализировать базу метаданных (superset db upgrade), создать администратора отдельной командой, загрузить примеры данных (опционально) и только потом поднимать веб-процесс:

git clone https://github.com/apache/superset.git
cd superset
docker compose -f docker-compose-image-tag.yml up -d
docker compose exec superset superset fab create-admin
docker compose exec superset superset db upgrade
docker compose exec superset superset init

Первый прогон дольше — сборка фронтенд-ассетов и инициализация ролей занимают несколько минут, а не секунд. Полный разбор с подключением к PostgreSQL и ClickHouse — в статье установка Apache Superset на VPS. После разворачивания оба сервиса стоит прятать за reverse-proxy с TLS — принципы настройки одинаковы для любого self-hosted веб-приложения на Docker.

Визуализации, дашборды и SQL Lab

Здесь разница ощущается сразу при первом клике. В Redash набор визуализаций скромный: линейные и столбчатые графики, таблицы, pivot, счётчики, карты — для регулярных отчётов и мониторинга метрик этого обычно достаточно, но для сложной аналитики (когорты, воронки, кастомные срезы с условным форматированием) инструментов не хватает. Зато создание дашборда занимает минуты: написали запрос, выбрали тип графика, перетащили виджет на дашборд.

Superset даёт более 40 типов графиков, включая Sankey-диаграммы, geo-карты с полигонами, box plot, waterfall и партиционированные деревья, плюс кросс-фильтрацию — клик по одному графику фильтрует все остальные на дашборде без переписывания запросов. SQL Lab — отдельный полноценный редактор с автодополнением, сохранением запросов в датасеты и возможностью экспортировать результат в CSV или отправить как новый Chart. Плата за эту мощность — время: чтобы выжать из Superset красивый дашборд, нужно сначала описать Dataset с метриками, а не просто вставить SQL.

Оба поддерживают запланированное обновление данных и алерты по email/Slack при выходе метрики за порог — механизм похожий, но в Redash он проще настроить (Alert Destinations в UI), в Superset — гибче за счёт SQL Lab.

Источники данных, права доступа и безопасность

Redash подключается к источникам данных через отдельные Python-коннекторы — их около полусотни: PostgreSQL, MySQL, ClickHouse, BigQuery, MongoDB, Google Sheets и другие. Права доступа простые: группы пользователей с доступом к конкретным источникам данных и дашбордам, без построчной фильтрации.

Superset использует SQLAlchemy — это даёт доступ практически к любой базе, для которой есть SQLAlchemy-диалект, включая менее популярные аналитические СУБД. Важное отличие — Row Level Security: можно настроить так, что один и тот же дашборд разным пользователям покажет только их часть данных (например, менеджер видит продажи только своего региона) без создания отдельных копий графиков. Для сценариев embedded-аналитики (встраивание дашборда на внешний сайт для клиентов) это часто решающий аргумент в пользу Superset.

Если источник данных — ClickHouse или классический PostgreSQL, оба инструмента подключаются без проблем через готовые драйверы; выбор конкретной аналитической СУБД под нагрузку разобран в статье ClickHouse или PostgreSQL для аналитики: что выбрать. На стороне сервера оба приложения стоит держать за reverse-proxy с ограничением доступа по IP или VPN, если дашборды не предназначены для публичного просмотра — сами приложения не рассчитаны на прямой доступ из интернета без дополнительного слоя защиты.

Когда выбрать Redash, а когда Superset

Redash оправдан, когда:

• Нужны быстрые ответы на вопросы «покажи мне число/график по этому SQL» без построения сложной модели данных;
• В команде есть люди, уверенно пишущие SQL, но нет выделенного BI-аналитика;
• Дашборды в основном для внутреннего мониторинга метрик — воронка регистраций, конверсия, статус очередей;
• Бюджет на сервер ограничен, а требования к визуализациям скромные.

Superset оправдан, когда:

• Нужны сложные визуализации — geo-аналитика, Sankey, кросс-фильтрация между графиками на одном дашборде;
• Требуется построчное разграничение доступа к данным (Row Level Security) — например, для клиентского портала или мультитенантной SaaS-аналитики;
• В команде есть человек, готовый потратить время на описание Datasets и метрик, а не просто писать сырой SQL;
• Планируется встраивание дашбордов на внешние сайты (embedded analytics) для клиентов или партнёров.

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

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