2. Azure数据平台核心组件
在Azure机器学习工作流中，数据平台组件并不是“随便选一个能存文件的地方”那么简单。一次完整的ML任务通常包含数据采集、清洗与特征工程、模型训练、批量推理、结果回写与监控等阶段，每个阶段对存储的访问模式、一致性、吞吐、并发和查询能力要求都不同。Azure Storage、Azure SQL、Azure Synapse Analytics、Azure Data Lake Storage Gen2（简称ADLS Gen2）分别承担不同角色，理解它们的定位与边界，是后续设计端到端数据管道的基础。
四个组件的核心定位
Azure Storage是Azure最基础的持久化服务，包含Blob、File、Queue、Table等形态。在ML场景中，最常用的是Blob Storage：它适合存放原始数据集、图像、音频、模型文件、训练脚本、日志和中间产物。Blob按容器和Blob路径组织，支持块Blob、追加Blob和页Blob，其中块Blob适合大文件顺序读写，追加Blob适合日志追加。它的优势是成本低、容量近乎无限、可通过SAS令牌或托管标识授权，并且与Azure Machine Learning的数据存储（Datastore）和数据集（Data Asset）天然集成。
Azure SQL是托管的关系型数据库服务，提供事务一致性、主键/外键约束、索引和T-SQL查询能力。它适合存放结构化程度高、需要频繁按行更新、需要强一致性的业务数据，例如用户标签表、订单事实表、实验元数据、模型注册信息或小规模特征表。在ML工作流中，Azure SQL常作为特征来源或结果回写目标，但不适合直接承担TB级训练数据的全量扫描。
Azure Synapse Analytics是面向分析工作负载的一体化平台，核心包括专用SQL池（Dedicated SQL Pool，原SQL DW）、无服务器SQL池（Serverless SQL Pool）、Spark池和管道。专用SQL池采用MPP架构，适合对大规模结构化数据做聚合、连接和宽表构建；无服务器SQL池可以直接对ADLS Gen2中的Parquet、CSV等文件执行T-SQL查询，无需预先加载。Synapse在ML工作流中通常承担“特征工程与训练集构建”的角色，把分散在数据湖中的原始数据加工成可供训练使用的宽表或特征表。
ADLS Gen2是启用了分层命名空间的Blob Storage，它在Blob的扁平命名空间之上增加了目录和文件语义，支持原子目录重命名、POSIX风格权限（ACL）以及与Hadoop、Spark、Synapse的原生兼容。它适合作为数据湖的存储底座，承载原始区（Raw）、清洗区（Cleansed）、加工区（Curated）等多层数据，是ML工作流中数据流转的中心枢纽。
选型依据：从访问模式出发
选型时不要先问“哪个组件更强大”，而要先问“这份数据在ML工作流中如何被访问”。可以从四个维度判断：
- 数据规模与格式：GB级以下、结构固定、需要频繁按行更新，优先Azure SQL；TB级以上、多格式、以文件为单位读写，优先ADLS Gen2；需要在湖上做大规模聚合和连接，优先Synapse。
- 一致性要求：需要事务、外键、唯一约束和强一致读写的场景，Azure SQL更合适；数据湖和Blob通常提供最终一致性，适合追加写入和批量覆盖。
- 访问模式：点查、按主键更新、小结果集返回，选Azure SQL；全表扫描、列裁剪、聚合分析，选Synapse；按路径读取文件、Spark/Notebook直接访问，选ADLS Gen2。
- 成本与运维：Blob和ADLS Gen2按存储量和请求计费，成本低但需要自己管理文件布局；Azure SQL按DTU/vCore计费，Synapse专用SQL池按DWU计费，成本更高但提供计算能力。
一个可参考的选型决策表
| 判断条件 | 优先选择 | 典型ML用途 |
|---|---|---|
| 数据量 < 100 GB，需事务更新 | Azure SQL | 用户标签表、实验元数据、模型注册表 |
| 数据量 > 1 TB，多格式文件 | ADLS Gen2 | 原始数据湖、图像/文本语料、Delta表 |
| 需要对湖中数据做大规模聚合 | Synapse | 特征宽表构建、训练集生成、指标汇总 |
| 存放模型文件、脚本、日志 | Azure Storage (Blob) | 模型产物、训练脚本、运行日志 |
| 需要直接查询Parquet而不加载 | Synapse无服务器SQL池 | 探索性分析、临时特征验证 |
组合使用：不是四选一
实际项目中，这四个组件通常组合出现。一个典型的ML工作流可能是：业务系统通过Azure Data Factory或Synapse管道把数据抽取到ADLS Gen2的Raw区；Synapse Spark池读取Raw区数据，完成清洗、去重、缺失值处理和特征计算，把结果写入Curated区的Delta表；Azure SQL保存特征字典、实验配置和模型版本元数据；训练时Azure Machine Learning从ADLS Gen2读取Curated数据，训练完成的模型文件写入Blob Storage，评估指标回写Azure SQL；批量推理结果再写回ADLS Gen2或Azure SQL供业务系统消费。
实操示例：把ADLS Gen2注册为AML Datastore
下面示例假设已有一个ADLS Gen2账户mldatalake01，容器名为curated，AML工作区已开启系统分配托管标识，并且该标识已被授予容器的Storage Blob Data Reader角色。使用Azure ML CLI v2注册Datastore：
az ml datastore create \
--file datastore-adls.yml \
--resource-group rg-ml-dev \
--workspace-name aml-ws-01
# datastore-adls.yml 内容示例
$schema: https://azuremlschemas.azureedge.net/latest/azureDataLakeGen2.schema.json
name: adls_curated
type: azure_data_lake_gen2
description: Curated zone for training datasets
account_name: mldatalake01
filesystem: curated
credentials:
credentials_type: managed_identity
注册完成后，在训练脚本中可以直接通过azureml://datastores/adls_curated/paths/features/train/引用数据，AML会自动解析为ADLS Gen2路径并注入托管标识凭据。判断注册是否成功，可以在Azure ML Studio的“数据”页面查看Datastore列表，或在Notebook中执行ml_client.datastores.get("adls_curated")，确认返回的account_name和filesystem与预期一致。
选型时的常见误区
第一个误区是把ADLS Gen2当成普通Blob使用，忽略分层命名空间带来的目录重命名和ACL能力，导致多团队共享时权限混乱。第二个误区是用Azure SQL承载全量训练数据，随着数据增长出现查询超时和成本飙升。第三个误区是认为Synapse只能做BI，实际上它的Spark池和无服务器SQL池在特征工程阶段非常高效。第四个误区是忽略数据移动成本：跨区域读取ADLS Gen2会产生出站流量费用，训练集群应尽量与数据湖部署在同一区域。
掌握这四个组件的角色与边界后，下一步就可以根据具体ML任务的数据规模、一致性要求和访问模式，设计出合理的数据存储与处理链路，而不是把所有数据都塞进同一个服务。