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

Настройка вашего dbt проекта с Databricks

Назад к гайдам
Databricks
dbt Core
dbt platform
Intermediate
Menu

    Введение​

    Databricks и dbt Labs сотрудничают, чтобы помочь командам по работе с данными мыслить как команды разработчиков программного обеспечения и быстрее предоставлять надежные данные. Адаптер dbt-databricks позволяет пользователям dbt использовать последние функции Databricks в своем dbt проекте. Сотни клиентов уже используют dbt и Databricks для создания выразительных и надежных конвейеров данных на Lakehouse, создавая активы данных, которые позволяют использовать аналитику, ML и AI в бизнесе.

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

    Настройка окружений Databricks​

    Для начала мы будем использовать Unity Catalog в Databricks. Без него мы не смогли бы спроектировать отдельные окружения для разработки и продакшена в соответствии с нашими лучшими практиками. Кроме того, он позволяет нам с помощью SQL убедиться, что применены корректные настройки контроля доступа. Для работы с ним вам потребуется использовать адаптер dbt-databricks (а не dbt-spark).

    Мы создадим два разных каталога в Unity Catalog: dev и prod. Каталог — это контейнер верхнего уровня для схем (ранее известных как базы данных в Databricks), которые, в свою очередь, содержат таблицы и представления.

    Наш dev catalog будет средой разработки, с которой аналитические инженеры взаимодействуют через свой Studio IDE. У разработчиков должна быть собственная песочница для создания и тестирования объектов без риска перезаписать или удалить работу коллег; для этого мы рекомендуем создавать персональные схемы. С точки зрения прав доступа, у них должен быть доступ только к каталогу dev.

    Только производственные запуски будут иметь доступ к данным в каталоге prod. В будущем руководстве мы обсудим каталог test, где наша система непрерывной интеграции/непрерывного развертывания (CI/CD) сможет запускать dbt test.

    На данный момент давайте упростим задачу и создадим два каталога — либо с помощью Data Catalog, либо в SQL‑редакторе, используя следующие команды:

    create catalog if not exists dev;
    create catalog if not exists prod;

    Пока вашему разработчику предоставлен доступ на запись в каталог данных dev, нет необходимости заранее создавать песочницы-схемы.

    Настройка сервисных принципалов​

    Когда аналитический инженер запускает проект dbt из своего Studio IDE, совершенно нормально, что итоговые запросы выполняются от имени этого пользователя. Однако для продакшен‑запусков мы хотим, чтобы выполнение происходило от имени service principal. Напомним, что service principal — это безличная учётная запись, не принадлежащая конкретному человеку.

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

    Давайте создадим сервисный принципал в Databricks:

    1. Попросите администратора вашего аккаунта Databricks добавить сервисный принципал в ваш аккаунт. Имя сервисного принципала должно отличаться от идентификатора пользователя и четко указывать на его назначение (например, dbt_prod_sp).
    2. Добавьте сервисный принципал в любые группы, членом которых он должен быть на данный момент. Более подробная информация о разрешениях содержится в нашем руководстве "Лучшие практики Unity Catalog".
    3. Добавьте сервисный принципал в ваше рабочее пространство и примените все необходимые права, такие как доступ к Databricks SQL и доступ к рабочему пространству.

    Настройка вычислительных ресурсов Databricks​

    Когда вы запускаете проект dbt, он генерирует SQL, который может выполняться на All Purpose Clusters или SQL warehouses. Мы настоятельно рекомендуем запускать SQL, сгенерированный dbt, в Databricks SQL warehouse. Поскольку SQL warehouses оптимизированы для выполнения SQL‑запросов, вы можете снизить затраты за счёт меньшего времени работы, необходимого для выполнения запросов. Кроме того, при отладке у вас будет доступ к Query Profile.

    Мы рекомендуем использовать serverless‑кластер, если вы хотите минимизировать время, затрачиваемое на запуск кластера, и избавиться от необходимости менять размеры кластера в зависимости от рабочих процессов. Если вы используете Databricks serverless SQL warehouse, вам всё равно необходимо выбрать размер кластера (например, 2X-Small, X-Small, Small, Medium, Large). Подробнее о serverless SQL warehouses см. в документации Databricks.

    Давайте создадим SQL склад Databricks:

    1. Нажмите SQL Warehouses в боковой панели.
    2. Нажмите Create SQL Warehouse.
    3. Введите имя для warehouse.
    4. Если вы используете serverless SQL warehouse, выберите размер кластера (от 2X-Small до 4X-Large) или оставьте значение по умолчанию, убедившись, что оно подходит для вашей нагрузки.
    5. Примите настройки warehouse по умолчанию или измените их при необходимости.
    6. Нажмите Create.
    7. Настройте права доступа к warehouse, чтобы наш service principal и разработчик имели необходимый уровень доступа.

    В этом материале мы не рассматриваем Python, но если вы хотите узнать больше, ознакомьтесь с этой документацией. В зависимости от вашей нагрузки, вы можете создать более крупный SQL Warehouse для production‑процессов и использовать меньший SQL Warehouse для разработки (если вы не используете Serverless SQL Warehouses). По мере роста проекта вам также может понадобиться применять настройки compute на уровне отдельных моделей.

    Настройка вашего dbt проекта​

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

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

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

    Подключение dbt к Databricks​

    Сначала вам нужно подключить проект dbt к Databricks, чтобы он мог отправлять инструкции по трансформации и создавать объекты в Unity Catalog. Следуйте инструкциям для dbt или Core, чтобы настроить учетные данные для подключения вашего проекта.

    Каждый разработчик должен сгенерировать свой Databricks PAT и использовать этот токен в своих учетных данных для разработки. Также необходимо указать уникальную схему разработчика, в которой будут храниться таблицы и представления, создаваемые запусками dbt, выполненными из их Studio IDE. Это обеспечивает изолированные среды для разработчиков и гарантирует, что доступ к данным соответствует назначению.

    Давайте сгенерируем персональный токен доступа Databricks (PAT) для разработки:

    1. В Databricks нажмите на ваше имя пользователя в верхней панели и выберите User Settings в выпадающем меню.
    2. На вкладке Access token нажмите Generate new token.
    3. Нажмите Generate.
    4. Скопируйте отображаемый токен и нажмите Done. (не потеряйте его!)

    Для ваших учетных данных разработки/profiles.yml:

    1. Установите ваш каталог по умолчанию на dev.
    2. Ваша схема разработчика должна быть названа в честь вас. Мы рекомендуем dbt_<первая_буква_имени><фамилия>.

    Во время первого вызова dbt run, dbt создаст схему разработчика, если она еще не существует в каталоге dev.

    Определение среды развертывания dbt​

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

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

    В core‑проектах можно использовать targets в profiles для разделения окружений. Окружения dbt позволяют определять окружения через UI и планировать задания для конкретных окружений.

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

    2. Теперь давайте вернемся к dbt Cloud, чтобы заполнить поля окружения. Нажмите на окружения в интерфейсе dbt Cloud или определите новую цель в вашем profiles.yml.

    3. Установите каталог производственной среды на prod каталог, созданный выше. Предоставьте сервисный токен для вашего prod сервисного принципала и установите его как токен в учетных данных развертывания вашей производственной среды.

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

    5. Предоставьте токен вашего сервисного принципала.

    6. Следуйте инструкциям Databricks, чтобы настроить токен вашего service principal. Обратите внимание, что параметр lifetime_seconds определяет, как долго этот учетный данные будут оставаться действительными. Рекомендуется указать большое значение, чтобы избежать частой регенерации токенов и сбоев production‑задач.

    7. Теперь вернитесь в dbt, чтобы заполнить поля окружения. Нажмите environments в UI dbt или определите новый target в вашем profiles.yml.

    8. Установите для production‑окружения значение catalog равным каталогу prod, созданному выше. Укажите service token для вашего prod service principal и задайте его в качестве token в deployment credentials вашего production‑окружения.

    9. Установите schema в значение по умолчанию для вашего prod‑окружения. При необходимости это можно переопределить с помощью custom schemas, если вам нужно использовать более одной схемы.

    10. Укажите токен вашего Service Principal.

    Далее вам понадобится место для хранения и контроля версий вашего кода, которое позволит вам сотрудничать с коллегами. Подключите ваш dbt проект к git репозиторию с помощью dbt Cloud. Core проекты будут использовать git CLI.

    Далее вам понадобится место для хранения кода и управления его версиями, которое также позволит вам совместно работать с коллегами. Подключите свой проект dbt к git-репозиторию с помощью dbt. Проекты Core будут использовать git CLI.

    Теперь, когда ваш проект настроен, вы можете начать трансформировать ваши данные в Databricks с помощью dbt. Чтобы помочь вам масштабироваться эффективно, мы рекомендуем следовать нашим лучшим практикам, начиная с лучших практик Unity Catalog, затем вы можете оптимизировать модели dbt на Databricks.

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

    0