Apache Superset: SQL-запросы, чарты и дашборды
Как собрать проверяемый дашборд в Apache Superset: подключить БД, выполнить SQL Lab, сохранить датасет, построить чарты и настроить фильтры.
Содержание статьи
Аналитик получил готовый SQL, но коллегам нужен экран, где можно выбрать дату и увидеть сумму броней без ручной отправки таблицы. Apache Superset соединяет SQL Lab, датасеты, чарты и дашборды. Ниже построим одну страницу на учебных «Авиаперевозках» и будем сверять каждый шаг с тем же SQL. Описания меню относятся к официальной документации Superset 6.1.0, проверенной 27 сентября 2026 года; перед повторением проверьте названия в своей установленной версии.
Коротко: путь от запроса к дашборду
Сначала подключите SQL-базу с правами чтения и проверьте контрольный запрос в SQL Lab. Затем создайте датасет на таблице либо сохраните запрос как виртуальный датасет, если нужна подготовленная форма. В Explore постройте чарты из этого датасета: карточку суммы, ряд по дням и сравнение групп. Разместите их на одном дашборде, добавьте фильтр времени и протестируйте два состояния.
Вопрос нашего экрана: какова стоимость оформленных броней за полную неделю 3–9 августа 2026 года и какая группа дала больше денег? Выполненный SQL дал 42 561 бронь на 3 377 874 800 ₽. У группы с одним билетом 28 011 броней на 1 586 128 300 ₽, у «2+» — 14 550 на 1 791 746 500 ₽. Эти цифры относятся к синтетически сдвинутой учебной базе, не к реальной авиакомпании.
Superset — открытый проект Apache для анализа и визуализации данных. Он выполняет запросы к подключённой SQL-системе; платформа не исправляет структуру источника. Если факт брони размножен JOIN с билетами, KPI станет неверным независимо от чартов. Поэтому первый артефакт здесь — запрос и контроль зерна, а экран идёт после.
| Слой | Что делает | Проверка |
|---|---|---|
| Database connection | Доступ к SQL-источнику | Только нужные права и схема |
| SQL Lab / Dataset | Запрос и переиспользуемые поля | Зерно, строки, итог |
| Explore / Chart | Агрегация и вид графика | Значения при фильтрах |
| Dashboard | Несколько чартов и фильтров | Один период и доступ читателя |
Установка: только учебная среда по официальному руководству
Quickstart Apache описывает запуск через Docker Compose для локального ознакомления и прямо отделяет его от production-размещения. Здесь мы не переписываем команды, потому что версии, драйверы и требования безопасности меняются. На дату проверки страница Quickstart в разделе 6.1.0 всё ещё указывает тег 6.0.0: перед запуском сверьте инструкцию со своим релизом. Описания экранов ниже взяты из раздела документации 6.1.0.
Для рабочего сервиса нужны ответственные за хостинг, метаданные, аутентификацию, сетевой доступ, драйвер конкретной базы и резервное копирование. Самостоятельный запуск тестового контейнера не является архитектурой публикации отчётов для компании. Перед демонстрацией на реальных данных попросите администратора подтвердить, какие источники и роли допускаются.
Эту статью можно пройти концептуально без установки: все приведённые SQL-запросы выполнены в DuckDB на Parquet-версии учебной базы. Чтобы повторить их именно в Superset, таблицы bookings и tickets должны быть доступны в подключённом SQL-движке. Синтаксис показанных запросов использует обычные JOIN, GROUP BY и временные границы, но диалект даты проверьте для своей БД.
Подключение базы и право на запрос
Администратор создаёт подключение к базе; аналитик выбирает разрешённый источник в SQL Lab. Документация подключения описывает поддержку SQL-источников через драйверы. Не выдавайте подключению права записи только ради построения графиков. Ограничьте его нужной схемой и таблицами; Superset не заменяет права самой базы.
Для упражнения нужна таблица bookings с book_ref, book_date, total_amount и таблица tickets с book_ref. В исходной базе одна бронь может иметь несколько билетов. Поэтому пользователь SQL Lab должен видеть обе таблицы, но не обязательно другие операционные сущности. Для коллективного отчёта лучше подготовить ограниченную витрину, чем давать всем доступ ко всему датасету.
Проверьте доступ под ролью аналитика, которая реально будет строить запросы, а не только под администратором. У роли читателя дашборда задачи другие: ей может быть достаточно готового датасета и опубликованных чартов без SQL Lab. Такое разделение помогает избежать случайного раскрытия деталей и сохраняет понятную ответственность за запросы.
SQL Lab: выполните контроль на детальных данных
Откройте SQL Lab и выполните недельный запрос. Полуоткрытый интервал от 2026-08-03 включительно до 2026-08-10 исключительно покрывает семь полных московских дней. COUNT(DISTINCT book_ref) проверяет количество броней, SUM(total_amount) — их стоимость. Результат должен быть 42 561 и 3 377 874 800 ₽. Не подменяйте исходные даты временем показа страницы: учебный набор исторический.
Если итог не сошёлся, проверьте, куда подключён Superset и есть ли в базе именно сдвинутая учебная версия данных. Запросы здесь выполнялись локально в DuckDB; возможное расхождение с другим движком нельзя списывать на «особенности BI» без сверки строк. Сначала сравните минимум и максимум дат, число уникальных ключей и тип суммы.
Сам результат SQL Lab ещё не является сохранённой общей метрикой. Запишите определение и владельца, прежде чем строить график. Иначе следующий аналитик выполнит SUM после JOIN с билетами и получит другой итог на странице с тем же названием.
SELECT COUNT(*) AS bookings,
COUNT(DISTINCT book_ref) AS unique_bookings,
SUM(total_amount) AS amount
FROM bookings
WHERE book_date >= TIMESTAMP '2026-08-03'
AND book_date < TIMESTAMP '2026-08-10'Как подготовить группу без удвоения суммы
Для разреза «1 / 2+ билета» сначала соберите по book_ref количество строк в tickets. Получится одна строка на бронь. Затем соедините этот результат с bookings по тому же ключу и добавьте категорию через CASE. Выполненный контроль после соединения показал 42 561 строку, 42 561 уникальный book_ref и прежнюю сумму 3 377 874 800 ₽.
Прямой JOIN bookings к каждой записи tickets будет иметь зерно «билет», а total_amount всё ещё хранит цену всей брони. Если сумма вырастет, изменение вполне может выглядеть как успешный рост продаж. Проверка числа строк до и после JOIN — обязательна именно потому, что ошибка даёт гладкий правдоподобный график.
Сохраните подготовленную форму как представление в БД или виртуальный датасет Superset. Если будете обновлять логику группы, укажите, какие чарты от неё зависят. Для более сложного источника SQL-проверка JOIN пригодится отдельно от настроек визуализации.
WITH ticket_counts AS (
SELECT book_ref, COUNT(*) AS ticket_count
FROM tickets GROUP BY book_ref
)
SELECT b.book_ref, CAST(b.book_date AS DATE) AS book_day,
b.total_amount,
CASE WHEN t.ticket_count = 1 THEN '1' ELSE '2+' END AS ticket_bucket
FROM bookings b JOIN ticket_counts t USING (book_ref)Датасет: физическая таблица или сохранённый SQL
Официальный пример Explore показывает работу с датасетом и отмечает, что SQL Lab-запрос для постоянных чартов нужно сначала сохранить как датасет. Физический датасет опирается на уже подготовленную таблицу или view в БД. Виртуальный позволяет использовать запрос как источник визуализаций. Для нашего упражнения запрос выше подходит как виртуальный датасет с полями book_day, total_amount, ticket_bucket.
Не фиксируйте границы учебной недели внутри определения общего датасета, если собираетесь выбирать другие периоды на дашборде. Пусть датасет содержит все разрешённые строки, а фильтр времени задаёт 3–9 августа на уровне чарта и страницы. Иначе селектор другой недели покажет пустоту, хотя в БД есть данные. Для учебной контрольной страницы допускается фиксированный период, но тогда его лучше прямо назвать в заголовке.
В датасете задайте описание полей и общую метрику стоимости. total_amount — стоимость оформленной брони в рублях, не оплаченная выручка. book_day — московская дата. Описания помогают автору следующего чарта не переименовать сумму в «продажи» и не усреднить уже агрегированные данные.
Чарт суммы и дневной ряд в Explore
Создайте первый чарт из подготовленного датасета. Выберите показатель SUM(total_amount) и временной диапазон 3–9 августа 2026 года; карточка должна вернуть 3 377 874 800 ₽. Второй чарт группирует по book_day и показывает ту же сумму в каждом дне. Для 3 августа получится 452 158 300 ₽, для 9 августа — 509 633 600 ₽. Точки должны складываться в недельный итог.
Даты в Explore могут иметь фильтр по умолчанию, не совпадающий с исторической учебной неделей. Снимите относительный «последний период» и выберите абсолютный диапазон. Если оставить фильтр на последние дни, пустой график будет выглядеть как отсутствие данных в источнике, хотя нужные строки лежат в августе 2026-го.
Линия нужна для вопроса «когда менялась сумма», а не для вывода «почему». Не добавляйте к ней тренд-прогноз без основания. После сохранения чарта посмотрите запрос к источнику и сравните итог с SQL Lab; если SQL Lab даёт 3,38 млрд ₽, а график больше, проверьте агрегатор, внутренние фильтры и зерно датасета.
Данные по московским календарным дням; сумма точек — 3 377 874 800 ₽.
Чарт групп: больше броней не значит больше сумма
Третий чарт строится по ticket_bucket и SUM(total_amount). У одиночных броней 28 011 записей, но сумма 1 586 128 300 ₽. У группы «2+» записей меньше — 14 550, а сумма выше — 1 791 746 500 ₽. Поэтому подпишите столбцы деньгами и не пытайтесь делать вывод о числе броней по их высоте. Для количества нужен отдельный показатель COUNT(*) на подготовленном зерне.
Доля группы «2+» в недельной стоимости 53,04%. Если визуал показывает долю от текущего фильтра, убедитесь, что числитель и знаменатель относятся к одной неделе. При выборе отдельного дня доля должна пересчитаться по этому дню; сохранённая в тексте недельная цифра не заменяет такой меры. Для объяснения пользователю рядом с графиком достаточно небольшой таблицы с двумя строками.
Сортировка категорий должна быть стабильной: «1», затем «2+». Автоматическая сортировка по убыванию меняет их местами после обновления и затрудняет сравнение. Цвет может помогать различению, но подписи и единицы обязаны оставаться понятными при печати или в узком браузере.
| Группа | Броней | Сумма, ₽ |
|---|---|---|
| 1 | 28 011 | 1 586 128 300 |
| 2+ | 14 550 | 1 791 746 500 |
| Всего | 42 561 | 3 377 874 800 |
Дашборд и native filters: одна дата для всех чартов
Разместите карточку суммы и количества сверху, под ними — дневную линию и сравнение групп. В режиме редактирования добавьте фильтр даты и задайте его область действия на все нужные чарты. В официальном руководстве по дашборду описаны Explore, сохранение чарта и настройка фильтров. Документация помечена версией 6.1.0; в другом релизе расположение кнопок может отличаться.
Проверьте два состояния. На всей неделе сумма 3 377 874 800 ₽ и 42 561 бронь; при выборе только 3 августа — 452 158 300 ₽ и 5 665 броней. Линия должна сжаться до одного дня, групповой чарт — показать суммы только этого дня. Если хотя бы одна карточка осталась недельной, у страницы нет единого контекста, даже если визуально всё выглядит аккуратно.
Не добавляйте фильтр группы без задачи. Когда читатель выбирает «2+», сравнение двух групп исчезает; это может затруднить анализ. Для первого экрана можно оставить обе группы на графике и фильтровать лишь дату. Сохраните контрольные состояния в чек-листе публикации, чтобы новый автор чарта не забыл подключить его к фильтру.
Права: SQL Lab и просмотр дашборда — разные возможности
Документация безопасности Superset разделяет роли, доступ к датасетам и право работать в SQL Lab. Пользователь, который смотрит готовый агрегат, не обязательно должен выполнять произвольный SQL. Пользователь SQL Lab получает доступ к подключённой базе в пределах прав соединения, поэтому ограниченный пользователь самой БД остаётся первым барьером.
Не рассчитывайте, что спрятанный чарт защищает чувствительную колонку. Для реального источника проверьте права доступа к схеме и датасету, а затем откройте дашборд под ролью читателя. Если нужно ограничить строки по подразделению, это отдельная политика, которую следует тестировать на запросах и на опубликованной странице. Учебный пример не содержит персональных данных.
Для первого релиза запишите владельца источника, владельца датасета и владельца страницы. При смене прав пользователь может видеть оболочку дашборда, но потерять данные отдельных чартов. Это рабочий инцидент, а не косметический дефект: нужна понятная процедура проверки и исправления.
Обновление и технический долг датасета
Если исходная БД дописывается ежедневно, дашборд может показывать новые строки, но это не гарантирует полноту дня. Укажите правило закрытия периода и время последнего успешного поступления данных. Если замена витрины изменила имя total_amount или тип даты, зависимые виртуальные датасеты и чарты надо проверить вместе. Сам факт, что SQL Lab выполняет запрос, не означает, что все сохранённые чарты используют его текущую версию.
Следите за числом строк и уникальных ключей на подготовленном зерне. В неизменном учебном периоде они оба равны 42 561. При новом периоде ожидаемое значение должно приходить из независимого контрольного запроса, а не из цифры на самом дашборде. Сравнение отчёта с его же экспортом не является независимой проверкой.
Если SQL в виртуальном датасете усложняется, вынесите устойчивую логику в управляемую витрину БД с ревью и тестом. Так несколько чартов будут опираться на одну версию расчёта. Но не переносите каждую простую группировку ради архитектурной красоты: сначала измерьте цену повторения и риск дрейфа.
Шесть ошибок, которые дают красивую неверную страницу
Первая — суммировать total_amount после JOIN на уровне билета. Вторая — оставить фильтр «последние дни» и решить, что исторических данных нет. Третья — сохранить запрос с жёстким недельным WHERE как общий датасет и ждать, что селектор покажет следующую неделю. Четвёртая — считать COUNT(*) на уже агрегированной таблице «день × группа», получая 14 вместо 42 561.
Пятая — подключить native filter только к линии, оставив KPI за весь период. Шестая — выдать доступ в SQL Lab тем, кому нужен только просмотр, и предположить, что безопасность обеспечена интерфейсом. Для каждого случая есть короткий тест: число строк, дата диапазона, два состояния фильтра и учётная запись читателя. Эти проверки дешевле расследования решения, принятого по неверной сумме.
Даже корректный график может ошибочно назвать стоимость оформленных броней выручкой. Возвраты и фактические платежи здесь не учитываются. Напишите определение на странице и в метрике датасета. Когда финансовая команда добавит данные об оплатах, это будет новая метрика с новым источником, а не переименование старой.
Частые вопросы и следующий шаг
«Нужно ли знать SQL для Superset?» Чарты можно строить через Explore, но SQL помогает проверить зерно, подготовить сложный датасет и объяснить расхождение. «Можно ли сделать чарт сразу из результата SQL Lab?» Для постоянного чарта запрос сохраняют как датасет либо используют физическую таблицу. «Почему историческая неделя пуста?» Проверьте относительный фильтр времени по умолчанию и выбранную базу.
«Чем виртуальный датасет отличается от таблицы?» Он опирается на сохранённый SQL-запрос, тогда как физический указывает на таблицу или view источника. «Можно ли давать всем SQL Lab?» Нет, права на произвольные запросы и просмотр готового агрегата решают разные задачи. «Почему фильтр меняет не всё?» Проверьте его область действия и поля дат у чартов.
Сверьте недельный SQL выше в тренажёре SQL с нуля, затем набросайте один экран по чек-листу дашборда. Если команде важнее вопросы через конструктор, прочитайте разбор Metabase; выбор зависит от процесса и прав, а не только от названия визуализаций.
Материалы по теме
Yandex DataLens: как собрать первый дашборд
Пошагово собираем дашборд в Yandex DataLens: подключение, датасет, вычисляемые поля, чарты, селекторы и доступы. Числа сверены SQL.
Metabase: вопросы, SQL и дашборды без программиста
Как работать в Metabase: собрать вопрос в конструкторе или SQL, сохранить модель, связать фильтры дашборда, настроить подписку и безопасный доступ.
Дашборд: что это такое, из чего состоит и какие бывают
Дашборд — это страница с несколькими регулярно обновляемыми показателями для одного решения. Чем он отличается от отчёта и BI-системы, какие бывают дашборды, из чего состоят и как посчитать KPI-карточки на SQL.