mlflow.diviner

mlflow.diviner 模块提供了一个用于记录、保存和加载 diviner 模型的 API。Diviner 将几个流行的开源时间序列预测库封装在一个统一的 API 中，允许对相关系列组进行训练、回测交叉验证和预测推理。该模块以下列格式导出单变量 diviner 模型组：

预言家格式: 使用原生 diviner 序列化器序列化的 diviner 模型类型实例。（例如，“GroupedProphet” 或 “GroupedPmdarima”）
mlflow.pyfunc: 为基于pyfunc的通用部署工具使用而生成，并用于历史预测的批量审计。

mlflow.diviner.get_default_conda_env()[源代码]

返回:: 使用 Diviner 风格生成的 MLflow 模型的默认 Conda 环境，该风格由调用 save_model() 和 log_model() 产生。

mlflow.diviner.get_default_pip_requirements()[源代码]

返回:: 由 Diviner 风格生成的 MLflow 模型的默认 pip 需求列表。调用 save_model() 和 log_model() 生成的 pip 环境至少包含这些需求。

mlflow.diviner.load_model(model_uri, dst_path=None, **kwargs)[源代码]

从本地文件或运行中加载一个 Diviner 对象。

参数:

model_uri – MLflow 模型的位置，采用 URI 格式。例如： - /Users/me/path/to/local/model - relative/path/to/local/model - s3://my_bucket/path/to/model - runs:/<mlflow_run_id>/run-relative/path/to/model - mlflow-artifacts:/path/to/model 有关支持的 URI 方案的更多信息，请参阅引用工件。
dst_path – 下载模型工件的本地文件系统路径。如果提供此目录，则必须已经存在。如果未指定，将创建一个本地输出路径。
kwargs – 加载 Diviner 模型的可选配置选项。对于已经使用 Spark 拟合并保存的模型，如果希望为加载 Diviner 模型指定特定的 DFS 临时目录，请使用关键字参数 “dfs_tmpdir” 来定义模型加载期间的临时路径。

返回:

一个 Diviner 模型实例。

将 Diviner 对象记录为当前运行的 MLflow 工件。

参数:

diviner_model – Diviner 模型已经在一个分组的时间 DataFrame 上进行了 fit。
artifact_path – 运行相对的工件路径，用于保存模型实例。
conda_env – 一个Conda环境的字典表示形式或Conda环境yaml文件的路径。如果提供，这将描述模型应运行的环境。至少，它应指定包含在 get_default_conda_env() 中的依赖项。如果为 None，则会向模型添加一个包含由 mlflow.models.infer_pip_requirements() 推断的pip要求的Conda环境。如果要求推断失败，则回退到使用 get_default_pip_requirements()。来自 conda_env 的pip要求被写入pip requirements.txt 文件，完整的Conda环境被写入 conda.yaml。以下是一个Conda环境的字典表示形式的*示例*:: { “name”: “mlflow-env”, “channels”: [“conda-forge”], “dependencies”: [ “python=3.8.15”, { “pip”: [ “diviner==x.y.z” ], }, ], }
code_paths – 本地文件系统路径列表，指向Python文件依赖项（或包含文件依赖项的目录）。这些文件在加载模型时会被*前置*到系统路径中。如果为给定模型声明了依赖关系，则应从公共根路径声明相对导入，以避免在加载模型时出现导入错误。有关``code_paths``功能的详细解释、推荐的使用模式和限制，请参阅`code_paths使用指南 <https://mlflow.org/docs/latest/model/dependencies.html?highlight=code_paths#saving-extra-code-with-an-mlflow-model>`_。
registered_model_name – 此参数可能在未来的版本中更改或移除，且不会提前警告。如果提供，将在 registered_model_name 下创建一个模型版本，如果给定名称的注册模型不存在，则同时创建一个注册模型。
signature – 模型签名 描述了模型的输入和输出 模式。模型签名可以从具有有效模型输入（例如，省略目标列的训练数据集）和有效模型输出（例如，在训练数据集上生成的模型预测）的数据集中 推断，例如：
input_example – 一个或多个有效的模型输入实例。输入示例用作提示，指示应向模型提供哪些数据。它将被转换为Pandas DataFrame，然后使用Pandas的面向分割的格式序列化为json，或者是一个numpy数组，其中示例将通过将其转换为列表来序列化为json。字节被base64编码。当``signature``参数为``None``时，输入示例用于推断模型签名。
await_registration_for – 等待模型版本完成创建并处于 READY 状态的秒数。默认情况下，函数等待五分钟。指定 0 或 None 以跳过等待。
pip_requirements – 可以是 pip 需求字符串的可迭代对象（例如 ["diviner", "-r requirements.txt", "-c constraints.txt"]），或者是本地文件系统上的 pip 需求文件的字符串路径（例如 "requirements.txt"）。如果提供，这将描述该模型应运行的环境。如果为 None，则通过 mlflow.models.infer_pip_requirements() 从当前软件环境中推断出默认的需求列表。如果需求推断失败，则回退到使用 get_default_pip_requirements()。需求和约束都会自动解析并分别写入 requirements.txt 和 constraints.txt 文件，并作为模型的一部分存储。需求也会写入模型 conda 环境（conda.yaml）文件的 pip 部分。
extra_pip_requirements – 可以是 pip 需求字符串的可迭代对象（例如 ["pandas", "-r requirements.txt", "-c constraints.txt"]），或者是本地文件系统上的 pip 需求文件的字符串路径（例如 "requirements.txt"）。如果提供，这将描述附加的 pip 需求，这些需求会被追加到根据用户当前软件环境自动生成的一组默认 pip 需求中。需求和约束会分别自动解析并写入 requirements.txt 和 constraints.txt 文件，并作为模型的一部分存储。需求也会被写入模型的 conda 环境（conda.yaml）文件的 pip 部分。 .. 警告:: 以下参数不能同时指定： - conda_env - pip_requirements - extra_pip_requirements 这个示例展示了如何使用 pip_requirements 和 extra_pip_requirements 指定 pip 需求。
metadata – 传递给模型并在 MLmodel 文件中存储的自定义元数据字典。
kwargs – mlflow.models.model.Model 的额外参数此外，对于在 Spark 中拟合的模型，可以使用以下支持的配置选项进行设置。当前支持的选项： - partition_by 用于设置一个（或多个）分区列，作为列名的列表。必须是一个字符串列表，表示分组键列。 - partition_count 用于设置每个 partition_by 组重新分区后写入的分文件数量。默认的分文件数量为 200。 - dfs_tmpdir 用于指定 DFS 临时位置，模型在从本地文件系统复制到 Spark 支持的 “dbfs:/” 方案时将存储在该位置。

