Точные команды dbt, которые мы запускаем в производственной среде

Без команды для их запуска, модели и тесты dbt просто занимают место в репозитории Git.

Конкретные команды dbt, которые вы запускаете в производственной среде, являются центром управления вашим проектом. Они формируют структуру, определяющую стандарты качества и свежести данных вашей команды.

Примечание: Начиная с dbt v0.21.0 (выпущенной в октябре 2021 года), вы можете установить предпочитаемые производственные команды, используя dbt build. После настройки, одна команда dbt build может использоваться для выполнения предписанных вами команд seed, test, run и snapshot и других команд в заданном порядке.

Самая важная команда — это dbt run. Но в развертывании мы редко используем только dbt run.

Вы, вероятно, уже знакомы с множеством команд dbt, и этот раздел посвящен тому, чтобы показать вам, какие команды, по нашему мнению, должны быть наиболее эффективными при запуске вашего проекта dbt в производственной среде!

В производственной среде надежность и согласованность являются ключевыми. Это гарантирует, что ваши заинтересованные стороны имеют данные, которые могут быть использованы значимым образом. Чтобы обеспечить надежность и согласованность, вот несколько принципов, которые, по нашему мнению, вы должны учитывать при разработке команд развертывания:

Принципы команд развертывания dbt

1) Всегда тестируйте ваши данные

Вы, вероятно, уже знакомы с тестированием в dbt, и мы считаем, что каждый производственный запуск всегда должен быть протестирован.

2) Понимание влияния задержанных данных в вашем проекте

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

3) Упрощение регулярных запланированных запусков

Чем сложнее ваши команды запуска, тем сложнее их поддерживать в долгосрочной перспективе. Не стесняйтесь полагаться на DAG dbt (больше информации о том, почему мы <3 DAGs в посте моих коллег Кристин и Рэнди о модульной технике моделирования данных).

Учитывая эти принципы, мы теперь рассмотрим наиболее распространенные команды запуска для производственных задач и почему мы считаем, что они могут работать для вашей организации! Обратите внимание, что ваши могут немного отличаться (в зависимости от конкретных потребностей вашей команды), но пока вы придерживаетесь вышеупомянутых принципов, ваш проект должен быть в хорошем состоянии!

Самые простые возможные производственные команды dbt

Самая простая версия запланированных команд запуска вашего проекта может быть:

dbt run

dbt test

Эта версия является самой базовой и соответствует всем вышеупомянутым принципам. Это предполагает, что вы можете позволить себе иметь немного некорректные данные (данные тестируются только после запуска проекта dbt).

Предпочтительные производственные команды dbt

На практике, однако, мы часто находим, что это более эффективно:

dbt test -s source:* (или dbt test -m source:* если вы используете версию ранее dbt v0.21.0)

dbt run

dbt test --exclude source:*

dbt source `freshness` (или dbt source snapshot-freshness если вы используете версию ранее dbt v0.21.0) (это может быть первым шагом)

Это более надежная реализация первой версии. Два дополнения здесь:

1. Тестирование исходных данных перед запуском любой трансформации dbt, и
2. Тестирование свежести источников

Когда вы тестируете исходные данные перед запуском трансформаций, это исключает возможность того, что плохие исходные данные повлияют на проект dbt.

Это остановит процесс сборки, если будут обнаружены плохие исходные данные, и защитит целостность ваших моделей dbt.

Когда источники тестируются на свежесть, это позволяет вам легко определить, являются ли данные в вашем хранилище старыми, и, впоследствии, уведомить соответствующих заинтересованных лиц.

Вы также можете выбрать запуск теста свежести источников в начале, если ваша организация предпочитает, чтобы устаревшие данные не обрабатывались, или если вы считаете, что устаревшие данные могут привести к ненадежным конечным моделям.

Профессиональный совет: остерегайтесь селекторов моделей

Сначала я хочу быстро рассмотреть тему использования селекторов моделей (-s для конкретных моделей/тегов/папок, или -m, если вы используете версию ранее dbt v0.21.0) в ваших командах запуска. Вы, возможно, уже знаете, как запускать конкретные модели и, впоследствии, их родительские или дочерние модели.

При создании производственных задач мы настоятельно не рекомендуем полагаться на них, так как это добавляет сложности вашему проекту и может привести к несоответствию времени в ваших шагах сборки.

Способ думать о селекторах моделей в запусках — это скорее исключение, чем правило. Лучше всего начать с одной основной задачи, которая выполняется с постоянной частотой. Оттуда оцените, нуждаются ли конкретные части вашего проекта dbt в специфической обработке для оптимизации.

Возможно, некоторые модели требуют обновления только раз в неделю, в то время как все остальное нужно обновлять каждый час. Возможно, некоторые команды нуждаются в данных в определенное время дня, и, следовательно, их модели должны запускаться в определенное время утром.

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

Чем отличаются ваши команды запуска?

Это команды dbt, которые наша команда запускает в производственной среде, и которые мы рекомендуем нашим клиентам по профессиональным услугам.

Но! Ваш опыт может отличаться, и есть вполне обоснованные причины для запуска других команд в производственной среде — мне всегда интересно узнать, что лучше всего работает для вашей команды.

Пока вы помните основные принципы, которые я поделился ранее (в основном, держите все просто), вы будете в отличной форме.