1. Databricks平台架构与AI集成全景

Databricks 的核心价值在于把数据工程、数据分析与机器学习统一到同一套 Lakehouse 架构之上。理解它的关键，不是记住一堆产品名，而是看清一条主线：数据从存储层进入，经计算层加工，由治理层统一管控，再通过 MLflow、Feature Store、模型服务与 AI Runtime 形成从特征到推理的闭环。本章先建立这张全景地图，后续章节再逐层深入。

Lakehouse：一套存储，两种负载

传统架构中，数据仓库负责 BI 报表，数据湖负责原始数据与机器学习，两者之间靠 ETL 反复搬运，导致数据冗余、口径不一致。Lakehouse 的思路是：底层用开放格式（Delta Lake）把数据存在云对象存储上，上层同时提供 SQL 数仓能力和 DataFrame/Spark 计算能力。Delta 表在目录里是一组 Parquet 文件加一份事务日志 _delta_log，日志记录每次提交的元数据，从而带来 ACID 事务、时间旅行（VERSION AS OF / TIMESTAMP AS OF）、Schema 演进和高效的 MERGE 更新。

对 AI 场景而言，Lakehouse 的意义在于：特征工程、训练数据准备、模型评估指标回写，都可以直接读写同一张 Delta 表，不需要在湖和仓之间同步副本。例如一张 ml.features.user_behavior 表，既可以被 SQL 分析师查询，也可以被 Spark 读取用于训练，还能被 Feature Store 注册为在线特征来源。

计算资源：按任务形态选择

Databricks 的计算资源主要分为几类，选择依据是“谁在用、要多快、跑多久”：

  • All-Purpose Cluster（通用集群）：交互式使用，适合 Notebook 探索、调试、小规模训练。启动后持续运行，成本较高，适合开发阶段。
  • Job Cluster（作业集群）：由 Job 调度创建，任务结束即释放，适合生产 ETL 和批量训练，成本更优。
  • SQL Warehouse：面向 BI 与 SQL 查询，支持 Serverless 与 Photon 向量化引擎，适合报表和高并发查询。
  • Serverless 计算：无需管理集群，秒级启动，适合 Notebook、Job、SQL 及模型服务等场景。
  • GPU 集群：用于深度学习训练与微调，可选 A100/H100 等实例，配合 Horovod 或 TorchDistributor 做分布式训练。

一个常见的教学示例：开发阶段用 2 节点通用集群（Driver 1 台 + Worker 1 台，Standard_DS3_v2）调试特征逻辑；上线后改为 Job Cluster，Worker 扩到 4 台并开启自动伸缩（min_workers=2, max_workers=8），夜间跑批，成本显著下降。

工作区组件与 Unity Catalog

工作区（Workspace）是用户日常操作的入口，包含 Notebook、Repos（Git 集成）、Jobs、Clusters、SQL Editor、Dashboards、Experiments 等。它们共享同一份目录与权限体系。Unity Catalog 是跨工作区的统一治理层，采用三层命名空间 catalog.schema.table，例如 prod_ml.features.user_profile。它统一管理表、视图、Volume（非结构化文件）、函数和模型，并提供细粒度权限（SELECT、MODIFY、EXECUTE）、血缘追踪与审计日志。

对 AI 集成来说，Unity Catalog 还承担模型注册的职责：MLflow 训练出的模型可以注册为 catalog.schema.model_name，从而让模型也具备权限、版本和血缘，而不是散落在个人 Notebook 里。

MLflow、Feature Store 与模型服务

MLflow 负责实验追踪与模型生命周期：一次训练运行会记录参数（如 learning_rate=0.05、n_estimators=200）、指标（auc=0.87）、代码版本和产物（模型文件、conda 环境）。通过 mlflow.log_param、mlflow.log_metric、mlflow.sklearn.log_model 即可完成记录，再在 Experiments UI 中对比多次运行。

Feature Store 解决特征复用与训练/推理一致性：特征表注册后，既可作为离线训练输入，也可通过在线存储（如 DynamoDB、Cosmos DB）提供低延迟查询，避免“训练用批处理、推理用另一套逻辑”造成偏差。模型服务（Model Serving）把注册模型部署为 REST 端点，支持自动扩缩容；AI Runtime 则面向大模型场景，提供 GPU 优化推理、向量检索与 LangChain 集成，用于构建 RAG 类应用。

Databricks Lakehouse 与 AI 集成全景 Unity Catalog 统一治理层 catalog.schema.table ｜ 权限 ｜ 血缘 ｜ 审计 ｜ 模型注册 存储层：云对象存储 + Delta Lake 原始数据 / Parquet Delta 表 + _delta_log Volume 非结构化文件 ACID ｜ 时间旅行 ｜ MERGE 计算层：按任务形态选择 通用集群 交互探索 / 调试 作业集群 生产 ETL / 批量训练 SQL Warehouse BI / 高并发查询 Serverless 秒级启动 / 免运维 GPU 集群 深度学习训练 AI 集成层：从特征到推理的闭环 Feature Store 离线特征表 在线特征存储 训练/推理一致性 MLflow 参数 / 指标 / 产物 实验对比 模型注册与版本 Model Serving REST 端点 自动扩缩容 在线推理 AI Runtime GPU 优化推理 向量检索 / RAG LangChain 集成 推理结果与监控指标回写 Delta 表，驱动再训练

一次端到端示例：从特征到在线推理

把上述组件串起来，可以走一遍最小闭环。假设要做一个用户流失预测模型：

  1. 在 prod_ml.features 下用 Delta 表保存用户行为特征，主键 user_id，特征列包括 days_since_login、orders_30d、avg_order_value。
  2. 用 Feature Store 注册该表，指定主键与时间戳列，生成训练集 create_training_set。
  3. 用 MLflow 训练 XGBoost，记录 max_depth=6、eta=0.1，指标 auc=0.86，并把模型注册为 prod_ml.models.churn_xgb。
  4. 将模型部署到 Model Serving，得到 REST 端点；在线请求携带 user_id，服务从在线特征存储取特征并返回 churn_probability。
  5. 把预测结果与真实标签回写 Delta 表，用 MLflow 监控指标漂移，触发下一轮训练。
判断集成是否成功，可以看三个信号：训练与推理使用同一份特征定义；模型有明确的 Unity Catalog 路径与版本；推理端点有可观测的延迟与吞吐指标。若三者缺一，往往意味着链路中仍有手工搬运或权限盲区。

这张全景图的意义在于建立坐标系：后续讲 Delta 表设计时，你知道它属于存储层；讲集群选型时，你知道它属于计算层；讲模型上线时，你知道它要穿过 MLflow、Feature Store 与 Serving 三层。先有地图，再走细节，学习效率会高得多。

← 上一章 📖 返回目录 下一章 →