29

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

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

这些压缩格式有什么区别？

4

5 回答 5

37

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

一般用法： GZip 对于不经常访问的冷数据 通常是一个不错的选择Snappy 或 LZO是访问频繁的热点数据的更好选择

Snappy 通常比 LZO 表现更好。值得进行测试以查看您是否检测到显着差异。

Splittablity ： 如果您需要压缩数据可拆分，BZip2、LZO 和 Snappy 格式是可拆分的，但 GZip 不是。

与使用 Snappy 数据相比，GZIP 在读取 GZIP 数据时的数据压缩率比 Snappy 多 30%，而 CPU 比使用 Snappy 数据的多 2 倍。

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

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

在本文中查看广泛的研究和基准代码和结果（各种通用压缩算法的性能——其中一些速度快得令人难以置信！）。

在此处输入图像描述

于 2019-06-01T20:50:52.553 回答
30

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

当 Spark 默认从 GZIP 切换到 Snappy 时，原因如下：

根据我们的测试，gzip 解压非常慢（< 100MB/s），使得查询解压受限。Snappy 可以在单核上以约 500MB/s 的速度解压缩。

活泼：

  • 存储空间：高
  • CPU 使用率：低
  • 可拆分：是(1)

压缩包：

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

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

于 2017-05-30T03:18:22.743 回答
23

只需在您的数据上尝试它们。

lzo 和 snappy 是快速压缩器和非常快速的解压缩器，但压缩比 gzip 压缩得更好，但速度稍慢。

于 2016-03-04T07:44:40.993 回答
5

根据下面的数据，我会说gzip在流式传输等场景之外的胜利，其中写入时间延迟很重要。

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

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

结果（大文件，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             |
+-------+---------+---------+--------------------------+

小文件.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

大文件.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
于 2020-09-24T15:08:59.560 回答
1

我同意 1 个答案（@Mark Adler）并有一些研究信息[1]，但我不同意第二个答案（@Garren S）[2]。也许 Garren 误解了这个问题，因为：[2] Parquet splitable with all supported codecs: 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 上执行转换。转换 - 选择按多个字段排序的所有字段。这项研究当然不是标准的，但至少有一点显示了真正的比较。与其他数据集和计算结果可能不同。

于 2018-11-20T09:12:06.680 回答