1. Databricks平台与流水线开发导论

在开始编写任何特征工程或模型训练代码之前，需要先建立对 Databricks 平台的整体认知。Databricks 并不是一个单纯的 Notebook 托管服务，而是把计算资源、数据存储、元数据治理和机器学习生命周期管理整合在一起的协作平台。理解它的分层结构，是后续设计流水线的前提。

一、Databricks 的分层架构

从控制面到数据面，Databricks 可以拆成四个层次。最上层是工作区（Workspace），它是用户登录后看到的协作界面，包含 Notebook、Repos、作业、集群管理入口以及权限设置。工作区本身不存储业务数据，它更像一个"操作台"。

第二层是计算层，由集群承担。Databricks 的集群分为两大类：通用集群（All-Purpose Cluster）用于交互式开发、调试和探索，可以手动启停、多人共享；作业集群（Job Cluster）由作业调度自动创建和销毁，生命周期与单次运行绑定，适合生产流水线。此外还有 SQL 仓库（SQL Warehouse）专门服务 BI 与 SQL 查询场景。集群的节点类型、Spark 版本、自动伸缩策略和库依赖，都会直接影响流水线的稳定性与成本。

第三层是存储与元数据层。数据通常存放在云对象存储（如 S3、ADLS、GCS）或 Delta Lake 表中，而Unity Catalog 作为统一的元数据与权限治理层，跨工作区管理 catalog、schema、table、volume、function 和 model。它让"谁能读哪张表、谁能调用哪个模型"变成可审计、可继承的权限体系，而不是散落在各个工作区的孤立配置。

第四层是运行时与生命周期层，其中 MLflow 负责实验跟踪、模型注册与部署。MLflow Tracking 记录每次运行的参数、指标、产物和代码版本；Model Registry 管理模型版本与阶段流转；配合 Unity Catalog，模型可以像数据表一样被授权和共享。

二、Notebook 与 Repos 的协作方式

Notebook 是 Databricks 中最常用的开发载体，支持 Python、SQL、Scala、R 混排，单元格之间可以共享变量与 Spark 会话。它适合探索性分析和快速验证，但直接在生产环境用 Notebook 手工点击运行并不可靠。因此实际工程中通常采用 Repos：把 Git 仓库（GitHub、GitLab、Azure DevOps 等）挂载到工作区，Notebook 以文件形式纳入版本控制，分支、提交、合并请求都走标准 Git 流程。这样做的价值在于：特征变换逻辑、训练脚本、配置文件都能被追溯，作业调度时可以直接引用 Repo 中的路径，而不是某个用户目录下的临时文件。

一个常见的组织方式是：/Repos/team/ml-pipeline/ 下分 feature/、training/、config/ 三个目录，分别存放特征计算 Notebook、模型训练 Notebook 和 YAML 参数文件。开发时在通用集群上以交互方式调试，验证通过后由 Job 引用同一路径在生产作业集群上运行。

三、特征工程与模型训练流水线的整体生命周期

一条完整的机器学习流水线，通常经历以下阶段：数据接入与探查 → 特征计算与写入特征表 → 训练集构建 → 模型训练与调参 → 评估与注册 → 批量/在线推理 → 监控与再训练。在 Databricks 上，这些阶段并不是靠一个脚本从头跑到尾，而是拆成可独立调度、可重跑的作业。

以特征工程为例，典型做法是把原始表经过清洗、聚合、编码后写入一张 Delta 特征表，并记录特征的计算时间与版本。训练阶段再从特征表按时间窗口取数，避免训练/推理特征口径不一致。MLflow 在这里的作用是：每次训练自动记录超参数（如 max_depth=6、learning_rate=0.1）、评估指标（AUC、F1）、模型文件以及对应的 Git commit。当需要回溯"上周那版 AUC 0.87 的模型是怎么来的"时，可以直接从 MLflow 运行记录定位到代码、数据和参数。

四、Unity Catalog 与 MLflow 的角色分工

两者容易混淆，但职责边界清晰。Unity Catalog 管"资产与权限"：数据表、Volume、函数、以及注册后的模型，都在三级命名空间 catalog.schema.object 下统一管理，权限可以按 catalog、schema、表逐级授予，并支持跨工作区共享。MLflow 管"实验与模型生命周期"：它关注一次训练运行产生了什么、模型版本如何从 Staging 走向 Production、以及推理服务如何加载指定版本。

二者结合后的典型链路是：训练脚本在 Unity Catalog 中读取特征表 → MLflow 记录本次运行 → 模型注册到 Unity Catalog 的 ml_models schema 下 → 推理作业通过 models:/catalog.schema.model_name/Production 这样的 URI 加载模型。权限由 Unity Catalog 控制，版本流转由 MLflow 控制，互不越界。

五、一个可参考的目录与命名约定

为了让流水线可维护，建议在项目初期就固定命名规范。以下示例仅作参考，实际字段可按团队约定调整：

catalog: ml_dev
schema:  feature_store
表命名:  feat_user_behavior_daily
模型命名: model_churn_predictor
MLflow 实验: /Users/team@example.com/churn_experiment
作业命名: job_feature_daily / job_train_weekly