Hive Parquet如何提升查询性能

Hive Parquet 这种列式存储格式，在查询性能上确实有两把刷子。它的设计思路，说白了就是“按需取用、绝不多读”，背后有五个核心特性在支撑。

1. 列式存储的天然优势

   数据按列存放，而不是传统的一行一行堆着。这就意味着，查询的时候只需要把用到的那些列拖出来就行，I/O 操作和内存占用自然就降下去了——别小看这一点，在数据量大的场景下，节省的可是真金白银的资源和时间。

2. 多重压缩算法加持

   Parquet 原生支持 Snappy、Gzip 等多种压缩方案。压缩之后，磁盘空间省了，网络传输也不那么拥堵了，查询速度自然就上去了。选对压缩算法，效果翻倍。

3. 两级索引加速定位

   行组索引和页级索引联手，让 Hive 能像翻书目录一样快速跳到目标行，而不是一页一页翻到底。行组索引先框定大致范围，页级索引再精确到具体页面，层层递进，效率极高。

4. 布隆过滤器快速判存

   这是一个非常聪明的概率型数据结构——空间占用极小，但能快速告诉你某个值到底在不在集合里。用它做前置过滤，Hive 就不用傻乎乎地扫描整个数据集，直接跳过无关块，性能提升立竿见影。

5. 写入时排序与分桶

   数据写进去之前就按查询常用的字段排好序、分好桶，后续查询时相关数据自然扎堆，扫描量大大减少。分桶还能并行拉数据，多线程齐上阵，本地性也好，提速效果很直观。

上面说的是 Parquet 自带的“天赋技能”，但如果想让查询性能再上一个台阶，还可以从下面几个方向动手。

1. 选对压缩算法

   没有什么万能的方案，得看数据类型。文本数据 Snappy 或 Gzip 比较常用；数值数据则可以考虑 LZ4 或 Zstandard，压缩比和解压速度往往更均衡。试一下就能找到最适合自己场景的那一款。

2. 调优 Parquet 参数

   行组大小、页大小这些参数，直接影响存储效率和读盘效率。数据量大、查询字段少，就把行组调大一点；反之则适当缩小。没有标准答案，但值得针对性测试。

3. 善用索引和布隆过滤器

   那些被高频用于 where 条件的列，给它们建上索引或者布隆过滤器，效果很直接。这一步投入的成本很小，但查询时能帮你砍掉大量无关数据扫描。

4. 排序和分桶别浪费

   在数据写入阶段，就提前按常用查询条件排好序、分好桶。等到实际查询时，数据定位快、并行度高，甚至还能利用本地性减少网络开销。这笔“前期投入”非常划算。

5. 优化 Hive SQL 本身

   底层的存储和参数调优做好了，SQL 写得不好也是白搭。尽量用 MapReduce 或 Spark 这类执行引擎，避免 full table scan；分区、分桶这些技术能帮你进一步缩小每次查询要扫的数据量。写出高效的查询，才算把 Parquet 的潜力彻底压榨出来。