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

dbt Mesh — это новая архитектура, поддерживаемая dbt Cloud. Она позволяет лучше управлять сложностью, развертывая несколько взаимосвязанных проектов dbt вместо одного большого монолитного проекта. Она разработана для ускорения разработки без ущерба для управления.

Обзор Mesh

 Каковы основные преимущества внедрения dbt Mesh?

Вот некоторые преимущества внедрения dbt Mesh:

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

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

 Что такое контракты моделей?

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

 Что такое версии моделей?

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

Вы можете использовать версии моделей для:

• Тестирования изменений "предрелизной" версии (в производстве, в последующих системах).
• Повышения последней версии, чтобы использовать ее в качестве канонического "источника истины".
• Предоставления окна миграции от "старой" версии.

 Что такое модификаторы доступа к моделям?

Модификатор доступа к модели в dbt определяет, доступна ли модель в качестве входных данных для других моделей и проектов dbt. Он указывает, где модель может быть упомянута с использованием функции ref. Существует три типа модификаторов доступа:

• Частный: Модель с частным модификатором доступа может быть упомянута только моделями в той же группе. Это предназначено для моделей, которые являются деталями реализации и предназначены для использования только в определенной группе связанных моделей.
• Защищенный: Модели с защищенным модификатором доступа могут быть упомянуты любой другой моделью в том же проекте dbt или когда проект установлен как пакет. Это настройка по умолчанию для всех моделей, обеспечивающая обратную совместимость, особенно когда группы назначаются существующему набору моделей.
• Публичный: Публичная модель может быть упомянута в разных группах, пакетах или проектах. Это подходит для стабильных и зрелых моделей, которые служат интерфейсами для других команд или проектов.

 Что такое группы моделей?

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

 Какие потенциальные проблемы могут возникнуть при использовании dbt Mesh?

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

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

 Как это связано с концепцией data mesh?

dbt Mesh позволяет вам лучше операционализировать data mesh, обеспечивая децентрализованное, доменно-специфическое владение данными и сотрудничество.

В data mesh каждый бизнес-домен отвечает за свои данные как за продукт. Это та же цель, которую dbt Mesh облегчает, позволяя организациям разбивать большие, монолитные проекты данных на более мелкие, доменно-специфические проекты dbt. Каждая команда или домен может независимо разрабатывать, поддерживать и делиться своими моделями данных, способствуя децентрализованной среде данных.

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

Как работает dbt Mesh

 Может ли dbt Mesh обрабатывать циклические зависимости между проектами?

Вы можете включить двунаправленные зависимости между проектами, чтобы эти связи могли идти в любом направлении. Это означает, что проект jaffle_finance может добавить новую модель, которая зависит от любых публичных моделей, созданных проектом jaffle_marketing, при условии, что новая зависимость не вводит циклы на уровне узлов. dbt проверяет наличие циклов между проектами и выдает ошибки, если они обнаружены.

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

1. Проект project_a выполняется в среде развертывания и создает публичные модели.
2. Проект project_b добавляет project_a в качестве зависимости.
3. Проект project_b выполняется в среде развертывания и создает публичные модели.
4. Проект project_a добавляет project_b в качестве зависимости.

 Возможно ли, чтобы несколько проектов напрямую ссылались на общий источник?

Хотя в настоящее время невозможно делиться источниками между проектами, можно иметь общий базовый проект с моделями стадии поверх этих источников, которые выставлены как "публичные" модели для других команд/проектов.

 Что если модель, на которую я уже построил из другого проекта, позже становится защищенной?

Это будет нарушением для потребителей этой модели. Если поддерживающие проект хотят удалить модель (или "понизить" ее модификатор доступа, что фактически одно и то же), они должны пометить эту модель для устаревания (используя deprecation_date), что выдаст предупреждение всем потребителям этой модели.

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

 Если я запущу `dbt build --select +model`, вызовет ли это запуск моделей в других проектах?

