# О команде dbt build

Команда `dbt build` выполняет следующие действия:

* запускает [модели](https://docs.getdbt.tech/docs/build/models.md)
* выполняет [тесты](https://docs.getdbt.tech/docs/build/data-tests.md)
* создаёт [снимки](https://docs.getdbt.tech/docs/build/snapshots.md)
* загружает [seed-файлы](https://docs.getdbt.tech/docs/build/seeds.md)
* создаёт [пользовательские функции](https://docs.getdbt.tech/docs/build/udfs.md) (доступно начиная с dbt v1.11)

В порядке DAG для выбранных ресурсов или всего проекта.

## Подробности

**Артефакты:** Задача `build` создаст один [manifest](https://docs.getdbt.tech/reference/artifacts/manifest-json.md) и один [артефакт результатов выполнения](https://docs.getdbt.tech/reference/artifacts/run-results-json.md). Результаты выполнения будут включать информацию обо всех моделях, тестах, данных и снимках, которые были выбраны для сборки, объединенные в один файл.

(Версии dbt: v2.0 и новее)

**Информационная схема dbt: **Используйте `--generate-info-schema`, чтобы записать [информационную схему dbt](https://docs.getdbt.tech/docs/build/dbt-information-schema.md) в `target/info_schema/`, в подкаталог с указанием версии (в настоящее время `v1/`). Информационная схема представляет метаданные вашего проекта в виде SQL-таблиц, доступных для запросов (аналогично `INFORMATION_SCHEMA` базы данных), что позволяет запрашивать модели, источники и другие объекты без разбора `manifest.json`.

```shell
dbt build --generate-info-schema
```

Чтобы заполнить автоматически определяемые типы столбцов моделей и данные о происхождении на уровне столбцов, используйте вместе с [`--static-analysis strict`](https://docs.getdbt.tech/docs/build/about-static-analysis.md). Без этого флага `dbt.node_columns` содержит только столбцы, объявленные в YAML, а `dbt.column_lineage` не содержит данных о происхождении.

```shell
dbt build --generate-info-schema --static-analysis strict
```

**Пропуск при сбоях:** Тесты вышестоящих ресурсов блокируют выполнение нижестоящих ресурсов, а сбой теста приводит к полному пропуску этих нижестоящих ресурсов. Например, если `model_b` зависит от `model_a` и тест `unique` для `model_a` завершается с ошибкой, то `model_b` получает статус `SKIP`.

* Не хотите, чтобы тест приводил к пропуску ресурсов? Измените его [уровень серьёзности или пороговые значения](https://docs.getdbt.tech/reference/resource-configs/severity.md), чтобы использовать `warn` вместо `error`.
* Если у теста несколько родительских ресурсов и один из них зависит от другого (например, тест `relationships` между `model_a` и `model_b`), этот тест блокирует и пропускает только дочерние ресурсы самого нижестоящего родительского ресурса (`model_b`).
* Если у теста несколько родительских ресурсов, независимых друг от друга, dbt [пропускает](https://github.com/dbt-labs/dbt/blob/d5071fa13502be273596a0b7c8b13d14b6c68655/core/dbt/compilation.py#L224-L257) нижестоящий узел, только если этот узел зависит от всех этих родительских ресурсов.

(Версии dbt: v2.0 и новее)

**Проверки:** `dbt build` выполняет [проверки](https://docs.getdbt.tech/docs/build/checks.md) перед компиляцией или выполнением любых моделей. Проверки — это SQL-запросы, которые вы пишете к [информационной схеме dbt](https://docs.getdbt.tech/docs/build/dbt-information-schema.md), чтобы обеспечить соблюдение стандартов проекта вашей команды. Например, проверка может требовать, чтобы у каждой модели было описание. Проверка считается пройденной, если её запрос не возвращает строк. Непройденная проверка останавливает сборку до материализации любых ресурсов, если только для параметра `severity` этой проверки не задано значение `warn`.

(Версии dbt: v1.12 и новее)

**Пропуск при ошибках моделей:** По умолчанию, если модель завершается с ошибкой, все нижестоящие модели пропускаются. Задайте для модели [`on_error: continue`](https://docs.getdbt.tech/reference/resource-configs/on_error.md), чтобы разрешить выполнение нижестоящих моделей, даже если эта модель завершается с ошибкой.

(Версии dbt: v1.12 и новее)

**Выбор ресурсов:** Задача `build` поддерживает стандартный синтаксис выбора (`--select`, `--exclude`), а также флаг `--resource-type`, который позволяет применить заключительный фильтр (как и в `list`). Именно выбранные ресурсы будут выполнены, протестированы, обработаны как snapshot или загружены как seed с помощью `build`.

* Помните, что тесты поддерживают косвенный выбор, поэтому `dbt build -s model_a` и выполнит, *и* протестирует `model_a`. Что это означает? Будут включены все тесты, напрямую зависящие от `model_a`, при условии, что эти тесты не зависят также от других, невыбранных родительских ресурсов. Подробности и примеры см. в разделе [Выбор тестов](https://docs.getdbt.tech/reference/node-selection/test-selection-examples.md).

**Флаги:** Задача `build` поддерживает те же флаги, что и `run`, `test`, `snapshot` и `seed`. Для флагов, общих для нескольких задач (например, `--full-refresh`), `build` использует одно и то же значение для всех выбранных типов ресурсов, которые его поддерживают (например, и модели, и seed-ресурсы будут полностью обновлены).

Снапшоты игнорируют полное обновление

Снапшоты игнорируют как параметр конфигурации `full_refresh`, так и флаг `--full-refresh`. Команда, например `dbt build --full-refresh` или `dbt snapshot --full-refresh`, включающая узел снапшота, выполняет его в обычном режиме — таблица снапшота не удаляется и не создаётся заново, поэтому существующая история снапшота сохраняется.

(Версии dbt: v2.0 и новее)

### Флаг `--skip-checks`

Флаг `--skip-checks` позволяет команде `build` пропустить обязательный этап [проверок](https://docs.getdbt.tech/docs/build/checks.md).

```shell
dbt build --skip-checks
```

Чтобы отключить одну проверку, не пропуская весь этап, задайте в её конфигурации `enabled: false`:

```yaml
checks:
  - name: all_models_have_descriptions
    config:
      enabled: false
```

### Флаг `--empty`

Команда `build` поддерживает флаг `--empty` для выполнения сухих запусков только со схемой. Флаг `--empty` ограничивает ссылки и источники до нуля строк. dbt все равно выполнит SQL модели в целевом хранилище данных, но избежит дорогостоящих чтений входных данных. Это проверяет зависимости и гарантирует, что ваши модели будут правильно собраны.

#### Метод render

Метод `.render()` обычно используется для разрешения или вычисления выражений Jinja (таких как `{{ source(...) }}`) во время выполнения.

При использовании флага `--empty`, dbt может пропустить обработку `ref()` или `source()` для оптимизации. Чтобы избежать ошибок компиляции и явно указать dbt обработать конкретное отношение (`ref()` или `source()`), используйте метод `.render()` в вашем файле модели. Например:

models.sql

```jinja
{{ config(
    pre_hook = [
        "alter external table {{ source('sys', 'customers').render() }} refresh"
    ]
) }}

select ...
```

## Тесты

Когда `dbt build` выполняется с применением модульных тестов, модели обрабатываются в соответствии с их родословной и зависимостями. Тесты выполняются следующим образом:

* [Модульные тесты](https://docs.getdbt.tech/docs/build/unit-tests.md) выполняются на SQL модели.
* Модель материализуется.
* [Тесты данных](https://docs.getdbt.tech/docs/build/data-tests.md) выполняются на модели.

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

Модульные тесты и тесты данных можно выбрать с помощью `--select test_type:unit` или `--select test_type:data` для `dbt build` (то же самое для флага `--exclude`).

### Примеры

```text
$ dbt build
Running with dbt=1.9.0-b2
Found 1 model, 4 tests, 1 snapshot, 1 analysis, 341 macros, 0 operations, 1 seed file, 2 sources, 2 exposures

18:49:43 | Concurrency: 1 threads (target='dev')
18:49:43 |
18:49:43 | 1 of 7 START seed file dbt_jcohen.my_seed............................ [RUN]
18:49:43 | 1 of 7 OK loaded seed file dbt_jcohen.my_seed........................ [INSERT 2 in 0.09s]
18:49:43 | 2 of 7 START view model dbt_jcohen.my_model.......................... [RUN]
18:49:43 | 2 of 7 OK created view model dbt_jcohen.my_model..................... [CREATE VIEW in 0.12s]
18:49:43 | 3 of 7 START test not_null_my_seed_id................................ [RUN]
18:49:43 | 3 of 7 PASS not_null_my_seed_id...................................... [PASS in 0.05s]
18:49:43 | 4 of 7 START test unique_my_seed_id.................................. [RUN]
18:49:43 | 4 of 7 PASS unique_my_seed_id........................................ [PASS in 0.03s]
18:49:43 | 5 of 7 START snapshot snapshots.my_snapshot.......................... [RUN]
18:49:43 | 5 of 7 OK snapshotted snapshots.my_snapshot.......................... [INSERT 0 5 in 0.27s]
18:49:43 | 6 of 7 START test not_null_my_model_id............................... [RUN]
18:49:43 | 6 of 7 PASS not_null_my_model_id..................................... [PASS in 0.03s]
18:49:43 | 7 of 7 START test unique_my_model_id................................. [RUN]
18:49:43 | 7 of 7 PASS unique_my_model_id....................................... [PASS in 0.02s]
18:49:43 |
18:49:43 | Finished running 1 seed, 1 view model, 4 tests, 1 snapshot in 1.01s.

Completed successfully

Done. PASS=7 WARN=0 ERROR=0 SKIP=0 TOTAL=7
```

## Функции

*Доступно начиная с dbt Core v1.11 и в dbt v2*

## Функции

*Доступно начиная с dbt v1.11*

Команда `build` создает [пользовательские функции](https://docs.getdbt.tech/docs/build/udfs.md) в рамках выполнения DAG. Чтобы создать или пересоздать только ресурсы типа `functions` в вашем проекте, выполните `dbt build --select "resource_type:function"`. Например:

```bash
dbt build --select "resource_type:function"
dbt-fusion 2.0.1
 Succeeded [  0.98s] function dbt_schema.whoami (function)
 Succeeded [  1.12s] function dbt_schema.area_of_circle (function)
```