返回:

一个包含记录模型元数据的 ModelInfo 实例。

将 Diviner 模型对象保存到本地文件系统的一个路径中。

参数:

diviner_model – Diviner 模型已经在一个分组的时间 DataFrame 上进行了 fit。
path – 序列化模型的本地路径目的地将被保存。
conda_env – 一个Conda环境的字典表示形式或Conda环境yaml文件的路径。如果提供，这将描述模型应运行的环境。至少，它应指定包含在 get_default_conda_env() 中的依赖项。如果为 None，则会向模型添加一个包含由 mlflow.models.infer_pip_requirements() 推断的pip要求的Conda环境。如果要求推断失败，则回退到使用 get_default_pip_requirements()。来自 conda_env 的pip要求被写入pip requirements.txt 文件，完整的Conda环境被写入 conda.yaml。以下是一个Conda环境的字典表示形式的*示例*:: { “name”: “mlflow-env”, “channels”: [“conda-forge”], “dependencies”: [ “python=3.8.15”, { “pip”: [ “diviner==x.y.z” ], }, ], }
code_paths – 本地文件系统路径列表，指向Python文件依赖项（或包含文件依赖项的目录）。这些文件在加载模型时会被*前置*到系统路径中。如果为给定模型声明了依赖关系，则应从公共根路径声明相对导入，以避免在加载模型时出现导入错误。有关``code_paths``功能的详细解释、推荐的使用模式和限制，请参阅`code_paths使用指南 <https://mlflow.org/docs/latest/model/dependencies.html?highlight=code_paths#saving-extra-code-with-an-mlflow-model>`_。
mlflow_model – mlflow.models.Model 这个模型正在被添加到的风格。
signature – 模型签名 描述了模型的输入和输出 模式。模型签名可以从具有有效模型输入（例如，省略目标列的训练数据集）和有效模型输出（例如，在训练数据集上生成的模型预测）的数据集中 推断，例如：
input_example – 一个或多个有效的模型输入实例。输入示例用作提示，指示应向模型提供哪些数据。它将被转换为Pandas DataFrame，然后使用Pandas的面向分割的格式序列化为json，或者是一个numpy数组，其中示例将通过将其转换为列表来序列化为json。字节被base64编码。当``signature``参数为``None``时，输入示例用于推断模型签名。
pip_requirements – 可以是 pip 需求字符串的可迭代对象（例如 ["diviner", "-r requirements.txt", "-c constraints.txt"]），或者是本地文件系统上的 pip 需求文件的字符串路径（例如 "requirements.txt"）。如果提供，这将描述该模型应运行的环境。如果为 None，则通过 mlflow.models.infer_pip_requirements() 从当前软件环境中推断出默认的需求列表。如果需求推断失败，则回退到使用 get_default_pip_requirements()。需求和约束都会自动解析并分别写入 requirements.txt 和 constraints.txt 文件，并作为模型的一部分存储。需求也会写入模型 conda 环境（conda.yaml）文件的 pip 部分。
extra_pip_requirements – 可以是 pip 需求字符串的可迭代对象（例如 ["pandas", "-r requirements.txt", "-c constraints.txt"]），或者是本地文件系统上的 pip 需求文件的字符串路径（例如 "requirements.txt"）。如果提供，这将描述附加的 pip 需求，这些需求会被追加到根据用户当前软件环境自动生成的一组默认 pip 需求中。需求和约束会分别自动解析并写入 requirements.txt 和 constraints.txt 文件，并作为模型的一部分存储。需求也会被写入模型的 conda 环境（conda.yaml）文件的 pip 部分。 .. 警告:: 以下参数不能同时指定： - conda_env - pip_requirements - extra_pip_requirements 这个示例展示了如何使用 pip_requirements 和 extra_pip_requirements 指定 pip 需求。
metadata – 传递给模型并在 MLmodel 文件中存储的自定义元数据字典。
kwargs – Spark DataFrame 存储的可选配置（仅在模型已在 Spark 中拟合时适用）。当前支持的选项：