本章涵盖以下内容：

 在深度学习环境中理解和管理元数据

 设计元数据和文件存储库以管理元数据

 介绍两个开源的元数据管理工具：ML Metadata和MLflow

为了生成符合业务要求的高质量模型，数据科学家需要尝试各种数据集、数据处理技术和训练算法。为了构建和交付最佳模型，他们花费大量时间进行这些实验。

从模型训练实验中产生了各种工件（数据集和模型文件）和元数据。元数据可能包括模型算法、超参数、训练指标和模型版本，这些在分析模型性能方面非常有帮助。为了有用，这些数据必须是持久且可检索的。

当数据科学家需要调查模型性能问题或比较不同的训练实验时，作为工程师，我们可以做些什么来简化这些工作？例如，我们是否可以使模型的再现和实验比较更加容易？

答案是肯定的。作为工程师，我们可以构建一个系统，保留数据科学家需要复现和比较模型的实验元数据和工件。如果我们设计好这个存储和检索系统，并进行适当的元数据管理，数据科学家可以轻松地从一系列实验中选择最佳模型，或者快速找到模型退化的根本原因，而无需深入了解元数据系统。

在之前的章节中，我们学习了如何设计用于生成和提供模型的服务。在本章中，我们将把注意力转向元数据和工件管理系统，该系统有助于两个关键操作：故障排除和实验比较。 我们将从介绍工件和元数据开始，并解释这些概念在深度学习环境中的含义。然后，我们将通过示例和强调设计原则，向您展示如何设计元数据管理系统。

最后，我们将讨论两个开源的元数据管理系统：MLMD（ML Metadata）和MLflow。通过阅读本章，您将清楚地了解如何管理元数据和工件，以促进实验比较和模型故障排除。

介绍工件

人们通常认为深度学习中的工件是模型训练过程中生成的模型文件。这在某种程度上是正确的。实际上，工件是模型训练过程中组成组件的输入和输出文件和对象。这是一个关键的区别，在设计支持模型可重现性的系统时，保持这个更广泛的定义非常重要。

根据这个定义，工件可以包括数据集、模型、代码或深度学习项目中使用的任何其他对象。例如，原始的训练数据、通过标注工具生成的标记数据集以及数据处理流程的结果数据都被视为工件。

此外，工件必须与描述其属性和来源的元数据一起保存，以实现性能比较、可重现性和故障排除。实际上，工件以原始文件的形式存储在文件服务器或云存储服务中，例如Amazon Simple Storage Service或Azure Blob Storage。我们将工件与它们的元数据关联在一个独立的存储服务中的元数据存储中。参见图8.1，了解这种安排通常的样子。

图8.1显示了管理工件的常见做法。工件文件保存在文件存储系统中，并且它们的文件URL与其他相关的元数据（如模型训练执行ID和模型ID）一起保存在元数据存储中。这种设置使我们或者数据科学家能够在元数据存储中搜索模型，并轻松找到相应模型训练过程的所有输入和输出工件。

深度学习上下文中的元数据

一般而言，元数据是结构化的参考数据，用于提供有关其他数据或对象的信息，例如包装食品上的营养成分标签。然而，在机器学习（ML）和深度学习中，元数据更具体地指模型的相关数据，它描述了模型训练执行（运行）、工作流、模型、数据集和其他工件的信息。

对于任何分布式系统，我们通过日志和指标来跟踪服务级别的元数据。例如，我们可能跟踪CPU使用率、活跃用户数和失败的网页请求数等指标。我们使用这些指标进行系统/服务监控、故障排除和观察。

在深度学习系统中，除了服务级别的指标之外，我们还收集用于模型故障排除、比较和重现的元数据。你可以将深度学习元数据视为日志和指标的特殊子集，用于监视和追踪系统中的每个深度学习活动。这些活动包括数据解析、模型训练和模型服务。

常见的元数据类别

尽管我们刚刚定义了元数据，但实际上这个术语有些随意；并没有明确的指导方针说明哪些数据应被视为元数据。对于深度学习系统的工程师来说，我们建议将元数据定义为以下四个类别：模型训练运行、常规文档、模型文件和编排工作流。为了让您对这些类别有一个具体的了解，让我们来看看每个类别以及其中包含的一些示例元数据。

模型训练运行的元数据

