# О локальном состоянии в dbt

Хотите использовать управляемое состояние?

Если вы хотите использовать управляемое состояние в dbt, чтобы не запускать повторно модели, которые не изменились, ознакомьтесь с [dbt State](https://docs.getdbt.tech/docs/deploy/dbt-state-about.md). В самостоятельно управляемых развертываниях с включенным dbt State все [селекторы `state:*`](https://docs.getdbt.tech/reference/node-selection/methods.md#state) также могут использовать dbt State в качестве источника для сравнения на уровне отдельных узлов без необходимости управлять файлом `manifest.json`. Подробнее см. в разделе [Селекторы `state:*` на основе dbt State](https://docs.getdbt.tech/docs/deploy/dbt-state-deferral.md#dbt-state-powered-state-selectors).

Почему здесь важна идемпотентность

Выбор на основе состояния и отложенное разрешение ссылок предполагают, что ваши модели [идемпотентны](https://docs.getdbt.tech/best-practices/idempotence.md), то есть повторный запуск с теми же входными данными возвращает тот же результат. Подробнее см. в разделе [Идемпотентность в dbt](https://docs.getdbt.tech/best-practices/idempotence.md).

Один из важнейших принципов, лежащих в основе dbt, заключается в том, что его операции должны выполняться **без сохранения состояния** и обладать свойством **идемпотентность**. То есть неважно, сколько раз модель запускалась ранее и запускалась ли она вообще. Неважно, запускаете ли вы ее один раз или тысячу раз. При одинаковых исходных данных можно ожидать одинакового результата преобразования. Конкретному запуску dbt не нужно «знать» о *каком-либо другом* запуске; ему достаточно знать о коде проекта и объектах в вашей базе данных в том виде, в котором они существуют *прямо сейчас*.

При этом dbt всё же хранит «состояние» (state) — детализированное представление ресурсов проекта (также называемых узлами), объектов базы данных и результатов выполнения в конкретный момент времени — в виде своих [артефактов](https://docs.getdbt.tech/docs/deploy/artifacts.md). При желании dbt может использовать эти артефакты для выполнения некоторых операций. Важно, что сами операции при этом остаются stateless и идемпотентность: при одинаковом manifest и одинаковых исходных данных dbt будет производить одинаковый результат трансформации.

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

* [Селектор `state`](https://docs.getdbt.tech/reference/node-selection/methods.md#state), с помощью которого dbt может определять новые или изменённые ресурсы, сравнивая код текущего проекта с manifest состояния.
* [Deferring](https://docs.getdbt.tech/reference/node-selection/defer.md) к другой среде, при котором dbt может определить вышестоящие, невыбранные ресурсы, отсутствующие в текущей среде, и вместо этого «отложить» ссылки на них, используя среду, указанную в manifest состояния.
* Команда [`dbt clone`](https://docs.getdbt.tech/reference/commands/clone.md), с помощью которой dbt может клонировать узлы на основе их расположения в manifest, переданном через флаг `--state`.

В совокупности селектор [`state`](https://docs.getdbt.tech/reference/node-selection/methods.md#state) и deferral позволяют реализовать подход ["slim CI"](https://docs.getdbt.tech/best-practices/best-practice-workflows.md#run-only-modified-models-to-test-changes-slim-ci). Мы ожидаем, что в будущих релизах появятся дополнительные возможности, которые смогут использовать артефакты, передаваемые через флаг `--state`.

## Связанные материалы

* [Настройка выбора по состоянию](https://docs.getdbt.tech/reference/node-selection/configure-state.md)
* [Ограничения и нюансы сравнения состояния](https://docs.getdbt.tech/reference/node-selection/state-comparison-caveats.md)