Работая с аналитикой, мы часто сталкиваемся с одной и той же проблемой: данные есть, но исследовать их неудобно.

Представим типичную ситуацию. Есть таблица с десятками колонок и миллионами строк. Нужно понять, почему изменился какой-то показатель — например, выручка или конверсия. Обычно это превращается в цепочку SQL-запросов: сначала агрегируем данные по стране, потом по городу, потом по конкретному сегменту пользователей и тд.

Если таких гипотез несколько, количество запросов быстро растёт с геометрической прогрессией. Каждый новый уровень детализации требует отдельного SQL.

В какой-то момент хочется просто кликнуть по графику и мгновенно увидеть более детальные данные. Без написания нового запроса.

Именно здесь на помощь приходят BI-инструменты. Один из самых популярных open-source инструментов для аналитики — Apache Superset.

В этой статье я разберу:

как устроен Apache Superset
какие компоненты стоят за его архитектурой
как работают датасеты и фильтры
что такое технология Drill в аналитике
и как настроить и использовать Drill By / Drill Down для исследования данных

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

Используемая версия Superset: 6.0.1

Apache Superset — это open-source платформа для бизнес-аналитики и визуализации данных.

Она позволяет:

писать SQL-запросы
строить графики
собирать дашборды
исследовать данные через интерактивные фильтры

Superset не является полноценным хранилищем данных. Он работает как слой аналитики поверх существующих баз данных.

Для работы с Superset обычно требуется:

источник данных (PostgreSQL, ClickHouse, MySQL и др.)
минимальные навыки написания SQL-запросов

Перед запуском Superset в production также необходимо настроить основной конфигурационный файл: superset_config.py

В качестве примера я покажу и объясню, как настроен мой:

Ключ для подписей сессионных cookies и шифрования чувствительных данных в БД

SECRET_KEY = os.getenv("SECRET_KEY_APACHE", "super_secret_super_secret_super_secret_super_secret_super_secret")

Креды к БД с метаданными Apache Superset

DB_USER = os.getenv("DB_USER") DB_PASSWORD = os.getenv("DB_PASSWORD") DB_HOST = os.getenv("DB_HOST") DB_PORT = os.getenv("DB_PORT") DB_NAME = os.getenv("DB_NAME")

Подключение к БД Апачи

SQLALCHEMY_DATABASE_URI = f"postgresql+psycopg2://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}"

Флаги для настройки Апачи

FEATURE_FLAGS = {

# Флаг для использования Drill by в Апачи

"DRILL_TO_DETAIL": True,

}

Для хранения результатов асинхронных воркеров

REDIS_HOST = os.getenv("REDIS_HOST", "redis") REDIS_PORT = os.getenv("REDIS_PORT", "6379")

Настройка класса воркера

class CeleryConfig: broker_url = f"redis://{REDIS_HOST}:{REDIS_PORT}/0" imports = ( "superset.sql_lab", "superset.tasks.scheduler", ) result_backend = f"redis://{REDIS_HOST}:{REDIS_PORT}/0" worker_prefetch_multiplier = 10 task_acks_late = True

CELERY_CONFIG = CeleryConfig

Хранилище результатов асинхронных SQL-запросов

RESULTS_BACKEND = RedisCache( host=REDIS_HOST, port=int(REDIS_PORT), key_prefix="superset_results" )

Разберём ключевые параметры:

SECRET_KEY - используется для подписи сессионных cookies и для шифрования/защиты чувствительных данных, которые Superset хранит в своей БД метаданных.

SQLALCHEMY_DATABASE_URI - это ключевая настройка, которая указывает в какой бд хранить метаданные. В моём случае это PostgreSQL через драйвер psycopg2.

FEATURE_FLAGS - список дополнительных опций.
- DRILL_TO_DETAIL - включает функциональность “drill to detail/drill down” в UI интерфейсе. При нажатии правой кнопки мыши появляются новые кнопки, которые открывают новые возможности для аналитики (об этом будет ниже).

CELERY_CONFIG - конфигурация Celery-воркеров. Если этот блок не прописан - Superset работает в синхронном режиме через Gunicorn. Если прописан - тяжёлые задачи уходят в фон:

broker_url - адрес Redis, откуда воркеры берут задачи.
result_backend - адрес Redis, куда воркеры кладут результаты выполненных запросов.
worker_prefetch_multiplier - сколько задач воркер берёт из очереди «авансом» до завершения текущей.
task_acks_late - задача подтверждается как выполненная только после завершения, а не при получении. Защищает от потери задачи при падении воркера.

RESULTS_BACKEND - отдельная настройка хранилища результатов асинхронных SQL-запросов из SQL Lab. Без неё асинхронные запросы работать не будут, даже если Celery настроен.

