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

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

Обзор​

Материализации — это стратегии для сохранения моделей dbt в хранилище данных. В dbt встроено пять типов материализаций. Это:

  • incremental
  • ephemeral
  • materialized view

Вы также можете настроить пользовательские материализации в dbt. Пользовательские материализации — это мощный способ расширить функциональность dbt для удовлетворения ваших специфических потребностей.

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

По умолчанию модели dbt материализуются как "views". Модели могут быть настроены с другой материализацией, указав параметр конфигурации materialized, как показано в следующих вкладках.

dbt_project.yml
# Следующий dbt_project.yml настраивает проект, который выглядит так:
# .
# └── models
#     ├── csvs
#     │   ├── employees.sql
#     │   └── goals.sql
#     └── events
#         ├── stg_event_log.sql
#         └── stg_event_sessions.sql

name: my_project
version: 1.0.0
config-version: 2

models:
  my_project:
    events:
      # материализовать все модели в models/events как таблицы
      +materialized: table
    csvs:
      # это избыточно и не требует настройки
      +materialized: view

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

View​

При использовании материализации view, ваша модель пересоздается как представление при каждом запуске с помощью оператора create view as.

  • Плюсы: Дополнительные данные не сохраняются, представления на основе исходных данных всегда будут содержать последние записи.
  • Минусы: Представления, выполняющие значительные преобразования или построенные на других представлениях, медленно запрашиваются.
  • Советы:
    • Обычно начинайте с представлений для ваших моделей и меняйте на другую материализацию только при возникновении проблем с производительностью.
    • Представления лучше всего подходят для моделей, которые не выполняют значительных преобразований, например, переименование или изменение типа столбцов.

Table​

При использовании материализации table, ваша модель пересоздается как при каждом запуске с помощью оператора create table as.

  • Плюсы: Таблицы быстро запрашиваются.
  • Минусы:
    • Таблицы могут долго пересоздаваться, особенно для сложных преобразований.
    • Новые записи в исходных данных не добавляются автоматически в таблицу.
  • Советы:
    • Используйте материализацию таблицы для любых моделей, запрашиваемых BI-инструментами, чтобы обеспечить более быстрый опыт для конечного пользователя.
    • Также используйте материализацию таблицы для любых медленных преобразований, которые используются многими последующими моделями.

Incremental​

incremental модели позволяют dbt вставлять или обновлять записи в таблице с момента последнего запуска этой модели.

  • Плюсы: Вы можете значительно сократить время сборки, просто преобразовывая новые записи.
  • Минусы: Инкрементальные модели требуют дополнительной настройки и являются продвинутым использованием dbt. Подробнее о использовании инкрементальных моделей читайте здесь.
  • Советы:
    • Инкрементальные модели лучше всего подходят для данных в стиле событий.
    • Используйте инкрементальные модели, когда ваши dbt run становятся слишком медленными (т.е. не начинайте с инкрементальных моделей).

Ephemeral​

ephemeral модели не строятся напрямую в базе данных. Вместо этого dbt будет интерполировать код из эфемерной модели в ее зависимые модели, используя общее табличное выражение (). Вы можете управлять идентификатором для этого CTE, используя псевдоним модели, но dbt всегда будет добавлять префикс к идентификатору модели __dbt__cte__.

  • Плюсы:
    • Вы все еще можете писать переиспользуемую логику.
    • Эфемерные модели могут помочь сохранить ваш чистым, уменьшая беспорядок (также рассмотрите возможность разделения ваших моделей по нескольким схемам, используя пользовательские схемы).
  • Минусы:
    • Вы не можете выбирать напрямую из этой модели.
    • Операции (например, макросы, вызываемые с помощью dbt run-operation не могут ref() эфемерные узлы).
    • Чрезмерное использование эфемерной материализации также может усложнить отладку запросов.
    • Эфемерная материализация не поддерживает контракты моделей.
  • Советы: Используйте эфемерную материализацию для:
    • очень легких преобразований, которые находятся в начале вашего DAG,
    • используются только в одной или двух последующих моделях, и
    • не нуждаются в прямом запросе.

