Лучшие практики для dbt и Unity Catalog
Ваш проект dbt для Databricks должен быть настроен после выполнения руководства по настройке вашего проекта dbt для Databricks. Теперь мы готовы начать строить проект dbt, используя Unity Catalog. Однако сначала следует рассмотреть, как мы хотим позволить пользователям dbt взаимодействовать с нашими различными каталогами. Мы рекомендуем следующие лучшие практики для обеспечения целостности ваших производственных данных:
Изолируйте ваши данные уровня Bronze (также известные как исходные данные)
Мы рекомендуем использовать Unity Catalog, так как он позволяет ссылаться на данные по всей вашей организации из любого другого каталога, устаревшего Hive метахранилища, внешнего метахранилища или выходных данных из Delta Live Table. Кроме того, Databricks предлагает возможность взаимодействовать с внешними данными и поддерживает федерацию запросов ко многим решениям баз данных. Это означает, что ваши среды разработки и производства будут иметь доступ к вашим исходным данным, даже если они определены в другом каталоге или внешнем источнике данных.
Сырые данные в вашем уровне Bronze должны быть определены как источники dbt и должны быть только для чтения для всех взаимодействий dbt как в разработке, так и в производстве. По умолчанию мы рекомендуем, чтобы все эти входные данные были доступны всем пользователям dbt во всех средах dbt. Это гарантирует, что преобразования во всех средах начинаются с одних и тех же входных данных, и результаты, наблюдаемые в разработке, будут воспроизведены, когда этот код будет развернут. Тем не менее, бывают случаи, когда требования к управлению данными вашей компании требуют использования нескольких рабочих пространств или каталогов данных в зависимости от среды.
Если у вас есть разные каталоги/схемы данных для ваших исходных данных в зависимости от вашей среды, вы можете использовать target.name для изменения каталога/схемы данных, из которых вы извлекаете данные, в зависимости от среды.
Если вы используете несколько рабочих пространств Databricks для изоляции разработки от производства, вы можете использовать переменные среды dbt Cloud в ваших строках конфигурации подключения, чтобы ссылаться на несколько рабочих пространств из одного проекта dbt Cloud. Вы также можете сделать то же самое для вашего SQL-склада, чтобы иметь разные размеры в зависим ости от ваших сред.
Для этого используйте синтаксис переменных среды dbt для имени хоста сервера вашего URL-адреса рабочего пространства Databricks и HTTP-пути для SQL-склада в ваших настройках подключения. Обратите внимание, что имя хоста сервера все еще должно выглядеть как действительное доменное имя, чтобы пройти проверку, поэтому вам нужно будет жестко закодировать суффикс домена в URL, например {{env_var('DBT_HOSTNAME')}}.cloud.databricks.com и префикс пути для ваших складов, например /sql/1.0/warehouses/{{env_var('DBT_HTTP_PATH')}}.
Использование синтаксиса переменных среды в конфигурациях подключенияКогда вы создаете среды в dbt Cloud, вы можете назнач ать переменные среды для динамического заполнения информации о подключении. Не забудьте убедиться, что токены, которые вы используете в учетных данных для этих сред, были сгенерированы из связанного рабочего пространства.
Определение значений переменных среды по умолчаниюКонтроль доступа
Для предоставления доступа потребителям данных используйте конфигурацию грантов dbt для применения разрешений к объектам базы данных, созданным моделями dbt. Это позволяет вам настраивать гранты как структурированный словарь, а не писать весь SQL самостоятельно, и позволяет dbt выбрать наиболее эффективный путь для применения этих грантов.
Что касается разрешений на запуск dbt и чтение источников данных, не предназначенных для потребителей, таблица ниже резюмирует модель доступа. Эффективно, все разработчики должны иметь не более чем доступ на чтение в каталоге prod и доступ на запись в каталоге dev. При использовании dbt создание схемы выполняется за вас; в отличие от традиционных рабочих процессов управления данными, вам не нужно вручную создавать какие-либо активы Unity Catalog, кроме верхнеуровневых каталогов.
Сервисный принципал prod должен иметь доступ на "чтение" к сырым исходным данным и доступ на "запись" в каталоге prod. Если вы добавите каталог test и связанную среду dbt, вы должны создать выделенный сервисный принципал. Сервисный принципал теста должен иметь чтение на сырые исходные данные и запись в каталоге test, но не иметь разрешений в каталогах prod или dev. Выделенная тестовая среда должна использоваться только для тестирования CI.
Гранты на уровне таблицы:
| Исходные данные | Каталог разработки | Каталог производства | Каталог тестирования | |
|---|---|---|---|---|
| разработчики | select | select & modify | select или none | none |
| сервисный принципал производства | select | none | select & modify | none |
| Сервисный принципал теста | select | none | none | select & modify |
Гранты на уровне схемы:
| Исходные данные | Каталог разработки | Каталог производства | Каталог тестирования | |
|---|---|---|---|---|
| разработчики | use | use, create schema, table, & view | use или none | none |
| сервисный принципал производства | use | none | use, create schema, table & view | none |
| Сервисный принципал теста | use | none | none | use, create schema, table & view |
Следующие шаги
Готовы начать преобразование ваших наборов данных Unity Catalog с помощью dbt?
Ознакомьтесь с ресурсами ниже для руководств, советов и лучших практик: