Теперь ваша очередь
Создайте свои стили
Теперь, когда вы увидели, как мы оформляем наши проекты dbt, пришло время создать свои собственные. Не стесняйтесь копировать это руководство и использовать его в качестве шаблона для вашего собственного проекта. Если вы это сделаете, нам будет интересно об этом узнать! Свяжитесь с нами на форуме сообщества или в Slack, чтобы поделиться своим руководством по стилю. Мы рекомендуем размещать ваше руководство по стилю рядом с вашим кодом, чтобы участники могли легко его соблюдать. Если вы используете GitHub, вы можете добавить руководство по стилю в вики вашего репозитория или включить его в ваш README.
Хуки pre-commit
Вы можете использовать pre-commit hooks, чтобы автоматически проверять ваш код на нарушения стилевых правил (и часто исправлять их автоматически) перед коммитом. Это отличный способ убедиться, что все участники проекта придерживаются вашего style guide. Мы рекомендуем внедрять это после того, как вы утвердили и опубликовали свой style guide и привели кодовую базу в соответствие с ним. Это обеспечит соблюдение style guide во всех будущих коммитах. Отличный набор open source pre-commit hooks для dbt, созданный сообществом, вы можете найти здесь, в проекте dbt-checkpoint.
dbt Project Evaluator
dbt_project_evaluator — это пакет, который проверяет соответствие проекта style guide и best practices dbt. Пакет dbt_project_evaluator подсвечивает области dbt‑проекта, которые не соответствуют best practices dbt, и предоставляет рекомендации по улучшению проекта. Это позволяет аналитическим инженерам точно определить, в каких местах их проекты отклоняются от best practices dbt, и самостоятельно внести необходимые улучшения. Пакет dbt_project_evaluator охватывает следующие категории:
- Моделирование
- Тестирование
- Документация
- Структура
- Производительность
- Управление
Подробнее см. Introducing the dbt_project_evaluator: Automatically evaluate your dbt project for alignment with best practices.
Шаблон руководства по стилю
# Пример руководства по стилю 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, дублирующиеся в разных моделях, должны быть выделены и созданы как отдельные модели.
