Parquet Java 中的压缩算法

Apache Parquet 是一种面向分析型工作负载的列式存储格式，但它也可以用于存储任何类型的结构化数据，从而解决多种用例。

其最显着的特性之一是能够在处理过程的两个阶段使用不同的压缩技术高效地压缩数据。这降低了存储成本并提高了读取性能。

本文解释了 Java 中 Parquet 的文件压缩，提供了使用示例，并分析了其性能。

压缩技术

与传统的基于行的存储格式不同，Parquet 使用列式方法，允许根据相同类型数据的局部性和值冗余性使用更特定和有效的压缩技术。

Parquet 以二进制格式写入信息，并在两个不同的级别应用压缩，每个级别使用不同的技术：

• 在写入列的值时，它会根据初始值的特性自适应地选择编码类型：字典编码、游程编码、位打包、增量编码等。
• 每当达到一定数量的字节（默认为 1MB）时，就会形成一个页面，并且使用程序员配置的算法（无压缩、GZip、Snappy、LZ4、ZSTD 等）压缩二进制块。

尽管压缩算法是在文件级别配置的，但每列的编码是使用内部启发式算法自动选择的（至少在 parquet-java 实现中是这样）。

不同压缩技术的性能在很大程度上取决于您的数据，因此没有一种万能的解决方案能够保证最快的处理时间和最低的存储空间消耗。 您需要执行自己的测试。

代码

配置很简单，只有在写入时才需要显式设置。读取文件时，Parquet 会发现使用了哪种压缩算法并应用相应的解压缩算法。

配置算法或编解码器

在使用 Protocol Buffers 和 Avro 的 Carpet 和 Parquet 中，要配置压缩算法，只需调用 builder 的 withCompressionCodec 方法：

Carpet

CarpetWriter<T> writer = new CarpetWriter.Builder<>(outputFile, clazz)
    .withCompressionCodec(CompressionCodecName.ZSTD)
    .build();

Avro

ParquetWriter<Organization> writer = AvroParquetWriter.<Organization>builder(outputFile)
    .withSchema(new Organization().getSchema())
    .withCompressionCodec(CompressionCodecName.ZSTD)
    .build();

Protocol Buffers

ParquetWriter<Organization> writer = ProtoParquetWriter.<Organization>builder(outputFile)
    .withMessage(Organization.class)
    .withCompressionCodec(CompressionCodecName.ZSTD)
    .build();

该值必须是 CompressionCodecName 枚举中可用的值之一：UNCOMPRESSED、SNAPPY、GZIP、LZO、BROTLI、LZ4、ZSTD 和 LZ4_RAW（LZ4 已弃用，应使用 LZ4_RAW）。

压缩级别

某些压缩算法提供了一种微调压缩级别的方法。此级别通常与它们需要为查找重复模式而付出的努力有关，压缩级别越高，压缩过程所需的的时间和内存就越多。

尽管它们带有默认值，但可以使用 Parquet 的通用配置机制进行修改，尽管每个编解码器使用不同的键。

此外，要选择的值不是标准的，并且取决于每个编解码器，因此您必须参考每个算法的文档以了解每个级别提供了什么。

ZSTD

要引用级别的配置，ZSTD 编解码器声明一个常量：ZstandardCodec.PARQUET_COMPRESS_ZSTD_LEVEL。

可能的值范围从 1 到 22，默认值为 3。

CarpetWriter<T> writer = new CarpetWriter.Builder<>(outputFile, clazz)
    .withCompressionCodec(CompressionCodecName.ZSTD)
    .build();

LZO

要引用级别的配置，LZO 编解码器声明一个常量：LzoCodec.LZO_COMPRESSION_LEVEL_KEY。

可能的值范围从 1 到 9、99 和 999，默认值为“999”。

ParquetWriter<Organization> writer = AvroParquetWriter.<Organization>builder(outputFile)
    .withSchema(new Organization().getSchema())
    .withCompressionCodec(CompressionCodecName.ZSTD)
    .build();

GZIP

它不声明任何常量，您必须直接使用字符串“zlib.compress.level”，可能的值范围从 0 到 9，默认值为“6”。

ParquetWriter<Organization> writer = ProtoParquetWriter.<Organization>builder(outputFile)
    .withMessage(Organization.class)
    .withCompressionCodec(CompressionCodecName.ZSTD)
    .build();

---

性能测试

为了分析不同压缩算法的性能，我将使用两个包含不同类型数据的公共数据集：

• 纽约市出租车行程：在几列中包含大量数值和少量字符串值。它有 23 列，包含 1960 万条记录。
• 意大利政府的凝聚力项目：许多列包含浮点值以及大量的各种文本字符串。它有 91 列，包含 200 万行。

