Дашборды из dbt-моделей: чем Lightdash меняет работу после Metabase

MAATRIX

Если в компании уже есть dbt-проект — модели, тесты, YAML с описанием колонок — рано или поздно всплывает один и тот же вопрос: почему метрики для дашбордов приходится описывать заново, уже в интерфейсе BI-инструмента, вместо того чтобы взять определения прямо из dbt. Metabase на этот вопрос отвечает «а зачем, у нас же есть визуальный конструктор» — и он прав ровно до тех пор, пока команда маленькая и метрики простые. Lightdash отвечает иначе: он вообще не хранит своей модели данных, а читает её из dbt-проекта, и превращает metrics.yml в дашборд без дублирования логики. Ниже — честный разбор, что от этого выигрывает команда на dbt, а что теряет по сравнению с привычным Metabase, и как это выглядит на практике на собственном сервере.

Разная философия: где живёт правда о метрике

Metabase — self-contained BI-инструмент. У него собственная модель данных: вопросы (questions), сохранённые запросы, «модели» (Metabase models — не путать с dbt models) как переиспользуемые вью поверх таблиц. Всё это хранится в служебной базе самого Metabase (по умолчанию H2 или подключённый Postgres) и живёт независимо от трансформации данных выше по стеку. Аналитик открывает визуальный конструктор, кликает по таблицам, джойнит их мышкой — и это реально работает без единой строчки кода, в этом вся сила Metabase.

Lightdash устроен иначе: он не хранит определения метрик у себя, а читает dbt-проект — модели, их YAML-описания и блоки meta, где для колонки объявляется, что это метрика (metrics:) и какого она типа (sum, count_distinct, average). Lightdash по сути витрина поверх уже готового семантического слоя dbt — сам он трансформацией данных не занимается, только визуализацией того, что описано в проекте.

Разница ощущается сразу, как только в компании больше одного аналитика. В Metabase два человека могут по-разному посчитать «активного пользователя» в двух разных вопросах, и разногласие всплывёт, только когда кто-то сравнит дашборды и увидит разные цифры. В Lightdash метрика описана один раз в dbt-проекте, лежит в git, проходит код-ревью вместе с остальными изменениями модели — и на дашборде физически невозможно взять другое определение.

Это не абстрактная разница в архитектуре — она определяет весь дальнейший разговор про удобство, объём работы при внедрении и то, кому вообще имеет смысл переходить.

Что нужно ДО установки: dbt-проект — это предпосылка, а не опция

Здесь первая и самая важная развилка. Если dbt-проекта в компании ещё нет — переход на Lightdash не имеет смысла обсуждать, пока проект не появится и в нём не накопится хотя бы минимальный набор моделей с описанными метриками. Lightdash не конкурент Metabase «из коробки» — это надстройка над dbt, бесполезная без него.

Если dbt уже используется — Lightdash ожидает конкретную структуру. В модели (файл .sql в папке models/) должен быть YAML-файл того же имени с описанием колонок, и внутри описания каждой измеряемой колонки — блок meta с объявлением метрики:

# models/marts/orders.yml
version: 2

models:
  - name: orders
    columns:
      - name: order_id
        description: "Уникальный идентификатор заказа"
      - name: amount
        description: "Сумма заказа в рублях"
        meta:
          metrics:
            total_revenue:
              type: sum
            avg_order_value:
              type: average
      - name: order_id
        meta:
          metrics:
            order_count:
              type: count_distinct

Дальше Lightdash при синхронизации с dbt-проектом (через lightdash generate или подключение к git-репозиторию) сам находит эти метрики и предлагает их в конструкторе дашбордов — без повторного описания каждой метрики в BI-инструменте, как пришлось бы делать в Metabase.

Важный нюанс, который стоит проговорить заранее: если в dbt-проекте метрики описаны небрежно или вообще не описаны (модели есть, а meta.metrics — нет), Lightdash из коробки покажет голые колонки без готовых агрегаций, и первое знакомство с ним разочарует — покажется, что инструмент «беднее» Metabase. На практике это не ограничение Lightdash, а просто означает, что настоящая работа — доописать метрики в dbt — ещё не сделана.

Установка на сервере: чем Lightdash сложнее по составу

