2. Databricks工作区与计算资源准备
在 Databricks 上构建 AI 批流数据管道之前，必须先完成工作区导航、计算资源选型和成本模型的准备。这一节的目标不是把每个按钮都点一遍，而是让你清楚：进入工作区后，哪些对象是后续管道要反复使用的，集群类型如何影响运行方式，DBU 成本如何估算，以及 AI 运行时与 GPU 实例在什么场景下才真正必要。
工作区导航：先认清四类核心对象
登录 Databricks 工作区后，左侧导航通常包含 Workspace、Catalog、Compute、Jobs & Pipelines、Marketplace 等入口。对数据管道开发而言，最需要先建立认知的是四类对象：
- Workspace：存放 Notebook、文件夹、Git 仓库和实验代码，是开发入口。
- Catalog：管理 Unity Catalog 中的元数据，包括 catalog、schema、table、volume、model、function 等，是数据与模型的治理边界。
- Compute：提供执行代码的计算资源，分为 All-purpose 集群、Job 集群、SQL Warehouse 和 Serverless 计算等。
- Jobs & Pipelines：承载批处理任务、流式管道和编排调度，是生产运行的落点。
一个常见的开发路径是：在 Workspace 中编写 Notebook，通过 Catalog 读取和写入表，在 Compute 上选择合适集群执行，最后把逻辑封装进 Jobs 或 Lakeflow 管道。理解这条路径，比记住菜单位置更重要。
集群类型选择：按用途而非按习惯
Databricks 的集群选择直接影响成本、启动速度和并发能力。All-purpose 集群适合交互式开发、探索和调试，支持多人共享，但单价较高；Job 集群由 Job 调度自动创建和销毁，适合生产批处理，成本更低；SQL Warehouse 面向 BI 和 SQL 分析，优化了并发查询；Serverless 计算则把资源管理交给平台，适合不希望维护集群配置的团队。
选择时可以先问三个问题：这段代码是交互式调试还是定时运行？是否需要 GPU？是否要求秒级启动和弹性伸缩？如果是交互式调试，用 All-purpose；如果是生产批处理，优先 Job 集群；如果是 SQL 报表，用 SQL Warehouse；如果希望减少运维，考虑 Serverless。对于 AI 训练或推理，再叠加 GPU 实例类型。
DBU 成本模型：把“用量”和“单价”分开看
Databricks 的计费单位是 DBU（Databricks Unit），它衡量的是 Databricks 平台侧的计算用量，而不是底层云主机的直接费用。实际账单通常由两部分组成：云厂商的虚拟机或存储费用，加上 Databricks 的 DBU 费用。DBU 单价取决于工作区所在云平台、区域、集群类型和 SKU 等级（如 Standard、Premium、Enterprise）。
估算成本时，可以用一个简化公式：
总成本 ≈ 云主机费用 + DBU 数量 × DBU 单价
DBU 数量 ≈ 集群节点数 × 运行小时数 × 每节点每小时 DBU 消耗例如，假设某区域 Premium 工作区中，一个 Job 集群使用 2 个 worker 节点，每节点每小时消耗 2 DBU，运行 1 小时，则 DBU 用量约为 2 × 1 × 2 = 4 DBU。若该 SKU 的 DBU 单价为 0.55 美元，则 Databricks 侧费用约为 2.2 美元，再加上云主机费用。这个例子中的参数是教学假设，实际单价和 DBU 消耗需以工作区账单和官方定价为准。
AI 运行时与 GPU 实例配置
当管道涉及深度学习训练、大模型微调或 GPU 推理时，需要选择 AI 运行时和 GPU 实例。Databricks Runtime ML 预装了 PyTorch、TensorFlow、Hugging Face、MLflow 等库，适合机器学习工作负载；GPU 集群则提供 NVIDIA GPU 资源。常见 GPU 实例包括单卡和多卡机型，选择时关注显存、GPU 数量、CPU 与内存配比，以及是否支持 NVLink 等互联能力。
配置 GPU 集群时，通常需要设置：
- Runtime：选择带 GPU 支持的 Databricks Runtime ML 版本。
- Worker 类型：选择 GPU 实例，如单卡或多卡机型。
- Driver 类型：小规模训练可用 CPU driver，大规模分布式训练建议 driver 也具备足够内存。
- Autoscaling：按负载伸缩 worker 数量，但 GPU 集群伸缩通常比 CPU 慢，需预留启动时间。
- Spark 配置：如
spark.task.resource.gpu.amount，控制每个任务占用的 GPU 资源。
如果只是数据预处理、特征工程或轻量推理，CPU 集群往往更经济；只有当模型训练或推理确实需要 GPU 加速时，才应引入 GPU 实例。否则，GPU 集群的高单价会迅速推高成本。
一个可复用的准备清单
在正式开发管道前，可以按下面这份清单逐项确认，避免中途返工：
| 检查项 | 确认内容 | 判断依据 |
|---|---|---|
| 工作区权限 | 能否访问目标 Catalog、Schema 和 Volume | 在 Catalog 中能看到对应对象并具备读写权限 |
| 集群类型 | 开发用 All-purpose，生产用 Job 集群 | 任务是否需要交互式调试、是否定时运行 |
| DBU 预算 | 估算单次运行 DBU 用量与月度上限 | 节点数 × 小时数 × 每节点 DBU × 单价 |
| AI 运行时 | 是否需要 ML Runtime 和 GPU | 是否涉及模型训练、微调或 GPU 推理 |
| 自动终止 | All-purpose 集群设置空闲自动终止 | 避免长时间空转产生额外 DBU |
完成以上准备后，你就具备了进入下一阶段的条件：在明确的工作区、计算资源和成本边界内，开始设计批流数据管道。后续的 Notebook 开发、Job 编排和管道监控，都会建立在这一节的资源选择之上。