Materialized View​

Материализация materialized_view позволяет создавать и поддерживать материализованные представления в целевой базе данных. Материализованные представления представляют собой комбинацию представления и таблицы и служат для случаев использования, аналогичных инкрементальным моделям.

  • Плюсы:
    • Материализованные представления сочетают в себе производительность запросов таблицы с актуальностью данных представления.
    • Материализованные представления работают аналогично инкрементальным материализациям, однако они обычно могут обновляться без ручного вмешательства на регулярной основе (в зависимости от базы данных), обходя регулярное обновление dbt, требуемое для инкрементальных материализаций.
    • dbt run на материализованных представлениях соответствует развертыванию кода, как и представления.
  • Минусы:
    • Из-за того, что материализованные представления являются более сложными объектами базы данных, платформы баз данных, как правило, имеют меньше доступных опций конфигурации; см. документацию вашей платформы базы данных для получения более подробной информации.
    • Материализованные представления могут не поддерживаться каждой платформой базы данных.
  • Советы:
    • Рассмотрите возможность использования материализованных представлений для случаев, когда инкрементальные модели достаточны, но вы хотите, чтобы платформа данных управляла инкрементальной логикой и обновлением.

Мониторинг изменения конфигурации​

Эта материализация использует конфигурацию on_configuration_change, которая соответствует инкрементальной природе одноименного объекта базы данных. Эта настройка указывает dbt попытаться внести изменения конфигурации непосредственно в объект, когда это возможно, вместо полного пересоздания объекта для реализации обновленной конфигурации. Используя dbt-postgres в качестве примера, индексы могут быть удалены и созданы на материализованном представлении без необходимости пересоздания самого материализованного представления.

Запланированные обновления​

В контексте команды dbt run материализованные представления следует рассматривать как аналогичные представлениям. Например, команда dbt run требуется только в случае потенциального изменения конфигурации или SQL; это фактически действие развертывания. В отличие от этого, команда dbt run требуется для таблицы в тех же сценариях и когда данные в таблице нуждаются в обновлении. Это также верно для инкрементальных и снимочных моделей, чьи базовые отношения являются таблицами. В случае таблиц механизм планирования — это либо dbt Cloud, либо ваш локальный планировщик; нет встроенной функциональности для автоматического обновления данных за таблицей. Однако большинство платформ (за исключением Postgres) предоставляют функциональность для настройки автоматического обновления материализованного представления. Таким образом, материализованные представления работают аналогично инкрементальным моделям с преимуществом отсутствия необходимости запускать dbt для обновления данных. Это, конечно, предполагает, что автоматическое обновление включено и настроено в модели.

к сведению

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

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

Модели Python поддерживают две материализации:

  • table
  • incremental

Инкрементальные модели Python поддерживают все те же инкрементальные стратегии, что и их SQL-аналоги. Конкретные поддерживаемые стратегии зависят от вашего адаптера.

Модели Python не могут быть материализованы как view или ephemeral. Python не поддерживается для типов ресурсов, отличных от моделей (например, тестов и снимков).

Для инкрементальных моделей, как и для SQL-моделей, вам нужно будет фильтровать входящие таблицы только на новые строки данных:

models/my_python_model.py
import snowflake.snowpark.functions as F

def model(dbt, session):
    dbt.config(materialized = "incremental")
    df = dbt.ref("upstream_table")

    if dbt.is_incremental:

        # только новые строки по сравнению с максимумом в текущей таблице
        max_from_this = f"select max(updated_at) from {dbt.this}"
        df = df.filter(df.updated_at >= session.sql(max_from_this).collect()[0][0])

        # или только строки за последние 3 дня
        df = df.filter(df.updated_at >= F.dateadd("day", F.lit(-3), F.current_timestamp()))

    ...

    return df

Примечание: Инкрементальные модели поддерживаются на BigQuery/Dataproc для инкрементальной стратегии merge. Стратегия insert_overwrite пока не поддерживается.

Вопросы от сообщества​

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