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

Обновление до версии 0.17.0

dbt v0.17.0 делает компиляцию более последовательной, улучшает производительность и исправляет ряд ошибок.

Статьи:​

Значительные изменения​

Обратите внимание на следующие изменения в версии 0.17.0, которые могут потребовать обновления кода в вашем проекте dbt.

Новая версия конфигурации dbt_project.yml​

dbt v0.17.0 вводит новую версию конфигурации для файла dbt_project.yml. Эта новая версия конфигурации изменяет семантику того, как dbt интерпретирует файл dbt_project.yml.

Указание версии конфигурации​

Версия конфигурации может быть указана с помощью ключа config-version в файле dbt_project.yml:

name: my_project
version: 1.0.0

config-version: 2

models:
  ...

Допустимые значения для config-version — это 1 и 2. При использовании config-version: 2 в dbt разблокируется новая функциональность.

Использование config-version: 2​

Улучшенная семантика области видимости переменных​

Предыдущие версии dbt позволяли переменным (vars:) быть ограниченными на уровне папки в иерархии models:. Это создает несколько проблем:

  • Переменные должны действительно применяться только к моделям (так как объявление переменной находится в конфигурации models:), но переменные также часто используются в тестах, файлах schema.yml, макросах, снимках и так далее.
  • Существует неоднозначность в том, как переменные разрешаются в файлах schema.yml. Рассмотрим случай, когда файл schema.yml ограничен одним значением для переменной, но модель, на которую он ссылается, ограничена другим значением для той же переменной. Поведение var() в этом сценарии плохо определено и часто не соответствует ожиданиям.

В версии 2 конфигурации dbt_project.yml переменные теперь должны быть определены в словаре верхнего уровня vars:, например:

dbt_project.yml
name: my_project
version: 1.0.0

config-version: 2

vars:
  my_var: 1
  another_var: true

models:
  ...

Этот синтаксис делает область видимости переменных однозначной, так как все узлы в данном пакете получат одно и то же значение для данной переменной. Обратите внимание, что этот синтаксис действительно поддерживает область видимости переменных на уровне пакета. См. документацию по синтаксису файла dbt_project.yml для получения дополнительной информации.

Однозначные конфигурации ресурсов​

Версия 1 спецификации файла dbt_project.yml допускала неоднозначные конфигурации моделей, когда конфигурации словаря определялись в блоке models:. Рассмотрим:

dbt_project.yml
models:
  my_project:
    reporting:
      partition_by:
        field: date_day
        data_type: timestamp

Этот пример предназначен для настройки параметра partition_by для всех моделей BigQuery в папке models/reporting/. Однако из синтаксиса в этом файле можно сделать два возможных вывода:

  • Настроить значение partition_by для моделей в папке models/reporting
  • Настроить значения field и data_type для моделей в папке models/reporting/partition_by

Чтобы разрешить эту неоднозначность, конфигурации теперь могут быть предоставлены с использованием синтаксиса + для ключей конфигурации. Для приведенного выше примера это будет выглядеть так:

dbt_project.yml

models:
  my_project:
    reporting:
      +partition_by:
        field: date_day
        data_type: timestamp

Этот синтаксис однозначно определяет partition_by как конфигурацию со значением словаря {field: date_day, data_type: timestamp}. Этот декоратор + может быть использован для любой конфигурации и может быть полезен, если у вас есть имя папки, которое совпадает с известным ключом конфигурации проекта dbt. Пример:

dbt_project.yml
# Ваша модель находится в models/materialized/my_model.sql

models:
  my_project:
    materialized:
      +materialized: table

Эта конфигурация будет работать в dbt v0.17.0, когда используется config-version: 2, но не могла быть представлена в предыдущих версиях dbt.

Инструкции по обновлению​
  • Добавьте config-version: 2 в ваш файл dbt_project.yml
  • Убедитесь, что все объявления vars: в вашем файле dbt_project.yml были перемещены в верхний уровень файла
  • Убедитесь, что все пакеты, на которые ссылается ваш проект, также объявлены с config-version: 2

Поддержка версии 1 будет удалена в будущих выпусках dbt.

Рендеринг NativeEnvironment для полей YAML​

В dbt v0.17.0 dbt включил использование Native Environment Jinja для рендеринга значений в YML файлах. Этот Native Environment преобразует строковые значения в их примитивные типы Python (логические, целые, числа с плавающей запятой и кортежи). С этим изменением вы теперь можете предоставлять логические и целочисленные значения для конфигураций через строковые входные данные, такие как переменные окружения или переменные командной строки.

Внимание

В dbt v0.17.1 нативный рендеринг не включен по умолчанию. Возможно нативно рендерить конкретные значения, используя фильтры as_bool, as_number и as_native.

Примеры ниже были обновлены, чтобы отразить функциональность 0.17.1.

Этот пример указывает номер порта как целое число из переменной окружения. Это было невозможно в предыдущих версиях dbt.


debug:
  target: dev
  outputs:
    dev:
      type: postgres
      user: "{{ env_var('DBT_USER') }}"
      password: "{{ env_var('DBT_PASS') }}"
      host: "{{ env_var('DBT_HOST') }}"

      # Номер порта будет преобразован из строки в целое число
      port: "{{ env_var('DBT_PORT') | as_number }}"

      dbname: analytics
      schema: analytics

Наконец, теперь вы можете включать или отключать модели условно в зависимости от окружения, в котором выполняется dbt. В этом примере модели в пакете admin будут отключены в dev. Это было невозможно в предыдущих версиях dbt.

dbt_project.yml
name: my_project
version: 1.0.0

config-version: 2

models:
  my_project:
    +enabled: true

  admin:
    +enabled: "{{ (target.name == 'prod') | as_bool }}"

Доступ к источникам в объекте graph​

В предыдущих версиях dbt, sources в проекте dbt могли быть доступны в контексте компиляции с использованием переменной контекста graph.nodes. В dbt v0.17.0 эти источники были перемещены из словаря graph.nodes в новый словарь graph.sources. Это изменение также отражено в артефакте manifest.json, создаваемом dbt. Если вы программно обращаетесь к этим источникам, пожалуйста, обновите все ссылки с graph.nodes на graph.sources.

Удаление locations из каталога BigQuery​

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

Макросы больше не видят переменные, определенные вне блоков макросов​

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

{% set my_global = ['a', 'b', 'c'] %}
{% macro use_my_global() %}
    {% for value in my_global %}
        {% do log('value: ' ~ value) %}
    {% endfor %}
{% endmacro %}

Теперь это ошибка, потому что my_global не виден для макроса use_my_global. Чтобы предоставить значение, доступное глобально, используйте макрос, который возвращает постоянное значение:

{% macro get_my_global() %}
    {% do return(['a', 'b', 'c']) %}
{% endmacro %}
{% macro use_my_global() %}
    {% for value in get_my_global() %}
        {% do log('value: ' ~ value) %}
    {% endfor %}
{% endmacro %}

Требования к Python​

Если вы устанавливаете dbt в окружение Python вместе с другими модулями Python, пожалуйста, обратите внимание на следующие изменения в зависимостях Python для dbt:

Core:

  • Закреплена зависимость Jinja2 на 2.11.2
  • Закреплен hologram на 0.0.7
  • Требуется Python >= 3.6.3

BigQuery:

  • Требуется protobuf>=3.6.0,<3.12

Новая и измененная документация​

Core

BigQuery

0
Отредактировать эту страницу