Перейти к основному содержимому

Доступ к моделям

"Доступ к моделям" не равен "Доступу пользователей"

Model groups and access и user groups and access — это два разных понятия. User groups and access — это конкретный термин, используемый в dbt для управления правами доступа. Подробнее см. в разделе User access.

Эти два концепта будут тесно связаны по мере того, как в течение этого года мы будем развивать рабочие процессы совместной работы над несколькими проектами:

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

Группы​

Модели могут быть сгруппированы под общим обозначением с общим владельцем. Например, вы можете сгруппировать все модели, принадлежащие определенной команде, или связанные с моделированием конкретного источника данных (github).

Зачем определять группы моделей? Есть две причины:

  • Это превращает неявные отношения в явную группировку с определенным владельцем. Размышляя о границах интерфейсов между группами, вы можете создать более чистый (менее запутанный) DAG. В будущем эти границы интерфейсов могут быть подходящими в качестве интерфейсов между отдельными проектами.
  • Это позволяет вам обозначить определенные модели как имеющие "приватный" доступ — для использования исключительно в этой группе. Другие модели будут ограничены в возможности ссылаться (зависеть) на эти модели. В будущем они не будут видны другим командам, зависящим от вашего проекта — только "публичные" модели будут.

Если вы следуете нашим лучшим практикам по структуре проекта dbt, вы, вероятно, уже используете подкаталоги для организации вашего проекта dbt. Легко применить метку group ко всему подкаталогу сразу:

dbt_project.yml
models:
  my_project_name:
    marts:
      customers:
        +group: customer_success
      finance:
        +group: finance

Каждая модель может принадлежать только одной группе, и группы не могут быть вложенными. Если вы установите другую группу в YAML этой модели или в конфигурации файла, она переопределит группу, примененную на уровне проекта.

Соображения​

Есть несколько моментов, которые стоит учитывать при использовании возможностей управления моделями:

  • Такие функции управления моделями, как доступ к моделям (model access), контракты (contracts) и версии (versions), повышают уровень доверия и стабильности в вашем проекте dbt. Однако из‑за добавления дополнительной структуры они могут усложнить откат изменений (например, при необходимости убрать ограничения доступа к модели) и увеличить затраты на сопровождение, если внедрить их слишком рано.
    Перед тем как добавлять функции управления, стоит оценить, готов ли ваш проект dbt извлечь из них пользу. Внедрение управления на этапе, когда модели все еще активно меняются, может усложнить будущие изменения.

  • Функции управления применяются только к моделям. Они не распространяются на другие типы ресурсов, включая snapshots, seeds или sources. Это связано с тем, что такие объекты могут со временем менять свою структуру (например, snapshots фиксируют изменяющиеся исторические данные) и плохо подходят для предоставления гарантий вроде контрактов, управления доступом или версионирования.

Модификаторы доступа​

Некоторые модели являются деталями реализации, предназначенными только для использования в их группе связанных моделей. Другие модели должны быть доступны через функцию ref между группами и проектами. Модели могут установить модификатор доступа, чтобы указать предполагаемый уровень доступности.

ДоступДоступен для ссылок
privateТа же группа
protectedТот же проект (или установлен как пакет)
publicЛюбая группа, пакет или проект. При определении, перезапустите производственную задачу, чтобы применить изменения
Loading table...

Если вы попытаетесь сослаться на модель вне ее поддерживаемого доступа, вы увидите ошибку:

dbt run -s marketing_model
...
dbt.exceptions.DbtReferenceError: Parsing Error
  Node model.jaffle_shop.marketing_model attempted to reference node model.jaffle_shop.finance_model, 
  which is not allowed because the referenced node is private to the finance group.

По умолчанию все модели protected. Это означает, что другие модели в том же проекте могут ссылаться на них, независимо от их группы. Это в основном для обратной совместимости при назначении групп существующему набору моделей, так как уже могут существовать существующие ссылки между назначениями групп.

Однако рекомендуется установить модификатор доступа новой модели на private, чтобы предотвратить зависимость других ресурсов проекта от моделей, не предназначенных для совместного использования между группами.

models/marts/customers.yml
# Сначала определите группу и владельца
groups:
  - name: customer_success
    owner:
      name: Customer Success Team
      email: cx@jaffle.shop

