机器学习生产系统——数据旅程和数据存储

238 阅读18分钟

本章讨论生产管道生命周期中数据的演变。我们还将介绍一些可用于帮助管理该过程的工具。

正如前几章所述,数据是机器学习生命周期中的关键部分。随着机器学习生命周期中数据和模型的变化,能够识别、追踪和重现数据问题和模型变更非常重要。本章介绍了ML Metadata (MLMD)、TensorFlow Metadata (TFMD)和TensorFlow Data Validation (TFDV)作为帮助实现这些目标的重要工具。MLMD是一个用于记录和检索与ML工作流程相关的元数据的库,可以帮助分析和调试机器学习系统中交互的各个部分。TFMD提供了用于训练ML模型时所需关键元数据的标准表示,包括描述管道输入数据特征预期的模式。例如,可以在TFMD的模式格式中指定预期的类型、数量和允许值的范围。然后,你可以在TFDV中使用TFMD定义的模式来验证数据,使用第2章讨论的数据验证过程。

最后,我们还将介绍一些特别适用于机器学习的数据存储形式,尤其是针对当前日益增多的大型数据集(如Common Crawl,380 TiB)。在生产环境中,数据处理方式决定了成本结构、实现结果所需的努力,以及是否能够践行负责任的AI并满足法律要求。

数据历程

理解数据溯源从数据历程开始。数据历程从原始特征和标签开始。对于监督学习,数据描述了一个将训练集和测试集中的输入映射到标签的函数。在训练过程中,模型学习从输入到标签的映射,以尽可能提高准确性。数据会在训练过程中发生转化,如更改数据格式和应用特征工程。解释模型结果需要理解这些转化,因此密切跟踪数据变化至关重要。数据历程指的是数据从一个过程流向另一个过程的流动,从最初收集原始数据到最终生成模型结果,并包括沿途的转化。数据溯源指的是在数据被不同过程转化和使用时将其不同形式连接起来,从而可以追溯每个数据实例的生成过程和先前实例。

工件是由管道组件产生的所有数据和其他对象,包括导入管道的原始数据、各个阶段的转化数据、模式、模型本身、指标等。数据溯源(或称数据沿袭)是随着我们在管道中推进而生成的一系列工件。

跟踪数据溯源对调试、理解训练过程以及随时间对比不同训练运行非常关键。它可以帮助理解特定工件的生成过程,追踪特定训练运行的过程,并比较训练运行以理解为何它们产生了不同结果。数据溯源跟踪还可以帮助组织遵守数据保护法规,这些法规要求密切跟踪个人数据的来源、变更和位置。此外,由于模型本身也是训练数据的表达,我们可以将模型视为数据本身的一种转化。数据溯源跟踪还可以帮助我们理解模型的演变过程及其优化方式。

正确实施的机器学习应能够生成相对一致的可重现结果。类似于代码版本控制(如使用GitHub)和环境版本控制(如使用Docker或Terraform),数据版本控制也很重要。数据版本控制是一种对数据文件的版本管理,允许你跟踪随时间的变化并轻松恢复以前的版本。目前,数据版本控制工具刚刚开始出现,包括DVC(一个用于ML项目的开源版本控制系统)和Git Large File Storage (Git LFS),这是一个用于大文件存储版本控制的Git开源扩展。

ML元数据

每次机器学习管道运行都会生成包含管道组件、执行过程及所创建工件信息的元数据。你可以使用这些元数据来分析和调试管道中的问题,从而理解管道各部分之间的相互关联,而非将它们单独看待。MLMD是一个用于记录和访问机器学习管道元数据的库,可用于跟踪管道生命周期中的工件和管道变更。

MLMD将元数据注册到一个元数据存储中,该存储提供API,以便在可插拔的存储后端(例如SQLite或MySQL)中记录和检索元数据。MLMD可以注册以下内容:

  • 关于工件的元数据——机器学习管道组件的输入和输出
  • 关于组件执行的元数据
  • 关于上下文的元数据,即工作流中一组工件和执行的共享信息(例如项目名称或提交ID)

