2. Databricks工作区与计算资源管理

Databricks 的工作区（Workspace）是团队协作、代码开发与任务调度的统一入口，而计算资源（Compute）则是真正执行 Spark、SQL 与机器学习负载的引擎。理解工作区的组织结构与三类计算资源的差异，是后续数据工程、特征工程与模型训练能否稳定运行的基础。本节围绕工作区结构、集群类型、集群配置与自动伸缩、库依赖管理、笔记本与版本控制集成五个方面展开，重点说明“怎么配、配成什么样、如何判断是否合适”。

一、工作区结构：从目录到对象

工作区在逻辑上分为几个层次：最上层是工作区根目录，其下按团队或项目划分文件夹；文件夹中存放笔记本（Notebook）、文件（Files，用于存放数据、脚本、配置文件）、以及可选的 Repos 目录（与 Git 仓库同步）。此外，工作区还挂载了若干全局对象：计算资源、作业（Jobs）、SQL 仓库、模型注册表、密钥（Secrets）与权限（Permissions）。

一个常见的组织方式是：/Workspace/Users/<邮箱> 存放个人草稿，/Workspace/Repos/<团队>/<项目> 存放与 Git 同步的正式代码，/Workspace/Shared 存放跨团队共享的笔记本与配置。数据本身通常不放在工作区，而是放在云存储（如 S3、ADLS、GCS）并通过外部位置（External Location）或挂载点访问。这样做的原因是工作区文件有大小与并发限制，不适合作为数据湖存储。

权限方面，工作区支持工作区级、文件夹级、对象级三层控制。例如，可以给某个文件夹授予“可管理”权限，让团队负责人自行管理子目录；给某个集群授予“可使用”权限，让分析师能提交作业但不能修改配置。理解这一点，可以避免“所有人都用管理员集群”的常见反模式。

二、三类计算资源：交互式集群、作业集群、SQL 仓库

Databricks 提供三类主要计算资源，它们的生命周期、适用场景与计费方式不同：

• 交互式集群（All-Purpose / Interactive Cluster）：用于笔记本探索、调试与协作。可以手动启动、停止，支持多人共享，支持自动伸缩。适合开发阶段，但长期运行成本较高。
• 作业集群（Job Cluster）：由作业（Job）在运行时自动创建，作业结束后自动销毁。适合生产调度，成本可控，但无法交互式调试。
• SQL 仓库（SQL Warehouse）：专为 SQL 与 BI 查询优化，支持多用户并发、结果缓存与 Photon 加速。适合报表、仪表盘与即席查询，不用于运行 Python/Scala 笔记本。

选择原则可以概括为：开发调试用交互式集群，生产调度用作业集群，SQL 分析与 BI 用 SQL 仓库。三者可以共存，但应避免用交互式集群跑生产作业，否则容易因人为停止或配置漂移导致任务失败。

三、集群配置与自动伸缩

创建集群时，关键配置项包括：集群模式（标准/高并发）、Databricks Runtime 版本、节点类型（Driver 与 Worker）、最小/最大 Worker 数、自动伸缩开关、自动终止时间、以及 Spark 配置。下面给出一份面向中等规模 ETL 的示例配置，参数为教学假设值，实际需按数据量与预算调整：

集群名称: etl-dev-cluster
集群模式: 标准（Standard）
Runtime: 14.3 LTS (Spark 3.5, Scala 2.12)
Driver: i3.xlarge (4 vCPU, 30.5 GB)
Worker: i3.xlarge
最小 Worker: 2
最大 Worker: 8
自动伸缩: 开启
自动终止: 60 分钟无活动
Spark 配置:
  spark.sql.shuffle.partitions = 200
  spark.databricks.delta.optimizeWrite.enabled = true

自动伸缩的核心逻辑是：Databricks 根据待处理任务（Task）数量与当前 Worker 的负载，在最小与最大 Worker 之间动态增减。判断是否“伸缩得当”，可以观察 Spark UI 中的 Executor 数量曲线与任务等待时间：如果任务长时间排队而 Worker 已达上限，说明最大 Worker 设小了；如果 Worker 频繁增减且任务执行时间波动大，说明最小 Worker 设得过低或数据倾斜严重。

自动终止（Auto Termination）是控制成本的关键。开发集群建议设为 30～60 分钟，生产作业集群由作业生命周期管理，无需额外设置。注意：自动终止只对交互式集群生效，且计时从最后一次命令执行完成开始。

四、库依赖管理

Databricks 支持三种库安装范围：集群级（Cluster-scoped）、笔记本级（Notebook-scoped）与工作区级（Workspace）。集群级库对所有使用该集群的笔记本生效，适合团队统一依赖；笔记本级库只对当前笔记本生效，适合临时试验；工作区级库已逐步被 Repos 与 init script 替代。

安装方式包括：PyPI、Maven、CRAN 以及上传自定义 wheel/JAR。对于生产作业，推荐将依赖写入 requirements.txt 或使用 %pip install 在笔记本开头安装，并配合作业集群的 init script 保证环境一致。一个常见的坑是：在交互式集群上手动安装的库，在作业集群上并不存在，导致生产任务报 ModuleNotFoundError。解决办法是把依赖声明写入作业配置或使用 Docker 镜像。

五、笔记本与版本控制集成

Databricks 笔记本支持与 Git 仓库集成，通过 Repos 功能实现。典型流程是：在 Repos 中克隆远程仓库，创建分支，在笔记本中编辑并提交，最后通过 Pull Request 合并。笔记本本身是源文件（.py 或 .sql 或 .ipynb），可以像普通代码一样进行 diff 与 review。

实际操作中，建议遵循以下约定：

• 每个项目一个 Repo，目录结构与本地开发一致；
• 笔记本命名使用 01_bronze_ingest、02_silver_transform 等前缀，便于排序；
• 敏感配置（如连接串、密钥）不写入笔记本，使用 Databricks Secrets 或环境变量；
• 提交前在交互式集群上运行关键单元格，确认无语法与依赖错误；
• 生产作业引用 Repo 中的笔记本路径，而非个人目录，保证可追溯。

判断版本控制集成是否成功，可以检查：Repos 中是否能看到提交历史；作业运行时是否拉取的是指定分支或 commit；以及当远程仓库更新后，本地 Repo 是否能通过 Pull 同步。若作业引用了个人目录中的笔记本，则无法保证版本一致性，应尽快迁移到 Repos。