用途
当基于 Delta Lake 的湖仓需要的不只是通用的表格式指导时，可使用本技能。它帮助智能体设计 Medallion 风格的分层、事务性更新行为、CDC 合并，以及面向 Delta 平台的发布安全转换路径。
何时使用
- 设计 bronze、silver、gold 分层
- 实现 Delta Lake 的合并（merge）、更新插入（upsert）或删除（delete）
- 构建以 Databricks 为中心的批处理和流式湖仓流程
- 决定原始落地数据如何演变为可信的发布输出
注意：如果各层不承担明确不同的职责，就不要把 Medallion 术语当作装饰使用。
工作流程
-
定义各层职责。典型模式：
- bronze：原始或轻度标准化的落地层
- silver：经过清洗、一致性处理、契约感知的转换层
- gold：面向业务、可直接发布的输出层
-
定义层间移动规则。需要涵盖：
- 校验要求
- 变更行为
- CDC 合并策略
- 模式强制与演进策略
保持 bronze 宽松、gold 严格。原始数据的留存与发布数据的可信需要不同的运行规则。
-
谨慎协调批处理和流式写入者。检查点、合并和小文件行为必须支持恢复与维护。
-
将维护作为架构的一部分进行规划。包括：
- 压缩（compaction）
- 保留（retention）
- 优化（optimization）
- 清理（cleanup）
常见合理化借口
| 借口 | 现实 |
|---|---|
| “bronze、silver、gold 本身就是足够的架构。” | 没有契约和规则的分层名称只会带来混乱，而非设计清晰度。 |
| “我们可以把所有内容直接合并到 gold。” | 面向业务的层需要比原始摄取路径更强的校验和稳定性。 |
| “Delta 事务能解决所有运维问题。” | 你仍然需要深思熟虑的分层、维护和重放设计。 |
危险信号
- bronze、silver、gold 没有明确的职责
- gold 表直接由不稳定的原始落地逻辑供给
- 针对 CDC 或迟到数据的合并语义不清晰
- 忽略压缩等维护任务
验证清单
- 每个 Medallion 层都有明确的目的和质量标准
- 层间的移动、校验和变更规则是显式的
- 流式和批处理与 Delta 表的交互在运维上是安全的
- 维护和生命周期行为是设计的一部分