在云端用 Azure ML SDK 训练、部署与调用心衰预测模型：Data-Science-For-Beginners 第 19 课实战指南

导读

本文是 Data-Science-For-Beginners 课程 "Data Science in the Cloud" 系列中的 Azure ML SDK 实战篇，讲解如何放弃图形界面，改用 Azure Machine Learning Python SDK 以纯代码的方式完成"训练 → 部署 → 调用"一条完整的机器学习流水线。你将学会创建 Workspace / Experiment / Compute Cluster，配置并提交 AutoML 分类任务，导出最佳模型并注册，通过 Azure Container Instances（ACI）将其部署为 REST 端点，最后用 SDK 发送心衰临床样本并解析预测结果——这套能力与上一篇 Low code/No code 课程 处理完全相同的业务问题，但全程可脚本化、可自动化、可进入生产环境。

1. Azure ML SDK 是什么，为何要用它

Azure Machine Learning SDK 是面向数据科学家与 AI 开发者的一组 Python 库，用来构建和运行基于 Azure Machine Learning 服务的机器学习工作流。它可以在任意 Python 环境中使用，包括 Jupyter Notebook、Visual Studio Code 以及你常用的 Python IDE。SDK 的主要能力覆盖以下几个方面：

• 数据生命周期管理：探索、准备并管理机器学习实验中使用的数据集。
• 云端资源编排：管理用于监控、日志记录和组织实验的云端资源。
• 模型训练：既可以在本地训练，也可以调用云端资源（包括 GPU 加速）训练模型。
• 自动化机器学习（AutoML）：只需提供配置参数与训练数据，系统会自动遍历候选算法与超参数组合，找出最适合做预测的模型。
• 服务化部署：把训练好的模型发布为可被任意应用消费的 RESTful Web 服务。

1.1 为什么在低代码路线之后还要掌握 SDK

在 第 18 课（Low code/No code） 中，我们使用同样的 Heart Failure（心衰）数据集，在 Azure ML Studio 的图形界面里完成了一次"心衰风险预测"项目的训练、部署与调用。而本课要完成的目标与它完全一致，唯一的差别是：所有操作都改由 Azure ML SDK 以编程方式驱动。

两条路线各有取舍，理解其中的差异对工程选型很有帮助：

对比维度	Low code/No code	Azure ML SDK
代码能力要求	不需要	需要
开发速度	快且简单	取决于代码熟练度
生产就绪	否	是

图形界面便于快速验证项目可行性与搭建概念验证（POC）；但项目一旦成长、需要"生产就绪"，依靠 GUI 逐个点击创建资源、部署模型就不可行了——资源的创建到模型的部署都应程序化自动化，这正是本课引入 SDK 的核心原因。下图来自本仓库，直观对比了两种方式处理同一数据科学项目的整体架构：都是从数据集出发，经 AutoML 训练得到最佳模型，再部署、最终消费端点，只是上层走低代码、底层走 SDK 代码。

1.2 心衰预测项目与数据集回顾

本课使用的业务背景、数据集结构与字段语义，与第 18 课完全相同，详细说明可参见 心衰预测项目与数据集介绍。这里做必要回顾，方便理解后续代码中的特征与标签列。

心血管疾病（CVDs）是全球第一大死因，约占全球死亡总数的 31%。如果能基于烟草使用、不健康饮食、肥胖、缺乏运动等风险特征估算个体罹患 CVD 的概率，就有望对高危人群提前干预。本项目使用 Kaggle 公开的 Heart Failure clinical data 表格数据集，共 13 列（12 个特征 + 1 个目标变量）、299 行：

变量名	类型	说明
age	数值	患者年龄
anaemia	布尔	是否贫血（红细胞或血红蛋白减少）
creatinine_phosphokinase	数值	血液中 CPK 酶水平
diabetes	布尔	是否患有糖尿病
ejection_fraction	数值	每次心脏收缩时离开心脏的血液百分比
high_blood_pressure	布尔	是否患有高血压
platelets	数值	血液中的血小板数量
serum_creatinine	数值	血液中的血清肌酐水平
serum_sodium	数值	血液中的血清钠水平
sex	布尔	性别（女 / 男）
smoking	布尔	是否吸烟
time	数值	随访期（天）
DEATH_EVENT（目标列）	布尔	随访期内患者是否死亡

