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

Обновление до 0.14.0

Это руководство описывает инструкции по миграции для:

  1. Обновление архивов до снимков
  2. Использование обновлений в макросе generate_schema_name
  3. Удаление флага --non-destructive
  4. Изменения в построении инкрементальных моделей на Snowflake

Обновление до блоков Snapshot​

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

Существует несколько изменений, о которых следует знать при миграции с архивов на снимки:

  • имена мета-столбцов теперь имеют префикс dbt_
  • снимки указываются в .sql файлах, тогда как архивы указывались в файле dbt_project.yml

Изменения в именах столбцов Snapshot​

Эта показывает различия между именами столбцов, создаваемыми dbt archive и dbt snapshot. Примечание: Новые имена мета-столбцов снимков не заключены в кавычки. Если вы используете Snowflake, это означает, что имена столбцов снимков будут отображаться в верхнем регистре, а не в нижнем.

Архивный столбец (в кавычках)Столбец Snapshot (без кавычек)
valid_fromdbt_valid_from
valid_todbt_valid_to
scd_iddbt_scd_id

Миграция архивов в снимки​

Миграция архивов в снимки включает два различных типа изменений в вашем проекте dbt:

  1. переименование столбцов в ваших существующих архивных таблицах
  2. замена секции archive: в файле dbt_project.yml на блоки snapshot

Мы предоставили скрипт миграции в dbt v0.14.0, который выполняет обе эти задачи. Этот скрипт:

  1. создаст резервную копию ваших архивных таблиц
  2. переименует столбцы, как указано в таблице выше
  3. создаст блоки снимков для ваших существующих архивов в новых .sql файлах

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

Запуск скрипта миграции​

Пользовательские материализации

Это руководство предполагает, что вы используете встроенную архивную материализацию. Если вы используете пользовательскую архивную материализацию, см. раздел "Ручная миграция архивов" ниже.

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

$ dbt snapshot-migrate --from-archive

Пример вывода:

$ dbt snapshot-migrate --from-archive
Running with dbt=0.14.0
Found 1 archive to migrate

Archive 1 of 1: "analytics"."archived"."orders_archived"
  - Skipping migration in dry-run mode
  - Skipping new snapshot file in dry-run mode

Re-run this script with `--apply` to apply these migrations

Эта команда выведет список архивных таблиц, которые должны быть мигрированы. После проверки списка архивных таблиц примените миграцию, используя флаг --apply:

$ dbt snapshot-migrate --from-archive --apply

Пример вывода:

$ dbt snapshot-migrate --from-archive --apply
Running with dbt=0.14.0
Found 1 archive to migrate

Archive 1 of 1: "analytics"."archived"."orders_archived"
  - Starting table migration
  - Backing up table to "analytics"."archived"."orders_archived_dbt_archive_migration_backup"
  - Finished table migration
  - Wrote new snapshot file to snapshots/orders_archived.sql

The following backup tables were created:
  - "analytics"."archived"."orders_archived_dbt_archive_migration_backup"

The following snapshot files were created:
  - snapshots/orders_archived.sql

After verifying the migrated tables in the database, please drop the backup
tables and remove any archive configs from your dbt_project.yml file.

Если этот шаг прошел успешно, поздравляем! Ваши архивы были мигрированы в снимки.

Завершение миграции​

После выполнения скрипта выше важно проверить данные в ваших новых таблицах снимков. Выполните запросы к таблицам снимков, чтобы убедиться, что они существуют и содержат мета-столбцы с префиксами dbt_.

Далее, проверьте новые снимки в вашем каталоге snapshots/. Должен быть один файл снимка на каждый архив, существующий в вашем проекте. Если эти файлы снимков присутствуют и действительны, вы можете удалить секцию archive: из вашего файла dbt_project.yml.

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

Снимки участвуют в графе dbt, поэтому не стесняйтесь заменять любые ссылки schema.table в вашем коде модели на {{ ref('archive_name') }}. Возможно, вам также потребуется внести изменения в модели или отчеты, чтобы учесть изменения в именах мета-столбцов снимков. Обратитесь к документации по снимкам для получения полных инструкций по использованию.

