I/O 优化手段

一句话定位：数据处理链路的吞吐上限往往卡在 I/O（磁盘/网络/解析），而非计算。优化的主线是”少读、少传、少解析、提前准备”。

1. 投影下推 / 谓词下推（少读、少传）

• 投影下推（Projection Pushdown）：只读取查询/计算需要的列。列存下同一列连续存储，可直接跳过无关列块，IO 量随列数下降。
• 谓词下推（Predicate Pushdown）：把 filter 条件下推到扫描层，在读取时即过滤。如 Parquet 用 Row Group / Page 的 min-max/null 统计做谓词剪枝，跳过不满足条件的数据块。
• 收益来源：减少从存储到计算引擎的数据量（IO + 网络 + 反序列化）。

2. 压缩算法选型（带宽 vs CPU）

算法	速度	压缩比	适用
Snappy	快	中（~2-3x）	CPU 是瓶颈、热数据/中间数据
Zstd	可调，较快	高（~3-5x+）	带宽/存储是瓶颈、冷数据

• 权衡：压缩省带宽与存储，但解压耗 CPU。CPU 紧张选 Snappy，IO/存储紧张选 Zstd。

3. 小文件合并（降元数据与调度开销）

• 大量小文件 → NameNode/文件句柄元数据压力大、每文件一个 task 导致调度开销高、随机寻址成本高。
• 手段：写入时合并大文件、定期 Compaction（HDFS 小文件合并、ORC/Parquet 合并）、使用面向大文件的格式。合并后 task 数下降，吞吐提升明显。

4. 异步预取与 MMap（掩盖延迟）

• 异步预取（Async Prefetch）：后台线程提前读取后续数据，与计算重叠，掩盖 IO 延迟（类比 CPU 硬件预取）。
• 内存映射（MMap）：文件映射到进程地址空间，由 OS 页缓存管理，免系统调用拷贝，适合大文件顺序/随机读；但大文件 MMap 可能挤占页缓存，需权衡。

参考：Apache Parquet / ORC 官方文档（Pushdown、压缩）；Linux mmap 手册