2. Azure 数据平台环境准备

持续交付的第一道门槛不是流水线，而是环境本身。如果订阅、资源组、存储账户、Key Vault、数据工厂、Synapse 与 Databricks 的命名、区域、网络与权限各自为政，后续的 ARM/Bicep 部署、CI/CD 变量替换和密钥轮换都会变成一次性手工修补。本节的目标是建立一套可重复、可审计、可参数化的数据平台基线，让每个环境（dev/test/prod）都能用同一份模板生成，差异只体现在参数文件中。

一、先定命名与标签规范，再谈资源

标准化配置的起点是命名约定。建议采用“资源类型缩写-项目-环境-区域-序号”的结构，例如存储账户 stdataopsdevcn001、数据工厂 adf-dataops-dev-cn-001、Synapse 工作区 syn-dataops-dev-cn-001、Databricks 工作区 dbw-dataops-dev-cn-001、Key Vault kv-dataops-dev-cn-001。存储账户和 Key Vault 有全局唯一、仅小写字母数字与连字符等限制，命名规则必须提前固化，否则模板在第二次部署时就会因重名失败。

标签（Tag）是成本归集与自动化筛选的依据。至少定义四个标签：Environment（dev/test/prod）、Project、Owner、CostCenter。标签不仅用于账单分析，也可作为 Azure Policy 的审计条件，例如拒绝未打 Environment 标签的资源组创建。

二、订阅与资源组的边界设计

订阅是配额、计费与访问控制的边界。数据平台常见做法是按环境拆分订阅：dev 与 test 可共用一个非生产订阅，prod 使用独立订阅，避免测试资源消耗生产配额，也便于对生产订阅施加更严格的 Policy。若组织规模较小，也可在同一订阅内用资源组隔离环境，但必须接受配额共享与权限边界较弱的代价。

资源组按“生命周期一致”原则划分。建议每个环境至少包含：rg-dataops-{env}-core（存储账户、Key Vault、Log Analytics）、rg-dataops-{env}-integration（数据工厂、Synapse）、rg-dataops-{env}-compute（Databricks 工作区及其托管资源组）。这样删除或重建某一层时不会误伤其他层。资源组本身也应打上环境标签，并在部署时通过 --tags 或 Bicep 的 tags 属性统一注入。

三、存储账户：数据湖的底座

存储账户建议启用 Hierarchical Namespace（即 ADLS Gen2），否则 Synapse 与 Databricks 无法使用目录级 ACL。创建时关键参数包括：--sku Standard_LRS（生产可升为 ZRS/GRS）、--kind StorageV2、--enable-hierarchical-namespace true、--min-tls-version TLS1_2、--allow-blob-public-access false。容器按分层组织：raw、curated、serving、landing，分别对应原始落地、清洗后、服务层与临时接入。

az storage account create \
  --name stdataopsdevcn001 \
  --resource-group rg-dataops-dev-core \
  --location chinaeast2 \
  --sku Standard_LRS \
  --kind StorageV2 \
  --enable-hierarchical-namespace true \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --tags Environment=dev Project=dataops Owner=data-team

创建后立即为数据工厂、Synapse、Databricks 的托管标识授予 Storage Blob Data Contributor，而不是使用账户密钥。这一步决定了后续能否做到“无密钥访问”。

四、Key Vault：密钥与连接的唯一出口

Key Vault 应作为所有连接字符串、服务主体密钥、存储访问密钥的集中存放点。创建时启用 --enable-rbac-authorization true，用 RBAC 而非访问策略管理权限，便于与 Entra ID 组统一治理。软删除与清除保护必须开启，防止误删导致密钥永久丢失。

az keyvault create \
  --name kv-dataops-dev-cn-001 \
  --resource-group rg-dataops-dev-core \
  --location chinaeast2 \
  --enable-rbac-authorization true \
  --enable-soft-delete true \
  --retention-days 90

数据工厂与 Synapse 通过托管标识访问 Key Vault，Databricks 则通过 Secret Scope 引用。这样密钥轮换只需在 Key Vault 更新，无需改动任何管道定义。

五、数据工厂、Synapse 与 Databricks 的标准化要点

数据工厂创建时指定 --location 与托管标识，并关闭公共网络访问（若使用托管虚拟网络或 Private Endpoint）。Synapse 工作区需要同时指定 Data Lake 存储账户与文件系统，创建后配置 SQL 池与 Spark 池的最小规模，避免默认大规格造成成本失控。Databricks 工作区建议使用 Premium 层级以启用基于角色的访问控制与 Secret Scope，并配置 VNet 注入或 Private Link。

三者的共同点是：都使用系统分配的托管标识，都通过 Key Vault 获取机密，都打上相同的环境标签，并都纳入同一份 Bicep 模板的参数化部署。下图展示了这一标准化配置的整体关系与依赖方向。

六、用一份参数化模板固化差异

上述资源不应逐个手工创建，而应写入 Bicep 或 Terraform 模板，通过参数文件区分环境。关键参数包括：env、location、projectName、storageSku、databricksSku、synapseSqlPoolSku。部署时使用 az deployment sub create 或 az deployment group create，并在 CI 中固定模板版本。这样 dev 与 prod 的差异只体现在参数文件，而不是散落在门户点击记录里。

七、部署后的最小验证

环境创建完成后，至少验证四件事：第一，数据工厂与 Synapse 的托管标识能否在 Key Vault 中读取指定机密；第二，Databricks 能否通过 Secret Scope 解析到同一机密；第三，存储账户的 raw 容器能否被三者以托管标识写入；第四，所有资源是否带有正确的环境标签。验证方式可以用一段简短的 CLI 或笔记本代码，例如在 Databricks 中执行 dbutils.secrets.get(scope="kv-scope", key="storage-key")，若返回密钥值而非异常，说明 Secret Scope 与 Key Vault 的 RBAC 配置正确。