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

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

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

Начиная с 2024 года, dbt предоставляет функциональность новых версий dbt Core через release tracks с автоматическими обновлениями. Если вы выбрали трек выпуска "Latest" в dbt, у вас уже есть доступ ко всем возможностям, исправлениям и другой функциональности, которые включены в dbt Core v1.9. Если вы выбрали трек выпуска "Compatible", вы получите доступ в следующем ежемесячном выпуске "Compatible" после финального релиза dbt Core v1.9.

Начиная с 2024 года, dbt Cloud предоставляет функциональность из новых версий dbt Core через треки выпусков с автоматическими обновлениями. Если вы выбрали трек "Latest" в dbt Cloud, у вас уже есть доступ ко всем функциям, исправлениям и другим возможностям, которые включены в dbt Core v1.9! Если вы выбрали трек "Compatible", вы получите доступ в следующем ежемесячном выпуске "Compatible" после финального выпуска dbt Core v1.9.

Для пользователей dbt Core, начиная с версии v1.8, мы рекомендуем явно устанавливать как dbt-core, так и dbt-<youradapter>. Это может стать обязательным в будущей версии dbt. Например:

python3 -m pip install dbt-core dbt-snowflake

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

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

incremental_strategy с микропакетами​

к сведению

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

Инкрементальные модели всегда были оптимизацией производительности — для наборов данных, которые слишком велики, чтобы их можно было удалять и воссоздавать с нуля каждый раз, когда вы выполняете dbt run. Узнайте больше об инкрементальных моделях.

Исторически управление инкрементальными моделями включало несколько ручных шагов и обязанностей, включая:

  • Добавление фрагмента кода dbt (в блоке is_incremental()), который использует уже существующую таблицу (this) в качестве грубой закладки, чтобы обрабатывать только новые данные.
  • Выбор одной из стратегий для объединения старых и новых данных (append, delete+insert или merge).
  • Если что-то идет не так или ваша схема изменяется, вы всегда можете выполнить "полное обновление", запустив тот же простой запрос, который перестраивает всю таблицу с нуля.

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

Начиная с Core 1.9, вы можете использовать новую стратегию микропакетов для оптимизации ваших самых больших наборов данных — обрабатывайте ваши данные событий в дискретные периоды с их собственными SQL-запросами, а не все сразу. Преимущества включают:

  • Упрощённое проектирование запросов: Пишите запрос модели для одного батча данных. dbt будет использовать ваши конфигурации event_time, lookback и batch_size, чтобы автоматически сгенерировать необходимые фильтры, делая процесс более удобным и избавляя вас от необходимости управлять этими деталями вручную.
  • Независимая обработка батчей: dbt автоматически разбивает данные для загрузки на более мелкие батчи на основе заданного batch_size и обрабатывает каждый батч независимо, повышая эффективность и снижая риск тайм-аутов запросов. Если некоторые батчи завершатся с ошибкой, вы можете использовать dbt retry, чтобы загрузить только неудавшиеся батчи.
  • Точечная повторная обработка: Чтобы загрузить конкретный батч или несколько батчей, вы можете использовать аргументы CLI --event-time-start и --event-time-end.
  • Автоматическое параллельное выполнение батчей: Обрабатывайте несколько батчей одновременно, а не последовательно, для более быстрой обработки ваших microbatch‑моделей. dbt интеллектуально автоматически определяет, могут ли батчи выполняться параллельно, а также позволяет вручную переопределить параллельное выполнение с помощью конфигурации concurrent_batches.

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

  • postgres
  • redshift
  • snowflake
  • bigquery
  • spark
  • databricks

Начиная с версии dbt Core 1.9, мы упростили конфигурацию snapshots и добавили несколько новых параметров, чтобы сделать snapshots в dbt более простыми в настройке, запуске и кастомизации. Эти улучшения включают:

