存储格式基础：Parquet 与 Delta Lake 的关系
聊成本管控，得先搞清楚数据是怎么存的。很多人一上来就调参数、配策略，结果发现效果不好——说白了，底层存储格式都没吃透。
我刚开始做数据架构那会儿，也踩过这个坑。当时团队用 JSON 存日志，每天几百 GB，跑个查询要等半小时。后来换成 Parquet，压缩比直接干到 1:5，查询时间降到几分钟。嗯，从那以后我就养成了一个习惯：先看存储格式，再谈优化。
Parquet：列式存储的压缩优势
Parquet 是啥？一种列式存储格式。跟行式存储（比如 CSV、JSON）完全两个路子。
你想想看，行式存储存一条记录，所有字段挨着写在一起。查某个字段时，得把整行数据都读出来。浪费 IO，也浪费内存。
列式存储呢？同一列的数据连续存放。查某个字段，只读那一列的数据块。IO 少了，压缩也更好——因为同一列的数据类型一致，值分布也相似。
核心结论：列式存储天然适合分析型负载。压缩率高、扫描快、IO 小。这三个特性，直接决定了你的存储成本和查询成本。
我举个例子。一个订单表有 50 个字段，但你每天只查 5 个。用 Parquet 存，只读那 5 列的数据。用行式存，50 列全读。差距有多大？你自己算算。
Parquet 的压缩机制
Parquet 支持多种压缩编码。我个人习惯用 Snappy，平衡压缩比和速度。但如果你对存储成本特别敏感，可以上 Zstd 或 Gzip。
| 压缩算法 | 压缩比 | 压缩速度 | 解压速度 | 适用场景 |
|---|---|---|---|---|
| Snappy | 中等（约 2:1） | 极快 | 极快 | 实时查询、高频写入 |
| Zstd | 高（约 3:1 ~ 5:1） | 较快 | 较快 | 冷数据、归档存储 |
| Gzip | 很高（约 4:1 ~ 6:1） | 慢 | 慢 | 低频查询、长期归档 |
| LZ4 | 较低（约 1.5:1） | 极快 | 极快 | 高吞吐写入、日志流 |
我的建议：热数据用 Snappy，冷数据用 Zstd。别一股脑全用 Gzip，压缩慢、解压也慢，查询延迟受不了。
Delta Lake：在 Parquet 之上加了什么？
Delta Lake 不是替代 Parquet 的。它是在 Parquet 外面包了一层「事务层」。
你可以这么理解：Parquet 是砖头，Delta Lake 是水泥。砖头本身很好，但堆在一起容易倒。水泥把它们粘起来，还加了钢筋——事务日志、版本控制、Schema 强制、数据回滚。
Delta Lake 的核心组件就两个：
- Parquet 数据文件：实际存储数据的文件，跟普通 Parquet 没区别
- Delta 事务日志（_delta_log）：记录每一次数据变更的 JSON 文件
每次写入、更新、删除，Delta Lake 都会在 _delta_log 目录下生成一个新的 JSON 文件。这个文件记录了这次操作改了哪些 Parquet 文件、新增了哪些、删除了哪些。
注意：事务日志会不断累积。时间长了，日志文件数量可能比数据文件还多。我见过一个项目，日志目录占了总存储的 30%。这就是成本黑洞。
数据文件的生命周期
理解文件生命周期，才能做好成本管控。Delta Lake 里的数据文件，大致经历这几个阶段：
- 写入阶段：新数据写入，生成新的 Parquet 文件
- 活跃阶段：文件被查询引擎频繁读取
- 合并阶段：小文件合并成大文件（OPTIMIZE 操作）
- 归档阶段：旧版本数据不再被查询，但保留用于时间旅行
- 清理阶段：VACUUM 操作删除过期文件
每个阶段都有成本优化的空间。比如写入阶段，文件大小控制不好，后面合并成本就高。归档阶段，保留版本太多，存储成本直线上升。
避坑指南：我曾经帮一个客户做成本审计，发现他们 Delta 表保留了 90 天的历史版本。实际上业务只需要 7 天。多出来的 83 天版本，每个月多花 2000 多美元的存储费。嗯，调完保留策略，成本直接砍半。
Parquet 与 Delta Lake 的对比
| 特性 | Parquet | Delta Lake |
|---|---|---|
| 存储格式 | 列式存储 | Parquet + 事务日志 |
| 事务支持 | 无 | ACID 事务 |
| 版本控制 | 无 | 时间旅行（默认保留 30 天） |
| Schema 强制 | 无 | Schema 校验 + 自动演进 |
| 小文件问题 | 存在 | 存在（需 OPTIMIZE 解决） |
| 压缩效率 | 高 | 与 Parquet 一致 |
| 成本管控手段 | 有限（压缩 + 分区） | 丰富（OPTIMIZE、VACUUM、ZORDER） |
说白了，Parquet 给了你一个很好的基础，但 Delta Lake 给了你更多控制权。控制权越多，优化空间越大，但也越容易出错。
核心知识体系
下面这张图，把本章的核心逻辑串起来了。我建议你多看几遍，理解每个节点之间的关系。
小结
这一章我们聊了三件事：
- Parquet 列式存储：压缩好、扫描快，是成本优化的基础
- Delta Lake 事务层：在 Parquet 上加了版本控制和事务能力，但也带来了额外的存储开销
- 数据文件生命周期：从写入到清理，每个阶段都有成本优化的切入点
记住一句话：不懂存储格式，就别谈成本优化。后面几章我们会深入每个优化手段，但地基先得打牢。