Metabase: вопросы, SQL и дашборды без программиста
Как работать в Metabase: собрать вопрос в конструкторе или SQL, сохранить модель, связать фильтры дашборда, настроить подписку и безопасный доступ.
Содержание статьи
Менеджер спрашивает, сколько стоят брони за неделю, и хочет сам выбрать день на экране. В Metabase один и тот же вопрос можно собрать в графическом конструкторе или написать SQL, затем сохранить результат как вопрос и добавить на дашборд. Ниже покажем оба пути на учебных «Авиаперевозках», проверим цифры и разберём, почему публичная ссылка не подходит для чувствительных данных. Возможности сверены с официальной документацией Metabase 27 сентября 2026 года.
Коротко: вопрос → сохранение → дашборд
Подключите БД с правами на нужные таблицы. В меню + New создайте Question через query builder, если достаточно фильтра, группировки и суммы, либо SQL/Native query, если надо подготовить сложное зерно. Сохраните вопрос с ясным названием и описанием, затем добавьте его на дашборд. Для интерактивности добавьте фильтр даты и подключите его к каждой карточке, которую он должен менять.
Metabase называет question сохранённым запросом, его результатом и визуализацией. Поэтому «вопрос» здесь не просто строка текста. Один вопрос может быть таблицей, KPI или графиком; дашборд объединяет несколько вопросов и добавляет общие фильтры. Если метрика должна переиспользоваться, договоритесь о её едином определении до копирования чарта.
Наш учебный вопрос: стоимость оформленных броней за полную неделю 3–9 августа 2026 года. Независимый SQL даёт 42 561 уникальную бронь и 3 377 874 800 ₽. Это не оплаченная выручка. Для повторения можно использовать те же исходные таблицы bookings и tickets, что в проектировании дашборда; в собственной установке Metabase их должен подключить администратор.
| Объект | Задача | Проверка |
|---|---|---|
| Question | Один запрос и его визуализация | Число совпало с SQL |
| Model | Переиспользуемая подготовленная форма | Поля и зерно описаны |
| Dashboard | Несколько вопросов и фильтров | Один период во всех карточках |
Подключение БД и первая проверка источника
Metabase запрашивает данные из подключённой базы. Для учебного кейса нужны bookings с уникальным book_ref, датой и суммой, а также tickets для группировки по числу билетов. Начните с bookings: проверьте минимум и максимум даты, тип total_amount, число строк и пропуски. На выбранной неделе book_ref, book_date и total_amount не пусты. Если соединение работает, но ноль строк, возможно, выбран другой срез базы или относительный фильтр даты.
Учебная база — производная от демо-базы Postgres Professional с календарным сдвигом; это не данные реального перевозчика. Запись суммы в рублях следует понимать как стоимость оформленных броней. Реальная система может хранить отмены и платежи в других таблицах, поэтому определение «выручка» потребует дополнительного источника и правил признания.
Право читать таблицы лучше ограничить на стороне БД и Metabase. Если вы отдаёте коллеге готовый дашборд, ему может не требоваться доступ к детальным бронированиям или SQL-редактору. Проверка от имени автора недостаточна: откройте объект под ролью конечного читателя, чтобы увидеть действительно доступную ему страницу.
Конструктор вопросов: сумма и группировка без SQL
В + New → Question выберите bookings, поставьте фильтр даты 3–9 августа включительно и добавьте Summarize для суммы total_amount и количества строк. Если интерфейс предлагает относительный период вроде «последние 30 дней», замените его абсолютной учебной неделей. Итог должен быть 3 377 874 800 ₽ и 42 561. В руководстве query builder этот процесс описан как последовательность источника, фильтров и итогов.
Затем сгруппируйте сумму по календарному дню book_date. Получится семь строк: 3 августа 452 158 300 ₽, 9 августа 509 633 600 ₽. Выберите линию, поскольку здесь вопрос о динамике по дням. Перед сохранением посмотрите таблицу результата: график может красиво интерполировать значения, но только таблица ясно покажет, не пропал ли день и не съехала ли временная зона.
Конструктор удобен, когда исходное зерно уже правильное. Не начинайте в нём с прямого соединения bookings и tickets для суммы броней: многоместная бронь повторится по количеству билетов. Если нужен такой разрез, подготовьте по одной строке на book_ref через модель или SQL-вопрос, а затем отдайте конструктору безопасный источник.
Семь точек складываются в 3 377 874 800 ₽ за полную неделю.
SQL-вопрос: независимый контроль числа
В + New → SQL/Native query выберите ту же базу и выполните запрос ниже. Он считает уникальные брони и сумму на полуоткрытом интервале: от 3 августа включительно до 10 августа исключительно. Ответ 42 561 и 3 377 874 800 ₽ был независимо получен в DuckDB на той же учебной Parquet-базе. При переносе в PostgreSQL проверьте часовой пояс даты и соответствие выгруженных таблиц.
SQL полезен, когда визуальный конструктор скрывает зерно или нужно явно проверить диапазон. Но сам SQL-вопрос не наследует автоматически каждый фильтр дашборда. Документация Metabase указывает: для подключения фильтра к native-запросу нужно добавить переменную или field filter и связать её с полем. Без этого KPI может оставаться недельным, пока линия показывает один день.
Сохраните вопрос с названием «Стоимость оформленных броней, 03–09.08.2026» либо замените фиксированные даты параметром, если он предназначен для регулярного отчёта. Не выдавайте исторический SQL с жёстким WHERE за динамический недельный виджет: новый селектор не создаст строки вне границ запроса.
SELECT COUNT(DISTINCT book_ref) AS bookings,
SUM(total_amount) AS amount
FROM bookings
WHERE book_date >= TIMESTAMP '2026-08-03'
AND book_date < TIMESTAMP '2026-08-10'Модель: общая подготовленная форма для нескольких вопросов
Модели Metabase дают переиспользуемую основу для последующих вопросов. В нашем кейсе логика по билетам должна сначала получить ticket_count на book_ref, затем присоединить эту единственную строку к брони. Модель с полями book_ref, book_day, total_amount, ticket_bucket позволит строить сумму, количество и дневной ряд без повторения сложного JOIN в каждой карточке.
Проверьте модель тремя числами после соединения: строк 42 561, уникальных book_ref 42 561, сумма 3 377 874 800 ₽ за неделю. Если строк стало больше, модель не готова к публикации. Не прячьте проблему COUNT(DISTINCT) в одном виджете: сумма остаётся завышенной. Когда модель построена SQL-запросом, настройте метаданные полей, чтобы конструктор корректно распознавал дату, категорию и числовой показатель.
Модель не обязана быть сложной. Если исходная база уже даёт проверенную витрину одной строки на бронь, используйте её. Сохраняйте ровно ту логику, которую команда должна переиспользовать, и назначьте владельца изменений. Один общий источник проще исправить, чем пять почти одинаковых SQL-вопросов с разными условиями.
| Билетов | Броней | Стоимость, ₽ |
|---|---|---|
| 1 | 28 011 | 1 586 128 300 |
| 2+ | 14 550 | 1 791 746 500 |
| Всего | 42 561 | 3 377 874 800 |
Визуализация: отдельный вопрос на отдельный ответ
Сохраните карточку суммы, линию по дням и сравнение групп как три вопроса. Карточка отвечает «сколько», линия — «когда», столбцы — «какая группа дала больший вклад». Если на одной картинке показать и рубли, и число броней без ясных осей, читатель смешает масштаб с составом. Лучше компактная таблица под графиком, чем второй нечитаемый ряд с другой единицей.
Для группы «2+» сумма 1 791 746 500 ₽ выше, чем у одиночных броней, хотя записей меньше: 14 550 против 28 011. Это важное различие. Не делайте вывод «группа продаётся лучше» лишь по сумме: цена на одну бронь и состав маршрутов могут отличаться. Статья о выборе диаграммы поможет подобрать вид под конкретный вопрос.
Названия сохранённых вопросов должны содержать метрику, период и единицу. «Продажи» не подходит нашему учебному набору, потому что факт платежа неизвестен. Сохраните вопросы в понятной коллекции и добавьте описание происхождения данных; следующий автор дашборда не обязан помнить, почему сумма на экране отличается от финансового отчёта.
Дашборд: свяжите фильтр с каждой карточкой
Создайте дашборд и добавьте сохранённые вопросы. Документация Metabase описывает дашборд как набор вопросов с общими фильтрами и текстовыми блоками. Наверху разместите период и KPI, под ними — ряд и групповой разрез. Рядом с суммой напишите «стоимость оформленных броней» и укажите московское время. Дата источника должна отличаться от времени открытия браузера.
Добавьте фильтр даты и подключите его к каждой карточке. Для вопроса из конструктора выберите соответствующее поле даты; для SQL-вопроса понадобится параметр в запросе. Проверьте два состояния: на всех семи днях 3 377 874 800 ₽ и 42 561 бронь, на 3 августа 452 158 300 ₽ и 5 665 броней. Если SQL-карточка не изменилась, не публикуйте страницу как единый отчёт.
Фильтр группы добавляйте только если он нужен читателю. При выборе «2+» столбчатое сравнение двух групп превращается в один столбец; это может скрыть контекст. Иногда лучше оставить оба столбца и дать только выбор даты. Каждый элемент управления — это ещё одно состояние для проверки после изменения модели.
Подписки: отправлять можно только проверенный срез
Подписки Metabase отправляют результаты вопросов с дашборда по электронной почте или в Slack при настроенном администратором канале. Перед расписанием проверьте, какие фильтры и какой момент обновления источника используются. Письмо, которое уходит раньше ежедневной загрузки, стабильно распространяет устаревшую цифру.
Сформулируйте цель подписки. Если менеджер принимает решение по закрытой неделе в понедельник, отправка в воскресенье покажет неполный период. Выберите время после подтверждённой загрузки и добавьте период в заголовок. Если источник ошибся, владелец должен знать, кому ушло письмо с прежним значением и как отправить исправление.
Подписка способна доставить данные человеку, который не открывает интерфейс. Поэтому получателей проверяйте отдельно от прав на сам дашборд. Не считайте внутренний почтовый список закрытым по умолчанию: пересылка, общие ящики и история писем сохраняют экспортированную цифру дольше, чем живой фильтр на странице.
Публичные ссылки и чувствительные данные
Публичная ссылка Metabase делает вопрос или дашборд доступным без входа тем, у кого есть адрес. Документация отдельно предупреждает, что параметры публичной ссылки можно удалить из URL и увидеть исходный объект без визуальных фильтров. Для персональных, финансовых или коммерчески чувствительных данных это неприемлемая модель доступа. Наш учебный агрегат обезличен, но рабочий отчёт требует ролей и проверки прав.
Не путайте публичную ссылку с приглашением конкретного сотрудника. Во втором случае система может применить права пользователя и ограничить данные; в первом человек не аутентифицирован. Metabase также предупреждает, что публичные объекты не могут надёжно опираться на пользовательскую защиту строк и колонок. Настройка «показывать только один регион» через URL-параметр не заменяет серверного ограничения.
Перед публикацией проверьте, есть ли на вопросе детали по отдельным броням, выгрузка CSV и фильтр по малочисленной группе. Даже агрегат может раскрыть информацию, если группа состоит из одной записи. Для рабочих данных согласуйте, что можно показывать без авторизации; обычно безопаснее дать адресный доступ по ролям и оставить публичные ссылки выключенными.
Metabase и Superset: один кейс, разная точка входа
Metabase начинает с понятия сохранённого вопроса: его можно собрать в конструкторе либо написать в SQL. Superset обычно ведёт аналитика через SQL Lab, датасет и Explore, после чего чарт добавляют на дашборд. Оба инструмента могут показать нашу неделю, но ни один не определит за команду, что значит «стоимость брони» и как не размножить её соединением.
Короткая таблица ниже — сравнение рабочих шагов по официальным руководствам, не рейтинг продукта. Для команды без регулярного SQL-контура может быть удобнее начать с конструктора вопросов. Для команды с управляемыми витринами и SQL-процессом важно проверить, где будут храниться общие определения и кто владеет размещением. Подробный путь второго инструмента — в гайде по Superset.
Сравните их на одном тесте: вся неделя, 3 августа, группа «2+», роль читателя. Если значения или доступы расходятся, это сигнал о настройках модели, а не доказательство, что один инструмент «точнее». Точность зависит от источника, зерна, фильтров и проверки.
| Задача | Metabase | Superset |
|---|---|---|
| Первый анализ | Question в конструкторе или SQL | Explore или SQL Lab |
| Общий слой | Model | Dataset |
| Экран | Dashboard из вопросов | Dashboard из чартов |
| Проверка | Контрольный SQL и фильтры | Контрольный SQL и native filters |
Шесть ошибок, из-за которых вопросы расходятся
Первая: конструктор считает COUNT(*) после JOIN с билетами и называет это числом броней. Вторая: SQL-вопрос зашивает неделю в WHERE, а дашборд притворяется динамическим. Третья: фильтр даты подключён к линии, но не к карточке суммы. Четвёртая: при смене источника дата осталась текстом и группируется не по календарю. Эти ошибки можно поймать сравнением двух состояний и числа уникальных ключей.
Пятая: отправка подписки стоит до обновления данных и рассылает старую неделю. Шестая: публичная ссылка используется как «доступ только по адресу» для чувствительной информации. Отдельно проверьте названия метрик: стоимость оформленной брони — не оплата и не чистая выручка. В тексте статьи цифры точны для учебной базы, но перенос определения на рабочую компанию требует нового договора о статусах и возвратах.
Не исправляйте расхождение только подписью графика. Если две карточки показывают разные суммы за одну дату, найдите их источники, фильтры и гранулярность. После исправления запишите контрольный SQL и ожидаемый результат в описание модели или командный регламент: следующий автор сможет повторить проверку.
Частые вопросы и следующий шаг
«Можно ли работать в Metabase без SQL?» Для простого фильтра и агрегата — да, через query builder; сложное зерно всё равно должен подготовить кто-то, кто понимает данные. «Зачем сохранять модель?» Чтобы несколько вопросов опирались на один проверенный источник и понятные поля. «Почему фильтр не меняет SQL-вопрос?» Для native query нужен связанный параметр или field filter.
«Можно ли разослать дашборд автоматически?» Да, если администратор настроил канал подписки, но период и момент обновления нужно проверять. «Безопасна ли публичная ссылка?» Для чувствительных данных — нет: адрес может распространяться, а визуальные параметры не заменяют права. «Чем Metabase отличается от Superset?» Прежде всего рабочим входом: сохранённый вопрос против связки датасета, Explore и SQL Lab.
Начните с одной карточки и сверки SQL на полном периоде и одном дне. Если запросы пока даются трудно, тренажёр SQL с нуля поможет разобрать агрегацию и JOIN до публикации. Затем прочитайте ТЗ на дашборд и закрепите владельца источника, определения метрики и прав.
Материалы по теме
Yandex DataLens: как собрать первый дашборд
Пошагово собираем дашборд в Yandex DataLens: подключение, датасет, вычисляемые поля, чарты, селекторы и доступы. Числа сверены SQL.
Apache Superset: SQL-запросы, чарты и дашборды
Как собрать проверяемый дашборд в Apache Superset: подключить БД, выполнить SQL Lab, сохранить датасет, построить чарты и настроить фильтры.
Дашборд: что это такое, из чего состоит и какие бывают
Дашборд — это страница с несколькими регулярно обновляемыми показателями для одного решения. Чем он отличается от отчёта и BI-системы, какие бывают дашборды, из чего состоят и как посчитать KPI-карточки на SQL.