Начиная с dbt Core 1.9, мы упростили конфигурацию снимков и добавили несколько новых конфигураций, чтобы сделать снимки dbt проще в настройке, запуске и кастомизации. Эти улучшения включают:

  • Новая спецификация снимков: Снимки теперь можно настраивать в YAML-файле, что обеспечивает более чистую и согласованную настройку.
  • Новая конфигурация snapshot_meta_column_names: Позволяет вам кастомизировать имена мета-полей (например, dbt_valid_from, dbt_valid_to и т.д.), которые dbt автоматически добавляет к снимкам. Это увеличивает гибкость для адаптации метаданных к вашим нуждам.
  • target_schema теперь является необязательным для снимков: Если не указано, снимки будут использовать схему, определенную для текущей среды.
  • Поддержка стандартных конфигураций schema и database: Снимки теперь будут согласованы с другими типами ресурсов dbt. Вы можете указать, где должны храниться снимки, зависящие от среды.
  • Предупреждение о неправильном типе данных updated_at: Чтобы обеспечить целостность данных, вы увидите предупреждение, если поле updated_at, указанное в конфигурации снимка, не является правильным типом данных или временной меткой.
  • Установите пользовательский текущий индикатор для значения dbt_valid_to: Используйте конфигурацию dbt_valid_to_current, чтобы установить пользовательский индикатор для значения dbt_valid_to в текущих записях снимка (например, будущая дата). По умолчанию это значение NULL. Когда настроено, dbt будет использовать указанное значение вместо NULL для dbt_valid_to для текущих записей в таблице снимков.
  • Используйте конфигурацию hard_deletes, чтобы получить больший контроль над тем, как обрабатывать удаленные строки из источника. Поддерживаемые методы: ignore (по умолчанию), invalidate (заменяет устаревший invalidate_hard_deletes=true) и new_record. Установка hard_deletes='new_record' позволяет отслеживать жесткие удаления, добавляя новую запись, когда строка становится "удаленной" в источнике.

Узнайте больше о мета-полях снимков.

Некоторые properties были перемещены в configs​

Следующие properties были перемещены в configs в Core v1.10 и портированы обратно в Core v1.9:

Улучшения state:modified​

Улучшения state:modified​

Мы внесли улучшения в поведение state:modified, чтобы помочь снизить риск ложных срабатываний и пропусков. Узнайте больше о флаге поведения state:modified, который разблокирует это улучшение:

  • Добавлены улучшения, зависящие от среды, для сред, где логика намеренно отличается (например, материализация в виде таблицы в prod, но в виде view в dev).

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

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

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

  • (Введено, отключено по умолчанию) state_modified_compare_more_unrendered_values. Установите в True, чтобы начать сохранять unrendered_database и unrendered_schema конфигурации во время парсинга источника и выполнять сравнение на неотрендеренных значениях во время проверок state:modified, чтобы уменьшить ложные срабатывания из-за логики, зависящей от среды, при выборе state:modified.
  • (Введено, отключено по умолчанию) skip_nodes_if_on_run_start_fails проектный флаг конфигурации. Если флаг установлен и любой on-run-start хук не удается, пометьте все выбранные узлы как пропущенные.
    • on-run-start/end хуки всегда выполняются, независимо от того, прошли они или не прошли в прошлый раз.
  • (Введено, отключено по умолчанию) [Redshift] restrict_direct_pg_catalog_access. Если флаг установлен, адаптер будет использовать API Redshift (через клиент Python), если он доступен, или запрашивать таблицы information_schema Redshift вместо использования таблиц pg_.
  • (Введено, отключено по умолчанию) require_nested_cumulative_type_params. Если флаг установлен в True, пользователи получат ошибку вместо предупреждения, если они неправильно форматируют кумулятивные метрики, используя новое вложение cumulative_type_params.
  • (Введено, отключено по умолчанию) require_batched_execution_for_custom_microbatch_strategy. Установите в True, если вы используете пользовательский макрос микропакетов для включения пакетного выполнения. Если у вас нет пользовательского макроса микропакетов, вам не нужно устанавливать этот флаг, так как dbt автоматически обработает микропакетирование для любой модели, использующей стратегию микропакетов.

Специфические для адаптеров функции и функциональность​

Redshift​

  • Поддержка аутентификации через IAM Role

Snowflake​

  • Iceberg Table Format — Поддержка будет доступна для трёх стандартных materializations «из коробки»: table, incremental, dynamic tables.
  • Breaking change — При обновлении с dbt 1.8 до 1.9 значение {{ target.account }} теперь заменяет подчёркивания на дефисы. Например, если target.account задан как sample_company, то скомпилированный код теперь будет генерировать sample-company. Подробнее см. issue в репозитории dbt-snowflake.

Bigquery​

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

Spark​

  • Поддержка переопределения строки подключения драйвера ODBC, что теперь позволяет вам предоставлять пользовательские подключения

Быстрые изменения​

Мы также внесли некоторые улучшения в качество жизни в Core 1.9, позволяя вам:

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

0
Loading