Question

我正在尝试使用Spark SQL来编写parquet文件。

默认情况下，Spark SQL支持gzip，但它也支持其他压缩格式，如snappy和lzo。

这些压缩格式之间有什么区别，哪种格式最适合Hive加载。

Answer 1

只需尝试使用您的数据。

lzo和snappy是快速压缩器和非常快速的解压缩程序，但压缩程度较低，与gzip相比压缩效果更好，但速度稍慢。

Answer 2

如果您可以处理更高的磁盘使用率以获得性能优势（使用较低的CPU + Splittable），请使用Snappy。

当Spark默认从GZIP切换到Snappy时，这就是原因：

根据我们的测试，gzip解压缩非常慢（<100MB / s），使查询解压缩绑定。 Snappy可以以~500MB / s的速度解压缩在一个核心上。

的Snappy：

存储空间：高
CPU使用率：低
分拆：是（1）

GZIP：

存储空间：中等
CPU使用率：中等
分拆：否

1）http://boristyukin.com/is-snappy-compressed-parquet-file-splittable/

Answer 3

根据下面的数据，我想说gzip在流式传输之外的情况下胜出，在这种情况下，写入时间延迟很重要。

请记住，速度本质上是计算成本，这一点很重要。但是，云计算是一次性成本，而云存储是经常性成本。权衡取决于数据的保留期限。

让我们用Python中大小为parquet的文件测试速度和大小。

结果（大文件，117 MB）：

        +----------+----------+--------------------------+
        | snappy   | gzip     | (gzip-snappy)/snappy*100 |
+-------+----------+----------+--------------------------+
| write | 1.62 ms  | 7.65 ms  | 372% slower              |
+-------+----------+----------+--------------------------+
| size  | 35484122 | 17269656 |  51% smaller             |
+-------+----------+----------+--------------------------+
| read  | 973 ms   | 1140 ms  |  17% slower              |
+-------+----------+----------+--------------------------+

结果（小文件，4 KB，虹膜数据集）：

        +---------+---------+--------------------------+
        | snappy  | gzip    | (gzip-snappy)/snappy*100 |
+-------+---------+---------+--------------------------+
| write | 1.56 ms | 2.09 ms | 33.9% slower             |
+-------+---------+---------+--------------------------+
| size  | 6990    | 6647    |  5.2% smaller            |
+-------+---------+---------+--------------------------+
| read  | 3.22 ms | 3.44 ms |  6.8% slower             |
+-------+---------+---------+--------------------------+

small_file.ipynb

import os, sys
import pyarrow
import pandas as pd
import numpy as np
from sklearn.datasets import load_iris

iris = load_iris()

df = pd.DataFrame(
    data= np.c_[iris['data'], iris['target']],
    columns= iris['feature_names'] + ['target']
)

# ========= WRITE =========
%timeit df.to_parquet(path='iris.parquet.snappy', compression='snappy', engine='pyarrow', index=True)
# 1.56 ms

%timeit df.to_parquet(path='iris.parquet.gzip', compression='snappy', engine='pyarrow', index=True)
# 2.09 ms

# ========= SIZE =========
os.stat('iris.parquet.snappy').st_size
# 6990

os.stat('iris.parquet.gzip').st_size
# 6647

# ========= READ =========
%timeit pd.read_parquet(path='iris.parquet.snappy', engine='pyarrow')
# 3.22 ms

%timeit pd.read_parquet(path='iris.parquet.gzip', engine='pyarrow')
# 3.44 ms

large_file.ipynb

import os, sys
import pyarrow
import pandas as pd

df = pd.read_csv('file.csv')

# ========= WRITE =========
%timeit df.to_parquet(path='file.parquet.snappy', compression='snappy', engine='pyarrow', index=True)
# 1.62 s

%timeit df.to_parquet(path='file.parquet.gzip', compression='gzip', engine='pyarrow', index=True)
# 7.65 s

# ========= SIZE =========
os.stat('file.parquet.snappy').st_size
# 35484122

os.stat('file.parquet.gzip').st_size
# 17269656

# ========= READ =========
%timeit pd.read_parquet(path='file.parquet.snappy', engine='pyarrow')
# 973 ms

%timeit pd.read_parquet(path='file.parquet.gzip', engine='pyarrow')
# 1.14 s

Answer 4

我同意1个答案（@Mark Adler）并有一些研究信息[1]，但我不同意第二个答案（@Garren S）[2]。也许Garren误解了这个问题，因为： [2]可使用所有受支持的编解码器拆分的Parquet：Is gzipped Parquet file splittable in HDFS for Spark?，Tom White的Hadoop：权威指南，第4版，第5章：Hadoop I / O，第106页。 [1]我的研究：源数据-205 GB。文本（分隔的字段），未压缩。输出数据：

<!DOCTYPE html>
<html>

<head>
  <style>
    table,
    th,
    td {
      border: 1px solid black;
      border-collapse: collapse;
    }
  </style>
</head>

<body>

  <table style="width:100%">
    <tr>
      <th></th>
      <th>time of computing, hours</th>
      <th>volume, GB</th>
    </tr>
    <tr>
      <td>ORC with default codec</td>
      <td>3-3,5</td>
      <td>12.3</td>
    </tr>
    <tr>
      <td>Parquet with GZIP</td>
      <td>3,5-3,7</td>
      <td>12.9</td>
    </tr>
    <tr>
      <td>Parquet with SNAPPY</td>
      <td>2,5-3,0</td>
      <td>60.4</td>
    </tr>
  </table>

</body>

</html>

使用Hive在2 m4.16xlarge的EMR上进行转化。转换-按几个字段的顺序选择所有字段。当然，这项研究不是标准的，但至少有一点表明了真正的比较。对于其他数据集，计算结果可能有所不同。

Answer 5

压缩率： GZIP压缩比Snappy或LZO占用更多的CPU资源，但提供更高的压缩率。

常规用法： 对于不经常访问的冷数据，GZip通常是一个不错的选择。对于经常访问的 hot 数据，Snappy或LZO是更好的选择。

Snappy的性能通常优于LZO。值得运行测试以查看是否检测到显着差异。

可拆分性： 如果需要压缩数据是可拆分的，则BZip2，LZO和Snappy格式是可拆分的，而GZip则不可。

与消耗Snappy数据的GZIP相比，读取GZIP数据时的GZIP压缩数据比Snappy多30％，CPU多2倍。

LZO专注于在低CPU使用率和更高压缩率下以更高的CPU成本为代价的解压缩速度。

对于 长期/静态 存储，GZip压缩仍然更好。

Spark SQL - gzip vs snappy vs lzo压缩格式之间的区别

5 个答案: