1. 课程导入与Databricks模型生命周期全景
欢迎进入《Databricks 模型生命周期管理与生产部署》。在开始动手之前，我们需要先建立一张“全局地图”：一个机器学习模型从想法到稳定服务，究竟要经过哪些阶段？每个阶段会产生什么产物、由谁负责、用什么工具承载？Databricks 又在这条链路的哪些位置提供了能力？只有把这张地图看清楚，后面每一章的实验、配置和排障才有落脚点。
一、为什么需要 MLOps：从“能跑通”到“可运营”
很多团队第一次做机器学习时，关注的是“模型能不能训出来”。笔记本里跑通一段代码，得到一个不错的准确率，任务似乎就结束了。但真正上线后问题才暴露：数据分布变了，模型效果悄悄下降；有人改了特征计算逻辑，训练和推理结果对不上；模型文件散落在个人目录，没人知道线上跑的是哪一版；出了问题无法快速回滚。这些问题的根源不是算法，而是缺少工程化的生命周期管理。
MLOps（Machine Learning Operations）可以理解为“把 DevOps 的工程纪律应用到机器学习系统”。它关注的不是单个模型，而是数据、代码、模型、配置、环境这五类资产在时间轴上的可追溯、可复现、可自动化。一个成熟的 MLOps 体系通常要回答四个问题：这次训练用的是哪份数据？产出模型的代码和参数是什么？模型经过哪些评估才被允许上线？上线后它的表现如何、何时需要重训？
二、模型生命周期的六个阶段
把模型当作一个有生命周期的“产品”，可以拆成六个阶段。它们不是严格的瀑布式顺序，而是带反馈回路的循环。
- 数据准备：从原始表出发，做清洗、特征工程，产出训练集与特征表。关键产物是可复现的数据版本。
- 实验与训练：尝试不同算法与超参数，记录每次运行的指标、参数和产物。关键产物是实验记录。
- 评估与注册：对候选模型做离线评估、偏差检查，通过后登记到模型注册表，形成带版本的模型资产。
- 部署：把注册模型发布为在线服务、批处理作业或流式推理，并配置资源与并发。
- 监控：持续采集推理请求、延迟、数据漂移和模型指标，判断服务是否健康。
- 重训与迭代：当漂移超阈值或业务变化时，触发新一轮训练，回到第一阶段。
注意最后一步回到第一步，这正是“生命周期”而非“流水线”的含义。监控数据会反过来成为下一轮训练的数据来源和触发信号。
三、Databricks 在生命周期中的角色
Databricks 的价值在于把上述阶段放在同一个数据平台上，减少数据搬运和工具拼接。对应关系大致如下：
| 生命周期阶段 | Databricks 承载组件 | 核心作用 |
|---|---|---|
| 数据准备 | Delta Lake、Unity Catalog | 版本化数据表、统一权限与血缘 |
| 实验与训练 | MLflow Tracking、Notebook、集群 | 记录参数/指标/产物，弹性算力 |
| 评估与注册 | MLflow Model Registry | 模型版本、阶段流转、审批 |
| 部署 | Model Serving、Jobs、Feature Serving | 在线/批量/流式推理 |
| 监控 | Lakehouse Monitoring、推理表 | 漂移与性能监控 |
| 重训迭代 | Workflows、Delta Live Tables | 编排与自动化触发 |
其中 MLflow 是贯穿全流程的主线：训练时它记录实验，评估后它承载模型版本，部署时它提供模型 URI，监控时它关联推理表。理解 MLflow 的对象模型（Experiment → Run → Model → Model Version），就理解了 Databricks MLOps 的骨架。
四、整体架构与工具链概览
下图把数据流、模型流和监控反馈三条线画在一起。左侧是数据与特征，中间是训练与注册，右侧是部署与监控，底部是贯穿始终的治理与编排层。请重点观察两条箭头：一条从“监控”回到“数据准备”，代表重训回路；一条从“模型注册表”指向“部署”，代表只有通过评估的版本才能上线。
五、本课程的学习目标
学完这门课，你应该能够独立完成一条端到端的模型交付链路，而不仅是理解概念。具体目标包括：
- 用 MLflow 组织实验，做到每次训练的参数、指标、模型产物都可查询、可对比。
- 把合格模型登记到 Model Registry，理解版本号、阶段（Staging/Production）与别名（Alias）的区别与用法。
- 将注册模型部署为在线 Serving 端点或批量 Job，并验证请求与响应格式。
- 配置推理表与监控，识别数据漂移和性能下降，设定合理的重训触发条件。
- 在出现故障时，能沿血缘和版本记录定位问题并回滚到上一个稳定版本。
六、一个贯穿全课的教学场景
为了让抽象概念有具体载体，本课程后续章节会围绕一个统一示例展开：某零售场景下的客户流失预测模型。假设输入是一张客户行为特征表（近 30 天登录次数、订单数、客单价、投诉次数等），目标是预测客户在未来 30 天内是否流失。示例中我们会用 churn_features 作为特征表，用 churn_model 作为注册模型名，用 0.85 的 AUC 作为候选模型的评估门槛（这些均为教学假设值，非实测结果）。
这个场景的好处是：特征明确、标签可定义、评估指标直观，而且天然需要定期重训——客户行为会随季节和促销活动变化，正是演示漂移监控的理想对象。后续每一章，我们都会在这个场景上增加一层能力：先记录实验，再注册模型，然后部署、监控、重训，最终形成闭环。
现在你已经有了全局地图。接下来，我们将从最基础的一环开始——用 MLflow 把每一次训练变成可追溯的实验记录。