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

Стратегии инкрементальной материализации

В dbt-redshift поддерживаются следующие стратегии инкрементальной материализации:

• append (по умолчанию, если unique_key не задан)
• merge
• delete+insert (по умолчанию, если unique_key задан)
• microbatch

Все эти стратегии унаследованы из dbt-postgres.

Оптимизация производительности

Использование sortkey и distkey

Таблицы в Amazon Redshift имеют два мощных механизма оптимизации для повышения производительности запросов: distkeys и sortkeys. Указание этих значений в конфигурации модели приводит к применению соответствующих настроек в сгенерированном CREATE TABLE DDL. Обратите внимание, что эти настройки не будут иметь эффекта для моделей с материализацией view или ephemeral.

• dist может принимать значение all, even, auto или имя ключа.
• sort принимает список sort key, например: ['reporting_day', 'category']. dbt создаст sort key в том порядке, в котором указаны поля.
• sort_type может иметь значение interleaved или compound. Если значение не указано, sort_type по умолчанию равен compound.

При работе с sort key настоятельно рекомендуется следовать лучшим практикам Redshift, касающимся эффективности sort key и кардинальности.

Sort key и dist key следует добавлять в блок {{ config(...) }} в .sql-файлах моделей, например:

my_model.sql

-- Example with one sort key
{{ config(materialized='table', sort='reporting_day', dist='unique_id') }}

select ...


-- Example with multiple sort keys
{{ config(materialized='table', sort=['category', 'region', 'reporting_day'], dist='received_at') }}

select ...


-- Example with interleaved sort keys
{{ config(materialized='table',
          sort_type='interleaved'
          sort=['category', 'region', 'reporting_day'],
          dist='unique_id')
}}

select ...

Подробнее о distkeys и sortkeys см. в документации Amazon:

• AWS Documentation » Amazon Redshift » Database Developer Guide » Designing Tables » Choosing a Data Distribution Style
• AWS Documentation » Amazon Redshift » Database Developer Guide » Designing Tables » Choosing Sort Keys

Позднее связывание представлений (Late binding views)

Redshift поддерживает представления, не связанные жёстко со своими зависимостями, или late binding views. Эта опция DDL «отвязывает» представление от данных, из которых оно выбирает. На практике это означает, что если вышестоящие представления или таблицы удаляются с использованием cascade, late-binding view при этом не будет удалено.

Использование late-binding views в продакшн-развёртывании dbt может значительно повысить доступность данных в хранилище, особенно для моделей, материализованных как late-binding views и используемых конечными пользователями, поскольку они не будут удаляться при обновлении вышестоящих моделей. Кроме того, late-binding views можно использовать с external tables через Redshift Spectrum.

Чтобы материализовать модель dbt как late-binding view, используйте параметр конфигурации bind: false:

my_view.sql

{{ config(materialized='view', bind=False) }}

select *
from source.data

Чтобы сделать все представления late-binding, настройте файл dbt_project.yml следующим образом:

dbt_project.yml

models:
  +bind: false # Materialize all views as late-binding
  project_name:
    ....

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

Адаптер Redshift поддерживает материализованные представления со следующими параметрами конфигурации:

Parameter	Type	Required	Default	Change Monitoring Support
on_configuration_change	<string>	no	apply	n/a
dist	<string>	no	even	drop/create
sort	[<string>]	no	none	drop/create
sort_type	<string>	no	auto if no sort compound if sort	drop/create
auto_refresh	<boolean>	no	false	alter
backup	<string>	no	true	n/a

Loading table...

Project YAML file

dbt_project.yml

models:
  <resource-path>:
    +materialized: materialized_view
    +on_configuration_change: apply | continue | fail
    +dist: all | auto | even | <field-name>
    +sort: <field-name> | [<field-name>]
    +sort_type: auto | compound | interleaved
    +auto_refresh: true | false
    +backup: true | false

Properties YAML file

models/properties.yml

models:
  - name: [<model-name>]
    config:
      materialized: materialized_view
      on_configuration_change: apply | continue | fail
      dist: all | auto | even | <field-name>
      sort: <field-name> | [<field-name>]
      sort_type: auto | compound | interleaved
      auto_refresh: true | false
      backup: true | false

SQL file config

models/<model_name>.sql

{{ config(
    materialized="materialized_view",
    on_configuration_change="apply" | "continue" | "fail",
    dist="all" | "auto" | "even" | "<field-name>",
    sort=["<field-name>"],
    sort_type="auto" | "compound" | "interleaved",
    auto_refresh=true | false,
    backup=true | false,
) }}

Многие из этих параметров соответствуют параметрам таблиц и были связаны выше. Параметры, уникальные для материализованных представлений, — это функции auto-refresh и backup, которые описаны ниже.

Подробнее об этих параметрах см. в документации Redshift: docs.

Auto-refresh

Parameter	Type	Required	Default	Change Monitoring Support
auto_refresh	<boolean>	no	false	alter

Loading table...

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

Дополнительную информацию о параметрах см. в документации Redshift.

Backup

Parameter	Type	Required	Default	Change Monitoring Support
backup	<boolean>	no	true	n/a

Loading table...

Redshift поддерживает настройку резервного копирования на уровне объектов кластера. Этот параметр определяет, должно ли материализованное представление включаться в резервные копии (snapshot) кластера. По умолчанию материализованное представление включается в snapshot кластера. dbt не может отслеживать этот параметр, так как он недоступен для запросов внутри Redshift. Если значение изменяется, материализованное представление необходимо пересобрать с использованием --full-refresh, чтобы применить настройку.

Подробнее об этих параметрах см. в документации Redshift: docs.

Ограничения

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

• Материализованные представления не могут ссылаться на представления, временные таблицы, пользовательские функции или late-binding tables.
• Auto-refresh нельзя использовать, если материализованное представление ссылается на изменяемые функции, внешние схемы или другое материализованное представление.

Дополнительную информацию об ограничениях материализованных представлений см. в документации Redshift: docs.

Ограничения unit-тестов

• Redshift не поддерживает unit tests, если SQL в common table expression (CTE) содержит функции, такие как LISTAGG, MEDIAN, PERCENTILE_CONT и т.п. Эти функции должны выполняться над таблицей, созданной пользователем. dbt объединяет переданные строки так, чтобы они были частью CTE, что Redshift не поддерживает.

  Чтобы в будущем поддержать этот паттерн, dbt потребуется «материализовывать» входные фикстуры в виде таблиц, а не подставлять их как CTE. Если вам интересна эта функциональность, мы рекомендуем поучаствовать в обсуждении issue на GitHub: dbt-labs/dbt Core#8499

• Redshift не поддерживает unit-тесты, которые используют источники (sources) в базе данных, отличной от базы данных моделей. Подробнее см. соответствующий issue на GitHub: https://github.com/dbt-labs/dbt-redshift/issues/995

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

Создать GitHub Issue