Материализации
Обзор
Материализация — это стратегия сохранения моделей dbt в хранилище. В dbt предусмотрено четыре типа материализации. Это:
- Таблица
- Представление
- Инкрементная
- Эфемерная
Настройка материализаций
По умолчанию модели dbt материализуются как «представления». Модели можно настроить с другой материализацией, указав параметр конфигурации материализации, как показано ниже.
dbt_project.yml
# The following dbt_project.yml configures a project that looks like this:
# .
# └── 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:
# materialize all models in models/events as tables
+materialized: table
csvs:
# this is redundant, and does not need to be set
+materialized: view
В качестве альтернативы материализации могут быть настроены непосредственно внутри файлов модели sql. Это может быть полезно, если вы также настраиваете конфигурации [Оптимизация производительности] для конкретных моделей (например, для конкретных конфигураций Redshift или для конкретных конфигураций BigQuery).
models/events/stg_event_log.sql
{{ config(materialized='table', sort='timestamp', dist='user_id') }}
select *
from ...
Материализации
Вид
При использовании материализации представления (view) ваша модель перестраивается как представление при каждом запуске с помощью оператора create view as .
- Плюсы: дополнительные данные не сохраняются, в представлениях поверх исходных данных всегда будут самые последние записи.
- Минусы: Представления, которые выполняют значительное преобразование или располагаются поверх других представлений, медленно обрабатывают запросы.
-
Совет:
- Лучше начинайте с представлений для своих моделей и переходите к другой материализации только тогда, когда заметите проблемы с производительностью.
- Представления лучше всего подходят для моделей, которые не претерпевают существенных преобразований, т.е. переименование, переделка столбцов.
Таблица
При использовании материализации таблицы (table) ваша модель перестраивается как таблица при каждом запуске с помощью оператора create table as .
- Плюсы: таблицы быстро запрашиваются.
-
Минусы:
- Перестроение таблиц может занять много времени, особенно для сложных преобразований.
- Новые записи базовых исходных данных не добавляются в таблицу автоматически.
-
Совет:
- Используйте материализацию таблицей для любых моделей, запрашиваемых инструментами бизнес-аналитики, чтобы предоставить конечному пользователю более высокое быстродействие.
- Также используйте материализацию таблицы для любых более медленных преобразований, которые используются во многих нижестоящих моделях.
Инкрементная
Инкрементные (incremental) модели позволяют dbt вставлять или обновлять записи в таблицу с момента последнего запуска dbt.
- Плюсы: вы можете значительно сократить время сборки, просто преобразовав новые записи
- Минусы: инкрементные модели требуют дополнительной настройки и представляют собой расширенное использование dbt. Подробнее об использовании инкрементных моделей читайте здесь.
-
Совет:
- Инкрементальные модели лучше всего подходят для данных событийного типа.
- Используйте инкрементные модели, когда работа вашей базы данных становится слишком медленной (т. е. не начинайте с инкрементных моделей)
Эфемерная
Эфемерные (ephemeral) модели не встраиваются непосредственно в базу данных. Вместо этого dbt будет интерполировать код из этой модели в зависимые модели как обычное табличное выражение.
-
Плюсы:
- Вы все еще можете писать повторно используемую логику
- Эфемерные модели помогают содержать хранилище данных в чистоте и порядке, уменьшая беспорядок (также рассмотрите возможность разделения моделей на несколько схем с помощью пользовательских схем).
-
Минусы:
- Вы не можете выбирать напрямую из этой модели.
- Операции (например, макросы, вызываемые через dbt run-operation, не могут использовать эфемерные узлы ref())
- Чрезмерное использование эфемерной материализации также может затруднить отладку запросов.
-
Совет: используйте эфемерную материализацию в следующих случаях:
- очень легкие преобразования, которые находятся на ранней стадии вашей DAG
- только в одной или двух последующих моделей, и
- их не нужно запрашивать напрямую
