Как спроектировать стратегию тестирования и документирования в dbt-проекте с несколькими сотнями моделей (staging → intermediate → marts), чтобы гарантировать качество данных, но не утонуть в поддержке тестов?

Короткий ответ

Единого готового рецепта нет: разумный подход — закладывать базовые тесты (unique, not_null) на ключи во всех слоях, более глубокие бизнес-тесты (relationships, кастомные тесты на допустимые диапазоны) концентрировать на уровне marts, которые видит бизнес, и явно определить владельцев моделей, а не пытаться покрыть тестами абсолютно всё одинаково строго.

Как это работает подробнее

• Как это работает: слой staging отвечает за приведение сырых данных к единому виду (типы, именование), intermediate — за промежуточные трансформации и соединения, marts — за финальные бизнес-метрики; тесты в dbt декларируются в YAML и могут быть как встроенными (generic tests), так и кастомными SQL-тестами (singular tests), которые возвращают строки-нарушения.

Пример кода

dbt_tests.ymlКопировать

models:
  - name: fct_revenue
    columns:
      - name: revenue_amount
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0
-- tests/assert_revenue_matches_source.sql (singular test)
select date, sum(revenue_amount) as mart_total
from {{ ref('fct_revenue') }}
group by date
having sum(revenue_amount) < 0

Что использовать на практике

• На практике: критичные для бизнеса marts-модели (например, таблица с выручкой для отчёта перед руководством) заслуживают дополнительных тестов на диапазоны значений и сверку с контрольной суммой из источника, тогда как промежуточные технические модели можно покрывать только базовыми тестами на ключи; документация (dbt docs) и явное описание owner/domain в YAML снижают риск того, что при увольнении автора модель станет «ничьей» и необслуживаемой.
• Пример и проверка. Проверка: dbt test -s fct_revenue должен падать, если в источнике появилась отрицательная выручка или итог разошёлся с ожидаемым, что сигнализирует о проблеме раньше, чем её увидят на дашборде руководства.

Подводные камни

• Частые ошибки: требовать одинаково исчерпывающего тестирования для всех 300+ моделей, что отнимает непропорционально много времени у команды и демотивирует писать новые тесты вообще; тестировать только технические свойства (not_null, unique), игнорируя смысловые проверки (например, что выручка не может быть отрицательной, что сумма по регионам сходится с общим итогом).