3、数据ETL
在这个步骤中，为ML任务准备数据。这包括数据清理、过滤、数据转换和特性调整。它应该做一些事情，比如为整数映射生成特性。此外，该组件准备可能在训练组件中需要的特征元数据(例如，这包括特征规范化训练步骤中需要的元参数，分类变量编码所需的字典，等等)。这些称为转换工件;它们帮助构建模型输入。
重要的是，生成的任何映射都必须保存并在服务时重用(当训练过的模型用于进行预测时)。如果不能始终做到这一点，就会导致我们之前谈到的培训服务倾斜问题。
4、模型训练
模型训练组件负责训练我们的模型。在大多数用例中，模型可以训练数小时、数天甚至数周。优化一个需要数周训练的模型是不可行的。在其他情况下，用于训练模型的数据甚至无法装入内存。
在这种情况下，模型训练组件应该能够支持数据和模型并行性;并扩大到大量工作线程。它还应该能够处理内存不足的数据。
理想情况下，ML系统的所有组件都应该是可伸缩的，并运行在支持可伸缩性的基础设施上。
这个模型训练组件还应该能够在训练时自动监视和记录一切。我们不能训练一个机器学习模型很长一段时间，而不去观察它的运行情况，并确保它的正确配置能够随着迭代次数的增加而最小化损失函数。最后，训练组件还应该支持超参数调优。
5、模型分析
在模型分析组件中，我们对训练结果进行深入分析，并确保导出的模型具有足够的性能，可以推向生产。
这一步帮助我们保证模型只有在满足框架阶段预设的质量标准时才会被提升服务。标准必须包括与以前部署的模型相比的性能改进，以及在不同数据子集/切片上的性能。在下面的图中，我们在特性切片trip_start_hour上显示我们训练过的模型的性能。
该步骤的输出是一组性能指标，以及是否将模型推广到生产环境的决策。
6、模型服务部署
与训练组件相反，我们通常关注的是数据和模型复杂性的缩放。在服务部署组件中，我们感兴趣的是通过最小化响应延迟和最大化吞吐量来响应可变的用户需求。
因此，服务组件应该具有较低的延迟以快速响应用户、高效率以便在需要时可以同时运行多个实例、水平扩展、可靠和健壮地应对故障。
我们还需要我们的服务组件能够轻松地更新到模型的新版本。当我们获得新的数据或触发新的管道运行，或测试新的模型架构思想时，我们将希望推出模型的新版本，并希望系统无缝地过渡到这个新版本。
7、监控
正如我们前面提到的，由于不断变化的数据配置文件，部署的ML模型的性能会随着时间的推移而下降，我们需要确保我们的系统正在监视并响应这种下降。
因此，我们需要跟踪数据的汇总统计数据，并监控模型的在线性能，以便发送通知、在值偏离预期时进行回滚，或者潜在地调用ML流程中的新迭代。
因此，在线监控是检测性能退化和模型过时的关键。它作为一个线索，以新的实验迭代和再训练模型的新数据。
我们刚才描述的步骤的自动化水平定义了我们的ML系统的成熟度，它也反映了由模型衰退或给定的新数据触发的新模型的训练速度。
管道编排组件:目前，手工流程在许多用例中非常普遍。当模型由于静态数据分布而很少更改时，这可能就足够了。但在实践中，这种情况很少发生。数据通常是动态的，模型在实际部署时经常会中断。静态模型肯定不能适应描述环境的数据的变化。
手工处理也可能是危险的，因为它会导致ML训练和ML服务之间的断开。它将创建模型的数据科学家和作为预测服务操作模型的工程师分开。而这一过程会导致训练服务的倾斜问题。
业务流程组件的目标是连接系统的不同组件。它按顺序运行管道，并根据定义的条件自动从一个步骤移动到另一个步骤。这是自动化的第一步，因为我们现在可以使用基于实时管道触发器的新数据自动培训生产中的新模型。
我们需要注意的是，在生产环境中，我们并没有将训练过的模型部署为预测服务。我们实际上正在部署一个完整的训练管道，它会自动且反复地运行，以作为预测服务来服务训练过的模型。
管道的元数据存储:管道元数据存储的作用是记录ML管道执行的所有细节。这对于保持组件之间的沿袭和在任何需要的时候重新生成已部署的模型非常重要。它还可以帮助我们调试遇到的任何错误。
每次执行管道时，存储都会记录所有关于管道执行的细节，例如:
- 我们的管道和组件的版本被执行的源代码。
- 传递给我们管道的输入参数。
- 管道中每个执行组件产生的工件/输出，如原始数据的路径、转换的数据集、验证统计数据和异常、训练的模型……
- 模型评估度量标准，以及关于模型部署的模型验证决策，这些决策是在模型分析和验证组件期间产生的……
CI / CD管道自动化
到目前为止，我们只讨论了如何自动化ML管道的持续执行，以基于新数据的可用性或模型衰减来捕捉新出现的模式等触发器来重新训练新模型。
但是，如果我们想测试一个新的特性，一个新的模型架构，或者一个新的超参数呢?这就是自动化CI/CD管道的意义所在。CI/CD管道让我们能够快速探索新的想法和实验。它允许我们自动构建、测试和部署新管道及其组件到预期的环境。
以下是CI/CD流水线自动化如何补充连续ML流水线自动化:
- 如果给定新的实现/代码(新的模型架构、特性工程和超参数……)，一个成功的CI/CD管道会部署一个新的连续ML管道。
- 如果给定新的数据(或模型衰减触发器)，成功的自动连续管道将部署新的预测服务。要用新数据训练新的ML模型，需要在新数据上执行之前部署的ML管道。
完整的端到端自动化管道应该如下所示:
- 我们迭代地尝试了新的ML想法，其中对一些管道组件进行了更新（例如，引入新功能将看到我们更新数据转换组件……）。此阶段的输出是新ML管道组件的源代码，然后将其推送到目标环境的源存储库中。
- 新源代码的存在将触发CI / CD管道，而CI / CD管道将反过来构建新的组件和管道，运行相应的单元和集成测试，以确保一切均已正确编码和配置，最后将新管道部署到目标环境是否通过所有测试。机器学习系统的单元测试和集成测试本身值得一篇独立的文章。
- 根据计划，新训练数据的存在或响应触发器，新部署的管道将在生产中自动执行。此阶段的输出是经过训练的模型，该模型被推送到模型注册中心并进行连续监视。
为什么Tensorflow ?
在这最后一节中，我想谈谈为什么Tensorflow是我开发集成ML系统时首选的框架。当然，TensorFlow可能并不适合并适用于所有的用例，有时甚至可能是一种过度使用，特别是在不需要深度学习的情况下。然而，我倾向于在可能的情况下使用Tensorflow，原因如下:
Tensorflow自带Tensorflow Extended (TFX)。TFX使我们能够专注于优化ML管道，同时减少对每次重复的样板代码的关注。像数据验证和模型分析这样的组件可以很容易地完成，而不需要开发自定义代码来读取数据并在两次管道执行之间检测异常。使用TFX，只需要很少几行代码就可以完成，从而节省了大量开发管道组件的时间。数据验证和模型分析组件中的截图来自TFX。
我们可以设计自定义模型，我们可以使用TF layers API、TF losses API、....来构建这些模型如果我们正在构建一些相当标准的东西，TensorFlow有一组我们可以尝试的预估器。Tensorflow 2可以很好地与Keras模型一起工作。随着数据和培训时间的增加，我们的需求也会增加。检查点允许我们在需要时暂停并恢复训练，如果预先设定的时间不够，则继续训练。
Tensorflow设计了一个数据集API，可以很好地处理内存不足的数据集。
模特训练需要几个小时，有时几天。我们不能在不检查模型是否按预期运行的情况下对模型进行长时间的训练Tensorboard是TensorFlow的可视化工具包。TensorBoard提供了机器学习实验所需的可视化和工具。它允许我们将在训练期间实时生成的TensorFlow关键指标显示出来，并将它们可视化在训练和验证集上，以便查看我们的模型是否正确地配置为收敛。如果情况不是这样，我们可以停止训练。
我们可以将TensorFlow分布在一个集群上以使它更快。从一台机器到多台机器可能听起来很复杂，但有了Tensorflow，我们就可以开箱即用了。TF为训练和评估抽象了分布式执行的细节，同时也支持跨本地/非分布式和分布式配置的一致行为。
