3. 目标架构设计
目标架构设计是迁移工程从“现状盘点”走向“落地实施”的关键桥梁。它要回答四个问题：数据以什么形态组织、计算与存储如何解耦、权限与血缘由谁统一治理、工作区与网络如何部署才能既安全又高效。本章围绕 Databricks Lakehouse 的四层结构展开，并给出可直接用于迁移方案评审的架构决策要点。
一、Lakehouse 分层：从原始落地到服务消费
Databricks Lakehouse 的核心思想是：用开放格式的云对象存储承载一份数据，同时支持 BI 的 SQL 分析、数据科学的 DataFrame/Python 处理以及流式增量加工，避免传统“数据湖 + 数据仓库”双份存储与双份治理。落地时通常按数据质量与用途划分为四层，每层对应独立的 Schema 与命名规范：
- Bronze（原始层）：与源系统结构基本一致，保留原始字段与原始时间戳，仅追加不覆盖，用于回溯与重放。示例：
bronze.orders_raw，字段含_ingest_ts、_source_file。 - Silver（清洗层）：完成去重、类型转换、空值处理、维度关联，形成可复用的明细事实与维度。示例：
silver.orders_cleaned，主键order_id，金额统一为decimal(18,2)。 - Gold（汇总层）：面向业务口径的宽表与指标聚合，供 BI 与报表直接查询。示例：
gold.daily_sales_by_region。 - Platinum/Feature（服务层）：面向机器学习特征、在线服务或对外数据产品的表，强调低延迟与版本可追溯。
分层不是形式主义，它直接决定迁移工作量：源系统表先映射到 Bronze，再按业务规则逐层加工。迁移评审时应确认每层的存储路径、表格式（Delta 或 Iceberg）、分区策略与保留周期，避免把源库的存储过程逻辑原样搬到 Gold 层造成口径混乱。
二、计算与存储分离：弹性与成本的关键
Lakehouse 的存储层是云对象存储（如 S3、ADLS Gen2、GCS），计算层是 Databricks 集群。两者通过 Delta 事务日志解耦，带来三个直接收益：计算可独立扩缩容、存储可独立生命周期管理、多计算引擎可并发读取同一份数据。迁移中需要重点确认的参数关系如下：
| 维度 | 存储侧 | 计算侧 |
|---|---|---|
| 扩缩容 | 按容量与请求量扩展，通常无需停机 | 按并发与数据量调整 Worker 数量，分钟级生效 |
| 成本构成 | 存储费 + 请求费 + 跨区流量费 | DBU 计费 + 云虚拟机费 |
| 迁移关注点 | 路径映射、权限继承、加密方式 | 运行时版本、库依赖、Spark 配置 |
一个常见的误区是把“分离”理解为“存储与计算完全无关”。实际上，分区裁剪、文件大小（建议 128MB～1GB）、小文件合并（Optimize）都会显著影响计算扫描量。迁移后若查询变慢，优先检查表是否按过滤字段分区、是否存在大量小文件，而不是先加集群规格。
三、Unity Catalog：统一治理层
Unity Catalog（UC）是跨工作区的统一元数据与权限层，采用三级命名空间 catalog.schema.table。它把原先分散在各工作区 Hive Metastore 中的表、视图、函数、模型统一纳管，并提供列级与行级权限、数据血缘、审计日志。迁移时的关键动作包括：
- 为每个环境（dev/staging/prod）建立独立 Catalog，例如
prod_lakehouse、dev_lakehouse，避免环境串用。 - 用 Storage Credential 与 External Location 把云存储路径授权给 UC，再由 UC 授予 Schema 与表权限，替代原先的 IAM 直授。
- 把源库的账号角色映射为 UC 的 Group，遵循最小权限：分析师只读 Gold，数据工程师可写 Silver/Gold，Bronze 仅由摄取服务写入。
- 启用血缘与审计，确认从 Bronze 到 Gold 的上下游链路可追溯，满足合规与排障需求。
四、工作区与网络拓扑规划
工作区是用户、Notebook、作业与集群的组织单元，网络拓扑决定数据平面与控制平面的连通方式。生产环境推荐采用“客户托管 VPC/VNet + 私有链接”的部署模式：控制平面由 Databricks 托管，数据平面（计算集群）运行在客户自己的网络中，集群访问对象存储走 VPC Endpoint，避免流量经过公网。规划时需明确：
- 区域选择：工作区区域应尽量靠近数据存储区域，减少跨区流量费与延迟。
- 子网划分：为集群节点、Private Link Endpoint、NAT 网关分别划分子网，预留足够 IP 以支持弹性扩容。
- 出站策略：限制集群对公网的出站访问，仅放行必要的包仓库与元数据端点。
- 工作区隔离：按团队或环境拆分工作区，通过 UC 共享数据，而不是共享工作区凭据。
下面这张图把本节四个设计对象放在同一张拓扑中：存储层、计算层、UC 治理层以及工作区/网络边界，并标出数据流与授权流的方向，便于在方案评审时对照检查。
评审这张图时，建议逐项确认：存储路径是否已通过 External Location 授权、计算集群是否运行在客户子网、UC 的 Catalog 是否按环境隔离、Private Link 是否覆盖控制平面与存储端点。任何一项缺失，都可能在迁移后表现为权限报错、跨区延迟或合规审计不通过。
五、迁移落地的架构决策清单
把上述设计固化为可执行的决策项，能显著降低迁移返工。以下清单可直接用于方案评审会：
| 决策项 | 推荐取值（示例） | 判断依据 |
|---|---|---|
| 表格式 | Delta Lake（默认），跨引擎需求时评估 Iceberg | 是否需与外部引擎共享 |
| Catalog 划分 | prod_lakehouse / dev_lakehouse | 环境隔离与权限边界 |
| 集群模式 | ETL 用 Job Cluster，BI 用 SQL Warehouse | 成本与并发特征 |
| 网络接入 | Private Link + VPC Endpoint | 合规与延迟要求 |
| 权限模型 | Group + 服务主体，最小权限 | 审计与密钥管理 |
需要强调的是，目标架构不是一次性画完就冻结的图纸。迁移过程中若发现源系统存在大量存储过程、跨库 JOIN 或非标准数据类型，应回到分层与 UC 授权设计上做增量调整，而不是在 Gold 层堆叠临时逻辑。保持 Bronze 可重放、Silver 口径统一、Gold 面向消费，是 Lakehouse 迁移后长期可维护的基础。