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

Конфигурации Starburst/Trino

Требования к кластеру​

Назначенный кластер должен иметь прикрепленный каталог, в котором можно создавать, переименовывать, изменять и удалять объекты, такие как таблицы и представления. Любой пользователь, подключающийся к кластеру с помощью dbt, также должен иметь эти же разрешения для целевого каталога.

Свойства сессии​

С кластерами Starburst Enterprise, Starburst Galaxy или Trino вы можете устанавливать свойства сессии для изменения текущей конфигурации вашей пользовательской сессии.

Стандартный способ определения свойств сессии — это использование поля session_properties в вашем profiles.yml. Это гарантирует, что все подключения dbt будут использовать эти настройки по умолчанию.

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

{{
  config(
    pre_hook="set session query_max_run_time='10m'"
  )
}}

Свойства коннектора​

Вы можете использовать свойства таблиц Starburst/Trino для настройки того, как вы хотите, чтобы ваши данные были представлены.

Для получения информации о поддерживаемых функциях для каждого поддерживаемого источника данных обратитесь к Trino Connectors или Starburst Catalog.

Каталоги Hive​

Целевой каталог, использующий коннектор Hive и службу метаданных (HMS), является типичным при работе с Starburst и dbt. Следующие настройки рекомендуются для работы с dbt. Цель состоит в том, чтобы гарантировать, что dbt может выполнять часто используемые операторы DROP и RENAME.

hive.metastore-cache-ttl=0s
hive.metastore-refresh-interval=5s

Конфигурация формата файла​

При использовании коннекторов на основе файлов, таких как Hive, пользователь может настроить аспекты коннектора, такие как используемый формат, а также тип материализации.

Ниже представлена конфигурация таблицы, которая будет материализована как набор разделенных файлов Parquet.

{{
  config(
    materialized='table',
    properties= {
      "format": "'PARQUET'",
      "partitioning": "ARRAY['bucket(id, 2)']",
    }
  )
}}

Seeds и подготовленные операторы​

Команда dbt seed использует подготовленные операторы в Starburst/Trino.

Подготовленные операторы — это шаблонные SQL-операторы, которые можно выполнять многократно с высокой эффективностью. Значения передаются в отдельном поле, а не жестко кодируются в самой строке SQL. Это часто используется в приложениях для структурирования операторов INSERT в OLTP базах данных. Из-за этого подготовленные операторы часто имеют столько же переменных-заполнителей (параметров), сколько и столбцов в целевой таблице.

Большинство файлов seed содержат более одной строки, и часто тысячи строк. Это делает размер клиентского запроса таким же большим, как и количество параметров.

Ограничение длины строки заголовка в клиенте HTTP на Python​

Вы можете столкнуться с сообщением об ошибке об ограничении длины строки заголовка, если в ваших подготовленных операторах слишком много параметров. Это связано с тем, что ограничение длины строки заголовка в HTTP-клиенте Python составляет 65536 байт.

Вы можете избежать этого ограничения, преобразовав большой подготовленный оператор в более мелкие операторы. dbt уже делает это, группируя весь файл seed в группы строк — одна группа для определенного количества строк в CSV.

Предположим, у вас есть файл seed с 20 столбцами, 600 строками и 12 000 параметров. Вместо создания одного подготовленного оператора для этого, вы можете заставить dbt создать четыре подготовленных оператора INSERT с 150 строками и 3 000 параметров.

Есть недостаток в группировке строк вашей таблицы. Когда в файле seed много столбцов (параметров), размер пакета должен быть очень маленьким.

Для адаптера dbt-trino макрос для размера пакета — это trino__get_batch_size(), и его значение по умолчанию — 1000. Чтобы изменить это поведение по умолчанию, вы можете добавить этот макрос в ваш проект dbt:

macros/YOUR_MACRO_NAME.sql
{% macro trino__get_batch_size() %}
  {{ return(10000) }} -- Измените это число по своему усмотрению
{% endmacro %}

Другой способ избежать ограничения длины строки заголовка — установить prepared_statements_enabled в true в вашем профиле dbt; однако это считается устаревшим поведением и может быть удалено в будущих выпусках.

Материализации​

Таблица​

