📚 课程目录第3章 Databricks工作区与计算架构规划

3. Databricks工作区与计算架构规划

在把既有AI平台迁移到Databricks之前，工作区与计算架构的规划决定了后续成本、权限、网络与性能的上限。这一节围绕五个相互制约的决策展开：工作区如何布局、集群策略如何制定、SQL仓库如何配置、无服务器计算用在何处、GPU实例如何选型并控制成本。它们不是五个独立选项，而是一组需要联立求解的约束——工作区边界决定权限与网络模型，计算策略决定成本曲线，而GPU选型又反过来约束工作区可用的实例族与配额。

工作区布局：按环境与数据边界切分

工作区（Workspace）是用户、Notebook、作业、集群与权限的顶层容器。规划的第一步不是“建几个工作区”，而是先确定切分维度。常见维度有三类：环境（开发/测试/生产）、数据敏感级别（一般/受控/机密）、团队或业务域。实践中推荐以“环境 + 数据边界”为主轴，避免仅按团队切分导致同一份生产数据被复制到多个工作区、权限难以收敛。

一个可落地的布局是：dev 工作区用于探索与开发，允许较宽松的集群创建权限；staging 工作区用于集成测试与回归，数据来自脱敏副本；prod 工作区只允许通过作业与服务主体运行，禁止交互式创建大集群。若存在强合规数据，则单独设立 restricted 工作区，配合独立元存储（Metastore）与私有网络。工作区之间通过 Unity Catalog 共享数据与模型，而不是靠复制表。

需要特别注意的是元存储绑定：一个工作区只能绑定一个 Unity Catalog 元存储，但一个元存储可被多个工作区共享。因此“多工作区 + 单元存储”是推荐形态，它让权限、血缘与审计集中，而计算与网络可以按环境隔离。

集群策略：把“谁在什么时候用多少算力”写进规则

集群策略（Cluster Policy）是成本控制的第一道闸门。它通过一组 JSON 约束限制用户可创建的集群形态，例如最大 Worker 数、允许的实例族、是否允许自动伸缩、空闲自动终止时间、是否强制使用 Spot 实例。策略应分环境设计：dev 允许较灵活但设上限，prod 则严格限定实例族与规模。

一个典型的策略约束示例（示意，非实测）：

{
  "spark_conf.spark.databricks.cluster.profile": { "type": "fixed", "value": "serverless" },
  "autoscale.max_workers": { "type": "range", "maxValue": 8 },
  "node_type_id": {
    "type": "allowlist",
    "values": ["Standard_DS3_v2", "Standard_DS4_v2", "Standard_NC6s_v3"]
  },
  "azure_attributes.availability": {
    "type": "allowlist",
    "values": ["SPOT_WITH_FALLBACK_AZURE", "ON_DEMAND_AZURE"]
  },
  "autotermination_minutes": { "type": "range", "maxValue": 30 }
}

关键参数的含义与取舍：autoscale.max_workers 控制弹性上限，防止单作业吞掉整个配额；node_type_id 白名单把实例族收敛到少数几种，便于容量规划与成本核算；SPOT_WITH_FALLBACK 让非关键作业优先用 Spot，被回收时回退到按需实例，通常可显著降低成本，但会带来重试与延迟波动，因此不适合对时延敏感的服务；autotermination_minutes 是交互式集群最容易被忽视的成本泄漏点，建议 dev 设为 30 分钟以内。

集群类型上，作业集群（Job Cluster）随作业生命周期创建销毁，适合批处理与训练；全用途集群（All-Purpose）适合交互式开发，但成本更高，应通过策略限制规模与空闲时间。对于可预测的批处理，优先作业集群；对于探索性工作，优先无服务器。

SQL 仓库：面向 BI 与并发查询的独立计算

SQL 仓库（SQL Warehouse）是专为 SQL 与 BI 负载设计的计算资源，与 Spark 集群分离。它有两种形态：Classic（用户可在自己 VPC 内配置，支持精细网络控制）与 Serverless（由平台托管，秒级启动，按用量计费）。选型依据是并发量、时延要求与网络合规要求。

