对象存储作为落地区
数据湖普遍用对象存储（S3、OSS 等）作为落地区：容量近乎无限、价格远低于块存储，Hadoop 生态通过 s3a:// 这类 scheme 访问。它的接口是「按 key 读写整个对象」，没有真正的目录——目录只是 key 前缀的展示效果。由此带来两个必须记住的差异：rename 实际是拷贝加删除，不具备原子性；列举目录（LIST）是按前缀操作，键空间越大代价越高。
基本信息
| 路径 scheme | s3a://（Hadoop 常用）、oss://、cos:// 依发行版而定 |
|---|---|
| 分层约定 | landing（原始）→ curated（清洗）→ marts（应用） |
| 访问工具 | spark/hadoop fs、各云厂商 CLI/SDK |
| 关键差异 | 无目录语义，rename 非原子、LIST 代价高 |
| 权限模型 | 按桶策略与账号策略控制，跨账号访问要双向配置 |
| 一致性 | 现代对象存储已提供强一致性读后写，仍不等于文件系统语义 |
用 hadoop fs 查看分区目录
用 hadoop fs 查看分区目录
hadoop fs -ls s3a://lake/curated/dwd/orders/dt=2026-10-11/ | head
hadoop fs -cat s3a://lake/curated/dwd/orders/dt=2026-10-11/_SUCCESS
# 只列举目标前缀，避免全桶扫描
hadoop fs -ls -d s3a://lake/curated/dwd/orders/dt=*典型使用场景
- 原始数据落地：上游文件原样存入 landing 区，便于问题回溯
- 清洗与加工：清洗结果放 curated 区，由多引擎按需读取
- 结果发布：应用层结果写入 marts 区，供报表与接口消费
- 长期归档：冷数据转低频存储，成本随访问频率下降
- 跨系统共享：不同集群与账号按前缀划分权限，共享同一份数据
语义差异对照
| 操作 | 本地文件系统 | 对象存储 |
|---|---|---|
| rename | 原子操作 | 拷贝加删除，非原子 |
| 列目录 | 读取目录元数据 | 按前缀 LIST，有请求成本 |
| 追加写 | 支持 | 不支持，需重写整个对象 |
| 权限 | POSIX 权限位 | 桶策略与账号策略 |
| 删除目录 | 递归删除 | 按前缀逐个删除对象 |
对象存储的 rename 是拷贝加删除、并非原子操作；依赖「临时目录 rename 落地」的流程要改为清单文件或提交协议标记完成。
很多分布式写入组件会通过提交协议（如输出提交器）把「写临时目录再改名」换成「写清单文件」，从而在对象存储上获得近似原子的可见性，这也是数据湖写入路径的标准做法。