Project state in dbt
dbt предоставляет stateful‑подход к деплою dbt‑проектов. Артефакты доступны для программного доступа через Discovery API в платформе метаданных.
С внедрением конечной точки environment в Discovery API, мы ввели концепцию множественных состояний. Discovery API предоставляет единую конечную точку API, которая возвращает последнее состояние моделей, источников и других узлов в DAG.
Одна deployment environment должна представлять продакшн‑состояние конкретного проекта dbt.
В dbt существуют два состояния, к которым можно выполнять запросы:
-
Примененное состояние относится к тому, что существует в хранилище данных после успешного выполнения
dbt run. Построение модели успешно завершено и теперь существует как таблица в хранилище. -
Состояние определения зависит от того, что существует в проекте, учитывая определенный в нем код (например, состояние манифеста), которое не обязательно было выполнено на платформе данных (возможно, это просто результат
dbt compile).
Состояние определения (логическое) vs. примененное состояние узлов dbt
В проекте dbt состояние определения узла представляет конфигурацию, трансформации и зависимости, определенные в файлах SQL и YAML. Оно фиксирует, как узел должен обрабатываться в отношении других узлов и таблиц в хранилище данных и может быть создано с помощью dbt build, run, parse или compile. Оно изменяется всякий раз, когда изменяется код проекта.
Примененное состояние узла относится к фактическому состоянию узла после его успешного выполнения в DAG; например, модели выполняются, и их состояние применяется к хранилищу данных через dbt run или dbt build. Оно изменяется всякий раз, когда узел выполняется. Это состояние представляет результат трансформаций и фактические данные, хранящиеся в базе данных, которые для моделей могут быть таблицей или представлением на основе определенной логики.
Примененное состояние включает информацию о выполнении, которая содержит метаданные о том, как узел достиг примененного состояния: последнее выполнение (успешное или попытка), например, когда оно началось, его статус и сколько времени оно заняло.
Вот как вы можете запросить и сравнить состояние определения и примененное состояние модели, используя Discovery API:
query Compare($environmentId: Int!, $first: Int!) {
environment(id: $environmentId) {
definition {
models(first: $first) {
edges {
node {
name
rawCode
}
}
}
}
applied {
models(first: $first) {
edges {
node {
name
rawCode
executionInfo {
executeCompletedAt
}
}
}
}
}
}
}
Большинство случаев использования Discovery API будут отдавать предпочтение примененному состоянию, так как оно относится к тому, что было фактически выполнено и может быть проанализировано.
Состояния, затронутые типом узла
Следующая таблица показывает состояния узлов dbt и как они затрагиваются Discovery API.
| Loading table... |
Предостережения о обновлениях состояния/метаданных
Со временем Cloud Artifacts будет предоставлять информацию для хранения и поддержки состояния функций и сервисов в dbt, а также позволит получать доступ к этому состоянию в dbt и его downstream-экосистеме. В настоящее время Cloud Artifacts сосредоточен на актуальном состоянии production, однако со временем этот фокус будет расширяться и развиваться.
Вот некоторые ограничения представления состояния в Discovery API:
- Пользователи должны получать доступ к среде production по умолчанию, чтобы узнать актуальное состояние проекта.
- API получает определение из последнего manifest, сгенерированного в заданной среде деплоя, однако это часто не отражает самое актуальное состояние кода проекта.
- Результаты скомпилированного кода могут быть устаревшими в зависимости от порядка шагов выполнения в dbt и наличия сбоев.
- Информация каталога может быть устаревшей или неполной (в applied state) в зависимости от того, запускалась ли и когда в последний раз команда
docs generate. - Проверки актуальности источников (source freshness) могут быть устаревшими (в applied state) в зависимости от времени последнего запуска команды; кроме того, они не входят в
build.