我将评估 Parquet Java 中启用的一些压缩算法：UNCOMPRESSED、SNAPPY、GZIP、LZO、ZSTD、LZ4_RAW。

正如预期的那样，我将使用带有 parquet-java 提供的默认配置和每种算法的默认压缩级别的 Carpet。

您可以在 GitHub 上找到源代码，测试是在配备 AMD Ryzen 7 4800HS CPU 和 JDK 17 的笔记本电脑上完成的。

文件大小

为了了解每种压缩的性能，我们将采用等效的 CSV 文件作为参考。

格式	gov.it	纽约出租车
CSV	1761 MB	2983 MB
未压缩	564 MB	760 MB
SNAPPY	220 MB	542 MB
GZIP	**146 MB**	448 MB
ZSTD	148 MB	**430 MB**
LZ4_RAW	209 MB	547 MB
LZO	215 MB	518 MB

在这两个测试中，使用 GZip 和 Zstandard 进行压缩最为高效。

仅使用 Parquet 编码技术，文件大小可以减少到原始 CSV 大小的 25%-32%。应用额外压缩后，它将减少到CSV 大小的 9% 到 15%。

写入

压缩信息会带来多少开销？

如果我们三次写入相同的信息并计算平均秒数，我们会得到：

算法	gov.it	纽约出租车
未压缩	25.0	57.9
SNAPPY	25.2	56.4
GZIP	39.3	91.1
ZSTD	27.3	64.1
LZ4_RAW	**24.9**	56.5
LZO	26.0	**56.1**

SNAPPY、LZ4 和 LZO 达到的时间与不压缩相似，而 ZSTD 会增加一些开销。GZIP 性能最差，写入时间变慢了 50%。

读取

读取文件比写入更快，因为需要的计算更少。

读取文件中的所有列，以秒为单位的时间为：

算法	gov.it	纽约出租车
未压缩	11.4	37.4
SNAPPY	**12.5**	**39.9**
GZIP	13.6	40.9
ZSTD	13.1	41.5
LZ4_RAW	12.8	41.6
LZO	13.1	41.1

读取时间接近于不压缩信息，解压缩的开销在 10% 到 20% 之间。

结论

在读取和写入时间方面，没有一种算法明显优于其他算法，所有算法都在相似的范围内。在大多数情况下，压缩信息可以弥补空间节省（和传输）带来的时间损失。

在这两个用例中，选择一种或另一种算法的决定因素可能是达到的压缩率，ZSTD 和 Gzip 突出（但写入时间较差）。

每种算法都有其优势，因此最佳选择是使用您的数据进行测试，考虑哪个因素更重要：

• 最大限度地减少存储使用，因为您存储大量很少使用的数据。
• 最大限度地减少文件生成时间。
• 最大限度地减少读取时间，因为文件会被多次读取。

就像生活中的一切一样，这是一个权衡，您必须看看什么最能弥补。在 Carpet 中，默认情况下，如果您不配置任何内容，它会使用 Snappy 进行压缩。

实现细节

该值必须是 CompressionCodecName 枚举中可用的值之一。与每个枚举值关联的是实现算法的类的名称：

CarpetWriter<T> writer = new CarpetWriter.Builder<>(outputFile, clazz)
    .withCompressionCodec(CompressionCodecName.ZSTD)
    .build();

Parquet 将使用反射来实例化指定的类，该类必须实现 CompressionCodec 接口。如果您查看其源代码，您会发现它位于 Hadoop 项目中，而不是 Parquet。这表明 Parquet 在 Java 实现中与 Hadoop 的耦合程度。

要使用其中一种编解码器，您必须确保已添加包含其实现的 JAR 作为依赖项。

并非所有实现都存在于添加 parquet-java 时具有的传递依赖项中，或者您可能过于积极地排除了 Hadoop 依赖项。

在 org.apache.parquet:parquet-hadoop 依赖项中，包含 SnappyCodec、ZstandardCodec 和 Lz4RawCodec 的实现，这会传递导入 snappy-java、zstd-jni 和 aircompressor 依赖项以及这三种算法的实际实现。

在 hadoop-common:hadoop-common 依赖项中，包含 GzipCodec 的实现。

BrotliCodec 和 LzoCodec 的实现在哪里？它们不在任何 Parquet 或 Hadoop 依赖项中，因此，如果您在不添加其他依赖项的情况下使用它们，则您的应用程序将无法使用那些格式压缩的文件。

• 要支持 LZO，您需要将依赖项 org.anarres.lzo:lzo-hadoop 添加到您的 pom 或 gradle 文件中。
• Brotli 的情况更为复杂：该依赖项不在 Maven Central 中，您还必须添加 JitPack 存储库。

以上是Parquet Java 中的压缩算法的详细内容。更多信息请关注PHP中文网其他相关文章！