在低代码课程中创建数据集时，会要求把 anaemia、diabetes、high_blood_pressure、sex、smoking、DEATH_EVENT 等列在 Schema 中显式声明为 Boolean 类型——SDK 路线读取该数据集时同样依赖这一预定义的类型信息，因此数据集加载步骤（见 2.3）与第 18 课保持一致。

2. 用 Azure ML SDK 训练模型

本节是从零开始的完整训练流程：先准备 Workspace 与计算资源（2.1/2.2），再加载数据集（2.3），创建 Notebook（2.4），最后在代码中完成 AutoML 训练（2.5）。本仓库已附带一份完整的可执行实现，即 19-Azure 的 notebook.ipynb（另有 solution 目录 存放其解决方案版本），你可以直接对照下文逐段阅读。

2.1 创建 Azure ML Workspace（前置条件）

为简化演示，本课约定在 Jupyter Notebook 中进行开发，这隐含两个前提：你已经拥有一个 Workspace，并且已经创建了一个 Compute instance。

• 如果还没有 Workspace，请按 上一课 §2.1 创建 Azure ML Workspace 的指引先在 Azure 门户完成创建（需填写订阅、资源组、Workspace 名称、区域等信息）。
• 如果已有 Workspace，可以直接跳到 2.4 的 Notebook 创建部分。

2.2 创建 Compute Instance

在之前创建的 Azure ML Workspace 中，进入 Compute 菜单即可看到各类计算资源（Compute instances、Compute clusters、Inference clusters、Attached computes）的入口。其中，Compute Instance 是供数据科学家使用的开发工作站——Azure 会为其创建一台虚拟机并启动 Notebook 实例，之后我们可以在 Notebook 中远程调用计算集群训练模型。

创建步骤如下：

1. 点击 + New 按钮。
2. 为你的计算实例命名。
3. 选择配置：CPU 还是 GPU、VM 规格（VM size）与核心数。
4. 点击 Create 按钮。

创建完成后即可在实例列表中看到该 Compute Instance，本课后续将用它创建 Notebook。

选型提示：CPU 擅长按时钟频率快速处理串行任务，但并发能力有限、成本较低；GPU 专为并行计算设计，训练深度学习模型明显更快，但成本更高。若预算紧张而时间充裕，可从小集群起步；反之可从大集群起步。Compute Instance 仅作为开发工作站按需付费，任务间隙记得停止以节省开销。

2.3 加载数据集（前置条件）

本课通过 ws.datasets 按名字获取数据集，因此请先确认数据集已经上传到 Azure ML，且数据集的 key 与代码中的名字完全一致。若尚未上传，请参照 上一课 §2.3 加载数据集：在 Studio 的 Datasets 菜单中从本地文件创建数据集、命名并选择类型，并在 Schema 中把布尔特征设为 Boolean 类型。

2.4 创建 Notebook

Notebook 是数据科学流程中极为重要的一环：它可以承载探索性数据分析（EDA）、远程调用计算集群去训练模型、也可以调用推理集群去部署端点。

NOTE：下一步你可以选择从零新建 Notebook，也可以直接把我们制作好的 notebook.ipynb 上传到你的 Azure ML Studio——在 "Notebook" 菜单中点击上传即可。

创建 Notebook 需要一个正在提供 Jupyter 服务的计算节点，操作如下：

1. 回到 Azure ML Workspace，点击 Compute instances，在实例列表中找到我们在 2.2 创建的实例。
2. 在 Applications 一栏点击 Jupyter 选项，勾选 "Yes, I understand" 后点击 Continue。此时实例列表中实例右侧应提供 JupyterLab / Jupyter / VS Code 等开发环境入口：

3. 浏览器会新开标签页打开 Jupyter Notebook 实例（包含 Files / Running / Clusters 等页签），点击 New 按钮即可创建新的 Notebook。

获得 Notebook 后，就可以开始用 Azure ML SDK 训练模型了。训练前，先在 Notebook 的第一个代码单元格中集中导入本课将用到的 SDK 模块（与 notebook.ipynb 首段保持一致）：