По количеству компонентов Lightdash тяжелее базовой установки Metabase. Metabase — одно приложение (JVM-процесс) плюс база метаданных, которую можно даже оставить встроенной H2 для теста. У Lightdash больше частей: сам сервис (Node.js), Postgres под служебные данные (пользователи, права, дашборды) и подключение к dbt-проекту — либо локально смонтированный репозиторий, либо интеграция через dbt Cloud API.

Минимальный docker-compose.yml для самостоятельного хостинга выглядит так (сверяйтесь с актуальным docker-compose.yml из официального репозитория Lightdash — набор переменных между релизами меняется):

services:
  lightdash:
    image: lightdash/lightdash:latest
    depends_on:
      - db
    environment:
      PGHOST: db
      PGPORT: "5432"
      PGUSER: lightdash
      PGPASSWORD: "пароль-к-базе"
      PGDATABASE: lightdash
      SECRET: "сгенерированный-случайный-ключ"
      SITE_URL: "https://bi.example.com"
      LIGHTDASH_INSTALL_ID: "server-1"
    ports:
      - "8080:8080"
    volumes:
      - dbt_project:/usr/app/dbt

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: lightdash
      POSTGRES_USER: lightdash
      POSTGRES_PASSWORD: "пароль-к-базе"
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  dbt_project:
  db_data:

Готовый рабочий docker-compose.yml под Metabase для сравнения лежит в отдельной статье — Metabase в Docker Compose, полезно держать оба варианта под рукой, если решаете, что разворачивать.

По требованиям к ресурсам Lightdash на небольшой команде укладывается в похожие рамки, что и Metabase — ориентировочно 2 GB RAM хватает на тест, 4 GB комфортнее для рабочего использования с несколькими одновременными пользователями. Точных цифр «на сколько именно больше ест Lightdash» без собственных замеров на своей нагрузке приводить не стоит — слишком зависит от объёма dbt-проекта и от того, как часто пересчитываются тяжёлые запросы к хранилищу данных. Если ориентировались на память под Metabase раньше, полезно свериться со статьёй сколько RAM нужно для Metabase как с точкой отсчёта — и заложить похожий или чуть больший запас с учётом второго сервиса (Postgres) в комплекте.

Отдельная деталь: и Metabase, и Lightdash в конечном счёте выполняют SQL-запросы к вашему складу данных (Postgres, BigQuery, Snowflake, Redshift) — сами данные они не хранят, только визуализируют результат запроса. Разница не в том, откуда берутся данные, а в том, откуда берётся описание того, как их агрегировать в метрику.

Как меняется работа аналитика день в день

Это тот раздел, ради которого вообще стоит читать сравнение, — потому что архитектурная разница из первого раздела превращается в разницу в повседневных привычках, и не для всех она приятная.

В Metabase аналитик открывает интерфейс, кликает «Новый вопрос», выбирает таблицу, накидывает фильтры и группировки мышкой — либо сразу пишет SQL в редакторе, если кликов недостаточно. Результат сохраняется как «вопрос», из вопросов собирается дашборд. Весь путь — от идеи до готового графика — может занять пять минут и не требует вообще никакого контакта с репозиторием кода.

В Lightdash путь длиннее, если метрики ещё нет, и короче, если она уже есть. Если метрика уже описана в dbt-проекте — аналитик открывает конструктор Lightdash, видит готовую метрику в списке (с человекочитаемым названием и описанием из dbt YAML), перетаскивает её на график, добавляет измерение — и это тоже быстро, сравнимо с Metabase. Но если нужной метрики ещё нет, короткого пути нет: нужно либо самому написать её в YAML и закоммитить в dbt-проект (через git, pull request, возможно код-ревью), либо просить дата-инженера. Для аналитика без опыта работы с git это реальный порог входа, а не мелочь.

Практический эффект на команду: Lightdash подталкивает к разделению ролей — тот, кто описывает метрики (обычно дата-инженер или аналитик, уверенно работающий с dbt и git), и тот, кто строит на них дашборды (может быть кто угодно). В Metabase такого разделения нет — любой человек с доступом может и придумать метрику, и сразу построить график, минуя ревью логики расчёта.

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

Что теряется при переходе: возможности, которых у Lightdash нет или меньше

Честное сравнение обязано назвать не только выгоды, но и потери — иначе это не сравнение, а реклама.