配置时关注三个参数：集群规模（T-shirt 尺寸，如 2X-Small 到 4X-Large）、自动停止时间（默认 10 分钟，BI 场景可适当延长以减少冷启动）、多集群负载均衡（高并发时自动扩展多个集群）。对于仪表板类负载，建议开启 Serverless 并设置合理的最小/最大集群数；对于需要固定出口 IP 或私有连接的场景，选择 Classic 并绑定网络配置。

成本上，SQL 仓库按 DBU 计费，Serverless 单价通常高于 Classic，但省去了空闲等待。判断标准是：若查询呈明显波峰波谷且对冷启动不敏感，Serverless 往往更省；若查询持续密集，Classic 的稳定单价可能更优。

无服务器计算：把运维负担交给平台

无服务器计算覆盖无服务器 SQL 仓库、无服务器作业（Serverless Jobs）与无服务器 Notebook。它的价值在于：无需管理集群、秒级启动、按实际用量计费、自动伸缩。适合场景包括：间歇性 ETL、事件驱动作业、BI 查询、模型推理的弹性部分。

但无服务器并非万能。它通常有并发与配额限制，冷启动虽快但仍存在，且对底层 Spark 配置的自定义能力弱于自建集群。因此建议的划分是：可预测、长时间、需要精细调优的负载用作业集群；间歇、突发、运维成本敏感的负载用无服务器。迁移初期可先用无服务器快速跑通链路，再对稳定的大负载做集群化优化。

GPU 实例选型与成本控制

GPU 选型要回答三个问题：模型多大、吞吐要求多少、预算是多少。以常见的 NVIDIA 实例族为例（以下为示例性对照，实际可用型号与区域供应需以云厂商为准）：

实例族（示例）	典型 GPU	显存	适用场景	成本取向
T4 类	NVIDIA T4	16 GB	轻量推理、小模型微调	低
V100 类	NVIDIA V100	16/32 GB	中等训练、批量推理	中
A100 类	NVIDIA A100	40/80 GB	大模型训练、高吞吐推理	高
H100 类	NVIDIA H100	80 GB	超大模型、极致吞吐	很高

选型原则：显存优先于算力。若模型参数与激活值放不进显存，再强的算力也无法利用。粗略估算：推理时显存需求约为“参数量 × 精度字节数 × 1.2～1.5（激活与缓存开销）”。例如 7B 参数模型以 FP16 推理，约需 14 GB 权重，加上缓存约 18～21 GB，因此单张 16 GB 卡偏紧，24 GB 或以上更稳妥。训练时还需叠加优化器状态与梯度，需求更高。

成本控制手段包括：Spot/抢占式实例用于容错训练，配合检查点（Checkpoint）定期保存，被回收后从最近检查点恢复；自动伸缩按负载增减 Worker；混合精度（FP16/BF16）降低显存与计算量；推理批处理提高 GPU 利用率；按需启停避免 GPU 长时间空闲。GPU 集群尤其要设置较短的自动终止时间，因为单位成本远高于 CPU 集群。

规划顺序建议：先定工作区与元存储边界 → 再定集群策略与配额 → 然后划分 SQL 仓库与无服务器负载 → 最后按模型规模选 GPU 并设置成本护栏。任何一步的变更都可能反向影响前一步，因此建议把这份规划作为可迭代的配置基线，而非一次性文档。

把上述决策落到配置层面，可以用一张“环境—计算—成本”对照表来固化：dev 用无服务器 + 小规模全用途集群，staging 用作业集群 + Serverless SQL，prod 用作业集群 + GPU 集群 + Classic/Serverless SQL 仓库，并对所有环境统一施加自动终止与实例白名单策略。这样，工作区布局、计算选型与成本控制就形成了一条可执行、可审计的链路。