📚 课程目录第2章 Databricks工作区与开发环境配置

2. Databricks工作区与开发环境配置

Databricks 的工作区（Workspace）是团队协作的统一入口，它把 Notebook、Repos、Cluster、SQL Warehouse 和 Unity Catalog 元数据组织在同一个受治理的命名空间下。理解这些对象之间的依赖关系，是搭建可复用开发环境的前提。本节围绕“创建—连接—协作—治理”四条主线，说明每个对象的实际配置方式与最佳实践。

一、工作区与身份入口

工作区按云账号（AWS/Azure/GCP）创建，每个工作区绑定一个区域和一套 Unity Catalog 元存储（Metastore）。用户通过 SSO（如 Azure Entra ID、Okta）登录，权限由账号级、工作区级、元存储级三层叠加。创建后第一件事是确认工作区已启用 Unity Catalog，并指定默认 Catalog，否则后续 Notebook 只能访问 Hive Metastore 的旧表。

工作区左侧导航栏是开发者的主要操作面：Workspace（目录树）、Repos（Git 集成）、Compute（Cluster 与 SQL Warehouse）、Catalog（元数据浏览）、Jobs、Workflows。建议团队统一约定目录结构，例如 /Workspace/Shared/<项目>/{notebooks,src,config}，避免个人目录散落导致资产无法复用。

二、Repos：把代码纳入 Git 管理

Repos 是 Databricks 与 Git 的桥接层，支持 GitHub、GitLab、Azure DevOps、Bitbucket。配置步骤：在 Repos 页面点击 Add Repo，填入 Git URL，选择认证方式（推荐 Git 凭据 + 个人访问令牌，或服务主体），指定分支后克隆到 /Repos/<user>/<repo>。克隆后目录与本地 Git 仓库一致，支持 commit、pull、push、分支切换。

最佳实践是：Notebook 只做编排与展示，核心逻辑放在 src/ 下的 Python 模块中，通过 %pip install -e . 或 sys.path.append 引入。这样同一份代码既能被 Notebook 调用，也能被 Job、Delta Live Tables 复用。Repos 中的 Notebook 支持相对路径引用，避免硬编码绝对路径。

三、Cluster：计算资源的创建与共享

Cluster 分为 All-Purpose（交互式，用于开发）和 Job Cluster（作业专用，成本更低）。创建 All-Purpose Cluster 的关键参数：

Runtime：选择 LTS 版本（如 15.4 LTS），并勾选 Photon 加速。
Node type：Driver 与 Worker 可不同，开发环境常用 1 Driver + 1~2 Worker。
Autoscaling：设置 min/max worker，避免空闲时仍占用大量节点。
Auto termination：建议 30~60 分钟，防止忘记关闭。
Access mode：Unity Catalog 下推荐 Shared（多用户共享）或 Single user（需访问特定库时）。

共享 Cluster 适合团队协作，但要注意库隔离：使用 %pip install 安装的库在 Shared 模式下可能影响其他用户，建议用 Cluster-scoped init script 或 %pip install --user。对于需要固定依赖的项目，可把依赖写入 requirements.txt，在 Cluster 的 Libraries 中引用。

四、SQL Warehouse：面向 BI 与 SQL 的独立计算

SQL Warehouse 与 Cluster 是两套独立计算。它专为 SQL 查询和 BI 工具（Power BI、Tableau、JDBC/ODBC）设计，支持 Serverless、Pro、Classic 三种类型。创建时选择 Size（如 Small、Medium）、Auto stop（如 10 分钟）、Scaling range。Serverless 启动快、按查询计费，适合交互式分析；Classic 适合需要精细控制或访问特定网络资源的场景。

连接方式：在 SQL Warehouse 详情页获取 JDBC/ODBC URL 和 HTTP Path，BI 工具用个人访问令牌或 OAuth 认证。注意 SQL Warehouse 的权限与 Unity Catalog 表权限联动，用户只能查询被授权的表。

五、Unity Catalog 元数据入口

Unity Catalog 采用三层命名空间：catalog.schema.table。元数据入口在 Catalog 页面，可浏览 Catalog、Schema、Table、View、Function、Volume。创建表时显式指定 Catalog，例如：

CREATE TABLE main.sales.orders (
  order_id BIGINT,
  customer_id BIGINT,
  amount DECIMAL(10,2),
  order_date DATE
)
USING DELTA
LOCATION 's3://bucket/sales/orders';

权限通过 GRANT 语句或 Catalog 页面授予，支持 Catalog、Schema、Table 三级。建议按“环境 + 业务域”划分 Catalog，如 dev_sales、prod_sales，避免开发数据污染生产。

六、协作配置与最佳实践

团队协作的核心是“共享计算 + 共享代码 + 共享元数据”。推荐配置：

使用 Shared Cluster 供团队开发，Job Cluster 用于生产作业。
Repos 统一分支策略：main 为稳定版，feature 分支开发，通过 PR 合并。
Notebook 中不写死路径，使用 dbutils.widgets 传参。
敏感信息用 Databricks Secrets 管理，不在 Notebook 中明文存储。
定期检查 Cluster 和 SQL Warehouse 的 Auto stop 设置，控制成本。

建议在项目初期就确定 Catalog 命名规范、Cluster 规格模板和 Repos 目录结构，后续所有开发都基于这套约定，减少返工。

以上配置完成后，一个典型开发流程是：开发者从 Repos 拉取代码 → 在 Shared Cluster 上运行 Notebook → 通过 Unity Catalog 读写表 → 用 SQL Warehouse 做 BI 验证 → 提交 PR 合并到 main。整个过程计算、代码、元数据三者解耦又联动，既保证协作效率，也满足治理要求。