对象存储上的湖仓布局
对象存储（AWS S3、阿里云 OSS、MinIO 等）没有真正的目录，只有按前缀（prefix）组织的扁平 key 空间；湖仓用「层 / 域 / 表 / 分区」四段前缀模拟目录，例如 s3://corp-lake/silver/trade/order/dt=2026-10-12/。这样分区裁剪、权限授权、生命周期策略都能落在前缀上，Spark、Trino、Hive、Flink 读的是同一份路径，不会各建一套目录。
基本信息
| 典型布局 | <bucket>/<层>/<域>/<表>/<分区>/ |
|---|---|
| 物理本质 | 扁平 key 空间，目录由前缀模拟 |
| 关键开销 | LIST 列举、rename（复制加删除） |
| 生命周期 | 按前缀转低频 / 归档 / 过期 |
| 权限粒度 | 桶策略加 IAM 前缀授权 |
典型使用场景
- 建表前统一前缀规范：同一张表只保留一种路径写法，避免各引擎各自建目录
- 冷分区降成本：按 dt 前缀配生命周期，30 天后转低频、一年后转归档
- 按层做权限隔离：ODS 只给采集账号写，ADS 只给报表账号读
- 迁移或重建表：按前缀整体复制，而不是逐文件搬运
- 排查「表里读不到数据」：先核对引擎访问的前缀、桶权限与生命周期规则是否一致
目录布局与生命周期
目录布局与生命周期
s3://corp-lake/ods/trade/order/dt=2026-10-12/part-00000.parquet # 贴源保真分区
s3://corp-lake/silver/trade/order/dt=2026-10-12/ # 清洗后明细
生命周期规则（S3 Lifecycle / OSS 规则，均按前缀匹配）：
silver/ 30 天后转低频访问 IA # 降低成本，仍可即时读
silver/ 365 天后转归档 Glacier/Archive # 只留合规，读取需解冻
ods/ 90 天后过期删除 # 配合补数窗口
规则的匹配对象是前缀，目录改名等于规则失效存储类别与读取代价
| 存储类别 | 相对成本 | 取回代价 | 适用数据 |
|---|---|---|---|
| 标准 | 高 | 即时 | 近 30 天热分区 |
| 低频访问 IA | 中 | 即时，有最小存储期 | 30 至 365 天冷分区 |
| 归档 | 低 | 需先解冻，分钟到小时 | 合规留存、极少读取 |
对象存储上的 rename 不是原子操作，S3 实际是复制加删除。所以湖表提交靠写新的清单文件（manifest）而非改目录名；手工 mv 目录会让表元数据指向失效路径。
归档类存储取回要付费且有延迟，把需要随时回溯的分区过早归档，补数和故障排查都会被卡住；归档前先确认业务回溯期。