技能介绍

要解决的问题

Parquet 虽然是列式存储，但读取侧的浪费经常被忽略：一次 SELECT a, b FROM t WHERE c > 100 如果不做规划，可能把整份文件的每个 row group 都拉进内存，再在应用层过滤。后果是 IO 放大、内存峰值上升、扫描时间线性增长，而这些开销本可以通过列裁剪和谓词下推避免。

另一个隐性成本在文件侧：row group 切得太大，并发度上不去；切得太碎，元数据膨胀。编码方式选错（比如对高基数列强行字典编码）也会让压缩收益归零。这类问题往往在数据量上来后才暴露，排查成本很高。

技能如何工作

Parquet 列裁剪优化器围绕读取路径做优化，核心能力包括：

列裁剪（Column Pruning）：解析查询涉及的列，只读取目标列所在的数据块，跳过无关列。
谓词下推（Predicate Pushdown）：把过滤条件尽可能下推到存储层，在 row group / page 粒度提前剔除不匹配的数据，减少回读量。
查询模式分析：归纳实际查询访问的列集合与过滤条件，据此给出优化建议，而不是套用固定模板。
row group 大小建议：根据查询模式和数据特征推荐 row group 切分策略，改善并发与扫描效率。
字典编码策略建议：判断哪些列适合字典编码，哪些列不适合，避免无效压缩。

典型流程是：先从查询里提取列引用与谓词，再映射到 Parquet 的物理布局，输出裁剪与下推方案，最后结合访问模式给出 row group 与编码的配置建议。

适用边界与注意点

该技能优化的是读取路径，不改变 Parquet 的写入格式；已有文件需要按建议重新组织才能拿到收益。
其上游文档来自 parquet.js 项目，这是一个纯 Node.js、完全异步的 Parquet 文件格式实现。官方文档明确提到该项目需要一次大规模重构，并有待处理的大量 issue 与 PR，接入前建议先在小规模数据上验证行为。
row group 与编码建议依赖查询模式分析，模式不稳定或数据分布特殊时，结论需要自行复核。
谓词下推的效果取决于谓词能否匹配到存储层的编码与排序信息，复杂表达式或跨列条件可能无法完全下推。