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

Релиз dbt v0.14.1 не содержит критических изменений в коде для пользователей, обновляющихся с версии v0.14.0. Если вы обновляетесь с версии ниже 0.14.0, обратитесь к руководству по миграции Обновление до 0.14.0. Следующий раздел содержит важную информацию для пользователей стратегии check на Snowflake и BigQuery. Возможно, потребуется действие в вашей базе данных.

Изменения в алгоритме "check" для Snapshot

Snowflake и BigQuery

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

Когда Snapshot настроен на использование стратегии check, dbt будет сравнивать указанные check_cols между исходным набором данных и снапшотом, чтобы определить, изменялась ли строка в Snapshot. Логическая ошибка в релизе v0.14.0 dbt вызвала сбой этой стратегии, если значения указанных check_cols для данной строки возвращались в ранее известное состояние. Важно отметить, что эта проблема затрагивает только Snowflake и BigQuery из-за их использования оператора merge в Snapshots.

В этом режиме сбоя dbt "завершал" существующие записи, устанавливая дату dbt_valid_to для измененной записи без соответствующей вставки новой записи для изменения. В этом состоянии завершенные записи больше не будут отслеживаться в таблице Snapshot .

Решение

Чтобы определить, затронута ли ваша таблица Snapshot этой проблемой, вы можете выполнить запрос для поиска "застрявших" записей. Эти "застрявшие" записи:

• Являются самыми последними записями для данного unique_key в снапшоте
• Имеют значения как для dbt_valid_from, так и для dbt_valid_to

Следующий запрос вернет строки, которые соответствуют этим критериям:

snapshot_check_cols_migrate.sql

with base as (

    select *,

        -- Замените `<your unique key>` на ваш указанный unique_key 
        <your unique key> as dbt_unique_key

    -- Замените <your snapshot table> на имя таблицы снапшота
    from <your snapshot table>

),

ranked as (

    select *,
        row_number() over (
            partition by dbt_unique_key
            order by dbt_valid_from desc
        ) as change_idx

    from base

),

to_migrate as (

    select *
    from ranked
    where change_idx = 1
    and dbt_valid_to is not null

)

select * from to_migrate
limit 100;

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

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

Подход #1: Ручное обновление таблиц снапшотов

Внимание!

Эта миграция требуется только для пользователей стратегии снапшота check на Snowflake и BigQuery. Если ваш проект не соответствует этим критериям, то вам не нужно мигрировать ваши таблицы Snapshot.

Запрос, показанный выше, сгенерирует набор строк, которые находятся в "застрявшем" состоянии. Вы можете использовать результат этого запроса, чтобы обновить записи в вашей таблице снапшота и вывести их из "застрявшего" состояния. Для этого используйте оператор update, который устанавливает столбец dbt_valid_to в null для записей, идентифицированных в приведенном выше запросе. Будьте осторожны при выполнении непосредственно против таблицы снапшота. Рекомендуется сделать резервную копию этой таблицы перед выполнением этой миграции вручную! Пример запроса приведен ниже: тщательно протестируйте этот запрос перед его выполнением в рабочей среде.

fix_snapshot_stuck_records.sql

-- Замените <your snapshot table> на имя таблицы снапшота
update <your snapshot table>
set dbt_valid_to = null
where dbt_scd_id in (

  with base as (

      select *,

          -- Замените `<your unique key>` на ваш указанный unique_key 
          <your unique key> as dbt_unique_key

      -- Замените <your snapshot table> на имя таблицы снапшота
      from <your snapshot table>

  ),

  ranked as (

      select *,
          row_number() over (
              partition by dbt_unique_key
              order by dbt_valid_from desc
          ) as change_idx

      from base

  ),

  to_migrate as (

      select *
      from ranked
      where change_idx = 1
      and dbt_valid_to is not null

  )
 
  select dbt_scd_id from to_migrate

);

Подход #2: Удаление существующих таблиц снапшотов

Внимание!

Эта миграция требуется только для пользователей стратегии снапшота check на Snowflake и BigQuery. Если ваш проект не соответствует этим критериям, то вам не нужно мигрировать ваши таблицы Snapshot.

Если вы только недавно начали создавать снапшоты таблиц, используя стратегию check, вы можете просто удалить существующую таблицу(ы) снапшота и начать запись новых таблиц снапшота с нуля. В общем, вы должны быть очень осторожны при ручной работе с таблицами снапшотов. Будьте особенно внимательны при удалении таблиц Snapshot. Если вы выберете этот путь, вы потеряете данные. Взвесьте этот компромисс с учетом сложности, указанной в первом подходе.

Получение помощи

Мы рады помочь с этой миграцией, если у вас есть вопросы или проблемы. Пожалуйста, дайте нам знать в Slack, если вам нужна помощь!