Нет, если только верхние проекты не установлены как пакеты (исходный код). В этом случае модели в проекте, установленном как проект, становятся "вашими" моделями, и вы можете выбирать или запускать их. Существуют случаи, когда это может быть желательным; см. документацию по зависимостям проекта.

 Если у каждого проекта/домена есть собственное хранилище данных, возможно ли все еще строить модели между ними?

Да, если они находятся на одной платформе данных (BigQuery, Databricks, Redshift, Snowflake и т.д.) и у вас настроены разрешения и совместное использование в этом поставщике платформы данных, чтобы это было возможно.

 Могу ли я запускать тесты, которые включают таблицы из нескольких разных проектов?

Да, поскольку перекрестное сотрудничество между проектами осуществляется с использованием макроса {{ ref() }}, вы можете использовать эти модели от других команд в единичных тестах.

 Какую схему данных создаст dbt Mesh для команды?

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

По умолчанию каждый проект, принадлежащий команде, создаст:

• Одну схему для производственных запусков (например, finance).
• Одну схему на разработчика (например, dev_jerco).

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

 Можно ли применять контракты моделей к исходным данным?

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

 Можно ли частично применять контракты?

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

• Если вы хотите заключить контракт только на подмножество столбцов, вы можете создать отдельную модель (материализованную как представление), выбирая только это подмножество.
• Если вы хотите ограничить, какие строки или столбцы может видеть потребитель, когда он запрашивает данные модели, в зависимости от того, кто он, некоторые платформы данных предлагают расширенные возможности для динамического доступа на уровне строк и маскирования данных на уровне столбцов.

 Могу ли я иметь нескольких владельцев в группе?

Нет, группа может быть назначена только одному владельцу. Однако назначенный владелец может быть командой, а не отдельным лицом.

 Можно ли назначить контракты индивидуальным владельцам?

Не напрямую, но контракты назначаются моделям, и модели могут быть назначены индивидуальным владельцам. Вы можете использовать мета-поля для этой цели.

 Могу ли я сделать модель “публичной” только для использования определенными командами?

В настоящее время это невозможно, но мы надеемся реализовать это в ближайшем будущем. Если вас интересует эта функциональность, пожалуйста, свяжитесь с вашей командой аккаунта dbt Labs.

 Возможно ли оркестровать выполнение заданий между несколькими разными проектами?

dbt Cloud вскоре предложит возможность запускать задания по завершении другого задания, включая задание в другом проекте. Это предлагает один из механизмов выполнения конвейера от начала до конца между проектами.

 Доступны ли интеграции между dbt Cloud Discovery API и другими инструментами для межпроектной родословной?

Да. Помимо возможности просмотра в dbt Explorer, можно просматривать межпроектную родословную, используя интеграции с инструментами каталогизации данных. Для списка доступных интеграций dbt Cloud обратитесь к странице интеграций.

 Как работает пересчет данных в dbt Mesh, особенно при исправлении ошибки в наборе данных?

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

Если проблема с качеством данных все же проскакивает, у вас также есть возможность просто откатить коммит git, а затем повторно запустить задание dbt Cloud с использованием старого кода.

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

Да, все эти метаданные доступны через dbt Cloud Admin API. Эти метаданные могут быть переданы в инструмент мониторинга или использованы для создания отчетов и панелей управления.

Мы также предоставляем часть этой информации в самом dbt Cloud в заданиях, средах и в dbt Explorer.

 Может ли dbt Mesh ссылаться на модели в других аккаунтах в рамках одной платформы данных?

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

Например, Snowflake cross-account data shares, Databricks Unity Catalog across workspaces или несколько проектов BigQuery.

Разрешения и доступ

 Как работают разрешения на доступ пользователей в dbt Mesh?

Существование проектов, в которых есть хотя бы одна публичная модель, будет видно всем в организации с доступом только для чтения.

Частные или защищенные модели требуют, чтобы пользователь имел доступ только для чтения к конкретному проекту, чтобы увидеть его существование.

 Как взаимодействуют все различные типы “доступа”?

