Доступные материализации

Представляем вашему вниманию виды, таблицы и инкрементальные модели! В этом разделе мы начнем углубляться в три базовые материализации, которые поставляются с dbt. Они значительно менее пугающие и более полезные, чем львы, тигры или медведи — хотя, возможно, не такие милые (может ли данные быть милыми? Мы в dbt Labs так думаем). Мы собираемся определить, реализовать и исследовать:

• 🔍 views
• ⚒️ tables
• 📚 incremental model

к сведению

👻 В dbt доступна четвертая стандартная материализация под названием временная материализация. Она менее универсальна, чем другие три, и лучше подходит для специфических случаев использования, требующих взвешивания некоторых компромиссов. Мы решили не включать ее в это руководство и сосредоточиться на трех материализациях, которые удовлетворят 99% ваших потребностей в моделировании.

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

Виды

• ✅ Стандартная материализация в dbt. Начальный проект не имеет определенных конфигураций для материализаций, что означает, что все по умолчанию строится как вид.
• 👩‍💻 Храните только SQL-логику преобразования в хранилище, а не данные. Таким образом, они являются отличным выбором по умолчанию. Они строятся почти мгновенно и стоят почти ничего.
• ⏱️ Всегда отражают самую актуальную версию входных данных, так как они выполняются заново каждый раз, когда запрашиваются.
• 👎 Должны обрабатываться каждый раз при запросе, поэтому медленнее возвращают результаты, чем таблица с теми же данными. Это также означает, что они могут стоить дороже со временем, особенно если содержат интенсивные преобразования и часто запрашиваются.

Таблицы

• 🏗️ Таблицы хранят сами данные, в отличие от видов, которые хранят логику запроса. Это означает, что мы можем упаковать все вычисления преобразования в один запуск. Вид хранит запрос в хранилище. Даже для предварительного просмотра этих данных нам нужно их запросить. Таблица хранит буквальные строки и столбцы на диске.
• 🏎️ Запросы позволяют нам непосредственно получить доступ к этим преобразованным данным, поэтому мы получаем лучшую производительность. Таблицы кажутся быстрее и более отзывчивыми по сравнению с видами с той же логикой.
• 💸 Улучшает затраты на вычисления. Вычисления значительно дороже, чем хранение. Поэтому, хотя таблицы используют гораздо больше места для хранения, это, как правило, экономически выгодный компромисс, так как вы платите за вычисления преобразования только при создании таблицы во время задания, а не каждый раз, когда вы ее запрашиваете.
• 🔍 Идеально для моделей, которые регулярно запрашиваются, благодаря сочетанию этих качеств.
• 👎 Ограничены исходными данными, которые были доступны во время последнего запуска. Мы 'замораживаем' логику преобразования в таблице. Поэтому, если мы запускаем модель как таблицу каждый час, в 10:59 у нас все еще есть данные только до 10:00, потому что это было доступно в наших исходных данных, когда мы в последний раз запускали таблицу в 10:00. Только при следующем запуске новые данные будут включены в наше обновление.

Инкрементальные модели

• 🧱 Инкрементальные модели строят таблицу по частям со временем, добавляя и обновляя только новые или измененные записи.
• 🏎️  Строятся быстрее, чем обычная таблица с той же логикой.
• 🐢 Начальные запуски медленные. Обычно мы используем инкрементальные модели на очень больших наборах данных, поэтому создание начальной таблицы на полном наборе данных занимает много времени и эквивалентно материализации таблицы.
• 👎 Добавляют сложность. Инкрементальные модели требуют более глубокого рассмотрения слоев и времени.
• 👎 Могут отклоняться от исходных данных со временем. Поскольку мы не обрабатываем все исходные данные при запуске инкрементальной модели, требуется дополнительное усилие для фиксации изменений в исторических данных.

Сравнение типов материализаций

	view	table	incremental
🛠️⌛ время сборки	💚  самое быстрое — хранит только логику	❤️  самое медленное — линейно к размеру данных	💛  среднее — строит гибкую часть
🛠️💸 затраты на сборку	💚  самые низкие — данные не обрабатываются	❤️  самые высокие — все данные обрабатываются	💛  средние — обрабатываются некоторые данные
📊💸 затраты на запросы	❤️  выше — повторная обработка каждого запроса	💚  ниже — данные в хранилище	💚  ниже — данные в хранилище
🍅🌱 свежесть	💚  лучшая — до минуты запроса	💛  умеренная — до последней сборки	💛  умеренная — до последней сборки
🧠🤔 сложность	💚 простая - соответствует объекту хранилища	💚 простая - соответствует концепции хранилища	💛 умеренная - добавляет логическую сложность

к сведению

🔑 Время — деньги. Обратите внимание, что в таблице выше строки времени и затрат содержат одинаковые результаты. Это подчеркивает, что когда мы говорим о времени в хранилищах, мы говорим о времени вычислений, которое является основным фактором затрат.