📚 课程目录第4章 Databricks工作区与基础设施交付验收

4. Databricks工作区与基础设施交付验收

工作区与基础设施验收，是Lakehouse项目从“能跑”走向“可交付”的第一道硬门槛。它验收的不是某个Notebook能否运行，而是整个平台底座是否按设计落地：工作区部署模式是否匹配业务隔离要求、网络与安全边界是否闭合、Unity Catalog元数据治理是否可用、集群策略与SQL仓库是否受控、权限模型是否最小化、基础设施即代码（IaC）是否可复现。这一节按“先看架构落点，再验配置细节，最后核对IaC一致性”的顺序展开。

一、工作区部署模式：先确认隔离边界

Databricks工作区部署模式决定了计算平面与存储平面的归属。验收时首先要确认采用的是经典计算平面（Classic，计算资源在Databricks账户VPC内）还是无服务器（Serverless，计算由Databricks托管），以及是否启用了“客户管理的VPC/VNet注入”。判断依据是：若客户要求数据不出自有网络、需自管安全组与Private Link，则必须采用VNet注入模式；若追求弹性与低运维，可接受Serverless，但需确认其出口与Private Link端点已配置。

验收动作包括：在账户控制台核对工作区所属区域与定价层（Premium/Enterprise），确认是否启用“合规安全配置文件”与“无服务器SQL仓库”。示例判断：某金融客户要求所有计算流量经自有VNet，则验收结论应为“必须VNet注入 + Private Link + 禁用公共IP”，若实际为默认经典模式，则判定不通过。

二、网络与安全配置：验证边界闭合

网络验收的核心是“进得来、出得去、看得见”。进向需确认Private Link（前端与后端）或IP访问列表已启用；出向需确认NAT网关、防火墙规则、存储与元数据服务的Private Endpoint。安全配置需核对：是否启用客户管理密钥（CMK）加密DBFS与托管存储、是否开启审计日志投递到云存储、是否配置了集群的“无公共IP”与“安全集群模式”。

实操中可用如下命令验证网络连通性（示例）：

# 在工作区集群内执行，验证到存储账户的Private Endpoint连通
nslookup mydatalake.dfs.core.windows.net
# 期望解析到10.x.x.x私有地址，而非公网IP
curl -v https://mydatalake.dfs.core.windows.net
# 期望TLS握手成功且不经过公网出口

若解析结果为公网IP，说明Private Endpoint未生效或DNS未正确转发，验收不通过。

三、Unity Catalog元数据治理：确认三层命名空间可用

Unity Catalog（UC）验收要确认Metastore已绑定到工作区，且三层命名空间catalog.schema.table可正常创建与查询。关键检查点：是否为每个环境（dev/staging/prod）建立独立Catalog、是否启用外部位置（External Location）并绑定存储凭证、是否配置了数据血缘与审计。示例：创建prod_finance.sales.orders，验证其存储路径指向abfss://prod@mydatalake.dfs.core.windows.net/finance/sales/orders，且该路径已通过External Location授权。

验收时还需确认UC与旧版Hive Metastore的兼容策略：若存在遗留表，需明确迁移计划，避免权限模型割裂。

四、集群策略与SQL仓库：验证资源受控

集群策略（Cluster Policy）用于限制用户可创建的计算规格。验收需核对策略是否覆盖：最大Worker数、节点类型白名单、自动终止时间、是否允许附加库、是否强制标签。示例策略片段：

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

SQL仓库验收需确认：仓库规模（如2X-Small）、自动停止时间、是否启用Serverless、是否绑定到UC。示例：为BI团队创建bi-warehouse，规模Small，自动停止10分钟，仅允许只读查询，验收时用SELECT current_catalog()确认返回prod_finance。

五、权限模型：最小化与可审计

权限验收遵循“默认拒绝、按需授予”。需核对：UC中Catalog/Schema/Table的GRANT是否按角色组授予，而非个人；是否禁用工作区级“所有用户可创建集群”；是否配置了服务主体（Service Principal）用于作业运行。示例：GRANT SELECT ON TABLE prod_finance.sales.orders TO `bi_readers`;，并确认bi_readers组内无写权限。

六、基础设施即代码验收要点

IaC验收的核心是“代码即事实”。需确认Terraform/Databricks Provider版本锁定、状态文件远程存储、工作区与UC资源均通过代码管理。验收时执行terraform plan，期望输出“No changes”，若存在漂移则需修复。同时核对敏感变量是否通过密钥管理注入，而非硬编码。

七、验收闭环与证据留存

上述六项验收完成后，需形成可追溯的证据包：网络连通性测试输出、UC建表与查询截图、集群策略JSON、SQL仓库配置、权限GRANT语句、terraform plan输出。建议在交付前执行一次“反向验证”：故意以普通用户身份尝试创建超规格集群或访问未授权表，确认被拒绝。若拒绝生效，说明权限与策略真正落地；若成功，则验收不通过。

验收不是一次性动作。建议将上述检查项固化为IaC中的自动化测试（如Terratest或自定义脚本），每次变更后自动执行，避免人工遗漏。

工作区与基础设施验收的本质，是把“设计文档里的承诺”变成“可验证的事实”。部署模式决定边界，网络与安全决定可信，UC决定治理，策略与仓库决定成本可控，权限决定合规，IaC决定可复现。六者齐备，Lakehouse才算真正具备交付条件。