Существует доступ на уровне модели в dbt, ролевой доступ для пользователей и групп в dbt Cloud, а также доступ к основным данным в платформе данных.

Во-первых, доступ к основным данным всегда определяется и обеспечивается основной платформой данных (например, BigQuery, Databricks, Redshift, Snowflake, Starburst и т.д.). Этот доступ управляется выполнением "DCL-операторов" (а именно grant). dbt упрощает настройку grants на моделях, которые предоставляют доступ к данным для других ролей/пользователей/групп в хранилище данных. Однако dbt не автоматически определяет или координирует эти гранты, если они не настроены явно. Обратитесь к системе вашей организации для управления разрешениями на хранилище данных.

Планы dbt Cloud Enterprise поддерживают ролевое управление доступом (RBAC), которое управляет детализированными разрешениями для пользователей и групп пользователей. Вы можете контролировать, какие пользователи могут видеть или редактировать все аспекты проекта dbt Cloud. Доступ пользователя к проектам dbt Cloud также определяет, может ли он "исследовать" этот проект в деталях. Роли, пользователи и группы определяются в приложении dbt Cloud через интерфейс пользователя или путем интеграции с поставщиком идентификации.

Доступ к моделям определяет, где модели могут быть упомянуты. Он также информирует о возможности обнаружения этих проектов в dbt Explorer. Доступ к моделям определяется в коде, как и любая другая конфигурация модели (materialized, tags и т.д.).

• Публичный: Модели с публичным доступом могут быть упомянуты везде. Это "продукты данных" вашей организации.

• Защищенный: Модели с защищенным доступом могут быть упомянуты только в рамках одного проекта. Это уровень доступа к моделям по умолчанию. Мы обсуждаем будущее расширение защищенных моделей, чтобы позволить их упоминание в конкретных последующих проектах. Пожалуйста, прочитайте вопрос на GitHub и проголосуйте/оставьте комментарий, если вас интересует этот случай использования.

• Частный: Группы моделей позволяют более детально контролировать, где могут быть упомянуты частные модели. Определив группу и настроив модели, чтобы они принадлежали этой группе, вы можете ограничить другие модели (не входящие в ту же группу) от упоминания любых частных моделей, которые содержит группа. Группы также предоставляют стандартный механизм для определения владельца всех ресурсов, которые она содержит.

В dbt Explorer публичные модели доступны для каждого пользователя в аккаунте dbt Cloud — каждая публичная модель перечислена в "многопроектном" представлении. Напротив, защищенные и частные модели в проекте видны только пользователям, которые имеют доступ к этому проекту (включая доступ только для чтения).

Поскольку dbt не координирует автоматически grants хранилища данных с доступом на уровне модели, возможно несоответствие между ними. Например, метаданные публичной модели видны всем пользователям dbt Cloud, любой может написать ref на эту модель, но когда они фактически запускают или просматривают, они понимают, что у них нет доступа к основным данным в хранилище данных. Это намеренно. Таким образом, ваша организация может сохранить минимально необходимый доступ к основным данным, обеспечивая при этом видимость и возможность обнаружения для более широкой организации. Вооружившись знанием о том, какие другие "продукты данных" (публичные модели) существуют — их описаниями, их владельцами, какие столбцы они содержат — аналитик из другой команды может подготовить хорошо обоснованный запрос на доступ к основным данным.

 Можно ли запросить разрешения на доступ от других команд в dbt Cloud?

На данный момент это невозможно! Но это то, что мы можем оценить в будущем.

 Как член центральной команды данных, могу ли я по-прежнему поддерживать видимость на весь организационный DAG?

Да! Пока у пользователя есть разрешения (по крайней мере, доступ только для чтения) на все проекты в аккаунте dbt Cloud, он может перемещаться по всей DAG организации в dbt Explorer и видеть модели на всех уровнях детализации.

 Как я могу ограничить доступ моих разработчиков к конфиденциальным производственным данным при ссылке из других проектов?

