Добавление тестов на основе данных с помощью dbt Wizard
Используйте dbt Wizard CLI, чтобы выявлять значимые пробелы в покрытии тестами, проверять предположения на текущих данных хранилища и создавать целевые тесты данных dbt.
В этом рабочем процессе используется встроенный агент test_writer. В отличие от запроса, в котором тесты указаны заранее, test_writer начинает с метаданных проекта и оценки значимости моделей, формулирует возможные проверяемые утверждения и проверяет их на доступных данных, прежде чем предлагать изменения YAML.
Встроенный агент test_writer доступен в dbt Wizard CLI. Сведения о доступности и поведении агента см. в разделе Использование субагентов с dbt Wizard CLI.
Предварительные требования
Прежде чем начать:
- Установите и настройте dbt Wizard CLI.
- Запустите dbt Wizard из проекта dbt с актуальным файлом
target/manifest.json. - Настройте подключение для разработки, позволяющее запрашивать данные моделей, которые вы хотите проверить.
- Выполните сборку соответствующих моделей, если их объекты в среде разработки ещё не существуют.
- Решите, следует ли исключить из профилирования столбцы с конфиденциальными данными или объекты, запросы к которым требуют значительных ресурсов.
Запросы к хранилищу могут расходовать вычислительные ресурсы и выводить значения данных в сеансе терминала. Проверяйте предлагаемые запросы и соблюдайте политики доступа к данным вашей организации.
Выберите ограниченную область работы
Начните с одной модели или небольшой части проекта. Так предлагаемые тесты будет проще проверить, а объём запросов к хранилищу останется ограниченным:
Use test_writer to improve test coverage for stg_customers. Inspect its existing
tests and downstream importance, validate candidate assumptions against current
data, and propose only high-signal tests. Do not change model SQL.
Вы также можете попросить dbt Wizard найти отправную точку:
Use test_writer to find three important models with weak test coverage. Prioritize
high fan-out models and models that define a business grain. Explain the ranking
before writing tests.
Укажите ограничения в запросе. Например, перечислите столбцы, которые нельзя запрашивать, ограничьте количество моделей или попросите dbt Wizard не создавать собственные универсальные тесты.
Проверьте анализ покрытия тестами
Прежде чем агент test_writer начнёт записывать YAML, попросите его объяснить:
- Для каких моделей и столбцов уже есть тесты.
- Почему выбранная модель важна для зависимых ресурсов.
- Какой уровень детализации или какое бизнес-правило отражает каждый предлагаемый тест.
- Какие варианты основаны на коде или метаданных, а какие выведены из данных.
- Какой запрос к хранилищу позволит проверить каждое предположение.
Наиболее ценные варианты тестов защищают контракты моделей и бизнес-логику, а не просто проверяют структуру текущей выборки.
| Предлагаемый тест | Что следует проверить |
|---|---|
not_null | Столбец обязателен с точки зрения уровня детализации модели, контракта или зависимой логики, а имеющиеся значения null были исследованы. |
unique | Столбец или сочетание столбцов соответствует предполагаемому уровню детализации, и проверки на дубликаты подтверждают это предположение. |
relationships | Родительский ресурс и ключ являются эталонными, а значения без соответствия в родительском ресурсе были исследованы. |
accepted_values | Поле представляет собой перечисление с регламентированным набором значений, а не просто список значений, полученных одним запросом. |
Если данные опровергают предлагаемое утверждение, исследуйте расхождение. Не добавляйте фильтр автоматически и не ослабляйте тест лишь для того, чтобы он прошёл.
Одобрите проверки в хранилище
test_writer может использовать предварительные запросы к хранилищу для проверки предположений об уникальности, допустимости значений null, связях и наблюдаемых значениях. Прежде чем одобрить запрос, убедитесь, что:
- Он использует ожидаемые целевую среду и объект данных.
- Выбранные столбцы соответствуют политикам доступа к данным.
- Его фильтры и ограничения не скроют нарушение условия, которое должен контролировать тест.
- Ожидаемые объём сканирования и время выполнения приемлемы.
Перед одобрением можно попросить сократить объём запроса или сделать его более целевым:
Validate the proposed grain without selecting customer attributes. Query only
customer_id and aggregate counts, and explain any sampling or date filter.
Проверьте предлагаемые тесты
Для каждого предлагаемого изменения YAML убедитесь, что:
- Тест выражает предусмотренное правило, а не случайное свойство текущих данных.
- Тест привязан к нужной модели и нужному столбцу.
- Синтаксис YAML соответствует версии dbt, используемой в проекте.
- Существующие тесты не дублируются.
- Имена тестов, аргументы, конфигурация и уровень серьёзности соответствуют соглашениям проекта.
- Набор изменений не содержит посторонних изменений документации или моделей.
Агент test_writer создаёт тесты. За их запуск отвечает стандартный процесс валидации dbt Wizard. Выберите подходящий уровень валидации и изучите все строки, не прошедшие проверку, прежде чем принять окончательное изменение.
Исследуйте предлагаемый тест, завершившийся ошибкой
Если новый тест не проходит, сохраняйте исходное предположение в фокусе, пока выясняете, о чём говорят данные:
The proposed unique test on customer_id fails. Show the duplicate pattern,
check whether the intended grain uses another column, and tell me whether this
is a model defect, a source-data issue, or a bad test assumption. Do not modify
the test until you explain the evidence.
Возможные результаты: исправление дефекта модели, документирование ограничения источника, выбор правильного составного ключа, определяющего уровень детализации, или отказ от предлагаемого теста.
Учитывайте ограничения
Генерация тестов на основе данных по-прежнему требует инженерной оценки:
- Текущие данные могут подтверждать или опровергать предположение, но не определяют бизнес-правило.
- Успешно пройденный тест может не учитывать будущие значения, данные, поступающие с задержкой, и разделы данных, к которым не выполнялись запросы.
- Тестам
accepted_valuesнужен регламентированный список значений, если могут появляться новые допустимые значения. - Доступ к хранилищу, разрешения, неактуальные объекты данных и использование выборок могут ограничивать доступные свидетельства.
- Большое количество тестов может увеличивать время сборки, не улучшая значимое покрытие.
- Тесты не заменяют контракты моделей, проверки актуальности источников, мониторинг или проверку владельцем модели.
Связанная документация
- Валидация изменений dbt с помощью dbt Wizard
- Использование субагентов с dbt Wizard CLI
- Тесты данных
- Рекомендации по тестированию
