📚 课程目录第3章环境策略与工作区规划

3. 环境策略与工作区规划

在 Databricks DataOps 持续交付体系中，环境策略决定了代码、数据、权限与网络如何从开发态逐步流向生产态。环境规划不是简单的“建三个工作区”，而是要回答四个问题：环境之间用什么隔离、代码与配置如何晋级、谁能访问哪些数据、网络边界如何收口。围绕这四个问题，业界通常有两种落地形态：多工作区方案（dev/staging/prod 各自独立工作区）与单工作区多环境方案（同一工作区内用目录、计算资源与权限划分环境）。两者并非互斥，很多团队会采用“多工作区为主、单工作区内再分环境”的混合模式。

一、两种方案的适用边界

多工作区方案的核心优势是强隔离：每个环境拥有独立的元数据存储（Unity Catalog metastore 或 workspace metastore）、独立的计算平面、独立的网络出口与独立的身份映射。生产工作区可以只允许 CI/CD 服务主体写入，人工账号仅保留只读与运维权限；开发工作区则允许工程师自由创建集群与 Notebook。代价是资源成本更高、跨环境数据共享需要显式配置、元数据同步需要额外治理。

单工作区多环境方案的核心优势是低成本与低延迟：同一工作区内通过 Catalog 命名空间（如 dev_catalog、staging_catalog、prod_catalog）隔离数据，通过集群策略与实例池隔离计算，通过 Unity Catalog 的 GRANT 隔离权限。它适合中小团队、数据量不大、合规要求不高的场景。风险在于：一旦工作区级配置被误改，可能同时影响多个环境；网络出口通常共享，难以对生产单独做白名单。

判断依据可以简化为三条：若存在强合规/审计要求、生产数据必须物理隔离、或需要独立网络出口，优先多工作区；若团队规模小、迭代快、成本敏感，可先用单工作区多环境，待合规压力上升再拆分。

二、隔离维度与配置要点

无论选择哪种方案，都需要在以下五个维度上明确隔离策略：

身份与权限隔离：使用 Unity Catalog 的账户级身份（用户、组、服务主体）。生产环境只授予 CI/CD 服务主体 USE CATALOG、USE SCHEMA、MODIFY 等必要权限，人工账号默认只读。开发环境可放宽到 CREATE 级别。
数据隔离：多工作区方案下，每个环境使用独立的外部存储路径（如 s3://corp-data-dev/、s3://corp-data-prod/）；单工作区方案下，用 Catalog 隔离，并在外部存储上按 Catalog 前缀分目录。
计算隔离：生产作业使用 Job Cluster 或专用 SQL Warehouse，禁止交互式集群；开发环境使用共享集群或实例池，配合集群策略限制最大节点数与自动终止时间。
网络边界：生产工作区建议启用 VPC/VNet 注入、Private Link、IP 访问列表与出口防火墙；开发工作区可放宽，但至少限制公网访问来源。
配置与密钥隔离：每个环境使用独立的 Secret Scope 或云密钥管理路径，禁止跨环境复用同一密钥。

三、代码与配置的晋级路径

环境规划必须与 CI/CD 流水线对齐。推荐做法是：代码仓库中只保留一份业务逻辑，环境差异通过参数化配置注入。例如在 Databricks Asset Bundles 中，用 databricks.yml 定义 target：

targets:
  dev:
    workspace:
      host: https://adb-dev.azuredatabricks.net
    variables:
      catalog: dev_catalog
      warehouse_id: dev_wh
  staging:
    workspace:
      host: https://adb-staging.azuredatabricks.net
    variables:
      catalog: staging_catalog
      warehouse_id: staging_wh
  prod:
    workspace:
      host: https://adb-prod.azuredatabricks.net
    variables:
      catalog: prod_catalog
      warehouse_id: prod_wh

流水线在合并到 main 后先部署到 staging，通过数据质量校验与集成测试后，再以手动审批方式晋级到 prod。每次部署都使用同一份 bundle，仅切换 target，从而保证“构建一次、多环境晋级”。

四、权限与网络边界的落地检查

权限配置建议遵循最小权限原则，并用组而非个人授权。典型的生产权限模型是：data-engineers 组拥有 prod_catalog 的 USE CATALOG 与 USE SCHEMA，ci-service-principal 拥有 MODIFY 与 CREATE TABLE，analysts 组仅拥有 SELECT。网络边界方面，生产工作区应配置 IP 访问列表，仅允许企业出口 IP 与 CI/CD 运行器 IP；若使用 Private Link，需确认前端与后端 Private Link 均已启用，并验证 Notebook 与 JDBC 连接均走私有链路。

常见误区：在单工作区多环境方案中，直接给开发人员 ALL PRIVILEGES 于整个工作区，导致其可访问 prod_catalog。正确做法是只授予开发人员对 dev_catalog 的权限，prod_catalog 通过组权限单独控制。

五、环境拓扑与晋级关系

下图给出一个典型的多工作区 + 单工作区内 Catalog 隔离的混合拓扑，展示代码、配置、数据与权限在三个环境之间的流向与边界。

从图中可以看到，代码从 Git 仓库经 CI/CD 流水线依次部署到 DEV、STAGING、PROD，每个环境拥有独立的 Catalog、计算资源、Secret Scope 与网络边界。权限模型在生产环境收得最紧：CI 服务主体负责写入，数据工程师可读可查，分析师仅能查询。这种“代码一份、配置分环境、权限分层、网络递进”的结构，是 Databricks DataOps 环境规划中最稳妥的起点。

六、落地建议与常见检查项

实际落地时，建议先用一个环境矩阵把决策固化下来，再逐项配置。矩阵至少包含：环境名称、工作区 URL、Catalog 名称、计算资源类型、网络模式、密钥路径、可写角色、可读角色。配置完成后，用以下检查项验证隔离是否生效：

用开发账号尝试访问 prod_catalog，应返回权限错误。
用 CI 服务主体在 prod 执行 CREATE TABLE，应成功；用人工账号执行，应失败。
从公网直接访问 prod 工作区 URL，应被 IP 访问列表拒绝。
在 prod 作业中读取 dev 的 Secret Scope，应无法解析。
部署流水线切换 target 后，确认作业参数中的 catalog 与 warehouse_id 已正确替换。

环境策略不是一次性的架构决策，而是随着团队规模、合规要求和数据敏感度持续演进的治理过程。建议每季度复核一次环境矩阵，确认权限没有膨胀、网络边界没有松动、密钥没有跨环境复用。只有把隔离、权限与网络边界同时纳入持续交付流水线的校验范围，环境规划才真正具备可运维性。