下载掌阅APP，畅读海量书库
立即打开
在建设MLOps中的数据系统时，我们有多个层面的问题需要解决：从业务层面来讲，各个环节的数据需要梳理、分析，从而形成完整的数据体系；从技术层面来讲，面对数据的复杂性，建立统一的大数据系统来聚合数据，而不同的业务场景往往需要构建不同的技术架构。具体来说，需要重点考虑的问题如下。
● 常见的数据质量问题。
● 时序数据穿越问题。
● 离线和实时数据一致性问题。
● 数据安全问题。
● 数据共享与复用问题。
本节将围绕这些问题及解决方案对MLOps中的数据部分做详细阐述。
数据质量是机器学习项目落地的关键。机器从历史数据中不断学习，学习效果与训练数据的质量密切相关。因此，高质量的数据是MLOps系统构建的基础。
让我们来分析一个业务场景：假设初步的探索性数据分析已经完成，并且可以看到模型的潜在性能，但令人失望的是，该模型的效果还不能被业务人员所接受。在这种情况下，考虑到研发成本和时效，我们下一步的操作可能是分析错误的预测并将其与输入数据相关联，以调查可能的异常情况和先前被忽略的数据模式；或者采用更加复杂的机器学习算法。
但是，如果模型的输入数据质量很差，那么采用更复杂的机器学习算法并不能带来更大的好处。
通常，机器学习算法需要单一视图（扁平化结构）的训练数据。但是现实中，企业维护的数据源复杂又多样，因此，组合多个数据源以便将所有的必要属性放在单个视图是一个耗时耗力的过程。
目前，大多数数据科学家有一个普遍共识：数据准备、清理和转换占据了模型构建的大部分时间。因此，在将数据输入模型之前要进行严格的数据质量检查。对于数据质量检查，每个人可能都会有非常主观的判断，但基本上要关注数据的一些关键要素，包括完整性、独特性、时效性、一致性、准确性，如图4-4所示。
图4-4 数据质量关键判断要素
接下来，我们分析几个数据质量问题并给出解决方案。
● 数据标注不同：不同的数据服务供应商用不同的方法来收集和标记数据，同时对数据的最终用途也有不同的理解。即使在同一个数据服务供应商中，主管得知需求并下达任务给不同的团队成员，也会出现多种标注形式的情况，因为所有的团队成员都是根据自己的理解进行标注的。
解决方案：在数据服务供应侧进行质量检查，在消费侧验证是否遵守达成共识的标注指南，以实现同等质量的数据标注，保证数据标注是按照相同的规则进行的。
● 数据操作不同：对模型的训练数据进行不同的聚类、转换等，例如计算滑动平均值、回填空值、缺失值估算等，会对效果产生影响。
解决方案：请领域专家参与数据处理和特征工程的过程，利用他们的专业知识对数据进行清洗、转换、补充与验证。此外，他们还可以为模型选择更有意义和相关性的特征。
● 数据缺失：数据缺失会导致结果有偏差，比如缺失值可能代表特定人群的某个属性。而且高缺失值会降低模型的预测能力。
解决方案：计算类似维度或级别数据的平均值。
● 缺少扁平化结构：大多数组织都缺少一个集中的数据仓库，且缺少结构化数据。
解决方案：建立统一的数据仓库，以及对元数据进行统一管理。
1.时序数据
时序数据是按时间顺序组织的一组数据。时序数据的关键特征是时态排序，即按照事件发生和到达处理的顺序进行记录。时序数据在写入、读取与存储时有一定的特点。
在写入时，时序数据通常按时间顺序到达进行写入，并添加到数据存储中，很少更新，因此它的写入比较平稳。这与应用数据不同。应用数据通常与应用的访问量成正比，生成存在波峰、波谷。时序数据通常是以固定的频率生成，不会受其他因素制约。其生成速度是相对比较平稳的。通常，时序数据由个体独立生成，当个体比较多时，写入并发和吞吐量都是比较高的。
在读取时，时序数据通常按时间范围进行读取，而不是时间点，且离当前时间越近的数据被读取的概率越高。同时，由于时序数据产自不同的个体，这些个体的特征可能是同一维度的，也可能是不同维度的，因此我们会对时序数据进行多维分析。
在存储时，时序数据量很大，且冷热分明，越是时间久远数据被查询与分析的可能性越低。
2.时序数据穿越问题
MLOps系统在利用时序数据解决实际问题时，有可能出现与过拟合相似的现象：离线训练时，模型效果非常好；在线推理时，模型效果很差。这有可能是时序数据穿越问题造成的。该问题是指在模型训练时，不小心将未来本应用于预测的数据引入训练集，比如，在金融信贷评估场景，训练集误引入建模时间点之后的数据，如还款表现等。
我们通过一个简单的二分类案例来介绍该问题。
表4-2为针对某用户的时序特征值。
表4-2 某用户的时序特征值
表4-3为针对该用户的二分类训练样本。
表4-3 针对该用户的二分类训练样本
我们希望重现过去特定时间点的特征状态，也就是Point-in-time Join。如此一来，便可以避免时序特征穿越的问题。最终正确的训练数据如表4-4所示。
表4-4 正确的训练数据
以13:30时刻为建模时间点举例，若使用14:00时刻的数据则会产生时序数据穿越问题。
3.时序数据穿越问题解决方案
一般来说，解决时序数据穿越问题可以从以下几个方面入手。
（1）数据回填
数据回填指的是在数据管道中追溯处理历史数据。我们若保存了完整的事件日志，便能精确地构建特定时刻的特征，然后通过特征生成训练集。从构建特征角度看，数据回填目的在于从历史数据中提取特征，以便构建时间跨度更长的模型。
数据回填的工程实现如图4-5所示。
图4-5 数据回填的工程实现
● Redis中只保存最新版本的特征数据，提供给线上推理使用。
● Kafka中的数据通过Flink写入数据仓库，作为原始数据层长期存储。
● 数据仓库中的数据通过SQL或Spark等作业进行数据回填，创建各个时刻的特征值。
● 通过Point-in-time Join关联样本与特征，生成训练集并训练模型。
该方法的优点如下。
● 数据存储量少，仅需保存原始日志。在构建训练集时按需构建，不需要维护特征版本。
● 方便之后从历史数据中提取特征。
该方法的缺点如下。
● 对于如今训练数据量越来越大，动辄百万级别的训练数据来讲，该方法的特征生成效率太低。
● 实现与维护复杂度高，通过不同数据管道得到的训练与推理数据容易产生不一致问题。
（2）快照
该方法是对用户多个时刻的特征进行快照保存，然后通过Point-in-time Join生成训练集。
快照的工程实现如图4-6所示。
图4-6 快照的工程实现
● Redis中只保存最新版本的特征数据，提供给线上推理使用。
● Kafka中的数据通过Flink写入数据仓库，作为原始数据层长期存储。
● Redis中的特征通过定时任务或者事件驱动任务生成快照。
● 通过Point-in-time Join关联样本与特征，生成训练集并训练模型。
该方法的优点如下。
● 特征的构建不需要在线下进行，而是通过快照实现，这样计算量巨大的问题得到了解决。
● 实现相对简单，不需要数据回填，不需要维护不同的数据管道，只需要保证Point-in-time Join的正确性。
该方法的缺点如下。
● 快照的时效性不好保证，尽管解决了时序数据穿越问题，但是如果快照调用周期过长，则会丢失大量信息、时效性降低，导致特征分布与实际不一致。
● 若快照调度频繁，粒度过细，则存储压力变大。
（3）请求快照
在进行线上推理时，我们可以获取每次模型推理的时刻所用的特征值，将此时刻的特征值与该推理请求的相关信息一同保存，就得到了请求快照。该方法在生成训练集时并不需要Point-in-time Join，因为训练集的样本是在线推理时实时记录下来的，所以可以有效避免时序数据穿越问题。
请求快照的工程实现如图4-7所示。
图4-7 请求快照的工程实现
● 线上推理时产生的特征值与请求相关信息一同保存。
● 天级（按天分组）Join操作生成训练集并训练模型。
该方法的优点如下。
● 特征的构建不需要在线下进行，而是通过快照实现，这样计算量巨大的问题得到了解决。
● 实现相对简单，不需要数据回填，不需要维护不同的数据管道，不需要保证Point-in-time Join。
● 训练样本生成后不需要保存快照，存储成本低。
该方法的缺点如下。
● 样本数据不能立刻得到，需要经过一段时间进行特征、样本积累，才能进行模型训练。
解决时序数据穿越问题的方法对比如表4-5所示。
表4-5 解决时序数据穿越问题的方法对比
时序数据穿越问题在很大程度上是由于线上推理与线下训练的数据处理管道不同引起的。将特征工程做到数据库中，利用数据库的内置函数、窗口函数等，并将实时流处理与数据库集成，做到较高的实时性，而且统一了线上推理与线下训练的数据处理管道，这样也可以解决此类问题。后面章节会有相应介绍。
在MLOps系统中，机器学习模型出现的问题很大程度上可以定义为广义的线上线下一致性问题。其中，离线与实时数据一致是模型稳定性的基础保障。通常，不一致的数据会导致模型稳定性指标抖动，预估效果不符合预期等问题的出现。因此，在模型全链路测试过程中，一致性测试非常重要。但是，通常的一致性测试方案难以做到全局，更多是做效果与效率测试。
本节将介绍离线和实时数据一致性问题及解决方案。
1.离线和实时数据一致性问题
以互联网中常见的有监督学习中的分类学习为例，分类学习的迭代过程如图4-8所示。每个方框中的内容表示一种数据形态，下标为数据的上游来源及版本。
图4-8 分类学习的迭代过程
● 训练阶段：训练集经过特征抽取和训练产出模型。
● 评估阶段：基于训练集产出的模型，输入未进入训练集的样本进行预估。当评估模型的效果符合预期时，该模型可以进入线上推理阶段。
● 线上推理阶段：使用经过评估符合预期的模型进行线上推理。线上推理的预估值会应用于具体的业务问题，并产生新的训练集，重新回到训练阶段。
机器学习模型训练、评估和线上推理过程中的数据一致性包括样本一致性与模型一致性。样本一致性指相同的输入数据集在经过训练、评估、线上推理阶段后的值应该是一致的。模型一致性指离线训练后产出的模型和线上推理使用的模型若有优化操作，效果损失应在预期范围内。实际上，离线训练后产出的模型在加载到线上时常常会经历剪枝、量化、压缩等优化操作。经过部分特征的过滤和参数精度的转换，任何模型的效果都会衰退。
处理逻辑不一致是影响数据一致性的关键因素之一。处理逻辑一致包括特征抽取逻辑一致（即相同的输入数据经过特征抽取操作后，产出的特征签名应保持一致）产出的模型在评估和线上推理阶段的使用逻辑一致。
若处理逻辑一致性不能保证，数据一致性则难以保证。任何一个阶段的处理逻辑都会影响下一阶段的输入数据。因此，保证数据一致性的同时也应保证处理逻辑一致性，从而保证MLOps系统中机器学习模型的健康迭代。
综上所述，围绕数据一致性评估的关键指标如下。
● 当前模型的迭代是否健康，有没有发生数据一致性问题。
● 能否定位数据不一致问题产生的原因。
● 数据不一致对MLOps系统产生的影响，解决数据不一致问题投入的成本与带来的收益。
2.离线和实时数据一致性问题解决方案
传统的解决方案是添加校验流，对上述3个关键指标进行一一验证。如图4-9所示，在线上推理阶段产生新的训练集T 2 之后，可以将E 1 替换为T 2 ，将其作为附加的校验流。
图4-9 附加校验流
此时，线上推理阶段的输入与校验的输入实现了统一，具体校验如下。
● 离线样本T 2 与在线样本P 1 的内容是否一致（T 2 应为P 1 的子集）。
● 离线特征抽取结果F T2 与在线特征抽取结果F P1 是否一致。
● 离线模型M T2 与在线模型M P1 是否一致。
● 离线预估值Q T2 与在线预估值Q P1 是否一致。
通常，MLOps系统的线上推理全链路十分复杂，这就需要针对整个过程进行校验流覆盖，对比是否有不一致问题以及寻找不一致问题出现的位置与原因。若数据量巨大，对比将十分困难。
在接下来的章节中，将介绍一个开源机器学习数据库OpenMLDB，该数据库提供了线上线下一致的特征计算平台。
从出现大数据概念之后，大数据的安全问题就一直被人们所关注。未经授权的用户可能会非法访问和窃取企业的数据，对外进行出售，使企业不论在业务还是在声誉等方面，都受到惨重损失。
对于MLOps系统来说，数据安全问题主要有以下几点。
● NoSQL数据库与非结构化数据的大量应用导致早前的常见安全策略与流程很难保证这些新的技术栈的安全。
● 一些成熟的安全工具可以有效保护数据安全，但在庞大且复杂的系统链路中，可能会对不同位置与环节的数据输出产生不同的影响。
● 庞大的数据量可能无法支持日常安全审计，而分布式集群架构会扩大安全漏洞的影响范围。
在MLOps系统中，数据是不可或缺的。只有利用大数据技术充分挖掘数据价值，才能成就强有力的MLOps系统。但是，这也意味着数据计算环境比以往更复杂，通常跨越公共云、企业私有云、数据中心等多个环境。这种复杂性使得攻击面扩大，数据安全更具挑战性。
为了应对上述挑战，可以采用以下解决方案。
● 采用细粒度的访问控制：确保每个用户或服务仅具有访问所需数据的权限，最小化潜在的数据泄露风险。
● 加密数据：在存储和传输过程中对数据进行加密，以确保即使数据被窃取，攻击者也无法轻易访问明文信息。
● 定期安全审计：通过定期进行安全审计，监控系统的安全状况，及时发现和修复潜在的安全漏洞。
● 采用数据脱敏技术：对敏感数据进行脱敏处理，降低数据泄露风险。
● 实施安全培训和意识教育：定期为员工提供安全培训和意识教育，帮助他们了解网络安全风险和预防措施，减少人为错误导致的数据泄露。
● 引入安全监控和告警机制：部署实时安全监控和告警系统，以检测异常行为、入侵尝试和潜在威胁，及时发现并阻止攻击。
● 强化网络防护：确保网络边界和内部网络的安全性，例如使用防火墙、入侵检测系统（IDS）和入侵防御系统（IPS）等技术手段进行保护。
● 制定严格的数据管理和保留政策：实施数据生命周期管理，确保数据在存储、使用和销毁过程中的安全性；限制长时间保留不必要的数据，降低潜在的安全风险。
通过采取这些措施，可以在很大程度上提高MLOps系统中大数据的安全性，保护企业的关键信息资产，同时确保数据的合规性。这将有助于降低企业面临的潜在风险，提高业务连续性和稳定性。
在机器学习系统中，特征复用率低会导致很多问题出现，比如算法迭代效率低，特征处理流程变复杂以及存储资源被浪费等。企业机器学习系统应用中经常会出现这些情况：同一个特征被不同的业务部门使用，数据源来自同一份日志文件，数据抽取逻辑类似，但因为是在不同的部门或不同的场景中使用而不能复用，相当于同一个抽取逻辑被执行了多次。而且，日志文件是海量的，这对存储资源和计算资源都是巨大的浪费。
为了解决这些痛点，MLOps系统中特有的平台——特征平台出现了。
特征平台是构建、管理、共享机器学习所需要的特征的中间仓库，自2017年被Uber首次提出后，已经有多个相关创业公司获得投资。2020年至今，国内已经有多个互联网大厂发布了相应的商业产品和开源项目。
作为MLOps系统中特有的平台，它除了解决了数据共享与复用问题之外，还具有以下特性。
● 同时满足线下训练以及线上推理需求。特征平台在不同的场景能满足不同的应用需求。在模型训练时，它能满足扩展性好、存储空间大的应用需求；在线上推理时，它能满足高性能、低延时的应用需求。
● 解决了特征处理在训练阶段和预估阶段不一致的问题。在模型训练时，AI科学家一般会使用Python脚本，然后用Spark或者SparkSQL来完成特征处理。这种训练对延时不敏感，对效率要求较低，因此AI工程师会在预测阶段使用性能较高的语言把特征处理过程翻译一下。但翻译过程异常烦琐，AI工程师要反复和AI科学家校对算法逻辑是否符合预期，只要稍微不符合预期，就会带来线上和线下不一致问题。特征平台提供统一的特征定义、管理的SDK和API，保证存储一致性，这样可以解决特征处理在训练阶段和预测阶段不一致的问题，从而提高模型的准确性和业务部署效率。