from azureml.core import Workspace, Experiment
from azureml.core.compute import AmlCompute
from azureml.train.automl import AutoMLConfig
from azureml.widgets import RunDetails
from azureml.core.model import InferenceConfig, Model
from azureml.core.webservice import AciWebservice

2.5 训练模型（Training a model）

本节代码涉及众多 SDK 模块，若对某个类的用法有疑问，随时可查阅 Azure ML SDK 官方文档（本课用到的主要对象：Workspace、Experiment、AmlCompute、AutoMLConfig、AutoMLRun、InferenceConfig、AciWebservice），文档中包含理解本节全部模块所需的接口说明。

2.5.1 初始化 Workspace、Experiment、Compute Cluster 与 Dataset

第 1 步：加载 Workspace。 通过配置文件加载工作区对象。前提是当前目录下存在 config.json 配置文件（内含 workspace 名称、资源组、订阅 ID 等信息）：

from azureml.core import Workspace
ws = Workspace.from_config()

返回的 ws 是 Workspace 类型对象，代表你的工作区。可打印 ws.name、ws.resource_group、ws.location、ws.subscription_id 确认连接信息。

第 2 步：创建 Experiment。 Experiment 用于组织多次训练运行（run），并保留每次运行的日志、指标、输出与脚本快照，供你判断哪次运行产出了最佳模型：

from azureml.core import Experiment
experiment_name = 'aml-experiment'
experiment = Experiment(ws, experiment_name)

Experiment 通过名称从 Workspace 中获取或创建：名称长度必须为 3–36 个字符，以字母或数字开头，且只能包含字母、数字、下划线与连字符。若该名称的 experiment 在 Workspace 中不存在，则自动新建。

第 3 步：创建 Compute Cluster。 训练需要远程计算目标（compute target）。下面的代码先在 Workspace 中按名字查找 heart-f-cluster，找不到就按 AmlCompute.provisioning_configuration 的配置创建——注意这一步可能耗时几分钟：

from azureml.core.compute import AmlCompute

aml_name = "heart-f-cluster"
try:
    aml_compute = AmlCompute(ws, aml_name)
    print('Found existing AML compute context.')
except:
    print('Creating new AML compute context.')
    aml_config = AmlCompute.provisioning_configuration(vm_size = "Standard_D2_v2", min_nodes=1, max_nodes=3)
    aml_compute = AmlCompute.create(ws, name = aml_name, provisioning_configuration = aml_config)
    aml_compute.wait_for_completion(show_output = True)

cts = ws.compute_targets
compute_target = cts[aml_name]

其中：

• vm_size="Standard_D2_v2" 指定节点 VM 规格（本课用通用型 D2 v2）。
• min_nodes=1 与 max_nodes=3 控制集群的伸缩范围——最小节点数设为 0 可以在集群空闲时省钱；最大节点数越大，训练通常越快（第 18 课建议最大节点数取 3）。
• 创建后通过 ws.compute_targets 取回命名计算目标，供后续 AutoML 配置使用。

第 4 步：加载数据集并做初步探查。 数据集此前已上传到 Workspace（见 2.3），通过名字直接取出并转成 pandas DataFrame：

dataset = ws.datasets['heart-failure-records']
df = dataset.to_pandas_dataframe()
df.describe()

df.describe() 可快速输出各数值列的统计描述（计数、均值、标准差、四分位数等），用来在训练前确认数据形态是否符合预期。

2.5.2 AutoML 配置与提交训练

AutoML 的核心入口是 AutoMLConfig 类。官方文档列举了大量可调参数，本课聚焦以下对项目结果影响最直接的参数：

参数	作用
experiment_timeout_minutes	实验允许运行的最大时长（分钟），超时自动停止并产出当前结果
max_concurrent_iterations	实验允许的最大并发训练迭代数
primary_metric	用于判定实验状态的主指标
compute_target	运行 AutoML 实验的计算目标
task	任务类型：classification、regression 或 forecasting
training_data	训练数据，应同时包含训练特征与标签列（可选含样本权重列）
label_column_name	标签列名
path	Azure ML 项目文件夹的完整路径
enable_early_stopping	若分数短期不再提升是否提前终止
featurization	是否自动执行特征化，或使用自定义特征化方案
debug_log	写入调试信息的日志文件

