环境创建概述

概述

Conda 是一个开源的、与语言无关的软件包和环境管理器。Mamba 是 Conda 包管理器的开源重新实现。Code Workbook 已经转向使用 Mamba 来解决软件包依赖并将一组软件包安装到独立的环境中。与 Conda 相比，Mamba 在软件包解析方面提供了几个优势，尤其是在速度提升和错误消息的可读性方面。

本页介绍了最重要的概念并概述了环境创建过程；有关更多信息，请查阅官方 Conda 文档 ↗和Mamba 文档 ↗。

重要术语

• 软件包
• 频道
• 环境

软件包

软件包是通常包含元数据、库和/或二进制文件的文件集合。Code Workbook 提供了广泛的软件包（例如 numpy）以补充核心语言功能。

一个软件包是有版本的，几乎总是有一组依赖项——为了使其正常运行，还必须安装的其他软件包。依赖项可能是软件包的特定版本、可接受版本范围或任何版本。

频道

频道，有时称为存储库，是存储软件包的任何位置。一个频道可能是本地文件系统中的目录，另一个频道可能是托管在网络服务器上的目录。

无论类型如何，每个频道都是一个按平台架构分隔软件包的目录树。每个平台子目录都包含一个名为 repodata.json 的文件，这是该子目录中所有软件包的索引。

Conda 在需要获取软件包时会搜索一组预配置的频道。有关 Foundry 中频道管理的更多信息，请参阅代码存储库文档。

环境

Conda 环境是包含特定软件包集合的目录。通过将环境配置面板中指定的软件包传递给 Conda，为每个 Workbook 创建一个环境。Conda 构建一个满足配置和所有依赖项的软件包集，并将这些软件包安装到支持 Workbook 的 Spark 模块上。

性能

以下性能说明借鉴了这篇 Anaconda 博客文章 ↗，该文章详细讨论了 Conda 的性能，但同样适用于 Mamba 的实现。接下来的两节总结了这篇材料并概述了与 Code Workbook 最相关的性能因素：

• 创建环境
• 限制

创建环境

环境创建包括两个主要步骤：解决步骤和安装步骤。

解决步骤

在解决步骤中，指定的软件包管理器（Conda 或 Mamba）尝试找到满足所有瞬态依赖项的软件包和版本。瞬态依赖项包括环境配置面板中指定的软件包的依赖项，这些依赖项的依赖项，等等。此步骤包含四个阶段：

1. 下载和处理软件包索引。Conda 将从每个配置的频道下载相关的 repodata.json 文件，并将索引条目转换为内存中的对象。
2. 简化索引。Conda 构建一个可能用于环境的所有软件包集。为此，算法从提供的软件包规范开始，并递归遍历所有依赖项。所有不需要的软件包——主要是那些不在依赖图中的软件包——都会被修剪掉。
3. 将依赖项约束表达为布尔可满足性（SAT）问题。Conda 偏好某些类型的解决方案（例如，使用最新可能版本的软件包），这些偏好被内置到子句构造中。
4. 运行 SAT 求解器。

安装步骤

如果解决成功，则进行安装步骤。在这里，从适当的频道检索每个工件并使用它们来构建环境。此步骤包含三个阶段：

1. 下载并提取已解决环境中的所有软件包。
2. 验证软件包内容。根据配置，Conda 将使用校验和或验证文件大小是否正确。
3. 将软件包链接到环境中。

限制

上面概述的所有步骤在某些情况下可能容易出现缓慢。缓慢的原因通常分为三类：

• 上游更改
• 环境规范
• 软件包大小

上游更改

显著的缓慢部分是由 Foundry 外部的因素引起的。

• 下载和处理频道索引的规模与索引文件的总大小成比例；需要考虑的频道越多，这些频道的规模越大，这些步骤所需的时间就越长。
• 索引缩减也与瞬态依赖项的数量成比例；瞬态依赖项的数量由软件包选择声明的依赖项决定。

