本文介绍 Databricks 应用背后的核心概念，包括如何构建应用、如何管理依赖项和状态、权限的工作原理以及应用如何与平台资源交互。 了解这些概念有助于在工作区中开发、部署和管理应用。
App
Databricks 应用是在 Azure Databricks 无服务器平台上作为容器化服务运行的 Web 应用程序。 开发人员使用受支持的框架（如 Streamlit、Dash 或 Gradio）构建在 Azure Databricks 工作区中提供交互式数据或 AI 体验的应用。
每个应用都包含其自己的配置、标识和独立运行时环境。 由于应用属于特定工作区，因此他们可以访问工作区级资源，例如 SQL 仓库和帐户级资源（如 Unity 目录）。 开发人员还可以选择与工作区外部的用户共享应用，但在同一 Azure Databricks 帐户中。
尽管应用容器在 Azure Databricks 无服务器基础结构上运行，但应用本身可以连接到无服务器和非无服务器资源。 从概念上讲，应用充当控制平面服务，用于托管 Web UI 并访问可用的 Azure Databricks 数据平面服务。 有关详细信息，请参阅 Databricks 体系结构概述。
若要启动和管理应用，请转到工作区 UI 中的 “应用” 部分。
应用程序 URL
创建该应用时，Databricks 会自动为每个应用分配唯一 URL。 此 URL 遵循以下格式：
https://<app-name>-<workspace-id>.<region>.databricksapps.com
Where:
-
<app-name>是创建应用时提供的名称 -
<workspace-id>是工作区的唯一标识符 -
<region>是工作区所在的云区域
创建应用后，无法更改 URL。 如果需要其他 URL，请创建具有不同名称的新应用。
Template
应用模板是一个预生成的基架，可帮助开发人员使用受支持的框架快速构建应用。 每个模板都包含基本文件结构、 app.yaml 清单、 requirements.txt Python 应用文件以及示例源代码。
该文件 app.yaml 定义用于运行应用的命令（例如， streamlit run <app-name> 对于 Streamlit 应用），设置本地环境变量，并声明任何所需的资源。
- 使用
requirements.txt列出需要与pip一起安装的其他 Python 包。 - 使用
package.json列出要使用npm安装的 Node.js 包。
这些文件补充了默认系统环境和预安装的包。 有关详细信息，请参阅 Databricks Apps 系统环境。
开发人员可以使用 Azure Databricks UI 或 CLI 从模板生成新应用。
系统环境和包
Databricks Apps 在由 Azure Databricks 管理的预配置系统环境中运行。 有关详细信息，请参阅 Databricks Apps 系统环境。
每个应用都有自己的独立环境，以防止依赖项冲突。 若要确保一致性，请在应用的相应文件中定义所需的包及其版本：
- 对于 Python，请使用
requirements.txt。 - 对于 Node.js，请使用
package.json。
对于混合部署，您可能会同时拥有这两个文件。
在部署期间，Azure Databricks 将这些依赖项安装到应用的隔离运行时环境中。 如果包含已安装的包，则指定的版本将替代默认值。
有关更多详细信息，请参阅 管理 Databricks 应用的依赖项 。
应用资源
应用资源是应用依赖的 Azure Databricks 服务，例如 SQL 仓库、模型服务端点、任务、密钥或存储卷。 在databricks.yml清单中使用resources字段声明这些依赖项。 Azure Databricks 支持以下资源类型：
- SQL 仓库
- Job
- 模型服务终结点
- 精灵空间
- Secret
- Volume
要访问尚未具有受支持资源类型的 Azure Databricks 服务，请使用 Unity Catalog 管理的机密安全地注入凭据。 请参阅机密管理。
配置应用资源分为两个阶段：
-
声明（开发） - 声明（开发）- 在
databricks.yml清单中声明每个所需资源。 这定义了应用需要的资源以及它所需的权限。 - 配置（部署） - 在部署期间，使用 Databricks Apps UI 使用实际特定于工作区的实例（例如，选择特定的 SQL 仓库）来配置声明的资源。
声明和配置之间的这种分离允许应用跨环境移植。 例如，可以在开发工作区中部署相同的应用代码，并将其链接到一个 SQL 仓库。 在生产环境中，可以重复使用代码并配置其他仓库，而无需更改代码。 若要支持此功能，请避免在应用中硬编码资源 ID 或特定于环境的值。
Azure Databricks 强制实施最低特权访问。 应用必须使用现有资源，并且无法创建新资源。 在部署期间，工作区管理员查看和批准应用请求的资源访问权限。 应用的服务主体会收到必要的权限，应用开发人员必须具有授予这些权限的权限。
若要了解详细信息，请参阅 向 Databricks 应用添加资源。
应用状态
应用可以具有以下状态之一： 正在运行、 停止、 部署或 崩溃。
- 正在运行 - 应用处于活动状态且可访问。 Azure Databricks 对应用运行时使用的计算资源计费。
- 已停止 - 应用不可访问，不会产生任何费用。 Azure Databricks 会保留应用的配置和环境，因此无需重新配置即可重启它。
- 部署 - 应用正在启动。 它尚不可访问，在此阶段不会产生任何费用。
- 崩溃 - 应用无法意外启动或停止。 无法访问，不会产生费用。 在解决问题后，可以查看日志以排查并重启应用。
应用状态
应用状态包括应用需要跨用户会话或交互保留的任何数据或上下文。 重启后，应用不会保留内存中状态。 当应用关闭时，内存中保存的任何数据都将丢失。
可以通过以下方式存储状态：
- 在单个会话中内存存储临时数据。 应用重启时，此数据会丢失。
- 应用执行期间临时文件的本地文件系统。 应用重启时，此数据会丢失。
- 使用 Databricks SQL 生成用于持久化结构化数据和分析工作负载的 Azure Databricks 表。
- 持久非结构化数据的工作区文件。
- 用于持久性非结构化数据的 Unity Catalog 卷，并由 Unity Catalog 治理。
- 用于持久存储关系数据，并兼容 PostgreSQL 的 Lakebase 数据库实例。
常见用例包括缓存查询结果、保存用户首选项或跨会话记录用户作。
应用身份验证和授权
Databricks 应用使用 OAuth 2.0 进行身份验证和访问控制。 每个应用都有两个互补标识，用于确定它如何对 Azure Databricks 资源进行身份验证和授权： 应用授权 和 用户授权。
应用授权 - Azure Databricks 会自动为每个应用创建服务主体。 此服务主体充当应用的标识，并由应用开发人员授予权限。 应用的所有用户共享此标识，并有权访问同一组权限。 此模型适用于不依赖于单个用户上下文的操作，例如日志记录或系统级操作。
用户授权 - 此模型使用应用用户的标识对访问权限进行身份验证和授权。 用户必须属于部署应用的 Azure Databricks 帐户。 通过单一登录（SSO）登录后，应用可以使用用户的凭据访问受管理的资源，例如 SQL 仓库。 这样，应用就可以尊重 Unity 目录管理的细化权限，而无需向应用的服务主体授予这些权限。
应用在其清单中请求特定的 OAuth 范围，以控制他们可以访问的 API 和资源。 此灵活模型支持企业级安全性，并支持精细的访问控制。
有关详细信息，请参阅 在 Databricks 应用中配置授权。
应用用户
部署后，应用开发人员可以通过向应用实例授予 CAN_USE 或 CAN_MANAGE 权限，与用户或组共享应用。 用户不需要属于同一工作区，但它们必须是同一 Azure Databricks 帐户的一部分。 若要与外部用户共享，请先使用标识提供者将其同步到帐户中。 如需了解更多信息，请参阅 使用 SCIM 从 Microsoft Entra ID 同步用户与组。
还可以使用 CI/CD 管道和基础结构即代码在开发、暂存和生产环境中分发同一应用程序。 集中式应用 UI 可帮助用户发现和启动他们有权使用的应用。