对应到本项目：

from azureml.train.automl import AutoMLConfig

project_folder = './aml-project'

automl_settings = {
    "experiment_timeout_minutes": 20,
    "max_concurrent_iterations": 3,
    "primary_metric" : 'AUC_weighted'
}

automl_config = AutoMLConfig(compute_target=compute_target,
                             task = "classification",
                             training_data=dataset,
                             label_column_name="DEATH_EVENT",
                             path = project_folder,
                             enable_early_stopping= True,
                             featurization= 'auto',
                             debug_log = "automl_errors.log",
                             **automl_settings
                            )

几个关键取值的含义：

• 任务是二分类（预测 DEATH_EVENT 为 true/false），故 task='classification'、label_column_name='DEATH_EVENT'。
• 由于类别可能存在不平衡，主指标选用 AUC_weighted（加权 AUC）而非 accuracy。
• 限制单次实验 experiment_timeout_minutes=20 分钟、并发 3 个迭代，既控制成本又保证尝试足够多的算法组合。
• enable_early_stopping=True 让 AutoML 在分数短期内不再提升时提前收敛，节省算力。
• featurization='auto' 表示自动特征化。
• 若训练过程出错，debug_log="automl_errors.log" 会把调试信息写入该文件便于排查。

配置就绪后，向 Experiment 提交运行——这一步的耗时取决于集群大小，最多可能接近一个小时：

remote_run = experiment.submit(automl_config)

提交后可以用 Jupyter 内嵌的 RunDetails 小组件实时查看各次迭代（run）的指标走势：

from azureml.widgets import RunDetails
RunDetails(remote_run).show()

3. 用 Azure ML SDK 部署模型并消费端点

3.1 保存最佳模型

experiment.submit 返回的 remote_run 是 AutoMLRun 对象，其 get_output() 方法返回最佳 run 及其对应的已拟合模型：

best_run, fitted_model = remote_run.get_output()

打印 fitted_model 可以查看最佳模型使用的算法与超参数；调用 get_properties() 可以查看该 run 的属性（如 model_name、primary_metric 得分等）：

best_run.get_properties()

拿到最佳模型后，用 register_model 方法把它注册进 Workspace 的模型注册表：

model_name = best_run.properties['model_name']
script_file_name = 'inference/score.py'
best_run.download_file('outputs/scoring_file_v_1_0_0.py', 'inference/score.py')
description = "aml heart failure project sdk"
model = best_run.register_model(model_name = model_name,
                                model_path = './outputs/',
                                description = description,
                                tags = None)

这段代码做了三件事：

1. 从 run 属性中取出 AutoML 生成的最佳模型名（model_name）。
2. 用 download_file 把 AutoML 自动生成的评分脚本 scoring_file_v_1_0_0.py（位于 run 的 outputs/ 目录下）下载保存为 inference/score.py——该脚本将被用作部署时的入口脚本（entry script），负责反序列化请求并把特征送入模型。
3. 调用 register_model 注册模型，并附上描述 "aml heart failure project sdk"。

3.2 模型部署（Deploy the best model）

模型注册后即可部署。这里引入两个关键类：

• InferenceConfig：描述用于部署的自定义环境配置（入口脚本 + 运行环境）。
• AciWebservice：把模型部署为 Azure Container Instances 上的 Web 服务端点；一个已部署的服务由模型、脚本与相关文件构成，最终表现为带 REST API 的负载均衡 HTTP 端点——可以向它发送数据并获得模型返回的预测。

部署通过 Model.deploy 方法完成：

from azureml.core.model import InferenceConfig, Model
from azureml.core.webservice import AciWebservice

inference_config = InferenceConfig(entry_script=script_file_name, environment=best_run.get_environment())

aciconfig = AciWebservice.deploy_configuration(cpu_cores = 1,
                                               memory_gb = 1,
                                               tags = {'type': "automl-heart-failure-prediction"},
                                               description = 'Sample service for AutoML Heart Failure Prediction')

aci_service_name = 'automl-hf-sdk'
aci_service = Model.deploy(ws, aci_service_name, [model], inference_config, aciconfig)
aci_service.wait_for_deployment(True)
print(aci_service.state)