MLMD还允许定义描述这些类型属性的工件、执行和上下文类型。此外,MLMD记录了工件与执行之间的关系(称为事件)、工件与上下文之间的关系(称为归属)以及执行与上下文之间的关系(称为关联)。

通过记录这些信息,MLMD提供了帮助理解、综合和调试复杂机器学习管道的功能,例如:

  • 查找从给定数据集训练的所有模型
  • 比较给定类型的工件(例如比较模型)
  • 检查某个工件是如何创建的
  • 确定某个组件是否已经处理了给定输入
  • 构建管道中组件执行的有向无环图(DAG)

使用模式

管理机器学习管道数据的另一个关键工具是模式,它描述了管道输入数据特征的预期情况,并可用于确保所有输入数据符合这些预期。

基于模式的数据验证过程可以帮助你了解机器学习管道数据的演变,帮助你识别并纠正数据错误,或在变化有效时更新模式。通过审查模式随时间的演变,可以更好地理解底层输入数据的变化。此外,模式还可以用于促进涉及管道数据的其他过程,例如特征工程。

TFMD库包含一个模式协议缓冲区,可以用于存储模式信息,包括:

  • 数据集中所有特征的名称
  • 特征类型(int、float、string)
  • 数据集每个样本中是否需要包含某个特征
  • 特征的多值性
  • 值的范围或预期值
  • 特征值分布在数据集不同迭代中预期的变化程度

TFMD和TFDV关系密切。可以使用TFMD提供的协议缓冲区定义的模式,在TFDV中高效地确保每个通过机器学习管道的数据集符合该模式中阐明的约束。例如,使用指定了必需特征值和类型的TFMD模式,可以使用TFDV尽早识别数据集中是否存在异常,如缺失的必需值、错误类型的值等,这些异常可能会对模型训练或服务产生负面影响。为此,可以使用TFDV的generate_statistics_from_tfrecord()函数(或其他特定输入格式的统计生成函数)生成数据集的摘要统计信息,然后将这些统计信息和模式传递给TFDV的validate_statistics()函数。TFDV将返回一个Anomalies协议缓冲区,描述输入数据与模式的偏差(如果有)。在第2章中更详细地描述了这种检查数据与模式是否匹配的过程。

模式开发

TFMD和TFDV在模式开发和模式验证方面关系密切。由于许多输入数据集的规模较大,手动生成新模式可能会很繁琐。为帮助生成模式,TFDV提供了infer_schema()函数,该函数基于单个数据集的摘要统计信息推断出初始的TFMD模式。尽管自动生成的模式是一个有用的起点,但对模式进行管理以确保其全面且准确地描述管道数据的预期非常重要。例如,模式推断会生成一个有效值的初始列表(或范围),但由于它仅基于单个数据集的统计信息生成,可能并不全面。专家管理可以确保使用完整的列表。

TFDV包含多种实用函数(例如get_feature()set_domain())以帮助你更新TFMD模式。还可以使用TFDV的display_schema()函数在Jupyter Notebook中可视化模式,以进一步辅助模式开发过程。

模式环境

尽管模式有助于确保机器学习数据集符合一组共享约束,但可能需要在不同数据(例如训练和服务数据)之间引入这些约束的变体。模式环境可以用于支持这些变体。可以使用模式中的default_environmentin_environmentnot_in_environment字段将某个特征与一个或多个环境相关联。然后,可以在validate_statistics()中为一组输入统计信息指定一个环境,TFDV将根据指定的环境过滤应用的模式约束。

例如,可以使用模式环境来处理训练需要而服务时缺少的标签特征。为此,在模式中设置两个默认环境:Training和Serving。在模式中,使用not_in_environment字段将标签特征仅与Training环境相关联,如下所示:

default_environment: "Training"
default_environment: "Serving"
feature {
  name: "some_feature"
  type: BYTES
  presence {
    min_fraction: 1.0
  }
}
feature {
  name: "label_feature"
  type: BYTES
  presence {
    min_fraction: 1.0
  }
  not_in_environment: "Serving"
}

