# Обновление до v1.6

Доступно в v1

Поддержка dbt v1.3 – v1.7 будет прекращена January 31, 2027

Версии dbt v1.3-v1.7 достигли [конца жизненного цикла](https://docs.getdbt.tech/docs/dbt-versions.md#end-of-life-versions), и их поддержка будет прекращена January 31, 2027. После этой даты dbt Labs больше не будет поддерживать эти версии, и они будут удалены из dbt platform.

До этой даты переведите свои окружения на [поддерживаемую версию dbt](https://docs.getdbt.tech/docs/dbt-versions.md) или [канал выпусков](https://docs.getdbt.tech/docs/dbt-versions/dbt-release-tracks.md), чтобы продолжать получать обновления и поддержку. Подробнее см. в руководстве [Переход с устаревших версий dbt](https://docs.getdbt.tech/guides/migrate-off-legacy-dbt-versions.md?step=1).

В dbt v1.6 основное внимание уделено трём направлениям:

1. Следующий этап развития [многопроектных развёртываний](https://github.com/dbt-labs/dbt/discussions/6725): улучшения контрактов, групп и прав доступа, версий; а также базовые компоненты для межпроектного `ref`
2. Перезапуск семантического слоя: интеграция dbt v1 и [MetricFlow](https://docs.getdbt.tech/docs/build/about-metricflow.md)
3. Механизмы для масштабируемого развёртывания в зрелых процессах разработки (`dbt clone` и `dbt retry`)

## Ресурсы

* [Журнал изменений](https://github.com/dbt-labs/dbt/blob/1.6.latest/CHANGELOG.md)
* [Руководство по установке dbt v1](https://docs.getdbt.tech/docs/local/install-dbt.md)
* [Руководство по обновлению Cloud](https://docs.getdbt.tech/docs/dbt-versions/upgrade-dbt-platform-version.md)
* [График выпусков](https://github.com/dbt-labs/dbt/issues/7481)

## Что нужно знать перед обновлением

dbt Labs обеспечивает обратную совместимость для всех версий 1.x, за исключением изменений, явно указанных ниже. Если при обновлении возникнет ошибка, сообщите нам об этом, [создав issue](https://github.com/dbt-labs/dbt/issues/new).

### Изменения в поведении

Требуются действия, если в вашем проекте определены `metrics`

[Спецификация метрик](https://github.com/dbt-labs/dbt/discussions/7456) изменилась и теперь использует [MetricFlow](https://docs.getdbt.tech/docs/build/about-metricflow.md).

Если в вашем проекте dbt определены метрики, необходимо перейти на dbt v1.6, поскольку спецификация YAML перенесена из dbt\_metrics в MetricFlow. Имеющиеся у вас тесты не будут компилироваться в v1.5 и более ранних версиях.

* dbt v1.6 не поддерживает Python 3.7, срок поддержки которого истёк 23 июня. Поддерживаются версии Python 3.8, 3.9, 3.10 и 3.11.
* В рамках перезапуска [семантического слоя dbt](https://docs.getdbt.tech/docs/use-dbt-semantic-layer/dbt-sl.md) спецификация `metrics` значительно изменилась.
* Версия схемы манифеста теперь — v10.
* dbt Labs прекращает поддержку установки dbt v1 и адаптеров через Homebrew. Подробнее см. в [обсуждении](https://github.com/dbt-labs/dbt/discussions/8277).

### Для пользователей артефактов dbt (метаданных)

Версия схемы [манифеста](https://docs.getdbt.tech/reference/artifacts/manifest-json.md) обновлена до `v10`. Конкретные изменения:

* Добавлен атрибут `semantic_models` и изменены атрибуты `metrics`
* Добавлено свойство модели `deprecation_date`
* В конфигурацию узла по умолчанию добавлен параметр `on_configuration_change` (для поддержки материализованных представлений)
* Небольшие изменения типов в `contracts` и `constraints`
* Раздел `metadata` манифеста включает `project_name`

### Для разработчиков плагинов адаптеров

Чтобы получить более подробную информацию и задать вопросы, ознакомьтесь с обсуждением на GitHub и оставьте комментарий: [dbt-labs/dbt-core#7958](https://github.com/dbt-labs/dbt/discussions/7958).

## Новая и обновлённая документация

### MetricFlow

* [**Создавайте метрики**](https://docs.getdbt.tech/docs/build/build-metrics-intro.md) с помощью MetricFlow — ключевого компонента Semantic Layer. С помощью MetricFlow можно определять метрики и создавать семантические модели; инструмент доступен в командной строке (CLI) для dbt v1.6 beta и более поздних версий.

### Материализованные представления

Поддерживаются на следующих платформах:

* [Postgres](https://docs.getdbt.tech/reference/resource-configs/postgres-configs.md#materialized-views)
* [Redshift](https://docs.getdbt.tech/reference/resource-configs/redshift-configs.md#materialized-views)
* [Snowflake](https://docs.getdbt.tech/reference/resource-configs/snowflake-configs.md#dynamic-tables)
* [Databricks](https://docs.getdbt.tech/reference/resource-configs/databricks-configs.md#materialized-views-and-streaming-tables)

### Новые команды для зрелых процессов развёртывания

[`dbt retry`](https://docs.getdbt.tech/reference/commands/retry.md) выполняет ранее запущенную команду с момента сбоя. Повторно собирайте только те узлы, которые завершились с ошибкой или были пропущены при предыдущем выполнении run/build/test, вместо того чтобы начинать всё с нуля.

[`dbt clone`](https://docs.getdbt.tech/reference/commands/clone.md) использует возможности каждой платформы данных для создания легковесных копий моделей dbt из одной среды в другой. Это полезно для быстрого создания новой среды разработки или переноса отдельных моделей из промежуточной среды в производственную.

### Совместная работа с несколькими проектами

[**Дата прекращения поддержки**](https://docs.getdbt.tech/reference/resource-properties/deprecation_date.md): для моделей можно указывать дату прекращения поддержки, о которой будут предупреждаться разработчики моделей и их потребители ниже по цепочке зависимостей. Это позволяет задавать чёткие сроки миграции для версионируемых моделей и предоставляет механизм, упрощающий удаление незрелых или редко используемых моделей, что помогает избежать разрастания проекта.

[Имена моделей](https://docs.getdbt.tech/faqs/Project/unique-resource-names.md) могут повторяться в разных пространствах имён (проектах/пакетах), если они уникальны в пределах каждого проекта/пакета. Мы настоятельно рекомендуем использовать [`ref` с двумя аргументами](https://docs.getdbt.tech/reference/dbt-jinja-functions/ref.md#ref-project-specific-models) при обращении к модели из другого пакета/проекта.

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

* Переменные `vars`, определённые в файле `dbt_project.yml` пакета, теперь учитываются в порядке разрешения переменных при компиляции узлов этого пакета, хотя `--vars` из CLI и `vars` корневого проекта по-прежнему имеют приоритет. Подробнее см. в разделе [«Приоритет переменных»](https://docs.getdbt.tech/docs/build/project-variables.md#variable-precedence).
* Макросы `generate_x_name` (задающие пользовательские правила именования баз данных, схем и псевдонимов) следуют той же схеме переопределения в области видимости пакета, что и другие «глобальные» макросы. Обзор возможных вариантов см. в разделе [диспетчеризация макросов](https://docs.getdbt.tech/reference/dbt-jinja-functions/dispatch.md).

Закрытая бета-версия — dbt Enterprise

[**Зависимости проектов**](https://docs.getdbt.tech/docs/mesh/govern/project-dependencies.md): добавлены `dependencies.yml` и зависимые `projects` как возможность dbt Enterprise. Позволяет обеспечивать соблюдение прав доступа к моделям (public в сравнении с protected/private) за пределами проектов/пакетов. Обеспечивает межпроектные ссылки `ref` на публичные модели без необходимости устанавливать исходный код вышестоящих проектов.

### Устаревающая функциональность

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

* Переопределение встроенной материализации из установленного пакета вызывает предупреждение об использовании устаревающей функциональности.

* Использование пользовательской материализации из установленного пакета не вызывает предупреждения об использовании устаревающей функциональности.

* Использование переопределения встроенной материализации из пакета в корневом проекте через материализацию-обёртку по-прежнему поддерживается. Например:

  ```text
  {% materialization view, default %}
  {{ return(my_cool_package.materialization_view_default()) }}
  {% endmaterialization %}
  ```

### Другие небольшие изменения

* [`state:unmodified` и `state:old`](https://docs.getdbt.tech/reference/node-selection/methods.md#state) для выбора по состоянию в соответствии с принципом [MECE](https://en.wikipedia.org/wiki/MECE_principle)
* [`invocation_args_dict`](https://docs.getdbt.tech/reference/dbt-jinja-functions/flags.md#invocation_args_dict) включает полную команду `invocation_command` в виде строки
* [`dbt debug --connection`](https://docs.getdbt.tech/reference/commands/debug.md) позволяет проверить только подключение к платформе данных, указанное в профиле
* [`dbt docs generate --empty-catalog`](https://docs.getdbt.tech/reference/commands/cmd-docs.md) позволяет пропустить заполнение каталога при генерации документации
* [`--defer-state`](https://docs.getdbt.tech/reference/node-selection/defer.md) обеспечивает более детальное управление
* В [`dbt ls`](https://docs.getdbt.tech/reference/commands/list.md) добавлен метод выбора семантических моделей, позволяющий использовать `dbt ls -s "semantic_model:*"`, а также возможность выполнять `dbt ls --resource-type semantic_model`.
* Синтаксис `DBT_ENV_SECRET_` изменён на `DBT_ENV_SECRET`: завершающий символ подчёркивания больше не требуется.