По умолчанию перекрестные ссылки на проекты разрешаются в "Производственную" среду развертывания верхнего проекта. Если в вашей организации действительно разные данные в производственной и непроизводственной средах, это представляет проблему.

По этой причине мы внедрили канонический тип среды развертывания: "Стадия." Если проект определяет как "Производственную" среду, так и "Стадию", то перекрестные ссылки на проекты из среды разработки и "Стадии" будут разрешаться в "Стадию", тогда как только ссылки, исходящие из "Производственной" среды, будут разрешаться в "Производственную". Таким образом, вы гарантированно разделяете среды данных, не дублируя конфигурации проекта.

 Работает ли dbt Mesh, если проекты 'дублируются' (проект разработки <> проект производства)?

Краткий ответ: "нет." Перекрестные ссылки на проекты требуют, чтобы каждое имя проекта было уникальным в вашем аккаунте dbt Cloud.

Исторические ограничения требовали от клиентов "дублировать" проекты, чтобы один фактический проект dbt (кодовая база) соответствовал более чем одному проекту dbt Cloud. В этой связи мы работаем над устранением исторических ограничений, которые требовали от клиентов "дублировать" проекты в dbt Cloud — Стадии для изоляции данных, разрешения на уровне среды и подключения к хранилищу данных на уровне среды (скоро появится). Как только эти элементы будут на месте, больше не будет необходимости определять отдельные проекты dbt Cloud для изоляции сред данных или разрешений.

Совместимость с другими функциями

 Как dbt Semantic Layer соотносится и работает с dbt Mesh?

Семантический слой dbt и dbt Mesh — это взаимодополняющие механизмы, поддерживаемые dbt Cloud, которые работают вместе для улучшения управления, удобства использования и управления данными в крупномасштабных средах данных.

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

dbt Mesh позволяет организациям разделять свою архитектуру данных на несколько доменно-специфических проектов, сохраняя при этом возможность ссылаться на "публичные" модели между проектами. Также возможно ссылаться на "публичную" модель из другого проекта для определения семантических моделей и метрик. Ваша организация может иметь несколько проектов dbt, которые питают единый семантический слой, обеспечивая, чтобы метрики и измерения были согласованно определены и поняты в этих доменах.

При использовании Семантического слоя dbt в контексте dbt Mesh, мы рекомендуем следующее:

• У вас должен быть один автономный проект, который содержит ваши семантические модели и метрики.
• Затем, по мере создания Семантического слоя, вы можете перекрестно ссылаться на модели dbt в различных проектах или пакетах, чтобы создавать свои семантические модели, используя функцию ref с двумя аргументами (ref('project_name', 'model_name')).
• Ваш проект Семантического слоя dbt служит глобальным источником истины для остальных ваших проектов.

Пример использования

Например, предположим, у вас есть публичная модель (fct_orders), которая находится в проекте jaffle_finance. При создании вашей семантической модели используйте следующий синтаксис для ссылки на модель:

models/metrics/semantic_model_name.yml

semantic_models:
  - name: customer_orders
    defaults:
      agg_time_dimension: first_ordered_at
    description: |
      Март на уровне клиентов, агрегирующий заказы клиентов.
    model: ref('jaffle_finance', 'fct_orders') # ref('project_name', 'model_name')
    entities:
      ...остальная часть конфигурации...
    dimensions:
      ...остальная часть конфигурации...
    measures:
      ...остальная часть конфигурации...

Обратите внимание, что в параметре model мы используем функцию ref с двумя аргументами для ссылки на публичную модель fct_orders, определенную в проекте jaffle_finance.

 Как dbt Explorer соотносится и работает с dbt Mesh?

dbt Explorer — это инструмент в dbt Cloud, который служит базой знаний и платформой визуализации родословной. Он предоставляет всесторонний обзор ваших активов dbt, включая модели, тесты, источники и их взаимозависимости.