# Затем добавьте 'group' + 'access' модификатор к конкретным моделям
models:
  # Это публичная модель -- это стабильный и зрелый интерфейс для других команд/проектов
  - name: dim_customers
    config:
      group: customer_success # changed to config in v1.10
      access: public # changed to config in v1.10
    
  # Это приватная модель -- это промежуточная трансформация, предназначенная только для использования в этом контексте
  - name: int_customer_history_rollup
    config:
      group: customer_success # changed to config in v1.10
      access: private # changed to config in v1.10
    
  # Это защищенная модель -- она может быть полезна в другом месте в *этом* проекте,
  # но не должна быть доступна в других местах
  - name: stg_customer__survey_results
    config:
      group: customer_success # changed to config in v1.10
      access: protected # changed to config in v1.10

Модели с materialized, установленным на ephemeral, не могут иметь свойство доступа, установленное на public.

Например, если у вас есть конфигурация модели, установленная как:

models/my_model.sql

{{ config(materialized='ephemeral') }}

И доступ к модели определен:

models/my_project.yml

models:
  - name: my_model
    config:
      access: public # changed to config in v1.10

Это приведет к следующей ошибке:

❯ dbt parse
02:19:30  Encountered an error:
Parsing Error
  Node model.jaffle_shop.my_model with 'ephemeral' materialization has an invalid value (public) for the access field

Часто задаваемые вопросы​

Как доступ к моделям соотносится с разрешениями базы данных?​

Это разные вещи!

Указание access: public на модели не заставляет dbt автоматически предоставлять select на эту модель каждому пользователю или роли в вашей платформе данных при ее материализации. Вы полностью контролируете управление разрешениями базы данных на каждую модель/схему, как это имеет смысл для вас и вашей организации.

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

  • Предоставление доступа к публичным моделям для downstream-запросов
  • Ограничение доступа к приватным моделям, отменяя стандартные/будущие гранты или размещая их в другой схеме

По мере того, как мы продолжаем развивать совместную работу над несколькими проектами, access: public будет означать, что другие команды могут начать зависеть от этой модели. Это предполагает, что они запросили, и вы предоставили им доступ, для выбора из базового набора данных.

Как я могу сослаться на модель из другого проекта?​

Вы можете использовать ref для модели из другого проекта двумя способами:

  1. Зависимость проекта: В dbt Enterprise вы можете использовать зависимости проектов, чтобы делать ref на модель. dbt использует скрытый от пользователя сервис метаданных для разрешения таких ссылок, что обеспечивает эффективное взаимодействие между командами и масштабируемую работу.
  2. "Пакетная" зависимость: Другой способ сделать ref на модель из другого проекта — рассматривать этот проект как пакетную зависимость. Для этого требуется установить другой проект как пакет, включая весь его исходный код, а также его вышестоящие зависимости.

Как я могу ограничить доступ к моделям, определенным в пакете?​

Исходный код, установленный из пакета, становится частью вашей среды выполнения. Вы можете вызывать макросы и запускать модели, как если бы они были макросами и моделями, которые вы определили в своем собственном проекте.

По этой причине ограничения доступа к моделям "выключены" по умолчанию для моделей, определенных в пакетах. Вы можете ссылаться на модели из этого пакета независимо от их модификатора access.

Проект, установленный как пакет, может опционально ограничить внешний доступ ref только к своим публичным моделям. Поддерживающий пакет делает это, устанавливая конфигурацию restrict-access в True в dbt_project.yml.

По умолчанию значение этой конфигурации — False. Это означает, что:

  • Модели в пакете с access: protected могут быть ссылками для моделей в корневом проекте, как если бы они были определены в том же проекте
  • Модели в пакете с access: private могут быть ссылками для моделей в корневом проекте, если они также имеют ту же конфигурацию group

Когда restrict-access: True:

  • Любая ссылка ref из-за пределов пакета на защищенную или приватную модель в этом пакете будет неудачной.
  • Только модели с access: public могут быть ссылками за пределами пакета.
dbt_project.yml
restrict-access: True  # по умолчанию False

Нашли ошибку?

0
Loading