Ручная миграция архивов (не рекомендуется)​

Если вы не можете использовать скрипт миграции архивов, вы можете вручную мигрировать ваши архивы в снимки. Точные шаги, необходимые для миграции архивов в снимки, зависят от базы данных, но в целом вам нужно будет переименовать мета-столбцы архивов в соответствии с таблицей миграции выше. Примеры запросов на миграцию (с использованием синтаксиса postgres):

alter table archived.orders_archived rename "valid_from" to dbt_valid_from;
alter table archived.orders_archived rename "valid_to" to dbt_valid_to;
alter table archived.orders_archived rename "scd_id" to dbt_scd_id;

Обновление сигнатуры generate_schema_name​

В dbt v0.14.0 сигнатура макроса generate_schema_name была изменена для принятия второго аргумента, node. Для получения дополнительной информации о новом аргументе node обратитесь к документации по использованию пользовательских схем.

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

Пример предупреждения​

Начиная с dbt v0.14.0, макрос `generate_schema_name` принимает второй аргумент "node".
Форма `generate_schema_name` с одним аргументом устарела и станет неподдерживаемой в будущем выпуске.

Обновление​

Чтобы обновить этот макрос (и подавить это предупреждение), добавьте второй аргумент, node, в ваш макрос generate_schema_name.

generate_schema_name.sql
{% macro generate_schema_name(schema_name, node) -%}
  ... ваша логика здесь ...
{%- endmacro %}

Неразрушающие запуски​

Флаг --non-destructive был удален из dbt в v0.14.0. Этот флаг существовал как обходной путь для отсутствия позднесвязываемых представлений в Amazon Redshift. С введением клаузулы with no schema binding для представлений Redshift, неразрушающие запуски больше не нужны.

Флаг --non-destructive был проблематичным по нескольким причинам:

  1. Он использовал оператор truncate, который фиксировал существующую транзакцию. Это означало, что неразрушающие запуски не были атомарными, и ошибки в сборке модели могли оставить вас с пустыми таблицами!
  2. Он делал материализации dbt невероятно сложными и трудными для поддержки
  3. Он полностью пропускал построение представлений, что редко бывает желательным
  4. Он терпел неудачу в сложных и коварных случаях, когда столбцы добавлялись или удалялись из моделей таблиц

Пользователи Snowflake, BigQuery, SparkSQL и Presto не должны быть затронуты этим изменением, так как использование флага --non-destructive на этих базах данных имеет ограниченный смысл.

Пользователи Redshift должны рассмотреть возможность использования конфигурации bind: false, чтобы указать dbt создавать несвязанные представления.

Пользователи Postgres должны убедиться, что они используют таблицы или инкрементальные модели для отношений, которые запрашиваются конечными пользователями.

Изменения в инкрементальных моделях Snowflake​

В dbt v0.14.0 реализация инкрементальных моделей на Snowflake изменилась. По умолчанию dbt будет использовать оператор merge для атомарного добавления и обновления записей в инкрементально. Предыдущие версии dbt использовали двухэтапный подход delete+insert для добавления и обновления данных.

Оператор merge требует, чтобы записи, участвующие в добавлении и обновлении, были уникальными. Если эти записи не уникальны, оператор завершится с ошибкой "недетерминированное слияние". Если вы видите эту ошибку после обновления до 0.14.0, вы можете решить ее одним из двух способов:

  1. Измените логику запроса вашей модели, чтобы гарантировать, что указанный параметр unique_key действительно уникален
  2. Установите конфигурацию incremental_strategy в delete+insert, чтобы продолжить использование предыдущего двухэтапного инкрементального подхода

Конфигурация incremental_strategy может быть установлена в вашем файле dbt_project.yml (если вы хотите применить эту конфигурацию ко всем моделям) или она может быть применена в конкретных моделях, где это необходимо.

Конфигурация incremental_strategy для всех моделей:

dbt_project.yml
# Ваш файл dbt_project.yml

models:
  incremental_strategy: "delete+insert"

Конфигурация incremental_strategy для одной модели:

models/my_model.sql

{{
  config(
    materialized='incremental',
    unique_key='id',
    incremental_strategy='delete+insert'
  )
}}

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