用途
当存储层本身构成一项架构决策时，可使用本技能。它帮助智能体围绕 Iceberg、Delta、Hudi 进行推理，涵盖表演进、分区、压缩、快照行为，以及批处理与流式作业如何与共享湖仓表交互。
适用场景
- 在 Iceberg、Delta 和 Hudi 之间做选择
- 设计具有更新或合并行为的湖仓数据集
- 更改分区策略、快照保留或压缩行为
- 将 Spark、Flink 或仓库读取器与共享表格式集成
- 实现 CDC 风格或增量式湖仓管道
不适用于非受管平面文件数据集，即那些不打算像受治理表一样行为的数据集。
工作流程
- 定义表契约。包括：粒度与键、变更模型、读取模式、保留与快照策略、跨引擎兼容性要求。
- 有意识地选择表格式。
- Iceberg：较强的开放表互操作性与元数据驱动的规划
- Delta：在以 Databricks 为中心的栈中具备较强的湖仓工效学与事务模式
- Hudi：较强的增量与记录级更新用例
- 为生命周期而非仅首日查询设计物理布局。考虑：分区演进、小文件控制、压缩、元数据增长、合并与删除行为。
- 使计算引擎与表行为对齐。批处理与流式写入器不得在检查点、提交或模式变更上静默冲突。
- 定义维护与恢复操作。表格式需要运维性日常维护，而不仅是一次性创建。
常见合理化借口
- “表格式只是存储细节。”——格式选择会影响互操作性、维护、变更语义和长期成本。
- “压缩可以以后再决定。”——小文件和元数据膨胀会很快变成运维痛点。
- “任何引擎都能以相同方式读写该表。”——跨引擎支持存在差异，尤其是在高级写入和变更行为方面。
危险信号
- 仅凭熟悉程度选择格式
- 变更与删除语义未定义
- 忽略快照保留与清理
- 批处理与流式写入器在无协调的情况下写入同一张表
- 采用之后才发现互操作性要求
验证
- 表格式选择与互操作性和工作负载需求挂钩
- 变更、分区、保留和压缩规则明确
- 引擎兼容性假设已记录
- 表生命周期存在维护与恢复流程