1. 课程导入与全景认知
在传统数据工程里，数据管道上线往往意味着一次“大动作”：开发在本地或 Notebook 里改逻辑，测试靠人工跑几段 SQL，发布靠运维手动改配置、重启任务。当模型、特征、数据质量规则、在线推理服务都被纳入同一条交付链路后，这种方式的代价会迅速放大——一次字段变更可能同时影响特征表、训练数据集、批处理作业和在线模型，任何一处遗漏都可能让线上推理结果悄悄漂移。AIDataOps 要解决的，正是把 AI 与数据资产当作可版本化、可测试、可自动发布的软件制品来管理。
可以把 AIDataOps 理解为 DataOps 在 AI 场景下的延伸：它继承了持续集成、持续交付、基础设施即代码、环境隔离等工程实践，同时额外处理模型、特征、向量索引、推理端点这类“非纯代码”资产。其核心定义可以概括为三点：一切资产版本化（代码、配置、数据契约、模型权重都有可追溯版本）、变更自动验证（每次提交触发单元测试、数据质量校验、模型评估）、发布可回滚可观测（灰度、影子流量、指标监控与快速回退）。持续交付关注“随时可发布”，持续发布关注“自动发布到生产”，二者共同构成从提交到上线的流水线骨架。
在 Databricks 平台上，这条骨架由若干关键组件协作完成。理解它们各自的职责与边界，是后续所有实操的基础。
- Workspace（工作区）：组织用户、Notebook、集群、作业与权限的顶层容器，通常按环境（dev/staging/prod）或团队划分。它是“人”和“资源”的入口，也是权限与网络隔离的边界。
- Repos（Git 文件夹）：把 Git 仓库挂载进工作区，使 Notebook、Python 包、SQL、配置以文件形式受版本控制。它是持续集成的起点——提交即触发流水线。
- Jobs（作业）：编排任务与依赖的调度单元，支持多任务 DAG、重试、告警、参数化。批处理 ETL、模型训练、特征回填通常以 Job 形式运行。
- Pipelines（管道）：以声明式方式定义数据流，支持流式与批处理、增量处理与数据质量期望（expectations）。它让“数据从哪来、经过哪些转换、产出什么表”成为可测试的声明。
- Model Serving（模型服务）：把注册到 Unity Catalog 的模型暴露为 REST 端点，支持自动扩缩容、版本切换与流量分配，是持续发布在推理侧的落点。
这些组件并非孤立存在，而是通过“代码—数据—模型—服务”的链路串联。下图给出本节的全景关系：Repos 中的提交触发 Jobs 与 Pipelines 的构建与测试，产物（表、模型）注册到统一目录，再由 Model Serving 发布为端点，Workspace 提供权限与环境边界。
围绕这条链路，本课程设计了一个贯穿始终的项目场景：“零售客户流失预测”。它包含原始订单与行为日志、特征工程管道、模型训练与评估、模型注册、在线推理端点，以及发布后的指标监控。选择这个场景的原因是它同时覆盖批处理、特征、模型与服务四类资产，能让每个组件都“有活可干”。
课程的学习路径按“先建骨架、再补血肉、最后上生产”推进。第一阶段建立 Repos 与分支策略，让代码与配置进入版本控制；第二阶段用 Jobs 与 Pipelines 把数据处理和训练串成可重复执行的 DAG，并加入数据质量期望；第三阶段引入模型注册、评估门槛与 Model Serving 的灰度发布；第四阶段补齐监控、告警、回滚与成本治理。每一阶段都会在同一个项目上叠加能力，而不是另起炉灶。
需要提前建立的一个认知是：AIDataOps 的难点通常不在工具本身，而在变更的影响面判断。一个特征字段的类型从 string 改为 double，可能同时影响 Pipeline 的期望校验、训练数据的 schema、模型的输入签名以及 Serving 端点的请求格式。因此，后续章节会反复强调“契约先行”和“自动化验证”，让每次变更在进入生产前就被拦截或确认。
最后，本课程会使用一组示例参数贯穿演示，例如：环境划分为 dev/staging/prod 三个 Workspace；特征表命名为 feature_customer_churn；模型注册名为 churn_model；发布策略采用 10% 灰度流量观察 30 分钟。这些参数均为教学示例，实际项目中应根据团队规模、合规要求和 SLA 调整。掌握这套方法后，你可以把它迁移到推荐、风控、预测性维护等任意 AI 数据场景。