Теперь ваша очередь

Создайте свои стили

Теперь, когда вы увидели, как мы оформляем наши проекты dbt, пришло время создать свои собственные. Не стесняйтесь копировать это руководство и использовать его в качестве шаблона для вашего собственного проекта. Если вы это сделаете, нам будет интересно об этом узнать! Свяжитесь с нами на форуме сообщества или в Slack, чтобы поделиться своим руководством по стилю. Мы рекомендуем размещать ваше руководство по стилю рядом с вашим кодом, чтобы участники могли легко его соблюдать. Если вы используете GitHub, вы можете добавить руководство по стилю в вики вашего репозитория или включить его в ваш README.

Pre-commit hooks

Наконец, чтобы гарантировать, что автоматические правила вашего руководства по стилю соблюдаются без дополнительной умственной нагрузки для вашей команды, вы можете использовать pre-commit hooks, чтобы автоматически проверять ваш код на нарушения стиля (и часто исправлять их автоматически) перед его фиксацией. Это отличный способ убедиться, что все участники следуют вашему руководству по стилю. Мы рекомендуем внедрить это после того, как вы утвердите и опубликуете ваше руководство по стилю, и ваш код будет ему соответствовать. Это обеспечит соблюдение руководства по стилю во всех будущих коммитах. Вы можете найти отличный набор pre-commit hooks с открытым исходным кодом для dbt от сообщества здесь в проекте dbt-checkpoint.

Шаблон руководства по стилю

# Пример руководства по стилю dbt

## Стиль SQL

- Используйте ключевые слова в нижнем регистре.
- Используйте завершающие запятые.

## Организация моделей

Наши модели (как правило) делятся на две основные категории:\

- Staging — Содержит модели, которые очищают и стандартизируют данные.        
- Marts — Содержит модели, которые объединяют или сильно трансформируют данные. 

Важные моменты:

- Существуют различные типы моделей, которые обычно существуют в каждой из вышеуказанных категорий. Подробнее см. в разделе Слои моделей.
- Прочтите Как мы структурируем наши проекты dbt для примера и более подробной информации об организации.

## Слои моделей

- Только модели в `staging` должны выбирать из sources.
- Модели, не находящиеся в папке `staging`, должны выбирать из refs.

## Именование файлов моделей и кодирование

- Все объекты должны быть во множественном числе.  
  Пример: `stg_stripe__invoices.sql` vs. `stg_stripe__invoice.sql`

- Все модели должны использовать соглашение об именовании `<type/dag_stage>_<source/topic>__<additional_context>`. Подробнее см. в этой статье.

  - Модели в папке **staging** должны использовать имя источника в качестве `<source/topic>` и имя сущности в качестве `additional_context`.

    Примеры:

    - seed_snowflake_spend.csv
    - base_stripe\_\_invoices.sql
    - stg_stripe\_\_customers.sql
    - stg_salesforce\_\_customers.sql
    - int_customers\_\_unioned.sql
    - fct_orders.sql

- Имена схем, таблиц и столбцов должны быть в `snake_case`.

- Ограничьте использование аббревиатур, связанных с доменной областью. Новому сотруднику будет легче понять `current_order_status`, чем `current_os`.

- Используйте названия, основанные на _бизнесе_, а не на терминологии источника.

- Каждая модель должна иметь первичный ключ для идентификации уникальной строки и должна называться `<object>_id`. Например, `account_id`. Это облегчает понимание того, какой `id` используется в последующих объединенных моделях.

- Для моделей `base` или `staging` столбцы должны быть упорядочены по категориям, где идентификаторы идут первыми, а поля даты/времени в конце.
- Столбцы даты/времени должны быть названы в соответствии с этими соглашениями:

  - Метки времени: `<event>_at`  
    Формат: UTC  
    Пример: `created_at`

  - Даты: `<event>_date`
    Формат: Дата  
    Пример: `created_date`

- Булевы значения должны иметь префиксы `is_` или `has_`.
  Пример: `is_active_customer` и `has_admin_access`

- Поля цены/дохода должны быть в десятичной валюте (например, `19.99` для $19.99; многие базы данных приложений хранят цены в виде целых чисел в центах). Если используется недесятичная валюта, укажите это с помощью суффиксов. Например, `price_in_cents`.

- Избегайте использования зарезервированных слов (таких как эти для Snowflake) в качестве имен столбцов.

- Последовательность важна! Используйте одинаковые имена полей в разных моделях, где это возможно. Например, ключ к таблице `customers` должен называться `customer_id`, а не `user_id`.

## Конфигурации моделей

- Конфигурации моделей на уровне папки должны быть рассмотрены (и, если применимо, применены) в первую очередь.
- Более специфичные конфигурации должны применяться на уровне модели с использованием одного из этих методов.
- Модели в папке `marts` должны быть материализованы как `table` или `incremental`.
  - По умолчанию, `marts` должны быть материализованы как `table` в `dbt_project.yml`.
  - Если переключение на `incremental`, это должно быть указано в конфигурации модели.

## Тестирование

- Минимум, тесты `unique` и `not_null` должны быть применены к ожидаемому первичному ключу каждой модели.

## CTEs

Для получения дополнительной информации о том, почему мы используем так много CTE, прочтите этот глоссарий.

- Если производительность позволяет, CTE должны выполнять одну логическую единицу работы.
- Имена CTE должны быть настолько подробными, насколько это необходимо, чтобы передать их назначение.
- CTE с запутанной или примечательной логикой должны быть прокомментированы с помощью SQL-комментариев, как и любые сложные функции, и должны располагаться выше CTE.
- CTE, дублирующиеся в разных моделях, должны быть выделены и созданы как отдельные модели.