为了重现模型、分析模型性能和简化模型故障排除，我们需要跟踪模型训练运行的所有输入和输出数据以及文档。这包括：

• 数据集ID和版本：用于模型训练的数据集的唯一标识符和版本。
• 超参数：训练中使用的超参数，如学习率和迭代次数。
• 硬件资源：在训练中分配的CPU、GPU、TPU、内存和磁盘大小，以及这些资源的实际消耗量。
• 训练代码版本-用于模型训练的训练代码快照的唯一标识符。
• 训练代码配置-用于重新创建训练代码执行环境的配置，例如conda.yml、Dockerfile和requirement.txt。
• 训练指标-显示模型训练的进展情况，例如每个训练迭代的损失值。
• 模型评估指标-显示模型性能的指标，例如F分数和均方根误差（RMSE）。

通用文档的元数据

文档可以是任意的文件，例如数据集、模型和预测结果。为了能够在文档存储中找到文档，我们希望跟踪以下文档的元数据：

• 文件位置-存储文档的路径，例如Amazon S3文件路径或内部文件系统路径。
• 文件版本-用于区分不同文件更新的唯一标识符。
• 描述-用于描述文档文件内容的附加信息。
• 审计历史-关于创建文档版本的人员、创建时间和创建方式的信息。

模型文件的元数据

模型是一种文档，但由于模型是每个深度学习系统的主要产品，我们建议将模型元数据与其他文档的元数据分开跟踪。在定义模型元数据时，最好从模型训练和模型服务的两个角度考虑。

对于模型训练，为了有模型谱系，我们希望保留模型和生成模型的模型训练运行之间的映射。模型谱系对于模型比较和重现非常重要。例如，在比较两个模型时，通过具有模型训练运行和模型的链接，数据科学家可以轻松确定模型的所有细节，包括输入数据集、训练参数和训练指标。模型训练指标对于理解模型性能非常有用。

对于模型服务，我们希望跟踪模型执行数据，以便进行未来的模型性能分析。这些执行数据，如模型响应延迟和预测错误率，对于检测模型性能下降非常有用。

以下是除了前面提到的通用文档元数据之外的几个推荐的模型元数据类别：

• 资源消耗-用于模型服务的内存、GPU、CPU和TPU消耗。
• 模型训练运行-用于找到创建模型的代码、数据集、超参数和环境的模型训练运行ID。
• 实验-跟踪生产中的模型实验活动，例如不同模型版本的客户流量分配。
• 生产-在生产中使用的模型，例如每秒查询和模型预测统计数据。
• 模型性能-跟踪模型评估指标以检测漂移，例如概念漂移和性能漂移。

注意： 模型一旦投入生产，不可避免地会表现出性能下降。我们将这种行为称为模型退化。随着目标群体的统计分布随时间变化，模型的预测变得不那么准确。例如，新的流行口号可能会影响语音识别的准确性。

管道元数据

当我们想要自动化多步骤的模型训练任务时，我们需要使用管道或工作流。例如，我们可以使用Airflow、Kubeflow或Metaflow等工作流管理工具来自动化包含多个功能步骤的模型训练流程：数据收集、特征提取、数据增强、训练和模型部署。我们将在下一章中详细讨论工作流。

对于管道元数据，通常我们会跟踪管道的执行历史和管道的输入输出。这些数据可以为未来的故障排除提供审计信息。

注意： 深度学习项目各不相同。对于语音识别、自然语言处理和图像生成等任务，模型训练代码有很大的差异。还有一些特定于项目的因素，如数据集的大小/类型、机器学习模型的类型和输入文件。除了之前提到的示例元数据，我们建议根据项目定义和收集元数据。当您需要寻找有助于模型重现和故障排除的数据时，元数据列表会自然而然地出现在您面前。

为什么要管理元数据？

因为元数据通常以日志或指标的形式被记录或记录下来，您可能会想为什么我们需要单独管理深度学习元数据。我们是否可以简单地从日志文件中获取深度学习元数据？类似Splunk（www.splunk.com/）和Sumo Logic（www.sumologic.com/）的日志管理系统非常方便，因为它们允许开发人员搜索和分析分布式系统产生的日志和事件。

为了更好地解释在深度学习系统中需要一个专门的元数据管理组件的必要性，我们将讲述一个故事。朱莉娅（数据工程师）、拉维（数据科学家）和建国（系统开发人员）一起在一个深度学习系统上工作，为聊天机器人应用程序开发意图分类模型。拉维负责开发意图分类算法，朱莉娅负责数据收集和解析，建国负责开发和维护深度学习系统。

