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

Перевод вашего проекта dbt Databricks в продакшн

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

    Введение​

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

    Предварительные требования​

    Если у вас нет каких-либо из следующих требований, обратитесь к инструкциям в Настройка вашего проекта dbt с Databricks для помощи в их выполнении:

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

    Среды развертывания​

    В программной инженерии среды играют ключевую роль, позволяя инженерам разрабатывать и тестировать код, не влияя на конечных пользователей их программного обеспечения. Аналогично, вы можете проектировать data lakehouses с отдельными средами. Продакшн среда включает в себя отношения (схемы, таблицы и представления), которые запрашивают или используют конечные пользователи, обычно в BI инструменте или модели ML.

    В dbt окружения бывают двух типов:

    • Deployment — определяет настройки, используемые для выполнения заданий (jobs), созданных в рамках этого окружения.
    • Development — определяет настройки, используемые в Studio IDE для конкретного проекта dbt.

    Каждый проект dbt может иметь несколько deployment-окружений, но только одно development-окружение на пользователя.

    Создание и планирование продакшн задачи​

    С вашей настроенной средой развертывания пришло время создать продакшн задачу для выполнения в вашей prod среде.

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

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

    Давайте создадим задание в dbt, которое будет выполнять трансформацию данных в нашем каталоге Databricks prod.

    1. Создайте новую задачу, нажав Deploy в заголовке, затем Jobs и Create job.

    2. Назовите задачу “Ежедневное обновление”.

    3. Установите Environment на вашу production среду.

    4. В разделе Execution Settings

      • Установите флажок Generate docs on run, чтобы настроить задачу на автоматическую генерацию документации проекта каждый раз, когда эта задача выполняется. Это обеспечит актуальность вашей документации по мере добавления и изменения моделей.
      • Выберите флажок Run on source freshness, чтобы настроить dbt source freshness как первый шаг этой задачи. Ваши источники должны быть настроены на снимок информации о свежести, чтобы это давало значимые инсайты.

      Добавьте следующие три Commands:

      • dbt source freshness
        • Это проверит, не устарели ли какие-либо источники. Мы не хотим пересчитывать модели с данными, которые не изменились с момента нашего последнего запуска.
      • dbt test --models source:*
        • Это проверит качество данных наших исходных данных, например, убедится, что поля ID уникальны и не пусты. Мы не хотим, чтобы плохие данные попадали в продакшн модели.
      • dbt build --exclude source:* --fail-fast
    • dbt build более эффективен, чем запуск отдельных команд dbt run и dbt test, потому что он сначала выполняет модель, а затем сразу тестирует её, прежде чем переходить к следующей.
    • Мы исключаем source-данные, потому что уже протестировали их на шаге 2.
    • Флаг fail-fast заставляет dbt немедленно завершить работу, если хотя бы один ресурс не смог собраться. Если в момент сбоя первой модели другие модели ещё выполняются, dbt завершит подключения для этих всё ещё выполняющихся моделей.
    1. В разделе Triggers с помощью переключателя настройте ваш job на запуск по расписанию. Вы можете указать конкретные дни и время либо создать собственное cron-расписание.
      • Если вы хотите, чтобы ваш job в dbt запускался другим оркестратором, например Databricks Workflows, см. раздел Advanced Considerations ниже.

    Это всего лишь один пример списка команд "все или ничего", предназначенного для минимизации потерь вычислительных ресурсов. Список команд задач и селекторы предоставляют большую гибкость в том, как будет выполняться ваш DAG. Вы можете захотеть спроектировать свой так, чтобы продолжать выполнение определенных моделей, если другие не удаются. Вы можете захотеть настроить несколько задач для обновления моделей с разной частотой. См. наш Job Creation Best Practices discourse для получения дополнительных предложений по проектированию задач.

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

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

    Добавление задачи CI​

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

    Ниже описаны шаги по созданию CI‑теста для вашего dbt‑проекта. CD в dbt не требует дополнительных шагов, так как ваши jobs автоматически подхватывают последние изменения из ветки, назначенной среде, в которой выполняется job. В зависимости от вашей стратегии развертывания вы можете добавить дополнительные шаги. Если вы хотите глубже разобраться в вариантах CD, ознакомьтесь с этой статьей в блоге о внедрении CI/CD с помощью dbt.

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

    1. Ежедневные запуски: Регулярное выполнение тестов на вашем конвейере данных помогает выявлять проблемы, вызванные плохими исходными данными, обеспечивая качество данных, которые достигают ваших пользователей.
    2. Разработка: Выполнение тестов во время разработки гарантирует, что изменения в вашем коде не нарушают существующие предположения, позволяя разработчикам быстрее итеративно работать, выявляя проблемы сразу после написания кода.
    3. Проверки CI: Автоматизированные задачи CI выполняют и тестируют ваш конвейер от начала до конца, когда создается запрос на слияние, обеспечивая уверенность разработчикам, рецензентам кода и конечным пользователям, что предлагаемые изменения надежны и не вызовут сбоев или проблем с качеством данных.

    Ваша задача CI будет гарантировать, что модели правильно строятся и проходят любые примененные к ним тесты. Мы рекомендуем создать отдельную тестовую среду и иметь выделенный сервисный принципал. Это обеспечит, что временные схемы, создаваемые во время тестов CI, находятся в своем собственном каталоге и не могут случайно раскрыть данные другим пользователям. Повторите шаги в Настройка вашего проекта dbt с Databricks для создания вашей prod среды, чтобы создать тестовую среду. После настройки у вас должно быть:

    • Каталог с именем test
    • Сервисный принципал с именем dbt_test_sp
    • Новая среда dbt с именем test, которая по умолчанию использует каталог test и применяет токен dbt_test_sp в учетных данных деплоя

    Мы рекомендуем настроить CI‑задачу в dbt. Это позволит сократить время выполнения задач за счет запуска и тестирования только изменённых моделей, а также снизить вычислительные затраты в lakehouse. Подробные инструкции по созданию CI‑задачи см. в разделе Set up CI jobs.

    С тестами dbt и SlimCI вы можете быть уверены, что ваши данные в продакшене будут своевременными и точными, даже при высокой скорости доставки.

    Мониторинг ваших задач​

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

    Дашборд run history в dbt предоставляет детальный обзор всех запусков заданий вашего проекта, а также различные фильтры, которые помогают сосредоточиться на нужных аспектах. Это отличный инструмент для разработчиков, которые хотят проверить последние запуски, убедиться в корректности ночных выполнений или отследить прогресс текущих заданий. Чтобы открыть его, выберите Run History в меню Deploy.

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

    Монитор развертывания показывает статус задач с течением времени в разных средахМонитор развертывания показывает статус задач с течением времени в разных средах

    Добавляя data health tiles в ваши BI-дашборды, вы даёте стейкхолдерам наглядное представление о состоянии вашего data pipeline, не заставляя их покидать привычный интерфейс. Data tiles повышают доверие к данным и помогают избежать лишних вопросов или необходимости переключаться между инструментами. Чтобы реализовать status tiles на дашбордах, у вас должна быть настроена документация dbt с определёнными exposures.

    Настройка уведомлений​

    Настройка уведомлений в dbt позволяет получать оповещения по электронной почте или в Slack‑канал каждый раз, когда выполнение задания завершается. Это гарантирует, что соответствующие команды будут уведомлены и смогут оперативно отреагировать в случае сбоя или отмены задания. Чтобы настроить уведомления:

    1. Перейдите в настройки проекта dbt.
    2. Выберите вкладку Notifications.
    3. Выберите нужный тип уведомлений (Email или Slack) и настройте соответствующие параметры.

    Если вам требуются уведомления через другие каналы, помимо электронной почты или Slack, вы можете использовать функцию исходящих webhooks в dbt для передачи событий заданий в другие инструменты. Webhooks позволяют интегрировать dbt с широким спектром SaaS‑приложений, расширяя автоматизацию вашего пайплайна на другие системы.

    Устранение неполадок​

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

    Пять ключевых шагов для устранения проблем с dbt:

    1. Прочитайте сообщение об ошибке: сообщения об ошибках dbt обычно указывают тип ошибки и файл, в котором она произошла.
    2. Проверьте проблемный файл и поищите очевидное решение.
    3. Изолируйте проблему, запуская по одной модели в Studio IDE или откатывая код, который вызвал ошибку.
    4. Проверьте наличие проблем в скомпилированных файлах и логах.

    Обратитесь к документации по отладке ошибок для получения полного списка типов ошибок и методов диагностики.

    Чтобы устранить проблемы с заданием dbt, перейдите на вкладку Deploy > Run History в вашем проекте dbt и выберите неудачный запуск. Затем разверните шаги выполнения, чтобы просмотреть console и debug логи и изучить подробные сообщения журнала. Чтобы получить дополнительную информацию, откройте вкладку Artifacts и скачайте скомпилированные файлы, связанные с этим запуском.

    Если ваши задачи занимают больше времени, чем ожидалось, используйте панель времени выполнения модели для выявления узких мест в вашем конвейере. Анализ времени, затраченного на выполнение каждой модели, помогает вам определить самые медленные компоненты и оптимизировать их для повышения производительности. История запросов Databricks Query History позволяет вам изучать детальные сведения, такие как время, затраченное на каждую задачу, возвращенные строки, производительность ввода-вывода и план выполнения.

    Для получения дополнительной информации о настройке производительности ознакомьтесь с нашим руководством по Как оптимизировать и устранять неполадки моделей dbt на Databricks.

    Продвинутые соображения​

    По мере того как вы будете набираться опыта работы с dbt и Databricks, вам может понадобиться изучить более продвинутые техники, которые помогут дополнительно улучшить ваш data pipeline и оптимизировать управление преобразованиями данных. Темы в этом разделе не являются обязательными, но они помогут укрепить production‑окружение, повысив уровень безопасности, эффективности и доступности.

    Обновление ваших данных с помощью Databricks Workflows​

    Планировщик заданий dbt предлагает несколько способов запуска ваших заданий. Если преобразования dbt — это лишь один из шагов в более крупном оркестрационном workflow, используйте API dbt, чтобы запускать ваше задание из Databricks Workflows.

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

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

    Добавление заданий dbt в Databricks Workflows позволяет выстраивать цепочки внешних задач, при этом продолжая использовать следующие преимущества dbt:

    • Контекст UI: UI dbt позволяет определять задания в контексте ваших окружений dbt, что упрощает создание и управление соответствующими конфигурациями.
    • Логи и история запусков: Доступ к логам и истории запусков становится более удобным при использовании dbt.
    • Возможности мониторинга и уведомлений: dbt оснащён функциями мониторинга и уведомлений, подобными описанным выше, которые помогают оставаться в курсе статуса и производительности ваших заданий.

    Чтобы запускать задания dbt из Databricks, следуйте инструкциям в нашем руководстве Databricks Workflows to run dbt jobs guide.

    Маскирование данных​

    В нашем руководстве Best Practices for dbt and Unity Catalog рекомендуется использовать отдельные каталоги dev и prod для сред разработки и развертывания, при этом Unity Catalog и dbt берут на себя управление конфигурациями и правами доступа для изоляции окружений. Обеспечение безопасности при сохранении эффективности в средах разработки и развертывания имеет решающее значение. Для защиты чувствительных данных, таких как персональные данные (PII), могут потребоваться дополнительные меры безопасности.

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

    Чтобы реализовать маскирование данных в модели dbt, убедитесь, что конфигурация материализации модели установлена на представление. Затем добавьте оператор case, используя функцию is_account_group_member для идентификации групп, которым разрешено просматривать значения в открытом виде. Затем используйте regex для маскирования данных для всех остальных пользователей. Например:

    CASE
    WHEN is_account_group_member('auditors') THEN email
    ELSE regexp_extract(email, '^.*@(.*)$', 1)
    END

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

    Использование одних и тех же источников для сред разработки и развертывания позволяет тестировать с теми же объемами и частотой, которые вы увидите в продакшене. Однако это может привести к тому, что запуски разработки будут занимать больше времени, чем необходимо. Чтобы решить эту проблему, рассмотрите возможность использования переменной Jinja target.name для ограничения данных при работе в среде разработки.

    Сочетание dbt Docs и Unity Catalog​

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

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

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

    Чтобы получить максимальную отдачу от обоих инструментов, вы можете использовать persist docs config для передачи описаний таблиц и столбцов, написанных в dbt, в Unity Catalog, делая информацию легко доступной для пользователей обоих инструментов. Сохранение описаний в dbt гарантирует, что они находятся под контролем версий и могут быть воспроизведены после удаления таблицы.

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

    0