Архитектура и воркеры в Apache Superset

Superset состоит из нескольких компонентов:

Веб-сервер - обрабатывает HTTP-запросы от пользователей, рендерит UI, формирует SQL-запросы.
Воркеры (Celery Workers) - выполняют задачи в фоне асинхронно (если у вас настроена конфигурация).
Брокер сообщений - очередь задач между веб-сервером и воркерами.
БД метаданных - хранит всё состояние Superset.

Важно понимать, что Apache Superset это Flask приложение.
Gunicorn - это HTTP-сервер, на котором работает Flask-приложение Superset. При запуске он поднимает несколько Gunicorn-воркеров - отдельных процессов, каждый из которых может обрабатывать один HTTP-запрос одновременно.

Если в вашей конфигурации не настроены воркеры - то, все ваши sql-запросы будут выполняться синхронно по 4-м Gunicorn-воркерам.

Остальные воркеры в Superset построены на библиотеке Celery (это библиотека для асинхронных задач). Superset использует Celery как основу для всех своих фоновых операций при использовании воркеров.

Виды асинхронных воркеров в Superset:

Celery Worker - это отдельный питоновский процесс, который «подхватывает» задачи из очереди и выполняет их в фоне, не блокируя UI. Количество задач, которые воркер может выполнять параллельно, зависит от размера его пула процессов (параметр -c).

celery --app=superset.tasks.celery_app:app worker --pool=prefork -O fair -c 4

Celery Beat - это отдельный планировщик (по типу cron), который по расписанию отправляет задачи воркерам.
Важный нюанс: Beat должен работать строго в одном экземпляре. Если запустить два Beat-процесса, задачи будут дублироваться - отчёты начнут приходить дважды, нагрузка удвоится. Об этом прямо указано в докуметации Superset.

celery --app=superset.tasks.celery_app:app beat --pidfile /tmp/celerybeat.pid -l INFO

Есть также Flower. Это веб-интерфейс для наблюдения за воркерами. Он Показывает активные задачи, историю, ошибки, загрузку воркеров. Доступен на http://localhost:5555 .

celery --app=superset.tasks.celery_app:app flower

Стоит понимать, что Gunicorn-воркеры и Celery-воркеры - это разные вещи. Первые обслуживают HTTP, вторые выполняют фоновые задачи.

Важный нюанс: асинхронные запросы не включаются автоматически на стороне UI. Нужно зайти в settings, выбрать Database Connections, найти ваше подключение к бд, редактировать его и в меню Advanced поставить галочку около Asynchronous Query Execution

Датасеты в Apache Superset: что это "на самом деле?"

Важно понимать, что Superset не хранит внутри себя датасеты. Он хранит лишь запросы и показывает последние данные на их основе.

Все датасеты в Superset делятся на два вида: Physical и Virtual. Их разница в том, где заканчивается ответственность Superset и где начинается ответственность БД.

Физические (physical) запросы - это ссылка на готовую таблицу в базе (SELECT ... FROM schema.table). Superset просто читает оттуда данные, как из базового источника.

Виртуальные (virtual) запросы - это текст SQL-запроса, сохранённый в Superset (например, SELECT ... FROM schema.table JOIN b ...). Когда строится график, Superset подставляет этот SQL как подзапрос и уже к его результату применяет свои группировки/фильтры/лимиты. То есть в virtual вы заранее фиксируете слой преобразований именно в Superset.

БД метаданных Apache Superset

Для Superset обязательно нужна отдельная база для метаданных - там хранятся определения чартов, дашбордов и прочих вещей, которые мы видим, когда открываем Superset. Если не указать в superset_ config.py настройки для этой базы, то будет использована встроенная база данных SQLite.

SQLite - это встроенная, бессерверная база данных. В контексте Docker это означает, что файл superset.db живёт внутри контейнера, и при docker compose down или пересборке образа он уничтожается вместе со всеми дашбордами, чартами и датасетами.

Конечно, если сделать монтирование, то всё останется целым, но SQLite имеет и другие минусы:
- к SQLite нельзя подключиться снаружи контейнера для бэкапа или мониторинга
- SQLite блокирует файл при записи, что критично при работе нескольких воркерах Superset

Официальная документация Superset прямо указывает, что для production SQLite неприемлема и рекомендует PostgreSQL или MySQL. Также там советуется использовать управляемый облачный сервис (Amazon RDS, Google Cloud SQL) для решения вопросов с бэкапом.

SQL Lab

SQL Lab - это встроенный редактор SQL и “песочница” для работы с данными.