Используемый в сочетании с dbt Mesh, dbt Explorer становится мощным инструментом для визуализации и понимания отношений и зависимостей между моделями в нескольких проектах dbt.

 Как dbt Cloud CLI соотносится и работает с dbt Mesh?

dbt Cloud CLI позволяет пользователям разрабатывать и выполнять команды dbt из предпочитаемых сред разработки, таких как VS Code, Sublime Text или терминальные интерфейсы. Эта гибкость особенно полезна в настройке dbt Mesh, где управление несколькими проектами может быть сложным. Разработчики могут работать в своих предпочитаемых инструментах, используя централизованные возможности dbt Cloud.

Доступность

 Требует ли dbt Mesh использования определенной версии dbt?

Да, ваш аккаунт должен быть на по крайней мере dbt v1.6, чтобы воспользоваться межпроектными зависимостями, одной из самых важных базовых возможностей, необходимых для реализации dbt Mesh.

 Есть ли способ использовать возможности dbt Mesh в dbt Core?

Хотя dbt Core определяет несколько основных элементов для dbt Mesh, dbt Cloud предлагает улучшенный опыт, который использует эти элементы для масштабного сотрудничества между несколькими командами, облегченного многопроектным обнаружением в dbt Explorer, адаптированным к доступу каждого пользователя.

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

Чтобы ссылаться на модели, определенные в другом проекте, пользователи также могут использовать пакеты, давнюю функцию dbt Core. Импортируя верхний проект как пакет, dbt импортирует все модели, определенные в этом проекте, что позволяет разрешать межпроектные ссылки на эти модели. Они могут быть опционально ограничены только моделями с публичным доступом.

Основное отличие заключается в метаданных dbt Cloud, которые уникальны для платформы dbt Cloud и позволяют разрешать ссылки только на публичные модели в проекте. Эта служба позволяет пользователям принимать зависимости от верхних проектов и ссылаться только на их публичные модели, без необходимости загружать всю сложность этих верхних проектов в свою локальную среду разработки.

 Требует ли dbt Mesh определенного плана dbt Cloud?

Да, для настройки нескольких проектов и ссылок на модели между ними требуется план dbt Cloud Enterprise.

Советы по внедрению dbt Mesh

 Есть ли рекомендованный процесс миграции или внедрения?

Обратитесь к нашему руководству разработчика по структурированию наших проектов dbt Mesh. Вам также может быть интересно посмотреть запись этого доклада с Coalesce 2023: Разблокировка управления моделями и многопроектных развертываний с помощью dbt-meshify.

Вы также можете узнать, как внедрить dbt Mesh, следуя нашему Руководству по быстрому старту dbt Mesh.

 Есть ли инструменты, которые помогут мне мигрировать на dbt Mesh?

dbt-meshify — это CLI-инструмент, который автоматизирует создание функций управления моделями и межпроектной родословной, введенных в dbt-core v1.5 и v1.6. Этот пакет будет использовать метаданные вашего проекта dbt для создания и/или редактирования файлов в вашем проекте, чтобы правильно настроить модели в вашем проекте с этими функциями.

 Моя команда не структурирована для необходимости нескольких проектов сегодня. Какие аспекты dbt Mesh актуальны для меня?

Предположим, в вашей организации менее 500 моделей и менее дюжины регулярных участников dbt. Вы работаете на масштабе, который хорошо обслуживается монолитом (один проект), и более крупный шаблон dbt Mesh, вероятно, не принесет никаких немедленных преимуществ.

Никогда не рано думать о том, как вы организуете модели внутри этого проекта. Используйте группы моделей, чтобы определить четкие границы владения и частный доступ, чтобы ограничить использование моделей, созданных для определенной цели, от становления несущими блоками в несвязанной части DAG. Ваши будущие "я" будут благодарны вам за определение этих интерфейсов, особенно если вы достигнете масштаба, при котором имеет смысл "выпускать" интерфейсы между группами в границы между проектами.