Адаптер dbt-trino поддерживает эти режимы в материализации table (и полные обновления в материализации incremental), которые вы можете настроить с помощью on_table_exists:

  • rename — Создает промежуточную таблицу, переименовывает целевую таблицу в резервную и переименовывает промежуточную таблицу в целевую.
  • drop — Удаляет и воссоздает таблицу. Это преодолевает ограничение на переименование таблицы в AWS Glue.
  • replace — Заменяет таблицу с использованием оператора CREATE OR REPLACE. Поддержка замены таблицы варьируется в зависимости от коннекторов. Обратитесь к документации по коннектору для получения подробной информации.

Если CREATE OR REPLACE поддерживается в базовом коннекторе, replace является рекомендуемым вариантом. В противном случае, рекомендуемая материализация table использует on_table_exists = 'rename' и также является значением по умолчанию. Вы можете изменить эту конфигурацию по умолчанию, отредактировав один из этих файлов:

  • SQL-файл для вашей модели
  • файл конфигурации dbt_project.yml

Следующие примеры настраивают материализацию table на drop:

models/YOUR_MODEL_NAME.sql
{{
  config(
    materialized = 'table',
    on_table_exists = 'drop`
  )
}}
dbt_project.yml
models:
  path:
    materialized: table
    +on_table_exists: drop

Если вы используете материализацию table и on_table_exists = 'rename' с AWS Glue, вы можете столкнуться с этим сообщением об ошибке. Вы можете преодолеть ограничение на переименование таблицы, используя drop:

TrinoUserError(type=USER_ERROR, name=NOT_SUPPORTED, message="Table rename is not yet supported by Glue service")

Представление​

Адаптер dbt-trino поддерживает эти режимы безопасности в материализации view, которые вы можете настроить с помощью view_security:

  • definer
  • invoker

Для получения более подробной информации о режимах безопасности в представлениях, см. Security в документации Trino.

По умолчанию, материализация view использует view_security = 'definer'. Вы можете изменить эту конфигурацию по умолчанию, отредактировав один из этих файлов:

  • SQL-файл для вашей модели
  • файл конфигурации dbt_project.yml

Например, эти настройки изменяют режим безопасности на invoker:

models/YOUR_MODEL_NAME.sql
{{
  config(
    materialized = 'view',
    view_security = 'invoker'
  )
}}
dbt_project.yml
models:
  path:
    materialized: view
    +view_security: invoker

Инкрементальная​

Использование инкрементальной модели ограничивает объем данных, которые необходимо преобразовать, что значительно сокращает время выполнения ваших преобразований. Это улучшает производительность и снижает затраты на вычисления.

{{
    config(
      materialized = 'incremental', 
      unique_key='<optional>',
      incremental_strategy='<optional>',)
}}
select * from {{ ref('events') }}
{% if is_incremental() %}
  where event_ts > (select max(event_ts) from {{ this }})
{% endif %}

Используйте свойство +on_schema_change, чтобы определить, как dbt-trino должен обрабатывать изменения столбцов. Для получения более подробной информации об этом свойстве см. изменения столбцов.

Если ваш коннектор не поддерживает представления, установите свойство +views_enabled в false.

Вы можете решить, как модель должна быть перестроена при выполнении full-refresh, указав конфигурацию on_table_exists. Варианты такие же, как описано в разделе материализации таблицы

стратегия append​

Стратегия инкрементальной загрузки по умолчанию — append. append добавляет только новые записи на основе условия, указанного в условном блоке is_incremental().

{{
    config(
      materialized = 'incremental')
}}
select * from {{ ref('events') }}
{% if is_incremental() %}
  where event_ts > (select max(event_ts) from {{ this }})
{% endif %}

стратегия delete+insert​

С помощью стратегии инкрементальной загрузки delete+insert вы можете указать dbt использовать двухэтапный инкрементальный подход. Сначала он удаляет записи, обнаруженные через настроенный блок is_incremental(), затем повторно вставляет их.

{{
    config(
      materialized = 'incremental',
      unique_key='user_id',
      incremental_strategy='delete+insert',
      )
}}
select * from {{ ref('users') }}
{% if is_incremental() %}
  where updated_ts > (select max(updated_ts) from {{ this }})
{% endif %}

