2. Lakehouse工程交付物清单设计

Lakehouse项目验收失败，往往不是因为技术方案不可行，而是因为“交付了什么、放在哪里、由谁确认、凭什么算通过”没有在项目早期被定义清楚。交付物清单（Deliverables Register）不是项目收尾时才补的文档目录，而是贯穿需求、设计、开发、测试、上线全过程的契约性资产台账。它的核心作用有三个：让甲方知道会收到什么，让乙方知道必须产出什么，让验收方知道依据什么签字。

一、交付物的六类资产模型

Lakehouse工程交付物可以按资产属性分为六类，每类都有不同的验收关注点：

• 代码资产：Notebook、Delta Live Tables管道定义、SQL脚本、Python/Scala作业包、CI/CD流水线配置。验收关注可运行性、版本可追溯、环境可迁移。
• 配置资产：集群策略、作业调度配置、Unity Catalog权限矩阵、密钥范围（Secret Scope）、连接配置。验收关注配置项与环境的对应关系、敏感信息是否脱敏。
• 数据资产：Bronze/Silver/Gold各层表结构、数据字典、血缘关系、数据质量规则、分区与保留策略。验收关注表清单完整性、字段口径一致性、血缘可追溯。
• 文档资产：需求规格说明书、架构设计文档、数据模型说明、运维手册、用户操作指南。验收关注版本一致性、与实现是否匹配。
• 运维资产：监控告警规则、作业SLA定义、故障处理Runbook、备份恢复策略、成本看板。验收关注可观测性覆盖度、告警阈值合理性。
• 验收证据链：测试报告、数据比对结果、性能压测记录、权限验证截图、上线确认单。验收关注证据与验收项的对应关系、可复现性。

这六类资产不是并列关系，而是存在依赖与支撑关系：代码和配置是“生产手段”，数据是“生产结果”，文档是“知识固化”，运维是“持续保障”，验收证据链则是“信任凭证”。下图展示了从需求到上线的交付物分类及其证据链构成：

二、交付物清单的字段设计

一份可执行的交付物清单，至少应包含以下字段：交付物编号、名称、类别、所属阶段、格式/存放位置、责任人、验收标准、关联需求编号、状态。其中“验收标准”是最容易被忽略却最关键的字段——它必须可观察、可复现，而不是“质量良好”这类主观描述。

例如，对于“Gold层销售汇总表”这一数据资产，验收标准可以写为：表行数与源系统日终对账一致；核心指标（GMV、订单量）与财务口径偏差≤0.1%；分区字段为dt且保留最近730天；表注释与数据字典一致。这样的标准让验收方有明确判断依据，也倒逼开发方在交付前自检。

三、验收证据链的构成逻辑

验收证据链的本质是“需求—实现—验证—确认”的闭环。每一条需求都应有对应的实现对象，每一个实现对象都应有对应的验证证据，每一份证据都应有确认人。证据链断裂通常发生在两个环节：一是需求变更后未同步更新测试用例，二是测试通过但未保留可复现的执行记录。

建议在项目早期就建立“需求追溯矩阵”（Requirements Traceability Matrix），将需求编号、设计文档章节、代码提交记录、测试用例编号、测试执行结果、验收确认单串联起来。在Databricks环境中，可以利用Git提交记录、MLflow实验记录、作业运行历史作为技术证据，用Unity Catalog的审计日志作为权限验证证据。

四、从需求到上线的阶段映射

不同阶段产生的交付物重点不同。需求阶段的核心交付物是需求规格说明书和验收标准草案；设计阶段是架构设计文档、数据模型、接口定义；开发阶段是代码资产和配置资产；测试阶段是测试报告和数据比对结果；上线阶段是运维资产和上线确认单。交付物清单应明确每个交付物的“产生阶段”和“冻结阶段”——例如数据模型在设计阶段冻结，代码在测试阶段冻结，配置在上线前冻结。

一个常见的误区是把所有文档都堆到上线前才写。正确的做法是：文档资产随阶段同步产出，验收证据链随测试同步积累。这样上线时只需要做“确认”而不是“补写”，验收周期可以从数周压缩到数天。

五、交付物清单模板示例

以下是一个可直接参考的交付物清单结构示例（字段为示例值，实际项目需根据合同和需求调整）：

这张表的价值不在于格式，而在于它把“交付什么”和“凭什么算交付”绑定在一起。当每个交付物都有明确的验收标准和责任人时，验收就从“扯皮”变成了“对账”。