Что только что произошло

На прошлом уроке вы выполнили dbt run и увидели PASS=1. Что-то сработало. Но что именно? В этом коротком уроке мы спокойно соберём всю картинку и поймём, что произошло “под капотом” — без новых сложных тем. А в конце посмотрим, куда курс пойдёт дальше.

Модель — это просто SELECT

Главное, что нужно унести: модель в dbt — это файл с одним SELECT-запросом, и ничего больше. Вы не писали CREATE TABLE, не писали циклов, не настраивали соединений в коде. Вы написали обычный запрос, который умели писать ещё на Ступени 0:

SELECT
    1 AS order_id,
    'completed' AS status,
    100 AS amount
UNION ALL
SELECT 2, 'cancelled', 50
UNION ALL
SELECT 3, 'completed', 75

Файл назывался my_first_model.sql. Запомните связку: имя файла -> имя объекта в хранилище. Файл my_first_model.sql стал объектом my_first_model, который можно запрашивать по имени. Это правило не изменится за весь курс: одна модель — один файл — один объект в хранилище с тем же именем.

Что dbt дописал за вас

Сам по себе SELECT ничего не сохраняет — он показывает данные и забывает их. Чтобы результат остался в хранилище, нужна команда вроде CREATE TABLE ... AS SELECT ... или CREATE VIEW ... AS SELECT .... Вот эту обёртку dbt дописал за вас автоматически.

Можно представить это так. Вы дали dbt половину фразы:

SELECT order_id, amount FROM ...

а dbt сам добавил начало:

CREATE VIEW my_first_model AS
SELECT order_id, amount FROM ...

и отправил полную команду в DuckDB. Поэтому в выводе dbt run вы видели строку OK created sql view model main.my_first_model. Слово created — это и есть момент, когда dbt выполнил CREATE в хранилище.

NOTE

Почему view (представление), а не table (таблица)? View — это сохранённый запрос: данные не копируются, при обращении запрос выполняется заново. Table — это реальная копия данных на диске. По умолчанию dbt делает view, потому что это быстро и дёшево. Как выбрать table вместо view — это и есть тема “материализаций”, к ней мы скоро вернёмся.

Зачем вообще dbt, если это просто CREATE VIEW

Справедливый вопрос: если dbt всего лишь дописывает CREATE VIEW, зачем он нужен — можно ведь и руками написать. Ответ виден уже на втором упражнении прошлого урока, где вы сделали две модели, одна из которых читала из другой.

Когда моделей две — порядок ещё легко удержать в голове. Когда их пятьдесят и они переплетены, как корни дерева, вручную уже не справиться: какую пересобрать первой, что сломается при изменении одной из них, откуда взялась конкретная цифра. dbt берёт эту работу на себя:

он сам понимает, какая модель от какой зависит;
он сам выстраивает правильный порядок выполнения;
он держит все модели в одном проекте, под версионным контролем.

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

Куда курс пойдёт дальше

Вы заложили фундамент: знаете, что такое хранилище, что dbt превращает SELECT в объект и не загружает данные, и умеете запускать dbt run. Дальше курс будет надстраивать этажи поверх этого фундамента. Коротко, чтобы вы видели карту впереди (без необходимости понимать это прямо сейчас):

ref() — правильный способ одной модели сослаться на другую. Вместо прямого имени таблицы вы пишете ref('другая_модель'), и dbt сам понимает зависимость и выстраивает порядок выполнения. Это сердце dbt.
Материализации — выбор между view и table (и не только) для каждой модели: что хранить как сохранённый запрос, а что как реальную копию данных.
Jinja — способ подставлять в SQL переменные и повторяющиеся куски, чтобы не копировать один и тот же код. Делает модели гибкими.
Тесты — автоматические проверки данных: “в этой колонке не должно быть пустых значений”, “идентификаторы не должны повторяться”. dbt проверит это за вас.

Каждую из этих тем мы разберём так же спокойно и по шагам, как разобрали первый запуск. Сейчас не нужно ничего из этого знать — достаточно видеть, что впереди логичное продолжение того, что вы уже потрогали руками.

Соберём в три мысли

Модель = один SELECT в файле. Имя файла становится именем объекта в хранилище.
dbt дописывает обёртку. Вы пишете SELECT, dbt сам добавляет CREATE VIEW/TABLE и выполняет это в хранилище.
Ценность dbt растёт с количеством моделей. На одной модели разница незаметна; на пятидесяти связанных — dbt сам держит порядок, зависимости и историю.

Попробуй сам

Откройте свой файл my_first_model.sql и мысленно (или на бумаге) допишите перед ним строку, которую добавляет dbt, чтобы получился полный, рабочий SQL-оператор создания объекта. Должно получиться что-то вроде CREATE VIEW my_first_model AS плюс ваш SELECT. Затем ответьте себе на один вопрос: если бы вы хотели, чтобы dbt создал не view, а реальную таблицу (копию данных на диске), какое одно слово в дописанной строке поменялось бы? Подсказка: с VIEW на TABLE. Именно этот выбор и называется материализацией — первой большой темой впереди.

Проверка знанийKnowledge check

Объясните своими словами, что dbt сделал с вашим SELECT-запросом при dbt run, и почему по умолчанию получился view, а не table.

ОтветAnswer

Сам SELECT только показывает данные и не сохраняет их. dbt автоматически дописал к вашему запросу обёртку для создания объекта — что-то вроде "CREATE VIEW my_first_model AS" перед вашим SELECT — и выполнил полную команду в хранилище DuckDB. Имя объекта взялось из имени файла модели. По умолчанию dbt создаёт view (представление), а не table (таблицу), потому что view — это просто сохранённый запрос: данные не копируются на диск, запрос пересчитывается при каждом обращении, что быстро и дёшево создавать. Table же копирует данные физически. Выбор между view и table называется материализацией и настраивается отдельно — это одна из ближайших тем курса.