当 parquet 使用 Snappy 算法而不是 gzip 时，将 parquet 数据写入 hive 的 spark 作业卡在最后一个任务中答案

【问题标题】：spark job which write parquet data to hive has stuck in the last task when parquet use Snappy algorithm rather than gzip当 parquet 使用 Snappy 算法而不是 gzip 时，将 parquet 数据写入 hive 的 spark 作业卡在最后一个任务中
【发布时间】：2017-12-31 01:56:51
【问题描述】：

我正在将一个镶木地板文件从 DataFrame 写入 Hive。当我使用 snappy 作为 parquet 压缩算法时，我可以看到除 1 之外的所有任务在写作阶段迅速完成（例如 30/31）。由于大量 gc 进程，最后一项任务需要很长时间才能完成。

当我使用 gzip 作为 parquet 压缩算法时，一切都会好起来的。

我想知道两种压缩算法的区别。

【问题讨论】：

这个问题是我用spark2.1.0才出现的。

标签： hadoop apache-spark apache-spark-sql parquet snappy

【解决方案1】：

gzip 自然地得到 Hadoop 的支持。 gzip 基于 DEFLATE 算法，它是 LZ77 和 Huffman Coding 的组合。

GZIP 压缩比 Snappy 使用 更多的 CPU 资源，但提供更高的压缩率。

GZip 通常是不常访问的冷数据的良好选择。

Snappy 是频繁访问的热点数据的更好选择。

Snappy 格式是可拆分，但 GZip 不是。可拆分性与 HBase 数据无关。

参考： Data Compression in Hadoop

【讨论】：