dbt Elementary на собеседовании Data Engineer

Зачем нужен Elementary

Elementary — open-source пакет для dbt, который добавляет к проекту слой data observability: обнаружение аномалий, мониторинг свежести и объёма данных, отслеживание истории тестов и отчёт с дашбордом. Ставится как обычная зависимость dbt.

# packages.yml
packages:
  - package: elementary-data/elementary
    version: 0.14.0

Проблема, которую он закрывает: обычные dbt-тесты (not_null, unique, accepted_values) проверяют жёсткие правила, которые вы задали руками. Но большинство инцидентов с данными — не нарушение явного правила, а тихий сдвиг: строк внезапно стало вдвое меньше, доля NULL подскочила, таблица перестала обновляться. Такие вещи заранее правилом не опишешь. Elementary отслеживает метрики во времени и ловит отклонения статистически, без ручных порогов.

На собесе DE это спрашивают в блоке про data quality и мониторинг: интервьюер проверяет, понимаете ли вы разницу между проверкой по правилу и обнаружением аномалий, и как встроить наблюдаемость в dbt-пайплайн, не поднимая отдельную платформу.

Обнаружение аномалий

Главная фича — автоматическое обнаружение необычных значений без ручных правил. Elementary накапливает историю метрик по таблице и сравнивает свежий замер с типичным поведением (по сути, z-score относительно исторического распределения).

Что он отслеживает:

• Число строк во времени. Резкое падение или всплеск объёма — типичный признак сломанного источника или дубликатов.
• Доля NULL. Скачок пропусков в колонке означает, что источник перестал присылать поле.
• Число уникальных значений. Схлопывание кардинальности часто говорит о том, что джойн размножил или, наоборот, потерял строки.
• min / max / mean / stddev по колонкам. Сдвиг статистик ловит выбросы и смену единиц измерения (например, рубли вдруг стали копейками).

Аномалии подключаются как обычные dbt-тесты в YAML-схеме модели:

models:
  - name: orders
    tests:
      - elementary.volume_anomalies
      - elementary.freshness_anomalies

Например, если число строк за прогон упало на 80% относительно типичного — тест не пройдёт и попадёт в алерт. Порог отклонения и размер окна настраиваются, но из коробки работает разумный дефолт.

Мониторы

Помимо аномалий Elementary регулярно снимает метаданные о таблицах и складывает их в свою служебную схему, чтобы можно было смотреть тренды и находить регрессии:

• Изменения схемы. Отслеживает появление новых и пропажу старых колонок и типов — так ловится незамеченный breaking change в апстриме.
• Свежесть данных. Фиксирует, когда таблица обновлялась в последний раз, и подсвечивает залежавшиеся.
• История тестов. Копит результаты прогонов, чтобы было видно, какой тест начал стабильно падать, а какой флапает от прогона к прогону.

Всё это визуализируется в отчёте Elementary (генерируется командой edr report) — HTML-дашборде, где регрессии видно глазами, а не через грепанье логов.

Алерты

Падения тестов и найденные аномалии Elementary умеет доставлять в Slack, на почту или через webhook. Важный нюанс для собеса: сами тесты выполняет dbt, а вот отправкой алертов и сборкой отчёта занимается отдельная CLI-утилита edr (Elementary CLI). Обычно её запускают после dbt test/dbt build в CI или по расписанию.

Маршрутизацию можно настраивать по моделям — направлять критичные таблицы в отдельный канал команды data quality:

models:
  - name: orders
    meta:
      elementary:
        alerts_config:
          channel: "#data-quality"

Типовой пайплайн выглядит так: dbt build прогоняет модели и тесты (включая elementary-аномалии), затем edr monitor собирает свежие результаты и рассылает алерты по подписчикам. Так расхождение в данных доходит до дежурного инженера, а не всплывает через день на сломанном дашборде.

Частые ошибки

Ждать алертов сразу после установки. Обнаружению аномалий нужна история: пока Elementary не накопил несколько прогонов, ему не с чем сравнивать, и аномалии молчат. На новом проекте это норма, а не поломка.

Путать, кто что делает. Тесты выполняет dbt, а отчёт и алерты — CLI edr. Если не запускать edr в пайплайне, тесты будут падать, но никто об этом не узнает.

Заменять аномалиями явные тесты. Обнаружение аномалий не отменяет not_null, unique и бизнес-правила. Это дополняющие слои: правила ловят известные инварианты, аномалии — неизвестные сдвиги.

Ставить аномалии на всё подряд. Метрики по каждой колонке всех таблиц дают шум и раздувают служебную схему. Начинают с ключевых витрин и критичных полей, а не покрывают проект целиком.

Связанные темы

• dbt на собесе DE
• Great Expectations для DE
• DQ dimensions для DE
• Data lineage для DE
• Подготовка к собесу Data Engineer

FAQ

Чем Elementary отличается от обычных dbt-тестов?

Стандартные тесты проверяют жёсткие правила, которые вы задали: значение не NULL, уникально, входит в список. Elementary добавляет статистическое обнаружение аномалий — ловит отклонения метрик (объём, доля NULL, кардинальность) от исторического поведения, для которых правило заранее не напишешь. Их используют вместе, а не вместо друг друга.

Чем Elementary отличается от Great Expectations?

Elementary живёт внутри dbt: тесты объявляются в YAML моделей, метрики и результаты складываются в схему проекта, всё идёт через привычный dbt-воркфлоу. Great Expectations — самостоятельный фреймворк валидации данных, не привязанный к dbt, с более богатым набором expectations, но и с отдельной инфраструктурой. Для проектов, уже живущих на dbt, Elementary дешевле в интеграции.

Нужна ли отдельная инфраструктура для Elementary?

Нет, отдельную платформу поднимать не нужно. Elementary хранит артефакты прямо в вашем хранилище (в служебной схеме), а отчёт и алерты собирает CLI edr, который достаточно вызвать в CI или по расписанию. Это его ключевое преимущество перед тяжёлыми observability-платформами.

Как Elementary решает, что значение аномально?

Он накапливает историю метрики по прогонам и сравнивает свежий замер с типичным распределением — по сути, считает, насколько сильно текущее значение отклонилось (z-score) с учётом окна и сезонности. Если отклонение выходит за настроенный порог, тест не проходит. Поэтому на свежем проекте без истории аномалии сначала молчат.

Это официальная информация?

Нет. Статья основана на документации Elementary и типовых практиках. Конкретные требования и версии зависят от компании и проекта.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.