然后,在使用训练数据调用validate_statistics()时,指定Training环境;在使用服务数据调用validate_statistics()时,指定Serving环境。通过使用模式,TFDV将检查训练数据中的每个示例是否包含标签特征,以及服务数据中是否缺少标签特征。

数据集变化

可以使用模式定义对数据集变化的预期,包括单个特征的值分布和整个数据集示例数量的变化。

如第2章所述,可以使用TFDV检测数据集之间的偏差和漂移,其中偏差关注两个不同数据源之间的差异(如训练数据和服务数据),漂移关注同一数据源的多个迭代间的差异(如连续迭代的训练数据)。可以通过在模式中使用skew_comparatordrift_comparator字段来表达特征值分布在数据集之间的预期变化。如果特征值分布超过这些字段中指定的阈值,TFDV会引发异常以标记该问题。

除了表达允许的特征值分布变化范围,模式还可以指定数据集整体差异的预期。特别是,可以使用模式中的num_examples_drift_comparator字段表达样本数量随时间的变化预期。TFDV将检查当前数据集样本数量与前一数据集样本数量的比率是否在num_examples_drift_comparator的阈值范围内。

模式还可以用于表达超出此讨论范围的约束。有关TFMD模式可以表达的最新信息,请参阅TFMD模式协议缓冲区文件中的文档。

企业数据存储

数据是任何机器学习工作的核心。数据的质量将直接影响模型的质量。在生产环境中管理数据会影响机器学习项目所需的成本和资源,以及满足伦理和法律要求的能力。数据存储是其中的一个方面。以下各节将帮助你基本了解一些在生产环境中用于机器学习的主要数据存储系统类型。

特征存储

特征存储是用于存储已记录、精心策划且受访问控制的特征的中央仓库。特征存储使得发现和使用特征变得容易,这些特征可以是在线或离线的,适用于服务和训练。

在实践中,许多建模问题使用相同或相似的特征,因此相同的数据通常会在多个建模场景中使用。在许多情况下,特征存储可以看作是特征工程和模型开发之间的接口。特征存储通常是共享的、集中化的特征仓库,可以减少团队之间的重复工作。它们使团队能够共享数据并发现已经可用的数据。在组织中,通常有不同的团队面临不同的业务问题,他们正在进行不同的建模工作,但使用的是相同或非常相似的数据。因此,特征存储正成为企业数据存储的主流选择。

特征存储通常允许对数据进行转换,这样你就可以避免在不同的单独管道中重复进行相同的处理。对特征存储中数据的访问可以根据基于角色的权限进行控制。特征存储中的数据可以进行聚合,以形成新的特征。数据还可以进行匿名化,甚至进行清除处理,例如为了符合《通用数据保护条例》(GDPR)而进行数据删除。特征存储通常允许离线特征处理,这可以定期进行,比如通过cron作业。

假设你将运行一个作业来摄取数据,然后可能进行一些特征工程,生成新的特征(例如,特征交叉)。这些新特征也会发布到特征存储中,其他开发人员可以发现并利用它们,通常通过新特征添加的元数据来实现。你还可以将其与监控工具集成,在处理和调整数据时使用它们。这些处理过的特征将存储以供离线使用。它们也可以成为预测请求的一部分,可能通过与预测请求中提供的原始数据进行联接,以引入额外的信息。

元数据

元数据是你存储在特征存储中的所有特征的关键组成部分。特征元数据帮助你发现所需的特征。描述你所保留数据的元数据是一个工具——并且通常是寻找你所需数据并理解其特征的主要工具。你使用的特征存储的具体类型将决定如何将描述数据的元数据添加并在特征存储中进行搜索。

预计算特征

对于需要实时返回预测的在线特征使用,延迟要求通常相当严格。你需要确保能够快速访问这些数据。例如,如果你需要进行联接,可能是将用户账户信息与个人请求数据联合,那么这个联接必须迅速完成,但通常在线计算特征的性能是一个挑战。因此,拥有预计算特征通常是一个好主意。如果你预先计算并存储这些特征,就可以在后续使用它们,通常这时的延迟非常低。你也可以在批处理环境中进行预计算。

时间旅行