стратегия merge​

С помощью стратегии инкрементальной загрузки merge dbt-trino создает оператор MERGE Trino для вставки новых записей и обновления существующих записей на основе свойства unique_key.

Если unique_key не уникален, вы можете использовать стратегию delete+insert.

{{
    config(
      materialized = 'incremental',
      unique_key='user_id',
      incremental_strategy='merge',
      )
}}
select * from {{ ref('users') }}
{% if is_incremental() %}
  where updated_ts > (select max(updated_ts) from {{ this }})
{% endif %}

Имейте в виду, что некоторые коннекторы Trino не поддерживают MERGE или имеют ограниченную поддержку.

Инкрементальная перезапись на моделях Hive​

Если есть коннектор Hive, обращающийся к вашей целевой инкрементальной модели, вы можете имитировать оператор INSERT OVERWRITE, используя настройку insert-existing-partitions-behavior в конфигурации коннектора Hive в Trino:

<hive-catalog-name>.insert-existing-partitions-behavior=OVERWRITE

Ниже приведен пример конфигурации Hive, которая устанавливает функциональность OVERWRITE для коннектора Hive под названием minio:

trino-incremental-hive:
  target: dev
  outputs:
    dev:
      type: trino
      method: none
      user: admin
      password:
      catalog: minio
      schema: tiny
      host: localhost
      port: 8080
      http_scheme: http
      session_properties:
        minio.insert_existing_partitions_behavior: OVERWRITE
      threads: 1

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

{{
    config(
        materialized = 'incremental',
        properties={
          "format": "'PARQUET'",
          "partitioned_by": "ARRAY['day']",
        }
    )
}}

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

Адаптер dbt-trino поддерживает материализованные представления и обновляет их для каждого последующего dbt run, который вы выполняете. Для получения дополнительной информации см. REFRESH MATERIALIZED VIEW в документации Trino.

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

Эта материализация поддерживает конфигурацию и флаг full_refresh. Всякий раз, когда вы хотите перестроить свое материализованное представление (например, при изменении базового SQL-запроса), выполните dbt run --full-refresh.

Вы можете создать материализованное представление, отредактировав один из этих файлов:

  • SQL-файл для вашей модели
  • файл конфигурации dbt_project.yml

Следующие примеры создают материализованное представление в формате Parquet:

models/YOUR_MODEL_NAME.sql
{{
  config(
    materialized = 'materialized_view',
    properties = {
      'format': "'PARQUET'"
    },
  )
}}
dbt_project.yml
models:
  path:
    materialized: materialized_view
    properties:
      format: "'PARQUET'"

Снимки​

Снимки в dbt зависят от макроса current_timestamp, который по умолчанию возвращает временную метку с точностью до миллисекунд (3 цифры). Некоторые коннекторы для Trino не поддерживают такую точность временной метки (TIMESTAMP(3) WITH TIME ZONE), например, Iceberg.

Чтобы изменить точность временной метки, вы можете определить свой собственный макрос. Например, это определяет новый макрос trino__current_timestamp() с точностью до микросекунд (6 цифр):

macros/YOUR_MACRO_NAME.sql
{% macro trino__current_timestamp() %}
    current_timestamp(6)
{% endmacro %}

Гранты​

Используйте гранты для управления доступом к наборам данных, которые вы создаете с помощью dbt. Вы можете использовать гранты с Starburst Enterprise, Starburst Galaxy и Hive (sql-standard).

Чтобы реализовать разрешения на доступ, определите гранты как конфигурации ресурсов для каждой модели, seed и снимка. Определите гранты по умолчанию, которые применяются ко всему проекту, в вашем dbt_project.yml, и определите гранты, специфичные для модели, в каждом SQL или YAML файле модели.

dbt_project.yml
models:
  - name: NAME_OF_YOUR_MODEL
    config:
      grants:
        select: ['reporter', 'bi']

Контракты моделей​

Адаптер dbt-trino поддерживает контракты моделей. В настоящее время поддерживаются только ограничения с type как not_null. Перед использованием ограничений not_null в вашей модели убедитесь, что базовый коннектор поддерживает not null, чтобы избежать ошибок.

0
Отредактировать эту страницу