📚 课程目录第1章 Databricks机器学习平台全景

1. Databricks机器学习平台全景

Databricks机器学习平台并不是单一工具，而是把数据工程、特征工程、模型训练、模型注册、部署与监控串成一条可治理的生产链路。理解它的第一步，是分清“控制面”和“数据面”：控制面负责工作区、权限、作业调度、集群策略与元数据管理；数据面负责真正读写数据、执行 Spark 任务、训练模型和提供在线推理。生产环境建设的目标，就是让这两面在安全、成本、可复现和可观测四个维度上同时达标。

一、核心组件与职责边界

从一次典型的模型交付看，平台组件按职责可分为六层：

存储与表格式层：云对象存储（如 S3/ADLS/GCS）承载原始数据，Delta Lake 提供 ACID 事务、时间旅行和 Schema 演进，Unity Catalog 统一管理表、卷、模型和函数的权限与血缘。
计算层：All-Purpose Cluster 用于交互式开发，Job Cluster 用于生产作业，SQL Warehouse 服务 BI 与特征查询，Model Serving 提供低延迟在线推理。
开发与调度层：Notebook、Repos、Workflows 负责代码版本、参数化运行与依赖编排。
特征与训练层：Feature Store 保证离线训练与在线推理特征一致，MLflow Tracking 记录每次实验的参数、指标和产物。
模型治理层：Model Registry 管理模型版本与阶段（Staging/Production），配合审批与 Webhook 实现发布控制。
监控与运维层：推理日志表、数据质量指标、集群事件日志和成本标签共同支撑可观测性。

这些组件不是并列堆叠，而是有明确的依赖方向：存储与表格式是地基，计算层在其上运行，开发调度层驱动任务，特征与训练层产出模型，治理层控制发布，监控层反馈回数据与模型。下图给出这一分层关系与关键数据流。

二、生产环境建设目标

把平台组件搭起来只是起点，生产环境建设要回答四个问题：能不能稳定跑、能不能安全管、能不能算清账、能不能快速查。对应到具体目标：

可复现：同一份代码、同一份数据、同一组参数，在任何时间重跑都应得到一致结果。这要求代码进 Git、数据进 Delta 表并保留版本、环境依赖用集群库或容器镜像固定、随机种子显式设置。
可治理：表、模型、函数都有明确 Owner，权限通过 Unity Catalog 的 Catalog-Schema-Table 三级模型控制，敏感列用行级/列级过滤，模型发布走 Registry 阶段审批。
可观测：训练任务有 MLflow 指标，推理端点有延迟与错误率，数据管道有质量校验结果，集群有事件日志和成本标签。没有观测就没有生产。
成本可控：交互式集群设自动终止，生产作业用 Job Cluster 按需创建，SQL Warehouse 按规模自动伸缩，所有资源打上项目/环境标签以便分摊。

三、从开发到生产的典型路径

以一个“用户流失预测”任务为例，说明平台各层如何协作。假设原始数据是 main.raw.user_events，每天增量写入 Delta 表。

-- 特征计算：从事件表聚合出用户级特征
CREATE OR REPLACE TABLE main.features.churn_features AS
SELECT
  user_id,
  COUNT(*) FILTER (WHERE event = 'login')      AS login_cnt_30d,
  COUNT(*) FILTER (WHERE event = 'purchase')   AS purchase_cnt_30d,
  DATEDIFF(CURRENT_DATE, MAX(event_date))      AS days_since_last_active,
  AVG(session_duration_sec)                    AS avg_session_sec
FROM main.raw.user_events
WHERE event_date >= CURRENT_DATE - INTERVAL 30 DAYS
GROUP BY user_id;

这段 SQL 在 SQL Warehouse 或 Job Cluster 上执行，结果写入 Feature Store 表。训练时用 MLflow 记录 max_depth=6、learning_rate=0.05、n_estimators=200 等参数，以及 AUC、F1 等指标。模型注册到 main.models.churn_classifier 后，先进入 Staging 阶段，由业务方在验证集上确认，再通过 Webhook 触发 Model Serving 端点更新。上线后，推理日志表 main.monitoring.churn_predictions 记录每次请求的输入特征、输出分数和时间戳，用于后续漂移检测。

判断生产就绪的简易检查：代码是否在 Git 中可追溯？数据表是否有 Delta 版本和权限？训练是否记录了完整参数与指标？模型是否有 Registry 版本和审批记录？推理是否有日志和延迟监控？集群是否有自动终止和成本标签？六项都满足，才具备进入生产的基本条件。

四、常见误区与建设顺序

很多团队一开始就追求“全自动 MLOps”，结果在权限混乱、数据质量差、没有监控的情况下强行上线，反而增加故障面。更稳妥的顺序是：先统一存储与表格式（Delta + Unity Catalog），再规范计算资源（Job Cluster + 自动终止），然后建立实验跟踪（MLflow），接着做模型注册与审批，最后补推理监控与漂移告警。每一步都以前一步的稳定为前提。

另一个误区是把 Notebook 直接当生产作业。Notebook 适合探索，但生产应使用 Workflows 调度参数化任务，把逻辑封装成可测试的函数或 Wheel 包，Notebook 只做编排入口。这样版本、依赖和错误处理才可控。

总结来说，Databricks 机器学习平台的全景可以概括为：Delta + Unity Catalog 做地基，Cluster + Warehouse + Serving 做算力，Notebook + Workflows 做开发调度，Feature Store + MLflow 做特征与实验，Registry 做治理，监控层做反馈。生产环境建设的目标不是堆组件，而是让这条链路在可复现、可治理、可观测、成本可控四个维度上持续运转。