AWS自动化机器学习-十、机器学习软件开发生命周期（MLSDLC）简介

在本书的这一点上，我们已经回顾了多种亚马逊 Web 服务 ( AWS )技术，这些技术可用于自动化机器学习 ( ML )过程，从使用亚马逊 SageMaker 自动驾驶自动化 ML 实验，到使用 AWS 代码管道、 AWS 步骤函数和亚马逊管理的 Apache Airflow 工作流()自动化模型训练和部署我们还通过回顾以源代码为中心和以数据为中心的方法来进一步优化 ML 过程，看到了各种过程如何应用于 ML 自动化的任务。在前面的章节中，我们也看到了组织中不同的团队如何对 ML 用例的整体成功做出贡献。

在这一章中，我们将应用我们已经学到的知识，并扩展影响自动化、端到端(【e2e】)ML 策略或 ML 软件开发生命周期(【mls DLC】成功执行的关键因素，即:

处理
技术
人

我们将通过关注跨职能、敏捷团队中的各种角色，以及每个团队为创建高质量的基于 ML 的应用所贡献的特定工件，来阐述这些因素，涵盖以下主题:

MLSDLC 简介
构建应用平台
检查 ML 和数据工程角色
了解安全镜头

在本章结束时，您将对 MLSDLC 流程包含的内容以及如何将该流程应用于年龄计算器用例有一个大致的了解。

技术要求

要了解本章中的示例，您需要以下内容:

web 浏览器(为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器)。
访问您在本书中一直使用的 AWS 帐户。
通过这本书访问我们一直使用的开发环境。
我们将再次在 AWS 免费层的使用限制内工作，以避免产生不必要的成本。
本章的配套 GitHub 存储库中提供了应用工件的完整源代码(https://GitHub . com/packt publishing/Automated-Machine-Learning-on-AWS/tree/main/chapter 10)。

mls DLC 简介

系统开发生命周期 ( SDLC )或应用开发生命周期的概念自 20 世纪 60 年代以来就一直存在，通过这一概念，六个单独的过程被放置到位，以有效地计划、设计、构建、测试、部署、维护生产中的应用。虽然过程的各个阶段以及实现这些阶段的机制已经发展了很多年，但是快速有效地将工作应用交付到生产环境中的基本需求却没有变化。下图概括了 SDLC 的六个阶段: ![Figure 10.1 – Six phases of the SDLC ]

图 10.1–SDLC 的六个阶段

当仔细观察图 10.1 时，你应该有希望推断出与本书中到目前为止我们所遇到的一些过程的相关性。例如，我们可以假设在 SDLC 的计划和设计阶段执行的一些潜在活动可能类似于在 CRISP-DM 流程的业务用例阶段执行的一些活动。回想一下，我们在 [第 1 章] B17649_01_ePub.xhtml##_idTextAnchor015) 、AWS 上的自动机器学习入门中回顾了跨行业数据挖掘标准流程 ( CRISP-DM

此外，如果我们参考 [第四章]过程，用于机器学习，我们也可以推断出在构建、测试、部署和维护之间存在相应的任务映射因此，当我们通过各种方式来实现用于年龄计算器*用例的生产级模型时，我们已经间接地创建了一个以 ML 为中心的 SDLC——或 MLSDLC。

证明这一假设的最佳方式是使用 SDLC 流程构建一个示例应用(网站),并结合一个 ML 用例(年龄计算器模型)来完成 MLSDLC 流程。因此，在本章和下一章中，我们将构建一个 ACME Fishing Logistics 网站，这样做不仅会突出 MLSDLC 流程，还会强调影响 MLSDLC 成功实现的关键因素，即流程(CI/CD)人员(跨职能团队)技术 (AWS 服务)。

为了做好准备，下图显示了我们将要构建的应用平台的高级架构: ![Figure 10.2 – ACME Fishing Logistics application platform ]

图 10.2-ACME 渔业物流应用平台

从图 10.2 可以看出，应用平台使用几个 AWS 服务来交付最终解决方案。我们可以按照以下步骤将组件分为六个特定类别:

为了构建这个解决方案，一个跨职能团队创建各种编码的工件，封装它们对整个解决方案的贡献。在这一章中，我们将着重于创建这些工件。
一旦工件被创建并提交到源代码存储库，解决方案的下一个组件将这些工件的构建和部署编排为代码管道资产。例如，CodePipeline 编排构建用于模型训练的 Docker 容器映像。这个过程类似于我们在 [第四章]*。
在构建好管道资产之后，CodePipeline 以 Step Functions 状态机的形式编排自动化 ML 工作流的部署。使用我们在 [第六章] B17649_06_ePub.xhtml##_idTextAnchor094
相应地，一旦我们有了生产级 ML 模型，CodePipeline 就可以利用存储在 SageMaker 模型注册中心的生产级 ML 模型来协调测试环境的部署。部署测试环境后，我们将对网站应用的伪生产版本执行系统测试。
一旦网站应用的测试版本通过了系统测试，CodePipeline 就会部署网站应用的生产版本。在这个阶段，我们使用以源代码为中心的方法，实现了生产 ML 应用的 E2E 自动化。
为了方便添加新的鲍鱼调查数据，CodePipeline 部署的最后一个组件是一个亚马逊 MWAA 环境，就像我们在第八章、中使用 Apache Airflow 自动化机器学习过程所创建的环境一样。因此，通过气流有向无环图 ( DAG )的手段来更新训练数据，我们将把一种以数据为中心的机制纳入到解决方案中。

现在，我们已经对本章和下一章要构建的内容有了一个概念，在下一节中，我们将从应用平台的规划、设计和构建开始。

构建应用平台

在 [第一章] B17649_01_ePub.xhtml##_idTextAnchor015

要开始构建应用，第一步是组建一个团队。下图说明了团队的样子: ![Figure 10.3 – The application team ]

图 10.3–应用团队

正如您从图 10.3 中看到的，初始应用团队由以下关键资源组成:

应用所有者
现场可靠性/平台工程团队
前端应用软件工程团队

让我们更详细地研究一下这些特定的角色，从应用所有者开始。

检查应用所有者的角色

应用所有者的主要职责是确保网站在战略上与业务目标保持一致。除此之外，所有者必须确保网站是功能性的、可用的、可靠的，并且以成本有效的方式运行。

虽然应用所有者可能不负责直接管理平台或开发工程师，但他们负责指导和协调这些团队执行的各种工作。应用所有者主要负责 MLSDLC 环境中的规划和设计阶段。他们的一些任务可能还包括以下内容:

文档:应用所有者创建并管理应用文档，为工程团队提供正确的需求和总体预期。
关系管理和战略协调:应用所有者协调来自用户和其他利益相关者的反馈，以确定产品战略、功能增强以及与业务目标的一致。
分析和报告:应用所有者生成必要的报告，与各种利益相关者进行沟通。

这些只是应用所有者可以执行的任务中的一部分。我们将考察的下一个角色是平台工程师。

审视平台工程师的角色

在前面的章节中，我们经常看到应用开发团队或开发-运营 ( DevOps )团队如何与 ML 分区交互，以将 ML 模型交付到生产中。在 MLSDLC 的背景下，这些团队也被称为平台或现场可靠性团队。在这里，平台团队负责设计整体平台架构(与应用所有者一起)，构建基础设施，以及维护平台。

为了演示这一点，我们将使用 AWS Cloud9 集成开发环境 ( IDE )开始 MLSDLC 构建，并使用以下步骤将 ACME 网站构建为 AWS 云开发套件 ( CDK )项目:

登录到你一直使用的同一个 AWS 帐户，打开 AWS Cloud9 控制台(https://console . AWS . Amazon . com/cloud 9)。
在MLOps-IDE开发环境中。
Run the following command in the Cloud9 terminal window to confirm that we are running version 2.3.0 (build beaa5b2) of the AWS CDK. Update the environment by running the following command in the workspace terminal:
```
$ cdk --version
```
注意如果您没有运行版本 2.3.0 (build beaa5b2)的 AWS CDK，请参考 [第 4 章]*以获得如何安装该版本的说明。

运行以下命令来初始化和引导 CDK 应用:

$ cd ~/environment
$ mkdir acme-web-application && cd acme-web-application
$ cdk init --language python
$ git add -A
$ git commit -m "Started CDK Project"
$ git branch main
$ git checkout main
$ source .venv/bin/activate

接下来，我们将通过运行以下命令来安装必要的开发库:
```
$ python -m pip install -U pip pylint boto3
```
由于我们将使用一些实验性的 CDK 构造库，使用 Cloud9 IDE 的左侧导航面板，展开acme-web-application文件夹并双击requirements.txt文件进行编辑，然后将以下 alpha 模块添加到该文件:
```
aws-cdk.aws-apigatewayv2-alpha==2.3.0a0
aws-cdk.aws-apigatewayv2-integrations-alpha==2.3.0a0
```
保存并关闭requirements.txt文件。
现在，我们通过在 Cloud9 终端窗口中运行以下命令来安装所需的 CDK 模块:
```
$ pip install -r requirements.txt
```
现在我们已经安装了相关的库，我们可以开始定义一个骨架 CDK 管道了。使用左侧导航面板，展开acme-web-application文件夹并删除acme_web_application_stack.py文件。
Now, right-click on the acme_web_application folder and select the acme_pipeline_stack.py. Double-click on the acme_pipeline_stack.py file for editing. 注意您可以参考配套的 GitHub 存储库(https://GitHub . com/packt publishing/Automated-Machine-Learning-on-AWS/blob/main/chapter 10/Files/CDK/acme pipeline stack . py)来获得完整版本的acme_pipeline_stack.py文件。

添加以下代码以导入必要的库:

import aws_cdk as cdk
import aws_cdk.aws_codecommit as codecommit
import aws_cdk.aws_s3 as s3
import aws_cdk.pipelines as pipelines
import aws_cdk.aws_ssm as ssm
from constructs import Construct

现在，使用下面的代码将PipelineStack类初始化为cdk.Stack构造:

class PipelineStack(cdk.Stack):
    def __init__(self, scope: Construct, id: str, *, model_name: str=None, group_name: str=None, repo_name: str=None, feature_group: str=None, threshold: float=None, cdk_version: str=None, **kwargs) -> None:
        super().__init__(scope, id, **kwargs)

我们创建的第一个资源是 CodeCommit 源代码存储库，用于所有的 MLSDLC 源代码。使用下面的代码，我们还为统一资源定位符 ( URL )创建了一个输出，以便其他团队可以轻松地克隆这个存储库:

        self.code_repo = codecommit.Repository(
            self,
            "Source-Repository",
            repository_name=repo_name,
            description="ACME Web Application Source Code Repository"
        )
        cdk.CfnOutput(
            self,
            "Clone-URL",
            description="CodeCommit Clone URL",
            value=self.code_repo.repository_clone_url_http
        )

我们创建的下一个资源是一个简单存储服务 ( S3 )存储桶，用于存放所有相关的 ML 和管道数据。下面是代码来完成这个:

        self.data_bucket = s3.Bucket(
            self,
            "Data-Bucket",
            bucket_name=f"data--{cdk.Aws.ACCOUNT_ID}",
            block_public_access=s3.BlockPublicAccess.BLOCK_ALL,
            auto_delete_objects=True,
            removal_policy=cdk.RemovalPolicy.DESTROY,
            versioned=True
        )

接下来，我们保存 S3 存储区名称，以及 SageMaker 特性存储库FeatureGroup名称作为系统管理器参数。这些将被其他团队用来引用管道之外的资产。我们是这样做的:

        ssm.StringParameter(
            self,
            "Data-Bucket-Parameter",
            parameter_name="DataBucket",
            description="SSM Parameter for the S3 Data Bucket Name",
            string_value=self.data_bucket.bucket_name
        )
        ssm.StringParameter(
            self,
            "Feature-Group-Parameter",
            parameter_name="FeatureGroup",
            description="SSM Parameter for the SageMaker Feature Store group",
            string_value=feature_group
        )

现在，我们创建一个source_artifact变量来告诉 CI/CD 管道在哪里找到各种工件和资源的源代码。代码如下面的代码片段所示:
```
        source_artifact = pipelines.CodePipelineSource.code_commit(
            repository=self.code_repo,
            branch="main"
        )
```

最后，我们使用下面的代码创建一个骨架管道:

        pipeline = pipelines.CodePipeline(
            self,
            "Application-Pipeline",
            pipeline_name="ACME-WebApp-Pipeline",
            self_mutation=False,
            cli_version=cdk_version,
            synth=pipelines.ShellStep(
                "Synth",
                input=source_artifact,
                commands=[
                    "printenv",
                    f"npm install -g aws-cdk@",
                    "python -m pip install --upgrade pip",
                    "pip install -r requirements.txt",
                    "cdk synth"
                ]
            )
        )

保存并关闭acme_pipeline_stack.py文件。
使用左侧的导航面板，打开app.py文件进行编辑。
文件打开后，删除任何现有的模板代码，并添加以下代码。在app.py文件中，我们正在初始化 CDK 应用使用的全局参数，比如模型的名称、CodeCommit 存储库的名称以及特性存储库名称的占位符。此外，在这段代码中，我们还将 CDK 应用中的acme_pipeline_stack.py文件实例化为PipelineStack()构造:

!/usr/bin/env python3

import os
import aws_cdk as cdk
from acme_web_application.acme_pipeline_stack import PipelineStack
MODEL = "abalone"
MODEL_GROUP = f"PackageGroup"
FEATURE_GROUP = "PLACEHOLDER"
CODECOMMIT_REPOSITORY = "acme-web-application"
CDK_VERSION = "2.3.0"
QUALITY_THRESHOLD = 3.1
app = cdk.App()
PipelineStack(
    app,
    CODECOMMIT_REPOSITORY,
    env=cdk.Environment(account=os.getenv("CDK_DEFAULT_ACCOUNT"), region=os.getenv("CDK_DEFAULT_REGION")),
    model_name=MODEL,
    repo_name=CODECOMMIT_REPOSITORY,
    group_name=MODEL_GROUP,
    feature_group=FEATURE_GROUP,
    cdk_version=CDK_VERSION,
    threshold=QUALITY_THRESHOLD,
)
app.synth()

21.  保存并关闭`app.py`文件。
22.  现在，我们部署主干管道。在 IDE 终端窗口中运行以下命令，引导应用:

$ export CDK_NEW_BOOTSTRAP=1
$ npx cdk bootstrap aws://$/${CDK_DEFAULT_REGION} \
 --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess

23.  使用以下命令部署 CDK 应用:

$ cdk deploy

24.  一旦部署了应用，并因此创建了 CodeCommit 存储库，我们现在就可以签入代码，以便其他团队可以访问这些资源。运行以下命令来初始化和更新存储库:

$ CLONE_URL=$(aws cloudformation describe-stacks --stack-name acme-web-application --query "Stacks[0].Outputs[?OutputKey=='CloneURL'].OutputValue" --output text)
$ git remote add origin $CLONE_URL
$ git add -A
$ git commit -m "Initial commit"
$ git push --set-upstream origin main

现在，CDK 应用已经部署好了，你会注意到我们引导它的方式不同于前几章中 CDK 的例子。这是因为我们正在使用 **CDK 管道**。CDK 管道本质上允许我们创建一个自我变异的 CI/CD 管道，将 **CDK 栈**部署为管道**阶段**。管道是*自变异*的，因为它自动构建各种管道资产，并在添加、更新或删除 CDK 构造时动态调整其工作流。

注意

关于 CDK 管道的更多信息，可以参考发布博客([https://AWS . Amazon . com/blogs/developer/CDK-Pipelines-continuous-delivery-for-AWS-CDK-applications/](https://aws.amazon.com/blogs/developer/cdk-pipelines-continuous-delivery-for-aws-cdk-applications/))。

正如我们将看到的，这一概念非常适合 MLSDLC 流程，因为它基本上允许每个跨职能团队创建、拥有和动态提供相关的 AWS 资产，这些资产与他们作为 CDK 结构对整个 MLSDLC 流程的贡献有关。

注意

由于多个跨职能团队将在本章和下一章中添加他们对代码源的贡献，在*步骤 17* 中，我们已经将`self_mutation`参数设置为`False`。这将防止管道自变异，直到所有相关的代码贡献都已完成。

这就完成了来自平台团队的*当前*代码贡献。正如*图 10.3* 所示，我们将考察的下一个角色是前端开发团队。

## 检查前端开发人员的角色

由于 ACME 应用涉及到部署网站，MLSDLC 流程需要一个 web 开发人员团队。根据*图 10.3* ，我们看到 web 开发人员与应用所有者互动，以确定网站所需的外观和感觉——本质上是网站设计规范。

该团队还与平台团队交互，以创建前端和后端服务之间的必要接口。

注意

由于一些 MLSDLC 资产的复杂性，并且为了确保本例中的一致性，大部分代码已经在 GitHub 存储库中为您创建了(https://GitHub . com/packt publishing/Automated-Machine-Learning-on-AWS/tree/main/chapter 10)。因此，本章中的一些任务只是简单地从配套的存储库中复制代码。你会记得我们已经在 [*第四章*]中为机器学习*克隆了支持代码到 Cloud9 工作区。

让我们回顾一下这个团队如何通过创建应用的 web 资产来为 MLSDLC 流程做出贡献。请遵循以下步骤:
1.  继续在 Cloud9 环境中，在 IDE 终端窗口中运行以下命令，通过运行以下命令将网站工件移动到我们在上一节中创建的存储库中:

$ cd ~/environment
$ cp -R src/Chapter10/www acme-web-application/

2.  通过运行以下命令将这些新的网站文件提交到 MLSDLC 源存储库:

$ cd ~/environment/acme-web-application
$ git add -A
$ git commit -m "Added website files"
$ git push

通过提交各种**超文本标记语言**(**HTML**)**级联样式表** ( **CSS** )文件和网站**图片**，这个实质上完成了前端开发团队对 MLSDLC 的贡献。

在这些不同的网站资产中，最重要的 HTML 文件是`index.html`文件。在`index.html`文件中代码的末尾，您将看到两个 JavaScript 函数——即`submitContactForm()`和`submitPredictForm()`函数。通过与平台团队合作开发这些功能，前端团队可以确保创建适当的后端资源来支持在这些表单中提交的数据——一个用于联系人处理，一个用于*年龄计算器*预测。

一旦平台团队创建了这些后端资源，我们就有效地拥有了一个完整的 web 应用。然而，我们仍然需要为应用创建 ML 组件。让我们从 ML 从业者和数据工程团队的角度进一步探索这些组件。

## 检查 ML 和数据工程角色

在前面的章节中，我们使用术语 **ML 从业者**作为任何负责 ML 过程自动化的人的总称。在 MLSDLC 流程的环境中，我们通常会看到该角色分为两个不同的功能，即:
*   **数据科学家**:数据科学家主要负责构建、训练和调整满足用例业务需求的 ML 模型。
*   **ML 工程师**:在众多的职责中，ML 工程师主要负责设计整个 ML 系统以支持模型，管理用于模型训练的适当数据集，并确保最终的 ML 应用解决用例的业务需求。

然而，出于 ACME 应用示例的考虑，我们将这两个功能归入 ML 团队，下图突出显示了该团队如何融入 MLSDLC 流程:
![Figure 10.4 – The ML practitioner team's role within the MLSDLC process
]

图 10.4–ML 从业者团队在 MLSDLC 流程中的角色

从*图 10.4* 可以看出，应用所有者与 ML 团队一起评估 ML 是否可以应用于业务案例。你应该还记得，我们在 [*第 1 章*] B17649_01_ePub.xhtml##_idTextAnchor015

因此，一旦确定 ML 适合商业案例，下一步就是确定我们是否有*支持 ML 模型的数据*。在这一点上，ML 工程师和数据工程师就数据源、访问要求、数据类型以及如何为 ML 模型重新设计数据进行协调。由于 ACME 用例使用来自**加州大学欧文分校** ( **UCI** ) *机器学习库*的数据，我们将放弃与数据工程师接口的这一步。

然而，在 MLSDLC 的背景下，我们将引入一种通常由 ML 工程师执行的技术，以进一步简化训练数据处理和**特征工程** ( **FE** )任务——使用 a **特征库**。

## 创建 SageMaker 特色商店

在 *re:Invent 2020* 上，AWS 在推出了一项 SageMaker 功能，名为 **SageMaker 功能商店**。这允许团队创建、存储并重用预处理和工程化特征，基本上消除了每次需要训练模型时不断执行数据预处理作业和 FE 任务的需要。

注意
AWS 在 Amazon SageMaker 示例 GitHub 存储库中([https://GitHub . com/AWS/Amazon-sage maker-examples/tree/master/sage maker-featurestore](https://github.com/aws/amazon-sagemaker-examples/tree/master/sagemaker-featurestore))提供了几个用于创建功能商店的示例笔记本。我们将重用这些例子中的代码，在 **Apache 2.0** 许可下许可，并使它们适应我们的用例。

以下步骤将带领我们创建鲍鱼数据集要素的存储:
1.  在你的 AWS 账户中，打开**亚马逊 SageMaker** 管理控制台，点击左侧导航面板中的 **SageMaker 域**链接。
2.  点击**启动应用**下拉菜单，选择**工作室**链接，启动工作室**用户界面** ( **界面**)。
3.  因为配套的 GitHub 库已经被克隆到 Studio UI 中，使用的是`src`文件夹，然后双击`Chapter10`文件夹，然后是`Notebooks`文件夹。
4.  现在，双击`SageMaker Feature Store Example.ipynb`笔记本启动它。
5.  笔记本打开后，等待笔记本内核启动。
6.  在菜单栏中选择**内核**，选择**重启内核并运行所有单元……**选项。
7.  When prompted on the **Restart Kernel?** dialog box, click the **Restart** button.
    注意
    运行这些笔记本大约需要 10 分钟。请务必记下特性组的名称，因为我们将在下一章中引用它。

让我们回顾一下通过执行本笔记，我们完成了哪些工作，如下所示:
*   是最重要的。我们还声明了一些助手函数，使用`check_feature_group_status()`函数跟踪特性库的创建状态，并使用`check_data_availabiltiy()`函数跟踪特性数据在库中的接收。您还会看到，我们引用了平台团队在*检查平台工程师*部分创建的 S3 数据桶(`data_bucket`)，从**系统管理器参数存储** ( **SSM** )中提取桶名参数。
*   在`get_dummies()`方法中，我们将性别特征设计成数值。然后，我们将这些新特性存储为一个名为`processed_data`的数据帧。
*   最后，在`time_stamp`变量中，将摄取时间戳作为一个特性列绑定到我们的数据。这使我们能够根据添加到组中的时间来区分各个功能。然后，我们为特性组定义一个模式，创建它，并将`processed_data`数据帧接收到表中。

运行笔记本后，我们现在有了一个包含所有相关鲍鱼数据集特征的特征库，从而消除了每次训练模型时不断重新创建这些特征的需要。

因此，现在我们已经准备好了数据集，我们可以继续创建 ML 工件。

## 创建 ML 工件

从*图 10.4* 中，我们可以看到，在与数据团队协调之后，ML 团队与平台团队一起传达其需求，并向 web 应用提供特定于 ML 的代码贡献，其中第一个就是模型工件。

### 创建模型工件

您将回忆起 [*第 5 章*] B17649_05_ePub.xhtml##_idTextAnchor078)*连续部署一个生产 ML 模型，*我们将算法代码，以及处理数据和训练的各种例程和评估模型打包成一个容器映像。这允许我们使用 SageMaker 的**自带容器** ( **BYOC** 

在 MLSDLC 示例的上下文中，在数据科学家构建了正确的 ML 解决方案后，他们可以为该解决方案构建、训练、调整和评估生产级模型，使用我们在 [*第 4 章*]*中使用的相同笔记本示例来复制模型工件。然后，数据科学家可以将这些组件打包到 ACME web 应用的容器工件中。

让我们通过以下步骤来模拟这个任务:
1.  使用 SageMaker Studio IDE 打开克隆的配套 GitHub 存储库的`src/Chapter10/Notebooks`文件夹中的`ACME Model Artifacts Example.ipynb`文件。
2.  一旦 **Python 3(数据科学)**内核启动，从菜单栏选择**内核**，选择**重启内核并运行所有单元……**选项。
3.  当**上提示重启内核时？**对话框，点击**重启**按钮。
4.  笔记本运行后，您应该会在左侧导航面板中看到一个`model`文件夹。该文件夹包含容器图像的相关模型工件。
5.  现在，从菜单栏点击**文件**，选择**新建**选项，然后点击**终端**选项，打开一个终端。
6.  在 terminal 选项卡中运行下面的命令，将模型工件添加到 web 应用源代码存储库中:

$ CLONE_URL=$(aws cloudformation describe-stacks --stack-name acme-web-application --query "Stacks[0].Outputs[?OutputKey=='CloneURL'].OutputValue" --output text)
$ git clone $CLONE_URL
$ mv ~/src/Chapter10/Notebooks/model acme-web-application/
$ cd acme-web-application/
$ git add -A
$ git commit -m "Initial commit of model artifacts"
$ git push

作为 ML 团队，我们现在已经创建了相关的模型工件，并将它们贡献给 web 应用存储库。然而，在进行下一步之前，让我们回顾一下运行笔记本时发生了什么。

如果你检查一下笔记本，你会发现我们遵循了与 [*第 5 章*] B17649_05_ePub.xhtml##_idTextAnchor078) 、*生产 ML 模型*的连续部署中的例子相似的过程，由此我们使用`%%writefile`魔法来创建一个`model.py`文件。该文件加载必要的 TensorFlow 库，为 SageMaker 容器环境设置全局变量，并以`train()`函数的形式定义一个模型训练例程。该函数在编译后的模型上定义训练和验证数据以及一个`fit(

在`app.py`文件中，它充当模型训练任务或模型推理任务的容器图像的入口点，这取决于 SageMaker 如何使用图像。在本节中，我们还初始化了 web 服务文件`nginx.conf`和`wsgi.py`，以便 SageMaker 可以托管和服务推理模型。

笔记本的最后一个部分创建了一个 Dockerfile 文件。该文件包含创建容器映像的构建指令。与前面的例子不同，我们没有拉一个**深度学习** ( **DL** )容器图像。相反，我们手动构建一个容器映像。

注意

手动构建 TensorFlow 容器映像(而不是提取 DL 容器映像)的主要原因是为了确保代码示例可以跨任何支持 CDK 管道和 SageMaker 的 AWS 区域工作。虽然 CDK 管道模块支持在`aws_cdk.pipelines.CodePipeline()`类中提供`docker_credentials`的能力，但是我们需要在示例代码中将凭证硬编码到 DL 容器**弹性容器注册库** ( **ECR** )存储库。因此，为了确保示例代码统一工作，我们将基于 Apache 2.0 许可证下提供的 DL 容器源([https://github . com/AWS/deep-learning-containers/blob/master/tensor flow/training/docker/2.6/py3/docker file . CPU](https://github.com/aws/deep-learning-containers/blob/master/tensorflow/training/docker/2.6/py3/Dockerfile.cpu))手动构建一个容器。

在`Dockerfile`中，还将看到我们安装了一个名为`awswrangler`的额外 Python 库(https://github . com/aw slabs/AWS-data-wrangler)。 **AWS Data Wrangler** 是 AWS 开发的开源库，允许与各种 AWS 服务轻松集成，例如**亚马逊 Athena** 、 **AWS Glue** 和**亚马逊红移**。由于训练数据存储在 SageMaker 特征库中，我们将使用该库选择特征数据，并将其存储为模型训练的数据帧。

开发模型工件并没有完成 ML 团队对 MLSDLC 例子的贡献。如果您还记得前面的章节，ML 团队还需要贡献各种额外的工件来自动化模型构建和评估过程。让我们在下一节探索这些额外的工件。

### 构建自动化 ML 工作流工件

在前面的章节中，我们已经回顾了多种自动化模型训练和评估过程的技术。例如，在 [*第 6 章*] B17649_06_ePub.xhtml#_idTextAnchor094) 、*使用 AWS 步骤函数自动化机器学习过程*和 [*第 8 章*](B17649_08_ePub.xhtml#_idTextAnchor115

因此，在 MLSDLC 示例的上下文中，ML 团队通过提供作为 CDK 管道的一部分执行的编码工作流，进一步为 ACME web 应用做出了贡献。为此，让我们从 ML 工程师的角度来看一下构建这些工件的过程。以下是我们需要遵循的步骤:
1.  作为 ML 工程师，我们需要用模型工件的最新更新来更新克隆的存储库。使用 Cloud9 IDE 工作区终端窗口，运行以下命令:

$ cd ~/environment/acme-web-application/
$ git pull

2.  在左侧的导航面板中，创建一个名为`stacks`的文件夹来保存 CDK 构造。你可以通过右击`acme_web_application`文件夹并选择`stacks`来完成。
3.  通过运行以下命令，将预先构建的堆栈结构从配套的 GitHub 存储库中复制到该文件夹:

$ cp ~/environment/src/Chapter10/Files/cdk/ml_workflow_stack.py acme_web_application/stacks/

4.  使用左侧导航面板，双击`ml_workflow_stack.py`文件进行查看。

在前面的章节中，我们已经回顾了自动化 ML 工作流的不同方法——即 AWS 步骤功能和 MWAA。在 *re:Invent 2020* 大会上，AWS 推出了一个名为 SageMaker Pipelines 的本机 SageMaker 模块来协调 ML 流程。当我们查看`ml_workflow_stack.py`文件时，您会注意到我们使用 AWS Step 函数而不是使用 SageMaker 管道来自动化 ML 过程，原因有两个。首先，你应该已经熟悉使用 AWS 步骤函数，来自第 6 章*、*使用 AWS 步骤函数*自动化机器学习过程中的数据科学 SDK 示例。*

其次，虽然 CDK 支持使用`CfnPipeline`构造([https://docs . AWS . Amazon . com/CDK/API/latest/python/AWS _ CDK . AWS _ SageMaker/cfnpipeline . html](https://docs.aws.amazon.com/cdk/api/latest/python/aws_cdk.aws_sagemaker/CfnPipeline.html))执行 SageMaker 管道，但是该构造要求管道作为工件在 CDK 项目之外单独进行编码和单元测试。在下一章中，我们将看到，通过将 AWS Step 函数集成到 CDK 项目中，编码、单元测试以及最终系统测试 ML 工作流的过程可以进一步自动化，成为自变异 CDK 管道的一部分。

既然`ml_workflow_stack.py`文件已经打开，让我们回顾一下 stack 构造创建的最重要的 AWS 资源。

#### 注册数据桶

在加载必要的 CDK Python 库和实例化`MLWorkflowStack()`类之外，我们声明的第一个变量是`data_bucket`变量。这里，我们将现有的 S3 存储桶引用为 CDK 对象，从而允许我们添加其他堆栈资源所需的各种权限，以添加和访问存储桶中的对象。例如，我们接下来使用`BucketDeployment()`构造，将 Python 脚本工件上传到`data_bucket`变量，以便这些对象可以用于工作流。

#### 创建占位符参数

接下来，我们声明两个 SSM 参数(`package_parameter`和`baseline_parameter`)作为占位符，以存储训练模型的名称和 SageMaker 模型监视器基线数据的 S3 存储桶位置。

#### 创建建模容器图像

由于我们现在已经创建了模型工件，我们可以将`model_image`参数定义为 ECR `DockerImageAsset()`资产，指向模型工件文件夹。正如您将看到的，通过声明该资产，自变异 CDK 管道将动态创建一个代码构建作业来构建容器映像，而无需我们声明单独的代码管道构建阶段。

#### 创建模型注册表

接下来，我们创建一个名为`registry_creator`的 AWS Lambda 函数变量。这个 Lambda 函数创建一个 SageMaker 模型注册表([https://docs . AWS . Amazon . com/sage maker/latest/DG/model-registry . html](https://docs.aws.amazon.com/sagemaker/latest/dg/model-registry.html))来存储在工作流执行时自动训练的各种模型版本。一旦声明了`registry_creator` Lambda 函数，我们就使用`CustomResource()`构造将它作为自定义资源调用。

注意

虽然 CDK 提供了一个名为`CfnModelPackageGroup`([https://docs . AWS . Amazon . com/CDK/API/latest/python/AWS _ CDK . AWS _ SageMaker/cfnmodelpackagegroup . html](https://docs.aws.amazon.com/cdk/api/latest/python/aws_cdk.aws_sagemaker/CfnModelPackageGroup.html))的 SageMaker 构造来注册经过训练的模型包，但是我们在这里使用一个 Lambda 函数来执行相同的任务。当我们在本章后面定义 Lambda 工件时，您将会看到，使用 Lambda 函数将允许我们在删除模型注册之前删除现有的模型包——这是`CfnModelPackageGroup`构造所不能做到的。

#### 创建 ML 实验

在我们将工作流定义为步骤功能状态机之前，我们需要定义将在工作流中使用的工件。第一个工件是用于版本跟踪的`experiment_creator` `executionId`，以便可以跟踪工作流的每次执行。这使得 ML 团队可以跟踪生产模型的谱系，从用于训练的数据到模型是如何被训练的以及模型是如何被评估的，就像 SageMaker 实验一样。这些信息对于审计目的和模型解释非常有用，并为生产模型监控提供了额外的环境。

#### 评估模型

下一个工件定义是`evaluate_results` Lambda 函数。该功能从工作流程中正在接受训练的当前模型的*中读取模型评估结果，以及来自之前*训练的任何*模型的评估结果，以确定当前*模型的性能是否有所改进。这样，我们可以保证生产模型总是性能最好的模型，不会被较差的模型覆盖。如果模型的性能提高了，我们使用`register_model` Lambda 函数用最新的、最好的模型更新模型注册。这是最终将部署到生产中的模型。**

#### 创建 pagemaker 作业

既然已经定义了工作流的λ工件，我们就可以构建各种 SageMaker **应用编程接口** ( **API** )调用了。对 SageMaker 有三个特定的 API 调用，如下所示:
*   `CreateProcessingJob`(https://docs . AWS . Amazon . com/sage maker/latest/API reference/API _ createprocessingjob . html)进行数据处理，使用`processing_definition`状态 JSON
*   `CreateTrainingJob`([https://docs . AWS . Amazon . com/sagemaker/latest/API reference/API _ createtrainingjob . html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateTrainingJob.html))进行模型训练，使用`training_definition`状态 JSON
*   `CreateProcessingJob`，对于模型评估，使用`evaluation_definition`状态 JSON

为了定义每个作业的 API 规范，我们在工作流结构中创建了三个单独的定义参数，即:
*   `processing_definition`
*   `training_definition`
*   `evaluation_definition`
    注意
    由于我们已经创建了一个特征库来保存工程数据特征，您可能想知道为什么我们在工作流中包含了一个*数据处理定义*。虽然功能存储确实包含训练数据，但我们仍然需要将数据分为训练、验证和测试数据集。因此，通过使用`processing_definition`，我们正在卸载从特征存储中检索工程数据的任务，将数据分成训练、验证和测试数据集，并将它们存储在 S3 中。

#### 定义状态机

现在我们已经定义了各种工作流工件和 SageMaker 作业定义，我们可以声明 Step Functions 状态机的不同任务和状态。您将回忆起 [*第 4 章*]`类。

接下来，我们定义引导我们实现最终工作流目标的步骤，从`create_experiment_step`开始，拥有一个生产级模型。如您所见，这个变量是一个名为`LambdaInvoke()`的`aws_stepfunctions_task`函数，我们通过调用`experiment_creator`函数来初始化工作流跟踪的实验参数。

接下来的步骤是数据`processing_step`变量，通过它我们将`processing_definition`注册为步骤函数`CustomState()`。

注意

您可能已经注意到，在本书的各个示例中，CDK 一直在更新，虽然有一个用于 SageMaker 训练作业的 CDK 构造(https://docs . AWS . Amazon . com/CDK/API/latest/python/AWS _ CDK . AWS _ step functions _ tasks/sagemakercreatetrainingjob . html)，但在撰写本文时，目前还没有用于 SageMaker 处理作业的构造。因此，将这些工作流步骤定义为一个`CustomState()`函数。

在`processing_step`之后是`training_step`变量，它使用`training_definition`作为`CustomState()`来执行 SageMaker 训练任务。

注意

尽管 CDK 有一个`SageMakerCreateTrainingJob()`类，但在撰写本文时，这个类不支持添加 SageMaker 实验配置。因此，为了给训练任务添加血统跟踪功能，我们将`training_step`声明为`CustomState()`。

一旦模型被训练好，我们就可以使用 SageMaker 处理作业来评估它的性能。工作流的这一步由`evaluation_step`变量定义，并使用`evaluation_definition`变量向 SageMaker 提供必要的 API 配置。随后的`results_step`变量使用这些评估指标，通过调用`evaluate_results`λ来确定训练好的模型是否准备好用于生产部署。

在应用各种工作流逻辑步骤来指导整个流程之后，我们使用`workflow_definition`变量创建一个工作流作为步骤功能状态机。下图描述了状态机的最后一步功能:
![Figure 10.5 – ML workflow state machine
]

图 10.5–ML 工作流状态机

#### 最终确定工作流工件

一旦定义了工作流结构，ML 团队对 web 应用贡献的最后一部分就是提供结构中引用的各种工件，即`lambda`和`scripts`文件夹中的工件。以下步骤将引导您创建这些支持工件:
1.  继续在 Cloud9 IDE 中，在终端窗口中运行以下命令，为`registry_creator`、`experiment_creator`、`evaluate_results`和`register_model` Lambda 函数添加代码:

$ cd ~/environment/acme-web-application
$ mkdir lambda
$ cp -R ~/environment/src/Chapter10/Files/lambda/{createExperiment,evaluateResults,registerModel,registryCreator} lambda/

2.  现在，执行以下命令来复制`processing_step`和`evaluation_step`变量所需的脚本:

$ cd ~/environment/acme-web-application
$ cp -R ~/environment/src/Chapter10/Files/scripts .

3.  将这些更改提交到 web 应用源存储库，如下所示:

$ git add –A
$ git commit -m "Initial commit of ML Workflow artifacts"
$ git push

您可以查看单个函数文件夹中的每个`index.py`文件，以准确评估该函数在 ML 工作流中的作用。但是，您应该特别注意`scripts`文件夹中的`preprocessing.py`文件，以查看 AWS Data Wrangler 如何从功能存储中读取功能数据。例如，如果您参考以下代码片段，您可以看到 AWS Data Wrangler 使用亚马逊雅典娜([https://aws.amazon.com/athena/](https://aws.amazon.com/athena/))服务对原始功能商店数据执行**结构化查询语言** ( **SQL** )查询:

… if name == “main“:

…
query_string = f'SELECT {",".join(columns)} FROM "{table}" WHERE is_deleted=false;'

featurestore_df = wr.athena.read_sql_query(query_string, database=database, ctas_approach=False)

…
X = shuffle(featurestore_df).to_numpy()
…
training, validation, testing = np.split(X, [int(.8*len(X)), int(.95*len(X))])
…

由于特性存储本质上是原始特性数据的元存储，原始特性数据存储在 S3 的 Parquet 文件中，因此 Athena 可用于直接对数据执行 interactive SQL 查询。从突出显示的代码片段中可以看出，我们使用 AWS Data Wrangler 通过`athena.read_sql_query()`方法选择相关的特性列，并将结果存储为 DataFrame。代码继续重组数据，从查询中删除任何有序索引，并将数据拆分为特定的训练、验证和测试数据集。

因此，在作为 ML 团队运行了前面的步骤之后，我们已经正式地向 ACME web 应用贡献了所需的 ML 工件，因此我们可以签署与平台团队的交互。然而，ML 团队还需要与另外一个群体互动——前端开发人员。

### 向前端应用添加 ML

在*图 10.4* 中，我们可以看到 ML 团队在 MLSDLC 的上下文中的最终交互是与前端团队的交互。在这个项目中，这两个团队确定需要做出哪些 web UI 更改，以便 web 应用用户针对生产 ML 模型做出推论——本质上，用户将不可避免地使用*年龄计算器*。

这需要 web 开发人员创建一个 HTML 表单，渔民可以通过这个表单将鲍鱼的物理尺寸输入到 web UI 中，并让生产级 ML 模型预测年龄。

注意
HTML 表单代码和支持的 JavaScript 函数已经为您提供了。您可以通过引用`index.html`文件中的`predictionModel` HTML 代码和`submitPredictForm()` JavaScript 代码来查看这段代码。

在完成必要的代码更新，验证它们满足应用所有者概述的功能需求，并将这些提交到应用源代码库中之后，ML 团队可以签署其对 ACME web 应用的贡献。

如果我们的示例应用仅仅基于 SDLC 流程，那么从技术上来说，我们拥有了所有必需的构件来更新主干 CDK 管道，并使用 CI/CD 流程部署 web 应用。然而，由于我们正在创建一个基于 ML 的 SDLC，所以我们需要将最后一个组件整合到整个自动化流程中。让我们在下一节中探索这是什么。

## 创建持续训练工件

在 [*第八章*] B17649_08_ePub.xhtml##_idTextAnchor115

尽管我们在本章中关注的是 MLSDLC 过程，但是我们仍然有将新的调查数据合并到 ACME web 应用示例中的业务需求。*那么，我们如何在当前 CI/CD 渠道的背景下满足这一业务需求呢？*

这个问题的答案比较简单。因为我们正在使用 CI/CD 管道来自动化我们的 web 应用的交付(以及生产级 ML 模型)，所以我们可以简单地应用我们已经学到的东西，并在 ML 模型已经部署到生产中之后添加重新训练它的需求。这本质上是**持续训练** ( **CT** 背后的前提，由此我们添加了重启 CI/CD 流程的能力(一旦我们有了新数据)以创建自动化的 **CI/CD/CT** 方法。

由于数据工程团队负责在 [*第 8 章*] B17649_08_ePub.xhtml##_idTextAnchor115
![Figure 10.6 – The data team's role with the MLSDLC process
]

图 10.6–数据团队在 MLSDLC 流程中的角色

既然我们已经开始了解数据团队的整体角色，那么让我们深入了解他们对流程的贡献。

### 构建数据工作流工件

遵循与 ML 团队相同的程序，数据团队通过提供必要的 MWAA 基础设施组件来为 ACME web 应用做出贡献，这些组件作为 CDK 管道的一部分被执行。让我们从数据工程师的角度来看一下构建这些工件的过程，如下所示:
1.  作为一名数据工程师，打开 Cloud9 IDE 工作区，使用终端窗口，通过运行以下命令，从该书的 GitHub 存储库中复制预构建的堆栈结构:

$ cd ~/environment/acme-web-application/
$ cp ~/environment/src/Chapter10/Files/cdk/data_workflow_stack.py acme_web_application/stacks/

2.  使用左侧导航面板，双击`data_workflow_stack.py`进行查看。

一旦打开了`data_workflow_stack.py`文件，我们就可以查看由堆栈结构创建的重要基础设施资源。

正如您所看到的，在导入所需的 CDK 库之后，我们将`DataWorkflowStack()`类实例化为一个`cdk.Stack`构造。我们做的第一件事是注册`data_bucket`、`data_bucket_param`和特征组 SSM 参数(`group_name_param`)变量。我们这样做是为了给`airflow_role`分配相关的访问权限。

在定义了`airflow_role`和适当的`airflow_policy_document`变量(https://docs . AWS . Amazon . com/mwaa/latest/user guide/mwaa-create-role . html)之后，我们构建了的**虚拟私有云** ( **VPC** )，因为 mwaa 需要一个 VPC，加上各种网络组件来支持一个环境。

注意

您可能还记得 [*第八章*] B17649_08_ePub.xhtml##_idTextAnchor115

接下来，我们将 MWAA 环境实例化为`airflow_environment`变量，并创建一个 S3 部署构造来将气流 DAG 工件上传到 S3。

最后，我们创建一个名为`releaseChange`的 Lambda 函数来调用代码管道服务并启动管道执行。

现在 CT 资源已经被定义为 CDK 构造，数据团队要完成的下一个任务是构建该构造引用的各种工件，即`releaseChange` Lambda 代码和气流 DAG。以下步骤将向您展示如何做到这一点:
1.  使用 Cloud9 IDE 的终端窗口，运行下面的命令来复制预先构建的`releaseChange` Lambda 代码工件:

index.py file, in the acme-web-application/lambda/releaseChange folder, to see how the Lambda function uses the start_pipeline_execution() API call to trigger a CodePipeline execution.

2.  使用 Cloud9 工作区的左侧导航面板，右键单击`acme-web-application`文件夹并选择**新文件夹**选项。
3.  创建一个名为`airflow`的文件夹。
4.  右击新创建的`airflow`文件夹，选择**新文件**选项。
5.  创建一个名为`requirements.txt`的文件，双击它进行编辑。
6.  Add the following code to the `requirements.txt` file:

sagemaker==2.49.1
s3fs<=0.4
boto3>=1.17.4
numpy
pandas

    注意
    我们特别引用 SageMaker Python SDK 版本`2.49.1`的唯一原因是为了确保书中所有示例的一致性。
7.  保存并关闭`requirements.txt`文件。
8.  右键点击`airflow`文件夹，选择**新建文件夹**选项。
9.  创建一个名为`dags`的文件夹。
10.  右击新创建的`dags`文件夹，选择**新文件**选项。
11.  创建一个名为`continuous_training_pipeline.py`的文件，双击该文件进行编辑。
12.  添加以下代码以导入所需的 Python 库，从而访问功能库:

import time
import json
import sagemaker
import boto3
import numpy as np
import pandas as pd
from time import sleep
from datetime import timedelta
from sagemaker.feature_store.feature_group import FeatureGroup

13.  接下来，添加所需的 Apache Airflow 库来构建 DAG，如下所示:

import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
from airflow.providers.amazon.aws.hooks.lambda_function import AwsLambdaHook
from airflow.providers.amazon.aws.sensors.s3_prefix import S3PrefixSensor

14.  现在，添加以下代码来创建全局变量，以引用来自 SSM 的 S3 `data_bucket`、`releaseChange` Lambda 函数和特性组名称(`fg_name`)参数:

sagemaker_session = sagemaker.Session()
region_name = sagemaker_session.boto_region_name
data_bucket = f"""{boto3.client("ssm", region_name=region_name).get_parameter(Name="DataBucket")["Parameter"]["Value"]}"""
data_prefix = "abalone_data"
lambda_function = f"""{boto3.client("ssm", region_name=region_name).get_parameter(Name="ReleaseChangeLambda")["Parameter"]["Value"]}"""
fg_name = f"""{boto3.client("ssm", region_name=region_name).get_parameter(Name="FeatureGroup")["Parameter"]["Value"]}"""

15.  现在，添加以下代码来初始化 Airflow DAG 默认配置:

default_args = {
    "owner": "airflow",
    "depends_on_past": False,
    "start_date": airflow.utils.dates.days_ago(1),
    "retries": 0,
    "retry_delay": timedelta(minutes=2)
}

16.  接下来，我们将在气流 DAG 的每一步中执行的代码定义为 Python 函数。第一个函数(称为`start_pipeline`)调用`releaseChange` Lambda 函数来触发 CI/CD/CT 管道的执行。用下面的代码定义这个函数:

def start_pipeline():
    hook = AwsLambdaHook(
        function_name=lambda_function,
        aws_conn_id="aws_default",
        invocation_type="RequestResponse",
        log_type="Tail",
        qualifier="$LATEST",
        config=None
    )
    request = hook.invoke_lambda(payload="null")
    response = json.loads(request["Payload"].read().decode())
    print(f"Response: ")

17.  The next function (called `update_feature_group`) takes the newly added abalone survey data, encodes the sex feature as numerical data, creates a `time_stamp` variable, and ingests this new data into the Feature Store. The code is illustrated in the following snippet:

def update_feature_group():
    fg = FeatureGroup(name=fg_name, sagemaker_session=sagemaker_session)
    column_names = ["sex", "length", "diameter", "height", "whole_weight", "shucked_weight", "viscera_weight", "shell_weight", "rings"]
    abalone_data = pd.read_csv(f"s3://{data_bucket}/{data_prefix}/abalone.new", names=column_names)
    data = abalone_data[["rings", "sex", "length", "diameter", "height", "whole_weight", "shucked_weight", "viscera_weight", "shell_weight"]]
    processed_data = pd.get_dummies(data)
    time_stamp = int(round(time.time()))
    processed_data["TimeStamp"] = pd.Series([time_stamp] * len(processed_data), dtype="float64")
    fg.ingest(data_frame=processed_data, max_workers=5, wait=True)
    sleep(300)

    注意
    `update_feature_store`功能本质上执行与 ML 工程师在`SageMaker Feature Store Example.ipynb`笔记本中创建的代码相同的任务，除了之前的代码使用更新的鲍鱼调查数据更新现有的特征组，而不是从 UCI *机器学习库*下载的原始数据。
18.  既然已经定义了任务执行功能，我们就可以创建 DAG 工作流了。以下代码使用默认参数初始化名为`acme-data-workflow`的 DAG:

with DAG(
    dag_id=f"acme-data-workflow",
    default_args=default_args,
    schedule_interval="@daily",
    concurrency=1,
    max_active_runs=1,
) as dag:

19.  使用 DAG 的第一步是使用`S3PrefixSensor()` provider 类来观察 S3 数据桶中的任何新数据。代码如下面的代码片段所示:

    s3_trigger = S3PrefixSensor(  
        task_id="s3_trigger",
        bucket_name=data_bucket,
        prefix=data_prefix,
        dag=dag
    )

20.  一旦新的调查数据被上传到 S3，Airflow 通过使用 Airflow `PythonOperator()`提供者执行`update_feature_group`函数来执行 DAG 的第二步。代码如下面的代码片段所示:

    update_fg_task = PythonOperator(
        task_id="update_fg",
        python_callable=update_feature_group,
        dag=dag
    )

21.  工作流的最后一步是通过调用`releaseChange` Lambda 函数启动代码管道执行来触发 CI/CD/CT 管道的发布变更。气流步骤通过使用`PythonOperator()`提供者调用`start_pipeline`函数来完成这个任务。代码如下面的代码片段所示:

    trigger_release_task = PythonOperator(
        task_id="trigger_release_change",
        python_callable=start_pipeline,
        dag=dag
    )

22.  现在已经定义了 DAG 步骤，代码的最后一部分将它们链接在一起以完成 DAG，如下所示:

    s3_trigger >> update_fg_task >> trigger_release_task

23.  保存并关闭`continuous_training_pipeline.py`文件。
24.  运行以下命令提交数据团队对 ACME web 应用存储库的贡献:

$ cd ~/environment/acme-web-application
$ git add -A
$ git commit -m "Initial commit of CT artifacts"
$ git push

通过完成前面的步骤，验证它们满足应用所有者概述的功能需求，并将这些提交到应用源代码存储库中，数据团队可以签署其对 ACME web 应用的贡献。

在示例中的这一点上，来自跨职能团队的所有相关贡献都已经开发完毕，ACME web 应用也几乎可以部署了。然而，在部署解决方案之前，还有一个团队需要参与进来。让我们在下一部分探讨这个团队的角色。

## 了解安全镜头

保护解决方案是 MLSDLC 中一项至关重要的任务。虽然大多数常见的 MLSDLC 实现通常会在出现安全问题时进行处理，但在将最终应用部署到生产环境中之前，主动评估其整体安全状况是一种良好的做法。

因此，本节不是对 ACME web 应用执行全面的安全审计，而是通过展示安全团队如何与跨职能团队的其他成员进行交互，来强调安全团队应该遵循的一些最佳实践。下图显示了安全小组在 MLSDLC 流程中扮演的总体角色:
![Figure 10.7 – The security team's role within the MLSDLC process
]

图 10.7–安全团队在 MLSDLC 流程中的角色

如图*图 10.7* 所示，安全团队需要做的第一件事是通过与数据团队合作，审查数据是如何被使用的。

## 保护数据

与数据团队合作时，应遵循以下准则，以确保所有数据的安全:
*   任何数据，无论是存储在数据库中还是文件系统中(本地或云中)，都应该加密。
*   从这些数据存储中读取或写入这些数据存储的任何数据都应该加密。
*   任何访问数据的应用或人员都应使用适当的访问控制进行授权。这些访问控制应包括日志记录功能，以确保可以跟踪和审核授权和未授权的访问。
*   No customer **personally identifiable information** (**PII**) with these data stores should be accessible by the data team or the ML team.
    注意
    有关这些建议的更多信息，请查看 AWS *安全、身份、&合规*网页的*数据保护*部分([https://AWS . Amazon . com/architecture/Security-Identity-Compliance](https://aws.amazon.com/architecture/security-identity-compliance))。

安全团队需要做的第二件事是与数据团队一起审查代码。

## 保护代码

在评审代码工件时，应遵循以下指南:
*   所有私有代码都应该放在安全的源代码存储库中，并有适当的访问控制来管理对代码的访问。对于 ACME web 应用示例，我们使用 CodeCommit，它提供了对存储库和分支级别的细粒度访问控制，同时还管理对存储库执行的各种任务的访问。
*   任何代码中都不应该有应用或用户凭据，也不应该有任何密码。这些*机密*应该存储在单独的存储中，比如 AWS Secrets Manager([https://aws.amazon.com/secrets-manager/](https://aws.amazon.com/secrets-manager/))，在那里可以控制、记录和审计访问。

在 ACME web 应用示例中，代码创建 AWS 资源这一事实进一步增加了代码的安全性。因此，建议安全团队也包括一名平台团队成员，以创建一个**安全运营(SecOps)团队**。这样，保护代码可以扩展到保护所提供的 AWS 资源。例如，CT 工件使用 VPC 创建 MWAA 基础设施。SecOps 团队应审查 VPC，以确保:
*   进出 VPC 以及 VPC 的所有网络流量都被记录和加密。
*   所有网络端口都是安全的，使用网络**访问控制列表**(**ACL**)和安全组。
*   创建的任何 IAM 角色都应该尽可能只授予执行角色所需任务所需的权限。

最后，但同样重要的是，安全团队必须与网站内容开发人员合作，以保护他们各自的工件。

## 保护网站安全

如图*10.7*所示，安全团队与之交互的最后一组是前端团队。以下是一些保护网站安全的建议:
*   所有网站内容应该只能通过安全的 web 服务器访问，换句话说，静态内容应该可以通过适当的 URL 访问，而不是直接访问，比如说，从 S3 桶。
*   进出网站的所有流量都应该使用适当的**安全套接字层** ( **SSL** )或**传输层安全** ( **TLS** )证书，使用**超文本传输协议安全** ( **HTTPS** )协议进行加密。
*   还建议安全团队包括合规性资源，以确保所有内容符合地区或国际可访问性标准。
*   所有可公开引用的内容或开源内容都必须记录在案，并包括适用的许可证。

这些前面的建议只涵盖了安全团队的几个重点领域，因为它与 ACME web 应用相关，但是一旦安全团队结束了对应用工件的审查并签字同意，我们就几乎可以将 ACME web 应用部署到生产环境中了。剩下要做的就是将每个团队的工件整合到 CDK 管道中。一旦平台团队完成了这项任务，管道就完成了，应用就可以部署到生产中了。这将是下一章的重点。

## 总结

在本章中，您已经了解了 MLSDLC 的概念，它是一个可以用来自动化基于 E2E ML 的应用的过程。我们还回顾了影响 MLSDLC 流程成功的三个关键因素，即人员、技术和流程。

通过关注*人员*成功因素，您还看到了跨职能团队如何在 MLSDLC 的规划和设计阶段一起工作，每个团队都提供符合业务目标并塑造解决方案整体设计的编码*技术*工件。

然而，我们还没有完成！在下一章中，我们将从我们停止的地方继续，平台团队将各种工件拼接到 E2E CI/CD/CT 管道中，从而自动化 MLSDLC 流程。

## 文章列表
- [AWS自动化机器学习-一、AWS 上的自动化机器学习入门](https://www.oomspot.com/post/shangdezidonghuajiqixuexirumen)
- [AWS自动化机器学习-七、使用 AWS 步骤函数构建 ML 工作流](https://www.oomspot.com/post/uzhouhanshugoujianmlgongzuoliu)
- [AWS自动化机器学习-三、使用 AutoGluon 技术自动化复杂的模型开发](https://www.oomspot.com/post/ishuzidonghuafuzademoxingkaifa)
- [AWS自动化机器学习-九、使用 Amazon Managed Workflows 为 Apache AirFlow 构建 ML 工作流](https://www.oomspot.com/post/acheairflowgoujianmlgongzuoliu)
- [AWS自动化机器学习-二、使用 SageMaker 自动驾驶器自动化机器学习模型开发](https://www.oomspot.com/post/izidonghuajiqixueximoxingkaifa)
- [AWS自动化机器学习-五、自动化 ML 模型的持续部署](https://www.oomspot.com/post/uzidonghuamlmoxingdechixubushu)
- [AWS自动化机器学习-八、使用 Apache Airflow 实现机器学习过程的自动化](https://www.oomspot.com/post/anjiqixuexiguochengdezidonghua)
- [AWS自动化机器学习-六、使用 AWS 步骤函数自动化机器学习过程](https://www.oomspot.com/post/nshuzidonghuajiqixuexiguocheng)
- [AWS自动化机器学习-十、机器学习软件开发生命周期（MLSDLC）简介](https://www.oomspot.com/post/fashengmingzhouqimlsdlcjianjie)
- [AWS自动化机器学习-十一、MLSDLC 的持续集成、部署和训练](https://www.oomspot.com/post/lcdechixujichengbushuhexunlian)
- [AWS自动化机器学习-四、机器学习的持续集成和持续交（CI/CD）](https://www.oomspot.com/post/idechixujichenghechixujiaocicd)
- [AWS自动化机器学习-第一部分：自动机器学习过程和 AWS 上的 AutoML 的基础知识](https://www.oomspot.com/post/eawsshangdeautomldejichuzhishi)
- [AWS自动化机器学习-第三部分：优化以源代码为中心的自动化机器学习方法](https://www.oomspot.com/post/gxindezidonghuajiqixuexifangfa)
- [AWS自动化机器学习-第二部分：通过持续集成和持续交付（CI/CD）实现机器学习过程的自动化](https://www.oomspot.com/post/anjiqixuexiguochengdezidonghua)
- [AWS自动化机器学习-第五部分：自动化 AWS 上的端到端生产应用](https://www.oomspot.com/post/deduandaoduanshengchanyingyong)
- [AWS自动化机器学习-第四部分：优化以数据为中心的自动化机器学习方法](https://www.oomspot.com/post/gxindezidonghuajiqixuexifangfa)
- [AWS自动化机器学习-零、前言](https://www.oomspot.com/post/szidonghuajiqixuexilingqianyan)

AWS自动化机器学习-十、机器学习软件开发生命周期（MLSDLC）简介

技术要求

mls DLC 简介

构建应用平台

检查应用所有者的角色

审视平台工程师的角色

!/usr/bin/env python3

更多推荐

更多

Apache CN

近期文章

更多

AWS自动化机器学习-第一部分：自动机器学习过程和 AWS 上的 AutoML 的基础知识

AWS自动化机器学习-第四部分：优化以数据为中心的自动化机器学习方法

AWS自动化机器学习-第二部分：通过持续集成和持续交付（CI/CD）实现机器学习过程的自动化

AWS自动化机器学习-十、机器学习软件开发生命周期（MLSDLC）简介

AWS自动化机器学习-三、使用 AutoGluon 技术自动化复杂的模型开发

AWS自动化机器学习-第五部分：自动化 AWS 上的端到端生产应用

热门标签

更多

推荐作者

更多