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

Конфигурации Snowflake

Динамические таблицы​

Адаптер Snowflake поддерживает динамические таблицы. Эта материализация специфична для Snowflake, что означает, что любая конфигурация модели, которая обычно идет вместе с dbt-core (например, как с view), может быть недоступна для динамических таблиц. Этот разрыв будет уменьшаться в будущих патчах и версиях. Хотя эта материализация специфична для Snowflake, она во многом следует реализации материализованных представлений. В частности, динамические таблицы имеют доступ к настройке on_configuration_change. Динамические таблицы поддерживаются с следующими параметрами конфигурации:

Узнайте больше об этих параметрах в документации Snowflake:

Целевое отставание​

Snowflake позволяет два сценария конфигурации для планирования автоматических обновлений:

  • На основе времени — Укажите значение в формате <int> { seconds | minutes | hours | days }. Например, если динамическую таблицу нужно обновлять каждые 30 минут, используйте target_lag='30 minutes'.
  • Нисходящий поток — Применимо, когда динамическая таблица ссылается на другие динамические таблицы. В этом сценарии target_lag='downstream' позволяет контролировать обновления на целевом уровне, а не на каждом уровне.

Узнайте больше о target_lag в документации Snowflake. Обратите внимание, что Snowflake поддерживает целевое отставание в 1 минуту или дольше.

Ограничения​

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

  • SQL динамической таблицы имеет ограниченный набор функций.
  • SQL динамической таблицы не может быть обновлен; динамическая таблица должна пройти через --full-refresh (DROP/CREATE).
  • Динамические таблицы не могут быть ниже по потоку от: материализованных представлений, внешних таблиц, потоков.
  • Динамические таблицы не могут ссылаться на представление, которое находится ниже по потоку от другой динамической таблицы.

Найдите больше информации об ограничениях динамических таблиц в документации Snowflake.

Для ограничений dbt, эти функции dbt не поддерживаются:

Временные таблицы​

Инкрементные слияния таблиц для Snowflake предпочитают использовать view, а не temporary table. Причина в том, чтобы избежать шага записи в базу данных, который инициировала бы временная таблица, и сэкономить время компиляции.

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

Чтобы гарантировать точность, инкрементная модель, использующая стратегию delete+insert с определенным unique_key, требует временной таблицы; попытка изменить это на представление приведет к ошибке.

Определено в YAML проекта:

dbt_project.yml
name: my_project

...

models:
  <resource-path>:
    +tmp_relation_type: table | view ## Если не определено, по умолчанию используется view.

В формате конфигурации для SQL файла модели:

dbt_model.sql

{{ config(
    tmp_relation_type="table | view", ## Если не определено, по умолчанию используется view.
) }}

Переходные таблицы​

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

Настройка переходных таблиц в dbt_project.yml​

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

dbt_project.yml
name: my_project

...

models:
  +transient: false
  my_project:
    ...

Настройка переходности для конкретной модели​

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

my_table.sql
{{ config(materialized='table', transient=true) }}

select * from ...

Теги запросов​

Теги запросов — это параметр Snowflake, который может быть весьма полезен позже при поиске в представлении QUERY_HISTORY.

dbt поддерживает установку тега запроса по умолчанию на время своих соединений Snowflake в вашем профиле. Вы можете установить более точные значения (и переопределить значение по умолчанию) для подмножеств моделей, установив конфигурацию модели query_tag или переопределив макрос set_query_tag по умолчанию:

dbt_project.yml
models:
  <resource-path>:
    +query_tag: dbt_special

models/<modelname>.sql
{{ config(
    query_tag = 'dbt_special'
) }}

select ...

В этом примере вы можете настроить тег запроса, который будет применяться к каждому запросу с именем модели.


  {% macro set_query_tag() -%}
  {% set new_query_tag = model.name %} 
  {% if new_query_tag %}
    {% set original_query_tag = get_current_query_tag() %}
    {{ log("Установка query_tag на '" ~ new_query_tag ~ "'. Будет сброшен на '" ~ original_query_tag ~ "' после материализации.") }}
    {% do run_query("alter session set query_tag = '{}'".format(new_query_tag)) %}
    {{ return(original_query_tag)}}
  {% endif %}
  {{ return(none)}}
{% endmacro %}

Примечание: теги запросов устанавливаются на уровне сессии. В начале каждой модели, если у модели настроен пользовательский query_tag, dbt выполнит alter session set query_tag, чтобы установить новое значение. В конце материализации dbt выполнит еще один оператор alter, чтобы сбросить тег на его значение по умолчанию. Таким образом, сбои сборки в середине материализации могут привести к тому, что последующие запросы будут выполняться с неправильным тегом.

Поведение слияния (инкрементные модели)​

Конфигурация incremental_strategy управляет тем, как dbt строит инкрементные модели. По умолчанию dbt будет использовать оператор слияния в Snowflake для обновления инкрементных таблиц.

Snowflake поддерживает следующие стратегии инкрементного обновления:

  • Слияние (по умолчанию)
  • Добавление
  • Удаление+вставка
  • microbatch