然而,当你训练模型时,你需要确保只包括在服务请求时能够获取的数据。包括那些在服务请求之后才可获得的数据被称为“时间旅行”,许多特征存储都包含防止这种情况的安全措施。例如,考虑有关事件的数据,每个示例都有一个时间戳。如果包含一个时间戳在模型预测时间之后的示例,将提供在模型服务时无法获得的信息。例如,当你试图预测明天的天气时,不应包括来自明天的数据。

数据仓库

数据仓库最初是为大数据和商业智能应用开发的,但它们也是生产环境中机器学习的有价值工具。数据仓库是一种聚合来自一个或多个来源的数据的技术,使其可以被处理和分析。数据仓库通常用于长时间运行的批处理作业,其存储优化以提高读取操作的效率。进入数据仓库的数据可能不是实时的。

当你将数据存储在数据仓库中时,数据需要遵循一致的模式。数据仓库是面向主题的,其存储的信息围绕一个主题展开。例如,数据仓库中存储的数据可能集中在组织的客户或供应商上。数据仓库中的数据通常来自多种类型的源,例如关系型数据库或文件。数据仓库中收集的数据通常会带有时间戳,以保持生成时的上下文信息。

数据仓库是非易失性的,这意味着当添加新数据时,旧版本的数据不会被删除。这意味着你可以按时间顺序访问存储在数据仓库中的数据,并理解这些数据如何随着时间演变。

数据仓库通过为数据打上时间戳,提供了增强的数据分析能力。数据仓库有助于你维护上下文。当你将数据存储在数据仓库中时,它遵循一致的模式,这有助于提高数据的质量和一致性。研究表明,对于许多应用场景,数据仓库的投资回报率通常较高。最后,数据仓库的读取和查询效率通常较高,使你能够快速访问数据。

数据仓库还是数据库?

你可能对数据库很熟悉,一个自然的问题是,数据仓库和数据库之间有什么区别?

数据仓库主要用于分析数据,而数据库通常用于事务处理。在数据仓库中,数据存储和数据变为可读取之间可能存在延迟。而在数据库中,数据通常在存储后立即可用。数据仓库按时间存储数据,因此历史数据也可以获取。与数据库相比,数据仓库通常能够存储更多的数据。数据仓库中的查询通常较为复杂,且运行时间较长,而数据库中的查询相对简单,通常是实时运行的。数据仓库不需要进行规范化处理,但在数据库中应当使用规范化。

数据湖

数据湖以其原始格式存储数据,通常以二进制大对象(blobs)或文件的形式存在。与数据仓库类似,数据湖汇聚来自各个企业数据源的数据。数据湖可以包括结构化数据(如关系型数据库)、半结构化数据(如CSV文件)或非结构化数据(如图像或文档集合)。由于数据湖以原始格式存储数据,因此它不进行任何处理,通常也不遵循模式。

需要意识到,如果数据湖管理不当,可能会变成数据沼泽。数据沼泽指的是当检索有用或相关数据变得困难时,削弱了存储数据的初衷。因此,在建立数据湖时,了解如何识别和检索存储的数据非常重要,并确保数据在添加到数据湖时附带支持这种识别和检索的元数据。

数据湖还是数据仓库?

数据湖和数据仓库的主要区别在于,数据仓库中的数据以一致的格式存储并遵循模式,而数据湖中的数据通常是以原始格式存储的。在数据湖中,存储数据的目的通常是在事先未确定的情况下进行的,而在数据仓库中,数据通常是为特定目的存储的。数据仓库通常也会被业务专业人员使用,而数据湖通常只由数据专业人员(如数据科学家)使用。由于数据仓库中的数据以一致的格式存储,对数据的更改可能是复杂且昂贵的。然而,数据湖更具灵活性,使得对数据的更改变得更加容易。

总结

本章讨论了生产机器学习管道中的数据历程,并概述了MLMD、TFMD和TFDV等工具如何帮助你识别、理解和调试数据和模型在这些管道中如何在机器学习生命周期中变化。还介绍了生产机器学习中使用的主要数据存储系统类型,以及如何确定存储生产机器学习数据的合适位置的相关考虑。