在项目的开发和测试阶段，朱莉娅和拉维一起工作，构建了一个实验性的训练流程来生成意图模型。在模型构建完成后，拉维将它们传递给建国，由他将实验模型部署到预测服务中，并通过真实的客户请求进行测试。

当拉维对实验感到满意时，他将训练算法从实验流程推广到自动化的生产训练流程。该流程在生产环境中运行，并以客户数据作为输入生成意图模型。该流程还会自动将模型部署到预测服务中。图8.2展示了整个故事的背景设置。

几周后，拉维发布了最新的意图分类算法之后，一个名为BestFood的聊天机器人客户向拉维报告了模型性能下降的问题。在调查请求中，BestFood提到他们的聊天机器人在使用新数据集后，意图分类的准确率下降了10%。

为了解决报告的模型性能下降问题，拉维需要验证大量信息。他首先需要检查BestFood在预测服务中当前使用的模型版本，然后检查当前模型的模型血统，例如在训练流程中使用的数据集版本和代码版本。之后，拉维还可能需要重新生成模型进行本地调试。他需要比较当前模型和之前的模型，以测试数据分布的影响（当前新数据集与之前的数据集）。

拉维是一位自然语言处理（NLP）专家，但对于他的训练代码运行的深度学习系统，他几乎没有了解。为了继续他的调查，他必须向建国和朱莉娅获取相关的模型、数据集和代码信息。因为每个人对模型训练应用和底层深度学习系统/基础设施只有片面的了解，对于每个与模型相关的问题的排查，拉维、朱莉娅和建国必须共同合作来掌握完整的上下文，这需要耗费时间且效率低下。

当然，这个故事是过于简化的。在实际中，深度学习项目的开发涉及数据、算法、系统/运行时开发以及硬件管理。整个项目由不同的团队负责，很少有一个人了解所有的细节。在企业环境中，依赖跨团队的协作来解决与模型相关的问题是不现实的。

图8.2中缺少的关键因素是一种有效的方法，可以在一个集中的地方搜索和连接深度学习的元数据，以便朱莉娅、拉维和建国可以轻松获取模型的元数据。在图8.3中，我们添加了缺失的部分-元数据和工件存储（中间的灰色框），以提高调试能力。

如果将图8.3与图8.2进行比较，您会发现在图8.3的中间引入了一个新的组件（元数据和工件存储）。我们在8.2.1节中描述的所有深度学习元数据，无论是来自实验流程还是生产流程，都会被收集并存储在这个元数据存储中。

元数据存储为深度学习系统中的每个数据科学活动提供了整体的元数据视图。模型、流水线/训练运行和工件的元数据不仅被保存，还在这个存储中进行了关联，这样人们可以轻松地获取相关信息。例如，由于模型文件和模型训练运行在存储中是关联的，人们可以轻松确定给定模型的模型血统。

现在，数据科学家拉维可以使用元数据存储的用户界面列出系统中的所有模型和训练运行。然后，他可以深入元数据存储中查找过去训练运行中使用的输入参数、数据集和训练指标，这对于评估模型非常有帮助。更重要的是，拉维可以在不了解模型训练和服务的底层基础设施的情况下，快速完整地自行检索元数据。

设计元数据和工件存储

在本节中，我们首先讨论构建元数据和工件存储的设计原则，然后介绍一个符合这些原则的通用设计方案。即使您更喜欢使用开源技术来管理元数据，本节的讨论仍将对您有所裨益；了解设计需求和解决方案将有助于您选择适合您需求的正确工具。

注意： 为了简洁起见，我们在本章中将“元数据和工件存储”和“元数据存储”互换使用。当我们提到元数据存储时，它也包括工件管理。

设计原则

元数据和工件存储的设计目的是促进模型性能的故障排查和实验比较。它存储各种元数据，并围绕模型和训练运行进行聚合，以便数据科学家可以快速获取任意模型的相关模型血统和模型训练元数据。一个好的元数据存储应该遵循以下四个原则。

原则1：显示模型血统和版本管理

