О локальном состоянии в dbt
Если вы хотите использовать управляемое состояние в dbt, чтобы не запускать повторно модели, которые не изменились, ознакомьтесь с dbt State. В самостоятельно управляемых развертываниях с включенным dbt State все селекторы state:* также могут использовать dbt State в качестве источника для сравнения на уровне отдельных узлов без необходимости управлять файлом manifest.json. Подробнее см. в разделе Селекторы state:* на основе dbt State.
Выбор на основе состояния и отложенное разрешение ссылок предполагают, что ваши модели идемпотентны, то есть повторный запуск с теми же входными данными возвращает тот же результат. Подробнее см. в разделе Идемпотентность в dbt.
Один из важнейших принципов, лежащих в основе dbt, заключается в том, что его операции должны выполняться без сохранения состояния и обладать свойством идемпотентность. То есть неважно, сколько раз модель запускалась ранее и запускалась ли она вообще. Неважно, запускаете ли вы ее один раз или тысячу раз. При одинаковых исходных данных можно ожидать одинакового результата преобразования. Конкретному запуску dbt не нужно «знать» о каком-либо другом запуске; ему достаточно знать о коде проекта и объектах в вашей базе данных в том виде, в котором они существуют прямо сейчас.
При этом dbt всё же хранит «состояние» (state) — детализированное представление ресурсов проекта (также называемых узлами), объектов базы данных и результатов выполнения в конкретный момент времени — в виде своих артефактов. При желании dbt может использовать эти артефакты для выполнения некоторых операций. Важно, что сами операции при этом остаются stateless и идемпотентность: при одинаковом manifest и одинаковых исходных данных dbt будет производить одинаковый результат трансформации.
dbt может использовать артефакты из предыдущего запуска, если путь к ним передан через флаг --state. Это является обязательным условием для следующих возможностей:
- Селектор
state, с помощью которого dbt может определять новые или изменённые ресурсы, сравнивая код текущего проекта с manifest состояния. - Deferring к другой среде, при котором dbt может определить вышестоящие, невыбранные ресурсы, отсутствующие в текущей среде, и вместо этого «отложить» ссылки на них, используя среду, указанную в manifest состояния.
- Команда
dbt clone, с помощью которой dbt может клонировать узлы на основе их расположения в manifest, переданном через флаг--state.
В совокупности селектор state и deferral позволяют реализовать подход "slim CI". Мы ожидаем, что в будущих релизах появятся дополнительные возможности, которые смогут использовать артефакты, передаваемые через флаг --state.
