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

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

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

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

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

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

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

к сведению

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

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

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

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

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

Начиная с версии dbt 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 1.9, мы упростили настройку снимков и добавили несколько новых параметров, чтобы снимки 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 в dbt v1.10, и это изменение также было перенесено в dbt v1.9:

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

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

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

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

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

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

  • (Добавлен, отключён по умолчанию) state_modified_compare_more_unrendered_values. Установите значение true, чтобы сохранять unrendered_config при разборе моделей и unrendered_database/unrendered_schema при разборе источников, а затем сравнивать значения до рендеринга при проверках state:modified. Это уменьшает число ложных срабатываний из-за логики, учитывающей окружение, но требует пересоздания каталога состояния; без этого state:modified может выбирать узлы с Jinja в конфигурациях YAML, которые на самом деле не изменились.
  • (Добавлен, отключён по умолчанию) Флаг конфигурации проекта skip_nodes_if_on_run_start_fails. Если флаг установлен и любой хук on-run-start завершается с ошибкой, все выбранные узлы помечаются как пропущенные.
    • Хуки on-run-start/end всегда выполняются независимо от того, завершились ли они успешно или с ошибкой в прошлый раз.
  • (Добавлен, отключён по умолчанию) require_nested_cumulative_type_params. Если флаг установлен в true, пользователи будут получать ошибку вместо предупреждения, если накопительные метрики оформлены неправильно и не используют новую вложенную структуру cumulative_type_params.
  • (Добавлен, отключён по умолчанию) require_batched_execution_for_custom_microbatch_strategy. Установите значение true, если вы используете пользовательский макрос микропакетной обработки, чтобы включить выполнение по пакетам. Если у вас нет пользовательского макроса микропакетной обработки, устанавливать этот флаг не нужно: dbt автоматически выполняет микропакетную обработку для любой модели, использующей стратегию microbatch.

Возможности и функциональность отдельных адаптеров​

Изменение размера столбцов в Snowflake

Snowflake планирует увеличить размер столбцов по умолчанию для строковых и двоичных типов данных в сентябре 2026 года. После внедрения этого изменения в версиях dbt-snowflake ниже v1.10.6 могут возникать ошибки при построении некоторых инкрементальных моделей.

 Оценка влияния и необходимые действия

Если вы используете версию dbt-snowflake ниже v1.10.6 или ещё не перешли на канал выпуска в dbt platform, ваша версия адаптера несовместима с этим изменением. Это может приводить к ошибкам при построении инкрементальных моделей, которые соответствуют обоим следующим условиям:

  • Содержат строковые столбцы с заданными правилами сортировки (collation)
  • Используют настройку on_schema_change='sync_all_columns'

Чтобы проверить, затрагивает ли это изменение ваш проект, выполните следующую команду list:

dbt ls -s config.materialized:incremental,config.on_schema_change:sync_all_columns --resource-type model

  • Если команда возвращает No nodes selected!, никаких действий не требуется.

  • Если команда возвращает одну или несколько моделей (например, Found 1000 models, 644 macros), изменение может затронуть вас, если в этих моделях есть строковые столбцы без явно указанной длины. В этом случае обновитесь до версии, содержащей исправление:

    • dbt v1: dbt-snowflake v1.10.6 или более поздняя версия. Указания по обновлению приведены в разделе Обновление адаптеров инструкции по установке dbt v1.
    • dbt platform: любой канал выпуска (v1 Latest, v1 Compatible, v1 Extended или v1 Fallback).
    • dbt v2: v2.0.0.

    Это позволит вашим инкрементальным моделям корректно обрабатывать изменения схемы, сохраняя необходимые настройки правил сортировки.

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

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, что теперь позволяет вам предоставлять пользовательские подключения

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

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

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

0
Loading