Первое — свобода произвольного визуального конструктора. В Metabase можно взять любые две таблицы, накликать джойн между ними прямо в интерфейсе, даже если такого джойна никто заранее не предусмотрел. В Lightdash так не получится: если джойн между двумя dbt-моделями не описан заранее (через meta.joins в YAML), собрать дашборд с произвольным соединением таблиц не выйдет. Это осознанное ограничение — оно даёт согласованность, но режет спонтанные исследовательские запросы.

Второе — порог входа для нетехнических пользователей выше. Открыть Metabase и накликать первый график может человек, который никогда не видел ни SQL, ни git. С Lightdash это возможно только в рамках уже готовых метрик — как только нужно что-то новое, разговор упирается в «попросите дата-инженера добавить».

Третье — экосистема готовых визуализаций у Metabase на практике богаче за счёт возраста проекта и размера сообщества. Lightdash моложе, набор типов графиков меньше — для базовых линейных, столбчатых графиков и таблиц разницы почти нет, но для нестандартной визуализации Metabase может оказаться гибче.

Четвёртое — если у вас в принципе нет dbt и трансформация делается напрямую SQL-скриптами или ETL-инструментом без слоя семантики, Lightdash не даст преимущества, а только добавит инфраструктуры. Тут переход не имеет смысла, пока dbt-слой не появится.

Миграция: что переносится автоматически, а что нет

Готового мигратора «Metabase → Lightdash» не существует, и это ожидаемо — слишком разные модели данных, чтобы конвертация была прямой. Переезд на практике состоит из ручной работы в несколько заходов.

Сохранённые вопросы и дашборды Metabase не переносятся автоматически. SQL-запросы вопросов Metabase можно использовать как справочный материал — посмотреть логику агрегации и перенести её в виде метрики в dbt YAML, но копипаст SQL один в один обычно не годится: агрегация в чистом SQL-вопросе Metabase часто смешивает несколько шагов трансформации, которые в dbt правильнее развести по отдельным моделям.

Практический порядок миграции, который снижает объём одновременной работы:

1. Составить список самых используемых дашбордов Metabase (по частоте открытия, если статистика доступна, или по опросу команды) — переносить всё сразу нет смысла, часть дашбордов со временем всё равно оказывается заброшенной.
2. Для каждого дашборда выписать, какие метрики и измерения в нём реально используются, и свериться — есть ли уже в dbt-проекте модели, откуда их взять.
3. Доописать недостающие метрики в dbt YAML, прогнать dbt test, закоммитить.
4. Пересобрать дашборд в Lightdash на основе готовых метрик — обычно быстрее, чем кажется, если метрики уже на месте.
5. Держать оба инструмента доступными параллельно на переходный период, пока команда не привыкнет искать метрики в Lightdash, а не заново в Metabase.

Права доступа переносятся тоже не один в один. В Metabase модель прав — коллекции с публичным/приватным доступом и ролями на уровне групп. В Lightdash права организованы вокруг проектов и пространств (spaces) внутри организации, с ролями участников. Прямого сопоставления «коллекция → пространство» может не получиться там, где в Metabase права были расставлены точечно, — придётся пересобирать структуру, а не переносить её механически.

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

Кому подходит переход, а кому лучше остаться на Metabase

Разбор был бы неполным без прямого ответа: не всем командам на dbt имеет смысл переходить на Lightdash, и не любой команде без dbt имеет смысл его заводить.

Lightdash оправдан, когда одновременно верны несколько условий: в компании уже есть зрелый dbt-проект с описанными моделями; больше одного аналитика регулярно строит дашборды, и разногласия в цифрах уже случались на практике; есть человек, готовый поддерживать git-workflow для метрик (писать YAML, проходить код-ревью); а скорость спонтанных экспериментов не важнее согласованности отчётности.

Metabase остаётся лучшим выбором, если: dbt в компании нет и не планируется; команда небольшая, метрик мало, и риск расхождения цифр низкий просто в силу масштаба; нетехнические сотрудники (продажи, маркетинг) должны сами строить себе отчёты без обращения к дата-инженеру; или ценность в скорости произвольного запроса выше, чем в строгой единой модели метрик.

Есть и промежуточный вариант: держать оба инструмента одновременно. Lightdash — для регулярной отчётности с проверенными метриками, которые видит руководство. Metabase — для быстрых разовых исследований, где точность агрегации не так критична, как скорость первого ответа. Дополнительная стоимость — ещё один сервис на сервере и ещё один инструмент для новых сотрудников, но при достаточном объёме обоих сценариев это часто дешевле, чем ломать одну модель под оба сразу.

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