Оператор merge Snowflake завершится с ошибкой "недетерминированное слияние", если unique_key, указанный в конфигурации вашей модели, не является уникальным. Если вы столкнулись с этой ошибкой, вы можете указать dbt использовать двухэтапный инкрементный подход, установив конфигурацию incremental_strategy для вашей модели на delete+insert.

Настройка кластеризации таблиц​

dbt поддерживает кластеризацию таблиц в Snowflake. Чтобы управлять кластеризацией для или инкрементной модели, используйте конфигурацию cluster_by. Когда эта конфигурация применяется, dbt выполнит два действия:

  1. Он неявно упорядочит результаты таблицы по указанным полям cluster_by
  2. Он добавит указанные ключи кластеризации в целевую таблицу

Используя указанные поля cluster_by для упорядочивания таблицы, dbt минимизирует объем работы, требуемой для автоматической кластеризации Snowflake. Если инкрементная модель настроена на использование кластеризации таблиц, то dbt также упорядочит промежуточный набор данных перед его слиянием в целевую таблицу. Таким образом, таблица, управляемая dbt, всегда должна находиться в основном кластеризованном состоянии.

Использование cluster_by​

Конфигурация cluster_by принимает либо строку, либо список строк для использования в качестве ключей кластеризации. Следующий пример создаст таблицу сессий, кластеризованную по столбцу session_start.

models/events/sessions.sql
{{
  config(
    materialized='table',
    cluster_by=['session_start']
  )
}}

select
  session_id,
  min(event_time) as session_start,
  max(event_time) as session_end,
  count(*) as count_pageviews

from {{ source('snowplow', 'event') }}
group by 1

Код выше будет скомпилирован в SQL, который выглядит (примерно) так:

create or replace table my_database.my_schema.my_table as (

  select * from (
    select
      session_id,
      min(event_time) as session_start,
      max(event_time) as session_end,
      count(*) as count_pageviews

    from {{ source('snowplow', 'event') }}
    group by 1
  )

  -- этот order by добавляется dbt для создания
  -- таблицы в уже кластеризованном виде.
  order by session_start

);

 alter table my_database.my_schema.my_table cluster by (session_start);

Автоматическая кластеризация​

Автоматическая кластеризация включена по умолчанию в Snowflake сегодня, никаких действий не требуется для ее использования. Хотя существует конфигурация automatic_clustering, она не имеет эффекта, кроме как для аккаунтов с (устаревшей) ручной кластеризацией.

Если ручная кластеризация все еще включена для вашего аккаунта, вы можете использовать конфигурацию automatic_clustering, чтобы управлять тем, включена ли автоматическая кластеризация для моделей dbt. Когда automatic_clustering установлено в true, dbt выполнит запрос alter table <table name> resume recluster после сборки целевой таблицы.

Конфигурация automatic_clustering может быть указана в файле dbt_project.yml или в блоке config() модели.

dbt_project.yml
models:
  +automatic_clustering: true

Настройка виртуальных складов​

Склад по умолчанию, который использует dbt, можно настроить в вашем профиле для соединений Snowflake. Чтобы переопределить склад, который используется для конкретных моделей (или групп моделей), используйте конфигурацию модели snowflake_warehouse. Эта конфигурация может быть использована для указания большего склада для определенных моделей, чтобы контролировать затраты на Snowflake и время сборки проекта.

Пример конфигурации ниже изменяет склад для группы моделей с помощью аргумента конфигурации в yml.

dbt_project.yml
name: my_project
version: 1.0.0

...

models:
  +snowflake_warehouse: "EXTRA_SMALL"    # используйте склад `EXTRA_SMALL` для всех моделей в проекте...
  my_project:
    clickstream:
      +snowflake_warehouse: "EXTRA_LARGE"    # ...кроме моделей в папке `clickstream`, которые будут использовать склад `EXTRA_LARGE`.

snapshots:
  +snowflake_warehouse: "EXTRA_LARGE"    # все модели Snapshot настроены на использование склада `EXTRA_LARGE`.

Копирование грантов​

Когда конфигурация copy_grants установлена в true, dbt добавит квалификатор copy grants при перестроении таблиц и представлений. Значение по умолчанию — false.

dbt_project.yml
models:
  +copy_grants: true

Безопасные представления​

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

Следующий пример настраивает модели в папке sensitive/ как безопасные представления.

dbt_project.yml
name: my_project
version: 1.0.0

models:
  my_project:
    sensitive:
      +materialized: view
      +secure: true

Известное ограничение свежести источника​

Snowflake рассчитывает свежесть источника, используя информацию из столбца LAST_ALTERED, что означает, что он полагается на поле, обновляемое всякий раз, когда любой объект подвергается модификации, а не только обновлениям данных. Никаких действий не требуется, но аналитические команды должны учитывать эту оговорку.

Согласно документации Snowflake:

Столбец LAST_ALTERED обновляется, когда выполняются следующие операции над объектом:

  • Операции DDL.
  • Операции DML (только для таблиц).
  • Фоновые операции по обслуживанию метаданных, выполняемые Snowflake.
0
Отредактировать эту страницу