📚 课程目录第1章 Azure DataOps 持续交付与发布全景

1. Azure DataOps 持续交付与发布全景

在传统数据平台里，数据工程师常常把大量时间花在“手工搬运”上：在本地改一段 SQL，用客户端连上生产库执行；把 Notebook 导出成文件，再上传到云端工作区；数据工厂管道靠人工点击触发；发布上线没有版本记录，出问题只能凭记忆回滚。Azure DataOps 要解决的正是这类问题——它把软件工程中已经成熟的持续集成、持续交付、基础设施即代码、自动化测试等实践，系统地引入到数据平台的建设与运维中。

需要先厘清一个常见误解：DataOps 不是某一款 Azure 产品，也不是把 CI/CD 工具简单接到数据仓库上。它是一套面向数据资产交付的组织能力与技术实践的组合，其交付对象既包括代码（SQL 脚本、Notebook、管道定义、IaC 模板），也包括数据本身（表结构、数据质量、血缘）以及运行这些内容的计算与存储资源。理解这一点，才能理解为什么 DataOps 的流水线比普通应用流水线更长、更复杂。

核心概念：从代码交付到数据交付

Azure DataOps 的持续交付围绕四个核心概念展开。第一是一切皆代码：数据工厂管道用 ARM/Bicep 或 ADF 的 Git 集成来管理，Synapse 的 SQL 脚本、Spark 作业、Databricks Notebook 都纳入 Git 仓库，连权限、链接服务、触发器也尽量声明式定义。第二是环境隔离：开发、测试、生产使用独立的资源组或独立工作区，通过参数化配置区分，而不是在同一环境里靠命名前缀区分。第三是自动化验证：不仅验证代码能否编译、管道能否部署，还要验证数据质量，例如行数波动、主键唯一性、空值率、枚举值范围。第四是可观测与可回滚：每次发布都有版本号、变更内容、部署时间和责任人，出问题时能定位到具体版本并快速回退。

这四点决定了 DataOps 流水线的形态：它是一条从代码提交到数据可用的端到端链路，中间穿插着构建、静态检查、单元测试、部署、数据质量校验和发布审批等多个关卡。

价值流：一次变更如何走到生产

把一次典型变更拆开看，价值流大致经过以下环节。开发人员在功能分支上修改一个 Databricks Notebook 和对应的 ADF 管道定义，提交 Pull Request。CI 触发后，先做静态检查（SQL lint、Python 格式检查、Bicep 语法校验），再运行单元测试（对转换逻辑用小型样例数据验证输出），然后构建发布产物（Notebook 打包、ARM 模板生成参数文件）。PR 合并到主分支后，CD 流水线把产物部署到测试环境，执行集成测试与数据质量检查；通过后进入生产部署，通常需要人工审批。生产部署完成后，触发一次冒烟运行，确认管道能正常调度、目标表能写入，最后把版本信息登记到发布台账。

这条链路的关键在于每一段都有明确的输入、输出和判断依据。例如数据质量检查的输入是目标表的抽样数据，输出是校验报告，判断依据是预设阈值（如行数偏差不超过 10%、主键重复数为 0）。只有判断通过，流水线才继续向下走。

关键角色与职责边界

DataOps 不是一个人的事，它需要几类角色协同。数据工程师负责编写和提交数据转换逻辑、管道定义，并对单元测试负责；平台工程师负责维护 CI/CD 流水线本身、IaC 模板、环境参数和密钥管理；数据质量工程师或数据分析师负责定义数据质量规则和验收标准；运维/SRE 角色负责生产监控、告警响应和回滚执行。在小型团队中这些角色可能由同一人兼任，但职责边界仍需明确，否则容易出现“流水线能跑但没人对数据质量负责”的盲区。

一个常见的分工约定是：数据工程师对“代码正确”负责，平台工程师对“部署可靠”负责，数据质量规则由业务方与数据团队共同确认。这样在流水线卡住时，能快速判断是代码问题、部署问题还是数据问题。

端到端流水线的落地要点

把上述概念落到 Azure 上，通常使用 Azure DevOps 或 GitHub Actions 作为编排引擎，配合 Azure Repos 或 GitHub 做版本管理，用 Azure Resource Manager/Bicep 做基础设施部署，用 Azure Data Factory 的 Git 集成和发布分支管理管道，用 Databricks Repos 或 Synapse 的 Git 集成管理 Notebook 与 SQL 脚本。数据质量校验可以放在流水线中调用 Databricks 作业或 Synapse 存储过程执行校验 SQL，把结果写回流水线判断。

需要特别注意的是环境参数化。同一份 ARM 模板在测试和生产部署时，链接服务指向的存储账户、Key Vault 地址、Databricks 工作区 URL 都不同，这些差异应通过参数文件或变量组注入，而不是在模板里硬编码。下面是一个简化的参数文件示例，用于说明这种分离方式：

{
  "environment": "prod",
  "adfName": "adf-dataops-prod",
  "storageAccount": "stdataopsprod",
  "keyVaultName": "kv-dataops-prod",
  "databricksWorkspaceUrl": "https://adb-dataops-prod.azuredatabricks.net",
  "dataQualityThresholds": {
    "rowCountDeviationPct": 10,
    "nullRatePct": 2,
    "duplicateKeyCount": 0
  }
}

这份参数文件本身也应纳入版本管理，但其中的敏感值（如连接字符串）应引用 Key Vault，而不是明文写入。部署时流水线读取对应环境的参数文件，替换模板占位符，再执行部署。

判断一条 DataOps 流水线是否“合格”，可以问三个问题：变更是否可追溯（每次发布对应哪个提交）？质量是否可验证（有没有自动化的数据校验）？故障是否可回退（能否在 15 分钟内回到上一个稳定版本）？三个都能回答“是”，说明流水线已经具备基本的持续交付能力。

最后要强调的是，DataOps 的持续交付不是一次性搭建完成的，而是随着数据资产增长不断演进的。初期可以从一条最简单的“提交→构建→部署到测试→人工审批→部署到生产”链路开始，再逐步加入数据质量校验、冒烟测试、自动回滚等环节。关键是先把版本管理和环境隔离做扎实，后续的自动化才有可靠的基座。