Основные понятия в Приложениях Databricks

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

App

Приложение Databricks — это веб-приложение, которое выполняется как контейнерная служба на бессерверной платформе Azure Databricks. Разработчики используют поддерживаемые платформы, такие как Streamlit, Dash или Gradio, для создания приложений, которые предоставляют интерактивные данные или возможности искусственного интеллекта в рабочей области Azure Databricks.

Каждое приложение включает собственную конфигурацию, удостоверение и изолированную среду выполнения. Так как приложения принадлежат определенной рабочей области, они могут получить доступ к ресурсам уровня рабочей области, таким как хранилища SQL и ресурсы уровня учетной записи, такие как каталог Unity. Разработчики также могут совместно использовать приложения с пользователями за пределами рабочей области, но в той же учетной записи Azure Databricks.

Хотя контейнер приложений выполняется в бессерверной инфраструктуре Azure Databricks, само приложение может подключаться как к бессерверным, так и к бессерверным ресурсам. Концептуально приложение выступает в качестве службы плоскости управления, которая размещает веб-интерфейс и обращается к доступным службам плоскости данных Azure Databricks. Дополнительные сведения см. в обзоре архитектуры Databricks.

Чтобы запустить приложения и управлять ими, перейдите в раздел "Приложения " в пользовательском интерфейсе рабочей области.

URL-адрес приложения

Databricks автоматически назначает каждому приложению уникальный URL-адрес при создании. У этого URL-адреса должен быть такой формат:

https://<app-name>-<workspace-id>.<region>.databricksapps.com

Where:

• <app-name> — это имя, которое вы предоставляете при создании приложения.
• <workspace-id> — уникальный идентификатор рабочей области
• <region> — это облачный регион, в котором находится рабочая область.

Вы не можете изменить URL-адрес после создания приложения. Если вам нужен другой URL-адрес, создайте новое приложение с другим именем.

Template

Шаблон приложения — это предварительно созданный каркас, который помогает разработчикам быстро начинать разработку приложений с помощью поддерживаемого фреймворка. Каждый шаблон включает базовую структуру файлов, манифест, app.yamlrequirements.txt файл для приложений Python и пример исходного кода.

Файл app.yaml определяет команду для запуска приложения (например, streamlit run <app-name> для приложения Streamlit), настраивает переменные локальной среды и объявляет все необходимые ресурсы.

• Используйте requirements.txt для перечисления дополнительных пакетов Python, которые следует установить с помощью pip.
• Используйте package.json, чтобы перечислить пакеты Node.js для установки с помощью npm.

Эти файлы дополняют системную среду по умолчанию и предварительно установленные пакеты. Дополнительные сведения см. в системной среде Databricks Apps.

Разработчики могут создать новое приложение из шаблона с помощью пользовательского интерфейса Azure Databricks или CLI.

Системная среда и пакеты

Приложения Databricks выполняются в предварительно настроенной системной среде, управляемой Azure Databricks. Дополнительные сведения см. в системной среде Databricks Apps.

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

• Для Python используйте requirements.txt.
• Для Node.jsиспользуйте package.json.

Для гибридных развертываний, скорее всего, у вас будут оба файла.

Во время развертывания Azure Databricks устанавливает эти зависимости в изолированную среду выполнения приложения. Если вы включаете уже установленный пакет, указанная версия переопределяет значение по умолчанию.

Дополнительные сведения см. в разделе "Управление зависимостями" для приложения Databricks .

Ресурсы приложения

Ресурсы приложений — это собственные службы Azure Databricks, от которых зависит приложение, например от хранилищ SQL, конечных точек обслуживания моделей, заданий, секретов или томов. Вы объявляете эти зависимости в манифесте с помощью поля databricks.ymlresources. Azure Databricks поддерживает следующие типы ресурсов:

• Хранилище SQL
• Job
• Сервисная конечная точка модели
• Пространство Genie
• Secret
• Volume

Чтобы получить доступ к службам Azure Databricks, которые еще не имеют поддерживаемого типа ресурсов, используйте секрет, управляемый каталогом Unity, для безопасного внедрения учетных данных. Дополнительные сведения см. в разделе Управление секретами.

Существует два этапа настройки ресурсов приложения:

• Декларация (разработка) — объявите каждый требуемый ресурс в манифесте databricks.yml. Это определяет ресурсы, необходимые приложению, и какие разрешения он требует.
• Конфигурация (развертывание) — во время развертывания используйте пользовательский интерфейс Databricks Apps для настройки объявленных ресурсов с фактическими экземплярами рабочей области (например, выбором определенного хранилища SQL).

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

Azure Databricks применяет доступ с минимальными привилегиями. Приложения должны использовать существующие ресурсы и не могут создавать новые. Во время развертывания администраторы рабочей области просматривают и утверждают запрошенный доступ к ресурсам приложения. Субъект-служба приложения получает необходимые разрешения, а разработчик приложения должен иметь разрешение на предоставление им.

Дополнительные сведения см. в статье "Добавление ресурсов в приложение Databricks".

Состояние приложения

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

• Запущено — приложение активно и доступно. Azure Databricks выставляет счета за вычислительные ресурсы, используемые во время работы приложения.
• Остановлено . Приложение недоступно и не несет никаких затрат. Azure Databricks сохраняет конфигурацию и среду приложения, чтобы ее можно было перезапустить без перенастройки.
• Развертывание — приложение запускается. Он еще недоступен и не несет никаких расходов на этом этапе.
• Сбой . Не удалось запустить или остановить приложение неожиданно. Он недоступен и не несет расходов. Журналы можно просмотреть для устранения неполадок и перезапуска приложения после устранения проблемы.

Состояние приложения

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

Состояние можно хранить следующим образом:

• Хранилище в памяти для временных данных в одном сеансе. Эти данные теряются при перезапуске приложения.
• Локальная файловая система для временных файлов во время выполнения приложения. Эти данные теряются при перезапуске приложения.
• Таблицы Azure Databricks с использованием Databricks SQL для постоянных структурированных данных и аналитических рабочих нагрузок.
• Файлы рабочей области для постоянных неструктурированных данных.
• Тома каталога Unity для постоянного хранения неструктурированных данных под управлением Unity Catalog.

• Инстанции базы данных Lakebase для персистентного реляционного хранения данных с совместимостью с PostgreSQL.

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

Проверка подлинности и авторизация приложений

Databricks Apps использует OAuth 2.0 для проверки подлинности и управления доступом. Каждое приложение имеет два дополнительных удостоверения, определяющие способ проверки подлинности и авторизацию доступа к ресурсам Azure Databricks: авторизация приложений и авторизация пользователей.

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

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

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

Дополнительные сведения см. в разделе "Настройка авторизации" в приложении Databricks.

Пользователи приложений

После развертывания разработчики приложений могут делиться приложением с пользователями или группами, предоставив разрешение CAN_USE или CAN_MANAGE на экземпляр приложения. Пользователям не нужно принадлежать к одной рабочей области, но они должны быть частью той же учетной записи Azure Databricks. Чтобы предоставить общий доступ внешним пользователям, сначала синхронизируйте их с учетной записью с помощью поставщика удостоверений. Дополнительные сведения см. в разделе Синхронизация пользователей и групп из идентификатора Microsoft Entra с помощью SCIM.

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