由于这些因素是外部和不透明的，因此很难对性能回归进行根本原因分析。环境可能会突然需要更长时间加载，因为某个频道最近增加了大小，或某个软件包在其最新版本中声明了几个新依赖项。

环境规范

更常见的是，缓慢初始化直接与环境规范本身相关联。解决步骤的规模与环境大小呈超线性关系，因此作为一般经验法则，包含更多软件包的环境初始化时间将呈不成比例地更长。

有两种方法可以缓解这些情况。

• 首先，从环境定义中移除不需要的软件包。拥有小型、专业的环境比拥有大型、通用的环境更高效。
• 其次，尝试在环境配置面板中为某些软件包添加版本约束。对于具有许多现有版本的软件包（如 python）和具有复杂依赖图的软件包（如 scipy）最有效。这样做将允许 Conda 更积极地缩减索引，这意味着 SAT 解决不需要考虑那么多软件包版本。

软件包大小

软件包大小通常比本节中的其他因素问题较少，但在某些情况下仍然相关。

下载和提取甚至单个软件包可能都不是小事。例如，pytorch 软件包大约有 460 MB 大小，提取可能需要 35 秒以上。

下载、提取和验证都随着环境中软件包的大小和数量线性扩展。由于瞬态依赖项，已解决环境通常包含比环境定义中明确指定的更多的软件包，软件包数量的增加可能会导致缓慢。

在这种情况下的补救措施与环境规范的建议类似：尝试保持环境尽可能小。

环境优化

本页的前几节描述了环境初始化过程和影响初始化性能的因素。以下图表总结了获取环境的标准过程：

为了减少在“等待资源”和“初始化环境”阶段花费的时间，Code Workbook 使用了一系列优化，旨在尽快获取环境。

解决步骤优化：规格文件

如果环境请求的软件包集没有更改，则无需再次解决环境，因为这样会导致相同的已解决环境。因此，Code Workbook 通过将成功解决的结果存储在规格文件中来避免环境初始化的解决步骤。下次需要初始化相同环境时，Code Workbook 会跳过解决步骤，而改为参考规格文件。这允许严格更好的初始化时间，因为 Code Workbook 只需执行安装步骤。作为预防措施，对于以前成功的环境停止工作的罕见情况，Code Workbook 默认会在 24 小时后失效规格文件。之后，在环境的下次成功解决时将生成一个新的规格文件。

因此，使用规格文件，每次已知环境的后续初始化尝试将如下图所示：

初始化优化：Conda Docker

如上图所示，要初始化环境，Code Workbook 必须首先获取一个 Spark 模块，然后将软件包安装到该模块上。类似于 Code Workbook 将成功解决的结果存储在规格文件中，有效的环境也可以存储为 Docker 镜像。使用此镜像，Code Workbook 可以请求后续的 Spark 模块，使其上已经存在所有必要的软件包。这绕过了解决步骤和模块上的 Conda 安装步骤，从而大大加快了环境初始化时间。默认情况下，Code Workbook 会在 24 小时后使 Docker 镜像失效。在环境的下次成功解决时将生成一个新镜像。

下图说明了 Conda Docker 如何简化初始化过程：

禁用 Conda Docker

在极少数情况下，如果环境中的软件包包含预链接或后链接脚本 ↗，使用 Conda Docker 的环境可能会在运行时失败。如果包含此类脚本的环境似乎出错，您可以在 Code Workbook 环境配置选项卡的左下角手动禁用此优化。禁用 Conda Docker 后，环境仍将受益于其他可用的优化。此配置将在使用的配置文件和在其上切换的工作簿分支的组合中保持不变。

预热

虽然上述优化可以缩短环境的初始化时间，但您可以通过主动初始化某些模块来避免等待环境。这些模块被称为“热”模块。通过配置热模块队列，Code Workbook 确保一组预初始化的 Spark 模块始终准备好被指派。有关如何配置热模块的更多信息，请参阅 Code Workbook 配置文档中的预热部分。