Перейти к основному содержимому

Обновление до версии v1.8

Ресурсы​

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

dbt Labs стремится обеспечивать обратную совместимость для всех версий 1.x, за исключением изменений, явно указанных на этой странице. Если вы столкнетесь с ошибкой при обновлении, пожалуйста, сообщите нам, создав задачу.

Треки релизов​

Начиная с 2024 года, dbt предоставляет функциональность из новых версий dbt Core через release tracks с автоматическими обновлениями. Выберите release track в ваших средах разработки, staging и production, чтобы получить доступ ко всем возможностям dbt Core v1.8+ и не только. Чтобы обновить среду через dbt Admin API или Terraform, установите параметр dbt_version в строковое значение latest.

Новые и измененные функции и функциональность​

Новые функции и функциональность в dbt v1.8.

Новая процедура установки адаптера dbt Core​

До dbt Core v1.8, когда вы устанавливали адаптер для хранилища данных с помощью pip install, pip автоматически устанавливал dbt-core вместе с ним. Адаптер dbt напрямую зависел от компонентов dbt-core, а dbt-core зависел от адаптера для выполнения. Эта двусторонняя зависимость затрудняла разработку адаптеров независимо от dbt-core.

Начиная с версии v1.8, dbt-core и адаптеры разделены. В дальнейшем ваши установки должны явно включать как dbt-core, так и нужный адаптер. Новая команда установки pip должна выглядеть так:

pip install dbt-core dbt-ADAPTER_NAME

Например, если вы используете Snowflake, используйте следующую команду:

pip install dbt-core dbt-snowflake

На данный момент мы сохранили зависимости во время установки, чтобы избежать неожиданных сбоев в существующих скриптах; pip install dbt-snowflake продолжит устанавливать последние версии как dbt-core, так и dbt-snowflake. Учитывая, что мы можем удалить эту неявную зависимость в будущих версиях, мы настоятельно рекомендуем обновить скрипты установки сейчас.

Модульные тесты​

Исторически, тестовое покрытие dbt ограничивалось “данными” тестами, оценивающими качество входных данных или структуру результирующих наборов данных.

В версии v1.8 мы вводим нативную поддержку модульного тестирования. Модульные тесты проверяют вашу SQL-логику моделирования на небольшом наборе статических входных данных до того, как вы материализуете вашу полную модель в производстве. Они поддерживают подход разработки, основанный на тестировании, улучшая как эффективность разработчиков, так и надежность кода.

Начиная с версии v1.8, когда вы выполняете команду dbt test, она будет запускать как модульные, так и данные тесты. Используйте метод test_type, чтобы запускать только модульные или данные тесты:

dbt test --select "test_type:unit"           # запустить все модульные тесты
dbt test --select "test_type:data"           # запустить все данные тесты

Модульные тесты определяются в YML-файлах в вашем каталоге models/ и в настоящее время поддерживаются только для SQL-моделей. Чтобы различать их, конфигурация tests: была переименована в data_tests:. Оба варианта в настоящее время поддерживаются для обратной совместимости.

Новый синтаксис data_tests:​

Синтаксис tests: изменяется, чтобы отразить добавление модульных тестов. Начните миграцию вашего теста данных YML на использование data_tests: после обновления до версии v1.8, чтобы избежать проблем в будущем.

models:
  - name: orders
    columns:
      - name: order_id
        data_tests:
          - unique
          - not_null

Флаг --empty​

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

Устаревшая функциональность​

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

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

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

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

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

Управление изменениями в устаревших поведениях​

dbt Core v1.8 ввел флаги для управления изменениями в устаревших поведениях. Вы можете включить недавно введенные изменения (по умолчанию отключены) или отключить зрелые изменения (по умолчанию включены), установив значения True / False соответственно для flags в dbt_project.yml.

Вы можете прочитать больше о каждом из этих изменений поведения по следующим ссылкам:

Быстрые заметки​

  • Пользовательские значения по умолчанию для глобальных конфигурационных флагов следует устанавливать в словаре flags в dbt_project.yml, вместо profiles.yml. Поддержка profiles.yml устарела.
  • Новый флаг CLI --resource-type/--exclude-resource-type для включения/исключения ресурсов из dbt build, run и clone.
  • Для улучшения производительности dbt теперь выполняет один (пакетный) запрос при расчете source freshness через метаданные, вместо выполнения запроса для каждого источника.
  • Синтаксис для DBT_ENV_SECRET_ изменен на DBT_ENV_SECRET и больше не требует завершающего подчеркивания.

Нашли ошибку?

0
Loading