Часто задаваемые вопросы о dbt Mesh
Mesh — это новая архитектура, включаемая с помощью dbt. Она позволяет эффективнее управлять сложностью за счёт развертывания нескольких взаимосвязанных проектов dbt вместо одного большого монолитного проекта. Архитектура спроектирована так, чтобы ускорять разработку без ущерба для управления и контроля (governance).
Обзор Mesh
Вот некоторые преимущества внедрения dbt Mesh:
- Быстрее выпускать продукты данных: Благодаря более модульной архитектуре команды могут быстро и независимо вносить изменения в конкретные области без воздействия на всю систему, что приводит к более быстрым циклам разработки.
- Улучшение доверия к данным: Применение dbt Mesh помогает гарантировать, что изменения в моделях данных одного домена не нарушат неожиданно зависимости в других областях домена, что приводит к более безопасной и предсказуемой среде данных.
- Снижение сложности: Организуя логику трансформации в отдельные домены, dbt Mesh снижает сложность, присущую большим монолитным проектам, делая их более управляемыми и понятными.
- Улучшение сотрудничества: Команды могут делиться и развивать работу друг друга без дублирования усилий.
Самое главное, все это можно достичь без потери центральной командой данных возможности видеть родословную по всей организации или компрометации механизмов управления.
dbt model contracts служат инструментом управления, который позволяет определять и обеспечивать соблюдение стандартов структуры данных в ваших моделях dbt. Они дают возможность задавать и поддерживать гарантии для моделей данных, включая типы данных колонок, что обеспечивает стабильность зависимых моделей. Если модель не соответствует установленным для неё контрактам, она не будет успешно собрана.
dbt model versions — это итерации ваших dbt-моделей, создаваемые с течением времени. Во многих случаях вы можете осознанно решить изменить структуру модели таким образом, что это «сломает» предыдущий контракт модели и может нарушить работу downstream‑запросов, зависящих от структуры этой модели. В таких ситуациях создание новой версии модели полезно для явного обозначения этого изменения.
Вы можете использовать версии моделей для:
- Тестирования изменений "предрелизной" версии (в производстве, в последующих системах).
- Повышения последней версии, чтобы использовать ее в качестве канонического "источника истины".
- Предоставления окна миграции от "старой" версии.
Model access modifier в dbt определяет, может ли модель быть доступна как входная (input) для других моделей и проектов dbt. Он указывает, где именно модель может быть использована с помощью функции ref. Существует три типа access modifiers:
- Частный: Модель с частным модификатором доступа может быть упомянута только моделями в той же группе. Это предназначено для моделей, которые являются деталями реализации и предназначены для использования только в определенной группе связанных моделей.
- Защищенный: Модели с защищенным модификатором доступа могут быть упомянуты любой другой моделью в том же проекте dbt или когда проект установлен как пакет. Это настройка по умолчанию для всех моделей, обеспечивающая обратную совместимость, особенно когда группы назначаются существующему набору моделей.
- Публичный: Публичная модель может быть упомянута в разных группах, пакетах или проектах. Это подходит для стабильных и зрелых моделей, которые служат интерфейсами для других команд или проектов.
Model group в dbt — это концепция, используемая для организации моделей в рамках общей категории или по признаку владения. Такая категоризация может основываться на различных критериях, например на команде, ответственной за модели, или на конкретном источнике данных, который эти модели описывают.
Это новый способ работы, и намеренность, необходимая для создания и поддержания интерфейсов и зависимостей между проектами, может показаться замедлением по сравнению с тем, к чему привыкли некоторые разработчики. Введенное намеренное трение способствует обдуманным изменениям, формируя мышление, которое ценит стабильность и систематические корректировки больше, чем быстрые трансформации.
Оркестрация между несколькими проектами также, вероятно, будет немного более сложной для многих организаций, хотя мы в настоящее время разрабатываем новую функциональность, которая упростит этот процесс.
dbt Mesh позволяет вам лучше операционализировать data mesh, обеспечивая децентрализованное, доменно-специфическое владение данными и сотрудничество.
В data mesh каждый бизнес-домен отвечает за свои данные как за продукт. Это та же цель, которую dbt Mesh облегчает, позволяя организациям разбивать большие, монолитные проекты данных на более мелкие, доменно-специфические проекты dbt. Каждая команда или домен может независимо разрабатывать, поддерживать и делиться своими моделями данных, способствуя децентрализованной среде данных.
dbt Mesh также улучшает интероперабельность и повторное использование данных в разных доменах, что является ключевым аспектом философии data mesh. Позволяя перекрестные ссылки на проекты и совместное управление через контракты моделей и контроль доступа, dbt Mesh гарантирует, что, хотя владение данными децентрализовано, существует все же управляемая структура для общей архитектуры данных.
Как работает dbt Mesh
Вы можете включить двунаправленные зависимости между проектами, чтобы эти связи могли идти в любом направлении. Это означает, что проект jaffle_finance может добавить новую модель, которая зависит от любых публичных моделей, созданных проектом jaffle_marketing, при условии, что новая зависимость не вводит циклы на уровне узлов. dbt проверяет наличие циклов между проектами и выдает ошибки, если они обнаружены.
При настройке проектов, которые зависят друг от друга, важно делать это пошагово. Каждый проект должен выполняться и создавать публичные модели, прежде чем исходный проект-производитель сможет взять зависимость от исходного проекта-потребителя. Например, порядок действий для простой настройки из двух проектов будет следующим:
- Проект
project_aвыполняется в среде развертывания и создает публичные модели. - Проект
project_bдобавляетproject_aв качестве зависимости. - Проект
project_bвыполняется в среде развертывания и создает публичные модели. - Проект
project_aдобавляетproject_bв качестве зависимости.
Хотя в настоящее время невозможно делиться источниками между проектами, можно иметь общий базовый проект с моделями стадии поверх этих источников, которые выставлены как "публичные" модели для других команд/проектов.
Это будет нарушением для потребителей этой модели. Если поддерживающие проект хотят удалить модель (или "понизить" ее модификатор доступа, что фактически одно и то же), они должны пометить эту модель для устаревания (используя deprecation_date), что выдаст предупреждение всем потребителям этой модели.
В будущем мы планируем, что dbt Cloud также сможет проактивно отмечать этот сценарий в непрерывной интеграции для поддерживающих публичную модель.
Это будет breaking change для downstream‑потребителей этой модели. Если мейнтейнеры upstream‑проекта хотят удалить модель (или «понизить» её модификатор доступа, что по сути то же самое), им следует пометить эту модель как устаревающую, используя deprecation_date. В этом случае всем downstream‑потребителям этой модели будет выдано предупреждение.
В будущем мы планируем, что dbt также сможет проактивно сигнализировать о такой ситуации в continuous integration для мейнтейнеров upstream‑публичной модели.
Нет, если только апстрим‑проекты не установлены как packages (исходный код). В этом случае модели в проекте, установленном как пакет, становятся «вашими» моделями, и вы можете выбирать или запускать их. В некоторых ситуациях это может быть полезно; см. документацию по project dependencies.
Да, поскольку перекрестное сотрудничество между проектами осуществляется с использованием макроса {{ ref() }}, вы можете использовать эти модели от других команд в единичных тестах.
Каждая команда определяет свое подключение к хранилищу данных и имена схем по умолчанию, которые dbt будет использовать при материализации наборов данных.
По умолчанию каждый проект, принадлежащий команде, создаст:
- Одну схему для производственных запусков (например,
finance). - Одну схему на разработчика (например,
dev_jerco).
В зависимости от потребностей каждой команды это можно настроить с помощью конфигураций схем на уровне модели, включая возможность определения различных правил по средам.
Нет, contracts можно применять только на уровне модели. В качестве рекомендуемой best practice стоит определять staging models поверх sources, и уже на эти staging-модели можно задавать contracts.
Нет. Contract применяется ко всей модели, включая все колонки в результирующем наборе. Это тот же набор колонок, который увидит потребитель при просмотре деталей модели в Explorer или при запросе к модели в платформе данных.
- Если вы хотите законтрактовать только часть колонок, можно создать отдельную модель (materialized как view), которая выбирает только этот поднабор.
- Если вы хотите ограничить, какие строки или колонки увидит downstream-потребитель при запросе к данным модели (в зависимости от того, кто он), некоторые платформы данных предоставляют расширенные возможности динамического row-level access и column-level data masking.
Нет, группу можно назначить только одному владельцу. Однако назначенным владельцем может быть команда, а не отдельный человек.
Нет, group может быть назначен только одному owner. Однако назначенным owner может быть team, а не отдельный человек.
Непосредственно — нет, но контракты назначаются моделям, а модели могут быть назначены отдельным владельцам. Для этой цели можно использовать поля meta.
dbt Cloud вскоре предложит возможность запускать задания по завершении другого задания, включая задание в другом проекте. Это предлагает один из механизмов выполнения конвейера от начала до конца между проектами.
Да. Помимо нативного просмотра через Catalog, также существует возможность просматривать межпроектную lineage с использованием партнёрских интеграций с инструментами каталогизации данных. Список доступных интеграций dbt см. на странице Integrations.
Тесты и контракты моделей в dbt помогают изначально снизить необходимость пересчёта данных. С помощью этих инструментов вы можете встроить проверки на уровне источников и выходных данных в ваших dbt-проектах, чтобы оценивать качество данных в самых критичных местах. Когда меняется логика трансформаций (например, изменяется определение конкретной колонки), пересчёт данных сводится к простому мерджу обновлённого кода и запуску задания в dbt.
Если проблема с качеством данных всё же проскочила, у вас также есть возможность просто откатить git-коммит и заново запустить задание dbt с предыдущей версией кода.
Да, все эти метаданные доступны через Admin API dbt. Эти данные можно передавать в инструменты мониторинга или использовать для построения отчётов и дашбордов.
Часть этой информации также отображается непосредственно в dbt — в разделе jobs, environments, а также в Catalog.
Вы можете ссылаться на модели в других аккаунтах в рамках одной и той же платформы данных, используя возможности шаринга данных этой платформы, при условии что идентификатор базы данных публичной модели совпадает у продюсера и консюмера.
Например, это могут быть кросс-аккаунтные data shares в Snowflake, Databricks Unity Catalog между разными workspace или несколько проектов BigQuery.
Разрешения и доступ
Существование проектов, в которых есть хотя бы одна публичная модель, будет видно всем в организации с доступом только для чтения.
Частные или защищенные модели требуют, чтобы пользователь имел доступ только для чтения к конкретному проекту, чтобы увидеть его существование.
Существует доступ на уровне моделей в dbt, ролевой доступ для пользователей и групп в dbt, а также доступ к базовым данным на стороне платформы данных.
Прежде всего: доступ к базовым данным всегда определяется и обеспечивается самой платформой данных (например, BigQuery, Databricks, Redshift, Snowflake, Starburst и т.д.). Такой доступ управляется через выполнение DCL-команд (в первую очередь grant). dbt упрощает этот процесс, позволяя настраивать grants для моделей, чтобы выдавать доступ к данным другим ролям, пользователям или группам в хранилище данных. При этом dbt не определяет и не синхронизирует такие права автоматически, если они не настроены явно. Ориентируйтесь на внутренние процессы вашей организации для управления правами доступа в хранилище данных.
Тарифы dbt Enterprise и Enterprise+ поддерживают ролевую модель доступа (RBAC), которая позволяет управлять детальными правами пользователей и групп. Вы можете контролировать, какие пользователи могут просматривать или редактировать различные части проекта в dbt. Уровень доступа пользователя к проектам в dbt также определяет, может ли он детально «исследовать» (explore) этот проект. Роли, пользователи и группы настраиваются внутри приложения dbt через интерфейс или через интеграцию с провайдером идентификации.
Доступ к моделям определяет, где именно модели могут быть использованы через ref. Он также влияет на их обнаруживаемость в Catalog. Параметр access для модели задаётся в коде — так же, как и любые другие настройки модели (materialized, tags и т.д.).
-
Public: Модели с уровнем доступа
publicмогут использоваться везде. Это «продукты данных» вашей организации. -
Protected: Модели с уровнем доступа
protectedмогут использоваться только внутри одного проекта. Это уровень доступа по умолчанию.
В будущем мы обсуждаем расширениеprotected, чтобы такие модели можно было использовать в определённых downstream-проектах. Подробнее см. GitHub issue. Если этот сценарий вам интересен — поставьте апвоут или оставьте комментарий. -
Private: Механизм
groupsпозволяет более тонко контролировать использованиеprivate-моделей. Определив группу и назначив модели в эту группу, вы можете запретить другим моделям (не входящим в ту же группу) ссылаться на любыеprivate-модели внутри неё. Группы также предоставляют стандартный механизм для заданияownerвсех ресурсов, которые они содержат.
В Catalog модели с уровнем доступа public доступны для обнаружения всем пользователям аккаунта dbt — каждая публичная модель отображается в режиме «multi-project». В отличие от них, protected и private-модели видны только тем пользователям, у которых есть доступ к соответствующему проекту (включая доступ только для чтения).
Поскольку dbt не синхронизирует автоматически grants на уровне хранилища данных с параметром access на уровне моделей, между ними возможны расхождения. Например, метаданные public-модели видны всем пользователям dbt, любой может написать ref на такую модель, но при фактическом запуске или предпросмотре выясняется, что у пользователя нет доступа к данным в хранилище. Это сделано намеренно. Такой подход позволяет сохранять принцип минимально необходимого доступа к данным, одновременно обеспечивая прозрачность и обнаруживаемость данных для всей организации. Зная, какие «продукты данных» (публичные модели) существуют — их описания, владельцев и набор колонок — аналитик из другой команды может подготовить обоснованный запрос на доступ к исходным данным.
На данный момент — нет. Но мы рассматриваем возможность добавить такую функциональность в будущем.
Да! Если у пользователя есть права доступа (как минимум доступ только для чтения) ко всем проектам в аккаунте dbt, он может перемещаться по всему DAG организации в Catalog и просматривать модели на всех уровнях детализации.
По умолчанию кросс-проектные ссылки разрешаются на deployment-окружение «Production» апстрим-проекта. Если в вашей организации данные в production и non-production окружениях действительно различаются, это может стать проблемой.
Поэтому мы ввели канонический тип deployment-окружения — «Staging». Если в проекте определены и «Production», и «Staging» окружения, то кросс-проектные ссылки из development- и «Staging»-окружений будут указывать на «Staging», а только ссылки из «Production»-окружений — на «Production». Таким образом обеспечивается строгая изоляция окружений данных без необходимости дублировать конфигурации проектов.
Краткий ответ: "нет." Перекрестные ссылки на проекты требуют, чтобы каждое имя проекта было уникальным в вашем аккаунте dbt Cloud.
Исторические ограничения требовали от клиентов "дублировать" проекты, чтобы один фактический проект dbt (кодовая база) соответствовал более чем одному проекту dbt Cloud. В этой связи мы работаем над устранением исторических ограничений, которые требовали от клиентов "дублировать" проекты в dbt Cloud — Стадии для изоляции данных, разрешения на уровне среды и подключения к хранилищу данных на уровне среды (скоро появится). Как только эти элементы будут на месте, больше не будет необходимости определять отдельные проекты dbt Cloud для изоляции сред данных или разрешений.
Совместимость с другими возможностями
Semantic Layer и dbt Mesh — это взаимодополняющие механизмы, предоставляемые dbt, которые совместно улучшают управление, удобство использования и управление данными (governance) в масштабных средах данных.
Semantic Layer в dbt позволяет командам централизованно определять бизнес‑метрики и измерения. Это обеспечивает единообразие и надежность определений метрик в различных аналитических инструментах и платформах.
Mesh позволяет организациям разделять архитектуру данных на несколько доменно‑ориентированных проектов, сохраняя при этом возможность ссылаться на «публичные» модели между проектами. Также возможно ссылаться на «публичную» модель из другого проекта с целью определения семантических моделей и метрик. Ваша организация может иметь несколько dbt‑проектов, которые наполняют единый семантический слой, обеспечивая согласованное и однозначное определение и понимание метрик и измерений во всех этих доменах.
При использовании Семантического слоя dbt в контексте dbt Mesh, мы рекомендуем следующее:
- У вас есть один отдельный проект, который содержит ваши семантические модели и метрики.
- Затем, по мере построения Semantic Layer, вы можете делать кросс‑ссылки на dbt‑модели между различными проектами или пакетами, чтобы создавать семантические модели, используя двухаргументную функцию
ref(ref('project_name', 'model_name')). - Проект dbt Semantic Layer служит глобальным источником истины для всех остальных ваших проектов.
Пример использования
Например, предположим, у вас есть публичная модель (fct_orders), которая находится в проекте jaffle_finance. При создании вашей семантической модели используйте следующий синтаксис для ссылки на модель:
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.
Catalog — это инструмент внутри dbt, который выступает в роли базы знаний и платформы визуализации lineage. Он предоставляет полное представление обо всех dbt-артефактах, включая модели, тесты, источники и их взаимозависимости.
В сочетании с dbt Mesh, Catalog становится мощным инструментом для визуализации и понимания связей и зависимостей между моделями в нескольких dbt-проектах.
CLI dbt позволяет пользователям разрабатывать и запускать dbt-команды из предпочитаемых сред разработки, таких как VS Code, Sublime Text или терминал. Эта гибкость особенно полезна в конфигурации dbt Mesh, где управление несколькими проектами может быть сложным. Разработчики могут работать в привычных инструментах, одновременно используя централизованные возможности dbt.
Доступность
Да, ваша учетная запись должна быть как минимум на версии dbt v1.6, чтобы вы могли воспользоваться межпроектными зависимостями — одной из самых важных базовых возможностей, необходимых для реализации dbt Mesh.
Хотя dbt Core определяет ряд базовых элементов для dbt Mesh, dbt предлагает расширенный пользовательский опыт, который использует эти элементы для масштабируемого взаимодействия между несколькими командами. Это достигается за счёт мультипроектного обнаружения в Catalog, настроенного в соответствии с уровнем доступа каждого пользователя.
Несколько ключевых компонентов, лежащих в основе паттерна dbt Mesh, включая контракты моделей, версии и модификаторы доступа, определены и реализованы в dbt Core. Мы считаем, что это элементы базового языка dbt, поэтому их реализации являются open source. Наша цель — определить стандартный паттерн, который аналитические инженеры по всему миру смогут использовать, расширять и помогать нам улучшать.
Для обращения к моделям, определённым в другом проекте, пользователи также могут использовать packages — давнюю функциональность dbt Core. При импорте апстрим‑проекта как пакета dbt загрузит все модели, определённые в этом проекте, что позволяет разрешать кросс‑проектные ссылки на эти модели. При необходимости доступ можно ограничить только моделями с уровнем доступа public.
Ключевое отличие связано с сервисом метаданных dbt, который является уникальной возможностью платформы dbt и позволяет разрешать ссылки только на публичные модели проекта. Этот сервис даёт пользователям возможность зависеть от апстрим‑проектов и ссылаться исключительно на их public‑модели, без необходимости загружать всю сложность этих апстрим‑проектов в локальную среду разработки.
Да, для настройки нескольких проектов и ссылки на модели между ними требуется тариф dbt уровня Enterprise. Подробнее о возможностях, доступных в разных тарифах dbt, см. в разделе model governance.
Советы по внедрению dbt Mesh
Обратитесь к нашему руководству для разработчиков How we structure our dbt Mesh projects. Также вам может быть интересно посмотреть запись этого доклада с Coalesce 2023: Unlocking model governance and multi-project deployments with dbt-meshify.
Вы также можете узнать, как внедрить dbt Mesh, следуя нашему Руководству по быстрому старту dbt Mesh.
dbt-meshify — это CLI-инструмент, который автоматизирует создание функций управления моделями и межпроектной родословной, введенных в dbt-core v1.5 и v1.6. Этот пакет будет использовать метаданные вашего проекта dbt для создания и/или редактирования файлов в вашем проекте, чтобы правильно настроить модели в вашем проекте с этими функциями.
Предположим, в вашей организации менее 500 моделей и менее дюжины регулярных участников dbt. Вы работаете на масштабе, который хорошо обслуживается монолитом (один проект), и более крупный шаблон dbt Mesh, вероятно, не принесет никаких немедленных преимуществ.
Никогда не рано думать о том, как вы организуете модели внутри этого проекта. Используйте группы моделей, чтобы определить четкие границы владения и частный доступ, чтобы ограничить использование моделей, созданных для определенной цели, от становления несущими блоками в несвязанной части DAG. Ваши будущие "я" будут благодарны вам за определение этих интерфейсов, особенно если вы достигнете масштаба, при котором имеет смысл "выпускать" интерфейсы между группами в границы между проектами.
