Первая модель: model = SELECT

dbt стоит, профиль подключается. Пора делать первую модель. Отто нужна аккуратная таблица заказов, где колонки названы понятно и в которой не надо помнить, что id в сырой таблице это номер заказа. Это будет stg_orders, первый кирпич проекта «Гонца».

Рецепт, а не блюдо

Повар записывает в карточку рецепт борща: что взять и что с ним сделать. Самого борща в карточке нет. Борщ варят по карточке, когда нужно, и всегда одинаково. Если рецепт поменяли, следующая кастрюля сварится по-новому.

Модель dbt это карточка с рецептом. Ты пишешь только SELECT: что взять и как преобразовать. Как приготовить результат в базе, решает dbt.

Модель это один SELECT

Создай файл models/staging/stg_orders.sql:

select
    id as order_id,
    zone_id,
    status,
    price_rub,
    created_at
from raw.orders

Всё. Нет create view, нет create table, нет drop. Только запрос, который возвращает нужные строки. Ни точки с запятой в конце, ни нескольких запросов подряд: один файл, один SELECT.

Остальное dbt берёт из соглашений.

• Имя в базе это имя файла без .sql: stg_orders.
• Схема берётся из профиля, у таргета dev это dbt_dev.
• Во что превратить решает материализация. По умолчанию это представление, view. В dbt_project.yml «Гонца» для папки staging так и написано: +materialized: view.

Папки внутри models нужны людям, а не базе: модель models/staging/stg_orders.sql в базе станет просто dbt_dev.stg_orders. Приставка stg_ тоже соглашение: так помечают модели слоя staging, которые один к одному повторяют сырую таблицу и только наводят в ней порядок. Про слои подробно в уроке 11.

Сырую таблицу мы пока берём по полному имени, raw.orders. Это работает, но так делать не принято: в уроке 8 появится source(), и dbt будет знать, откуда берутся данные.