此页面列出了开发和运行 Databricks Apps 的重要最佳做法。 这些准则侧重于安全、性能和平台要求。
一般最佳实践
使用 Azure Databricks 本机功能进行数据处理。 应用计算已针对 UI 呈现进行优化。 将 Databricks SQL 用于查询和数据集，使用 Lakeflow 作业进行批处理，将模型服务用于 AI 推理工作负载。 将大量数据处理卸载到这些服务，以避免性能问题。 在预期的负载条件下测试应用，以验证它是否符合你的要求。
实现正常关闭处理。 应用在收到
SIGTERM信号后必须在 15 秒内关闭，否则将会被SIGKILL强行终止。避免特权操作。 应用以非特权用户身份运行，无法执行需要更高权限的操作，例如根访问权限。 不能使用包管理器（例如
apt-get，yum或apk）安装系统级包。 请改用 PyPI 中的 Python 包，或者从 npm 使用 Node.js 包来管理应用依赖项。了解平台托管的网络。 请求通过反向代理转发，因此应用不能依赖于请求的来源。 Azure Databricks 处理 TLS 终止，并要求应用支持 HTTP/2 明文（H2C）。 不要实现自定义 TLS 处理。
绑定到正确的主机和端口。 应用必须侦听
0.0.0.0并使用环境变量中指定的DATABRICKS_APP_PORT端口。 有关详细信息，请参阅 环境变量 。最小化容器启动时间。 保持初始化逻辑轻量级，以减少冷启动延迟。 避免在启动期间阻止大型依赖项安装或外部 API 调用等作。 仅在需要时加载大量资源。
登录到 stdout 和 stderr。 Azure Databricks 捕获来自标准输出和错误流的日志。 将这些日志用于所有日志记录，以确保日志在 Azure Databricks UI 中可见。 避免将日志写入本地文件。
正常处理意外错误。 实现全局异常处理，以防止未捕获的错误导致崩溃。 返回正确的 HTTP 错误响应，而不公开堆栈跟踪或敏感数据。
固定依赖项版本。 使用
requirements.txt文件中的确切版本号来确保跨生成环境一致。 避免使用未固定或最新版本的包。验证并清理用户输入。 始终验证传入数据并对其进行清理，以防止注入攻击或格式不正确的输入，即使在面向内部的应用中也是如此。
使用内存缓存来处理消耗资源的操作。 缓存常用数据（如查询结果或 API 响应）以减少延迟并避免冗余处理。 在多用户应用中使用
functools.lru_cache、cachetools或类似库，并仔细管理缓存的范围。为长时间运行的操作使用异步请求模式。 避免同步等待的请求，因为这可能会导致超时。相反，请发出初始请求以启动操作，然后定期查询资源状态或终结点以检查其完成状态。
安全最佳做法
遵循最低特权原则。 仅授予每个用户或组所需的权限。 使用
CAN USE而不是CAN MANAGE，除非需要完全控制。 请参阅 有关权限的最佳做法。仔细选择身份验证方法。 当访问资源和数据时，对应用的所有用户都使用相同的服务主体。 仅当应用必须尊重调用用户的权限时，才在具有受信任应用作者和对等评审的应用代码的工作区中实现用户身份验证。
为每个应用使用专用服务主体。 不要跨应用或用户共享服务主体凭据。 仅授予所需的最低权限，例如
CAN USE或CAN QUERY。 当应用创建者离开组织时轮换服务主体凭据。 请参阅 “管理应用对资源的访问权限”。隔离应用环境。 使用不同的工作区来分隔开发、过渡和生产应用。 这可以防止在开发和测试期间意外访问生产数据。
通过适当的计算访问数据。 不要将应用配置为直接访问或处理数据。 使用 SQL 仓库进行查询、用于 AI 推理的模型服务，以及用于批处理的 Lakeflow 作业。
管理机密。 切勿在环境变量中公开原始机密值。 在
valueFrom应用配置中使用并定期轮换机密，尤其是在团队角色更改时。 请参阅 最佳做法。最小化范围并记录用户操作。 当使用用户授权时，仅请求应用程序所需的权限范围，并使用结构化的审核记录记录所有用户操作。 请参阅 用户授权的最佳做法。
限制出站网络访问。 仅允许应用所需的域，例如包存储库和外部 API。 使用干运行模式和拒绝日志验证配置。 请参阅 配置网络策略的最佳做法。
遵循安全编码做法。 参数化 SQL 查询以防止注入攻击，并应用常规安全开发准则，例如输入验证和错误处理。 请参阅 语句执行 API：在仓库上运行 SQL。
监视可疑活动。 定期查看审计日志，以了解异常访问模式或未经授权的操作。 为关键安全事件设置警报。