要点说明：

• InferenceConfig(entry_script=..., environment=best_run.get_environment()) 复用 AutoML 最佳 run 的 Python 环境作为部署环境，确保评分脚本依赖与训练时一致。
• AciWebservice.deploy_configuration(cpu_cores=1, memory_gb=1, ...) 指定容器资源配额（1 核 CPU、1 GB 内存），并加上便于识别的标签与描述。
• Model.deploy(ws, 'automl-hf-sdk', [model], inference_config, aciconfig) 执行部署，服务名取 automl-hf-sdk。
• wait_for_deployment(True) 阻塞直到部署完成；随后打印的 aci_service.state 应为 Healthy（部署过程通常需要几分钟，也可在 Azure ML 门户中查看部署状态）。

3.3 消费端点（Endpoint consumption）

部署完成后即可消费端点。先构造一条待预测的样本输入——JSON 以 "data" 数组包裹单条患者的 12 个特征记录：

data = {
    "data":
    [
        {
            'age': "60",
            'anaemia': "false",
            'creatinine_phosphokinase': "500",
            'diabetes': "false",
            'ejection_fraction': "38",
            'high_blood_pressure': "false",
            'platelets': "260000",
            'serum_creatinine': "1.40",
            'serum_sodium': "137",
            'sex': "false",
            'smoking': "false",
            'time': "130",
        },
    ],
}

test_sample = str.encode(json.dumps(data))

把该 JSON 文本编码为字节串（str.encode）后，通过 ACI 服务的 run() 方法发送给模型做推理：

response = aci_service.run(input_data=test_sample)
response

预期输出为 '{"result": [false]}'——含义是：对这条 60 岁患者的输入样本，模型预测结果为 false，即该患者短期内发生心衰（死亡事件）的可能性较低。

恭喜！至此你已经用 Azure ML SDK 在云端完成了"训练 → 部署 → 消费"的完整闭环。

NOTE：项目完成后，别忘了删除所有相关资源（Compute Instance、Compute Cluster、ACI 服务乃至整个 Workspace），因为只要 Workspace 存在，Azure 订阅就会按数据存储等用量持续产生小额费用。

4. 深入挑战：用 Pipeline 编排工作流

本课只展示了 SDK 的一小部分能力。要想在真实项目中游刃有余，学会快速浏览 SDK 文档是重要技能。一个推荐的自学挑战是：查阅 Azure ML SDK 文档并找到 Pipeline 类——Pipeline 是若干 step 的集合，可以作为一条工作流被整体执行。

提示：在 SDK 文档中搜索 "Pipeline" 关键词，结果中会出现 azureml.pipeline.core.Pipeline 类。你可以尝试把本课"加载数据 → AutoML 训练 → 注册模型"的步骤改造成一条可复用的 Pipeline，感受从"手工编排 notebook 单元"到"程序化定义可重跑工作流"的工程化升级。

5. 回顾与延伸

本课核心成果回顾：

• 流程能力：掌握了在云端用 Azure ML SDK 训练模型（Workspace → Experiment → Compute Cluster → AutoML）预测心衰风险，并完成部署与端点消费的完整流程。
• 代码复用：全部步骤可脚本化，比 GUI 更适合自动化与生产环境；可对照 notebook.ipynb 中的 import 块与各代码单元格顺序执行，也可直接把它上传到自己的 Azure ML Studio 运行。
• 与低代码路线对照：与 第 18 课 使用同一数据集、同一目标列，建议对照两课的部署/消费代码，体会"图形点击"与"代码驱动"两种范式的差异，从而理解为何生产化场景必须依赖 SDK。

想进一步巩固，可以自行寻找新数据集（Kaggle、Azure Open Datasets 等公开来源），用同样的套路完成你自己的 "数据 → AutoML → 部署 → 消费" 项目。本课对应的课后实践任务 Data Science project using Azure ML SDK 给出了评分细则：最完整的做法包括查阅 SDK 文档自定义 AutoML 配置参数、通过 AutoML 跑通训练并查看模型解释（model explanations）、部署最佳模型并通过 SDK 成功消费端点。