当接收到一个模型名称时，元数据存储应该能够确定该模型的版本以及每个模型版本的血统关系，例如哪个训练运行生成了该模型，输入参数和数据集是什么。模型的版本和血统对于模型故障排查非常重要。当客户报告模型存在问题，例如模型性能下降时，我们首先要问的问题是：模型是何时生成的？训练数据集是否发生了变化？使用了哪个版本的训练代码，我们可以在哪里找到训练指标？我们可以在模型血统数据中找到所有答案。

原则2：支持模型可复现性

元数据存储应该跟踪所有复现模型所需的元数据，例如训练管道/运行配置、输入数据集文件和算法代码版本。能够复现模型对于模型实验评估和故障排查至关重要。我们需要一个地方来记录配置、输入参数和工件，以启动一个模型训练运行以复现相同的模型。元数据存储是保留这些信息的理想场所。

原则3：方便获取打包模型

元数据存储应该让数据科学家能够轻松访问模型文件，而无需了解复杂的后端系统。存储库应该具有手动和程序化两种方法，因为数据科学家需要能够同时运行手动和自动化的模型性能测试。

例如，通过使用元数据存储，数据科学家可以快速识别当前在生产服务中使用的模型文件，并下载它进行调试。数据科学家还可以编写代码从元数据存储中提取任意版本的模型，以自动化比较新旧模型版本。

原则4：可视化模型训练跟踪和比较

良好的可视化能够极大提高模型故障排查过程的效率。数据科学家依赖各种各样的指标来比较和分析模型实验，元数据存储需要配备能够处理所有（或任何类型的）元数据查询的可视化工具。

例如，它需要能够显示一组模型训练运行的模型评估指标的差异和趋势行为。它还需要能够显示最新发布的10个模型的性能趋势。

一个通用的元数据和工件存储设计提案

为了满足8.3.1节中的设计原则，一个深度学习元数据存储应该是一个指标存储系统，并且需要存储各种类型的元数据及其之间的关系。这些元数据应该围绕模型、训练/实验执行进行聚合，以便在故障排除和性能分析过程中快速找到与模型相关的所有元数据。因此，内部元数据存储的数据模式是元数据存储设计的关键。

虽然元数据存储是一个数据存储系统，但数据扩展通常不是一个问题，因为深度学习系统的元数据量并不大。由于元数据的大小取决于模型训练执行和模型的数量，我们不希望每天有超过1,000个模型训练运行，所以一个单独的数据库实例应该足够用于元数据存储系统。

为了方便用户，元数据存储应该提供Web数据摄入接口和日志记录SDK，这样深度学习元数据就可以以类似应用程序日志和指标的方式进行记录。基于设计原则和对系统需求的分析，我们提供了一个样例元数据存储的设计供参考。图8.4显示了该组件的概览。

在图8.4中，样例元数据存储系统由四个组件组成：客户端SDK、Web服务器、后端存储和Web用户界面。深度学习工作流程中的每个组件和步骤都使用客户端SDK将元数据发送到元数据存储服务器。元数据存储提供了用于元数据摄入和查询的RESTful接口。Web用户界面可视化了元数据存储服务器的RESTful接口。除了基本的元数据和文件组织和搜索功能，它还可以可视化各种模型训练运行的模型性能指标和模型差异。

元数据存储服务器是这个设计的核心。它有三层结构：一个RESTful的Web接口、一个数据聚合器和存储层。数据聚合器组件了解元数据的组织和关联方式，因此它知道如何添加新的元数据以及如何处理不同类型的元数据查询。在存储方面，我们建议构建一个抽象的元数据和文件存储层。这个抽象层作为一个适配器，封装了实际的元数据和文件存储逻辑。因此，元数据存储可以在不同类型的存储后端上运行，例如云对象存储、本地文件和本地或远程SQL服务器。

元数据存储模式

现在让我们来看一下元数据存储的数据模式。无论我们是将元数据保存在SQL数据库、NoSQL数据库还是纯文件中，我们都需要定义一个数据模式来描述元数据的结构和序列化方式。图8.4展示了我们元数据存储的实体关系图。

在图8.5中，模型训练运行（Training_Runs对象）处于实体关系图的核心位置。这是因为模型性能的故障排除始终从生成模型的过程（训练运行或工作流程）开始，因此我们希望有一个专门的数据对象来跟踪生成模型文件的训练执行。

详细的模型训练元数据保存在Metrics（指标）和Parameters（参数）对象中。Parameters对象保存训练运行的输入参数，例如数据集ID、数据集版本和训练超参数。Metrics对象保存训练过程中产生的指标，例如模型的F2分数。