В SQL Lab можно писать и запускать SQL‑запросы, сразу видеть результат, сохранять часто используемые запросы, а также дебажить/подбирать фильтры и агрегации. Оттуда же можно превратить готовый запрос в виртуальный датасет и дальше уже строить по нему графики и дашборды.

Фильтры

В Superset есть два вида фильтров. Статичные и Нативные.

Статичные фильтры создаются на уровне графика. Они относятся исключительно к этому графику и представляют из себя фиксированные условия WHERE.

Нативные фильтры создаются на уровне дашборда. Они относятся к выбранным графикам на этом дашборде и видны пользователям. С помощью них происходит кросс-фильтрация.

Кросс-фильтрация - это когда клик по элементу одного графика автоматически фильтрует другие графики на дашборде.
У каждого нативного фильтра есть текущее значение - то, что в нем выбрано прямо сейчас. Обычно это значение устанавливает сам пользователь вручную через UI. Но при кросс-фильтрации Superset делает это автоматически: он берёт то, на что пользователь кликнул в графике, и записывает это значение в нативный фильтр. Остальные графики, которые «слушают» этот фильтр, сразу перестраиваются.

То есть механика кросс-фильтрации такая:

Пользователь кликает по бару/строке в графике (например, «Россия»)
Superset автоматически выставляет значение «Россия» в нативный фильтр
Все остальные графики дашборда, привязанные к этому фильтру, перестраиваются с условием WHERE country = 'Россия'

Визуально это выглядит как мгновенная синхронизация всех графиков на дашборде.

Drilling, отец Drill Down и Drill By

Drilling - это общая концепция в BI, которая позволяет пользователю менять уровень детализации данных одним кликом. Ключевая идея: аналитик начинает с широкой картины и последовательно «углубляется» в данные до нужного уровня.
Пример:
Общий уровень
Выручка: 1M$ (год)
↓ drilling
Выручка: RU=600k, US=400k (страны)
↓ drilling
Выручка RU: Москва=300k, СПб=200k, регионы=100k (города)

Drilling включает в себя Drill Down, Drill Up, Drill By, Drill Through и Drill to Detail. Разберем их все подробнее.

Drill Down - переход по строго предопределённой иерархии от общего к частному. Данные не меняются - они просто перехрдят на следующий уровень. Для Drill Down нужно минимум 2 уровня иерархии, иначе нечего разворачивать

Drill Up - операция, обратная Drill Down. Позволяет вернуться на уровень выше по иерархии.

Drill By - это Drill Down без иерархии. Вместо того чтобы заранее прописывать иерархию нужных полей, пользователь сам выбирает поле для просмотра его детализации.
Главное преимущество: не нужно знать заранее, какие связи между данными интересны аналитику. Drill By позволяет исследовать данные свободно, без написания запросов.

Drill Through - переход от текущего дашборда к другому, более детальному. Контекст (фильтры) автоматически передаётся в новый дашборд. Используется когда нужно перейти от сводного дашборда к детальному в отдельном представлении.

Drill to Detail - открывает таблицу с данными до агрегации.
Например, кликнул на «выручка России = 600k$» -> видишь список всех отдельных регонионов, составляющих эту сумму. Данные те же, просто без агрегации.

Чтобы эти фильтры работали в Superset, необходимо прописать соответствующий флаг в superset_ config.py .

"DRILL_TO_DETAIL": True

При добавлении этого флага, в Superset появляется новое крутое контекстное меню. Нажимаем правой кнопкой мыши по интересующему нас значению из чарта и видим:

Я буду рассматривать только Drill By. При наведении на Drill By, мы видим все колонки датасета (даже те, которые мы не включили в график):

Как только мы выберем одну из интересующих нас колонок, откроется новое окно с выполненным условие WHERE

Можно пойти дальше и ещё раз выбрать какое-то значение и использовать Drill By.

Вверху показана линия всех условий WHERE - Название поля (значение поля)

Поздравляю, теперь вы научились применять и настраивать технологию Drill By в Apache Superset :)

Заключение:

Apache Superset помог нашим аналитикам с помощью Drill Down и нативной фильтраций данных. По нему действительно удобно анализировать данные до самого детального уровня (особенно когда в одной таблице 60+ колонок и по миллиону записей в день). Но, перед тем, как использовать Superset, нужно понимать для чего он вам нужен. И исходя из этого, его необходимо грамотно и правильно настроить. Без настроенной БД для метаданных, без правильно сконфигурированных датасетов и флагов - большая часть возможностей не будет у вас работать.

Получается, что классический Drill Down с жёсткой иерархией в современных версиях, фактически вытеснен более гибким Drill By - что является осознанным решением команды Apache.

Apache Superset 2026. Как работает Drill Down и Drill By