Experiments（实验）对象用于组织和分组模型训练运行。一个实验可以包含多个训练运行。例如，我们可以将意图分类模型开发项目定义为一个训练实验，并将所有意图分类模型训练执行与该实验关联起来。然后，在用户界面上，我们可以按不同的实验对训练执行进行分组。

Models（模型）对象存储模型文件的元数据，例如模型版本、类型和阶段。一个模型可以有多个阶段，例如测试、预生产和生产，所有这些阶段都可以被保留。

请注意，在图8.5中的每个实体都与生成它们的特定训练运行相关联（在图中用线表示），因此它们将共享一个共同的training_run_id。通过利用这种数据链接，您可以从任何训练运行对象开始，找到其输出模型、训练输入数据和模型训练指标。

前面我们说过我们可能简称为元数据存储，但它也存储了artifacts（工件）。那么在这个设计中artifacts在哪里呢？我们将artifact的URL存储在Training_Runs对象中，作为训练运行的输出。如果我们查询模型或训练执行，我们将获得artifacts的URL。

开源方案

在本节中，我们将讨论两个广泛使用的元数据管理工具，即MLMD和MLflow。这两个系统都是开源的，可以免费使用。我们将首先概述每个工具，然后进行比较，以确定在何时使用哪个工具。

ML Metadata

MLMD（github.com/google/ml-m…）是一个轻量级的库，用于记录和检索与机器学习开发人员和数据科学家工作流相关的元数据。MLMD是TensorFlow Extended（TFX; www.tensorflow.org/tfx）的一个组成部分，但它被设计为可以独立使用。例如，Kubeflow（www.kubeflow.org/）使用MLMD来管理其管道和笔记本服务生成的元数据。有关详细信息，请参阅Kubeflow元数据文档（mng.bz/Blo1）。您可以将MLMD视为一个日志记录库，并在ML管道的每个步骤中使用它来记录元数据，以便您可以了解和分析工作流/管道的所有相互连接的部分。 系统概述 使用MLMD库进行元数据记录可以设置两种不同的后端：SQL或gRPC服务器。请参见图8.6的概念。

在图8.6中，我们可以看到ML管道/工作流的每个步骤都使用MLMD库（MLMD客户端API）来记录元数据。在后端，MLMD将元数据保存在关系数据库中，例如MySQL或PostgreSQL。 您可以选择让每个MLMD库直接与SQL服务器通信（图8.5，A），或者使用MLMD库中的服务器设置代码来设置一个gRPC服务器，并让客户端库与服务器通信（图8.5，B）。方法A很简单，您不需要托管专用的日志服务器，但推荐使用方法B，因为它避免了暴露后端数据库。 您可以查看以下两个文档，了解详细的元数据存储配置：”Metadata Storage Backends and Store Connection Configuration”（mng.bz/dJMo）和”Use MLMD with a Remote gRPC Server”（mng.bz/rd8J）。

日志记录API

在MLMD中，元数据存储使用以下数据结构来记录存储后端的元数据。Execution表示工作流中的一个组件或步骤；Artifact描述执行中的输入或输出对象；Event是Artifact和Execution之间关系的记录。Context是一个逻辑分组，用于将Artifact和Execution在同一个工作流中关联在一起。

了解了这个概念，让我们来看一些示例的元数据记录代码：

# define a dataset metadata
data_artifact = metadata_store_pb2.Artifact() data_artifact.uri = 'path/to/data' data_artifact.properties["day"].int_value = 1 data_artifact.properties["split"].string_value = 'train' data_artifact.type_id = data_type_id
[data_artifact_id] = store
   .put_artifacts([data_artifact])
   
# define a training run metadata
trainer_run = metadata_store_pb2.Execution()
trainer_run.type_id = trainer_type_id
trainer_run.properties["state"].string_value =
[run_id] = store.put_executions([trainer_run])

# define a model metadata
model_artifact = metadata_store_pb2.Artifact() model_artifact.uri = 'path/to/model/file' model_artifact.properties["version"].int_value = 1 model_artifact.properties["name"].string_value = 'MNIST-v1' model_artifact.type_id = model_type_id
[model_artifact_id] = store.put_artifacts([model_artifact])

# define an experiment metadata
my_experiment = metadata_store_pb2.Context()
my_experiment.type_id = experiment_type_id
# Give the experiment a name
my_experiment.name = "exp1"
my_experiment.properties["note"].string_value = 
"My first experiment."
[experiment_id] = store.put_contexts([my_experiment])

# declare relationship between model, training run 
# and experiment
attribution = metadata_store_pb2.Attribution() attribution.artifact_id = model_artifact_id attribution.context_id = experiment_id
association = metadata_store_pb2.Association()
association.execution_id = run_id
association.context_id = experiment_id

# Associate training run and model with the 
# same experiment
store.put_attributions_and_associations( 
  [attribution], [association])

请查看MLMD的“入门指南”文档（mng.bz/VpWy），了解详细的代码示例和本地设置说明。

搜索元数据

MLMD没有提供用于显示其存储的元数据的用户界面。因此，要查询元数据，我们需要使用其客户端API。请参考以下代码示例：

artifacts = store.get_artifacts()
[stored_data_artifact] = store
   .get_artifacts_by_id([data_artifact_id])

artifacts_with_uri = store
   .get_artifacts_by_uri(data_artifact.uri)

artifacts_with_conditions = store
   .get_artifacts(
      list_options=mlmd.ListOptions(
        filter_query='uri LIKE "%/data"
        AND properties.day.int_value > 0'))

MLMD的“入门指南”文档（mng.bz/VpWy）提供了许多查询示例，用于获取artifact、execution和context的元数据。如果您有兴趣，请参阅该文档。

学习MLMD数据模型的最佳方法是查看其数据库模式。您可以首先创建一个SQLite数据库，并配置MLMD元数据存储以使用该数据库，然后运行MLMD的示例代码。最后，所有实体和表将被创建在本地SQLite数据库中。通过查看表的模式和内容，您将深入了解MLMD中的元数据组织方式，从而可以自己在其上构建一个良好的用户界面。以下示例代码展示:

connection_config = metadata_store_pb2.ConnectionConfig()
connection_config.sqlite.filename_uri =
  '{your_workspace}/mlmd-demo/mlmd_run.db'
connection_config.sqlite.connection_mode = 3
store = metadata_store.MetadataStore(connection_config)

MLflow

MLflow（mlflow.org/docs/latest…）是一个开源的MLOps平台。它旨在管理机器学习生命周期，包括实验、可重现性、部署和中央模型注册。

与MLMD相比，MLflow是一个完整的系统，而不仅仅是一个库。它由四个主要组件组成：

• MLflow Tracking（元数据跟踪服务器）- 用于记录和查询元数据
• MLflow Projects – 以可重用和可重现的方式打包代码
• MLflow Models – 用于打包可以用于不同模型服务工具的机器学习模型
• MLflow Model Registry – 用于管理MLflow模型的完整生命周期，包括模型血统、模型版本控制、注释和生产推广等，具备用户界面（UI）。

在本节中，我们将重点关注跟踪服务器，因为它与元数据管理最相关。

系统概览

MLflow提供了六种不同的设置方法。例如，MLflow运行（训练流程）的元数据可以记录到本地文件、SQL数据库、远程服务器或具有代理存储后端访问的远程服务器中。有关这六种不同设置方法的详细信息，请参阅MLflow文档中的“How Runs and Artifacts Are Recorded”（mlflow.org/docs/latest…）。

在本节中，我们将重点关注最常用的设置方法：具有代理式存储访问的远程服务器。请参阅图8.7，了解系统概述图。

从图8.7中可以看出，深度学习流程（工作流）的每个步骤/操作都使用MLflow客户端将元数据和工件记录到MLflow跟踪服务器中。跟踪服务器将元数据（例如指标、参数和标签）保存在指定的SQL数据库中，工件（例如模型、图像和文档）保存在配置的对象存储（例如Amazon S3）中。

MLflow提供了两种上传工件的方式：（1）从客户端直接上传和（2）通过跟踪服务器进行代理上传。在图8.6中，我们演示了后一种方法：利用跟踪服务器作为涉及工件操作的代理服务器。优点是最终用户可以直接访问后端远程对象存储，无需提供访问凭据。

MLflow的另一个好处是它提供了一个友好的用户界面；数据科学家可以通过托管在跟踪服务器中的网站来查看和搜索元数据。该界面不仅允许用户从流程执行的角度查看元数据，还可以直接搜索和操作模型。

日志目录API

将元数据发送到MLflow跟踪服务器非常简单。我们可以通过创建一个活动的运行（active run）作为上下文管理器，然后调用log函数来记录工件或单个键值参数、指标和标签。以下是示例代码：

import mlflow

remote_server_uri = "..."
mlflow.set_tracking_uri(remote_server_uri)

mlflow.set_experiment("/my-experiment")

with mlflow.start_run(): 
  mlflow.log_param("parameter_a", 1)   
  mlflow.log_metric("metric_b", 2) 
  mlflow.log_artifact("features.txt")

**自动记录日志 **

如果您厌倦了手动指定大量元数据，MLflow支持自动日志记录。在您的训练代码之前调用mlflow.autolog()或特定于库的autolog函数，例如mlflow.tensorflow.autolog()、mlflow.keras.autolog()或mlflow.pytorch.autolog()，MLflow将自动记录元数据，甚至是工件，而无需显式的日志语句。如果您想了解更多关于MLflow日志记录的信息，请查看MLflow日志记录函数文档（mng.bz/xd1d）。

搜索元数据

MLflow跟踪服务器托管的跟踪UI允许您可视化、搜索和比较运行，并下载运行的工件或元数据以在其他工具中进行分析。UI具有以下关键功能：基于实验的运行列表和比较，按参数或指标值搜索运行，可视化运行指标，以及下载运行结果。除了UI之外，您还可以通过编程方式实现跟踪UI提供的所有操作，如以下示例：

from mlflow.tracking import MlflowClient
client = MlflowClient()
.. .. ..

# Fetch the run metadata from the backend store, 
# which contains a list of metadata
active_run = client.get_run(run_id) 
print("run_id: {}; lifecycle_stage: {}"
     .format(run_id, active_run.info.lifecycle_stage))

# Retrieve an experiment by
# experiment_id from the backend store
experiment = client.get_experiment(exp_id)

# Get a specific version of a model
mv = client.get_model_version(model_name, mv_version)

以编程方式访问元数据不仅在使用分析工具（例如，pandas）查询和比较不同训练运行的模型性能时很有帮助，而且在将模型与模型服务系统集成时也很有帮助，因为它允许您以编程方式从MLflow模型注册表中获取模型。有关完整的MLflowClient API用法，请参阅MLflow Tracking API文档（mng.bz/GRzO）。

MLflow vs. MLMD

从前面的描述中，我们可以看出，MLMD更像是一个轻量级的库，而MLflow是一个MLOps平台。这两个工具都可以独立运行，提供元数据摄取和搜索功能，并在模型训练运行的基础上跟踪元数据。但是，MLflow提供了更多的功能。 除了MLMD的功能外，MLflow还支持自动元数据记录和精心设计的UI，用于可视化实验元数据（包括实验比较）、模型注册表、工件管理、代码可复现性、模型打包等等。 如果您需要引入一个完整的、新的元数据和工件存储到您的系统中，MLflow是您的首选。它得到了活跃的开源社区的支持，并涵盖了大部分ML元数据管理的用户需求。作为额外的福利，MLflow在MLOps方面有很好的支持，例如MLflow项目管理和模型部署。 如果您已经拥有一个工件注册表和度量可视化网站，并且希望将元数据功能集成到现有系统中，那么MLMD是一个很好的选择。MLMD轻量、易于使用和学习。例如，Kubeflow（www.kubeflow.org/）深度学习平台将MLMD作为元数据跟踪工具集成到其组件中，如Kubeflow管道（www.kubeflow.org/docs/compon…）。

总结

• 机器学习元数据可以分为四个类别：模型训练运行、通用工件、模型工件和流程管道。
• 元数据和工件存储设计用于支持模型性能比较、故障排除和复现。
• 良好的元数据管理系统可以帮助展示模型血统、实现模型可复现性并促进模型比较。
• MLMD是一个轻量级的元数据管理工具，起源于TensorFlow的管道，但可以独立使用。例如，Kubeflow使用MLMD来管理其管道组件中的ML元数据。
• MLMD非常适合将元数据管理集成到现有系统中。
• MLflow是一个MLOps平台，旨在管理机器学习的生命周期，包括实验、可复现性、部署和中央模型注册表。
• 如果您希望引入一个完全独立的元数据和工件管理系统，MLflow是适用的。