iceberg中的压缩：微调iceberg表的数据文件

Apache Iceberg格式已经席卷了数据湖世界，成为许多公司数据基础架构的基石。有一些维护最佳实践可以帮助您从Iceberg表获得最佳性能。本文将深入了解压缩和重写数据文件过程。

小文件问题

当频繁提取数据时，特别是在流式传输时，可能没有足够的新数据来创建最佳的数据文件大小来读取，如128MB、256MB或512MB。这导致越来越多的较小的文件，随着文件操作数量的增加（打开文件、读取文件、关闭文件），这些文件可能会影响性能。

使用压缩，您可以根据目标文件大小将每个分区中的数据文件重写为较少的较大文件。因此，如果您的目标是128MB的文件，那么分区在压缩后将是这样的：

现在，当您扫描特定分区时，只有一个文件要扫描，而不是五个文件，这将文件操作数量减少80%，并加快查询性能。

重写数据文件过程

在Iceberg 库中，有一个名为rewriteDataFiles的过程，用于执行压缩操作。该过程可以在Spark 中使用SparkSQL，如下所示：

-- 这将运行压缩,-- 通过表属性write.target-file-size-bytes设置目标文件大小-- 默认为512MB
CALL catalog.system.rewrite_data_files(     table => 'db.table1',       strategy => 'binpack',       options => map('min-input-files','2'))

这也可以使用Java在Spark中运行：

Table table = ...SparkActions    .get()    .rewriteDataFiles(table)    .option("min-input-files", "2")    .execute();

在这两个代码段中，都指定了一些压缩的参数：

• 表：在哪个表上运行操作

• 策略：是使用“binpack”还是“sort”策略（每种策略都在下面的章节中详细介绍）

• 选项：用于定制作业运行方式的设置，例如，要压缩的最小文件数，以及要压缩的文件的最小/最大文件大小

上述示例之外的其他参数包括：

• 查询条件：过滤要压缩的数据文件的条件（比如您只想针对特定分区进行压缩）

• 排序顺序：使用“sort”策略时如何对数据进行排序

如果您正在利用Iceberg 中的读取时合并来优化行级更新和删除操作，另一件要记住的事情是，压缩还将协调删除文件，这缩短了读取时间，因为它们在读取期间不必合并删除文件。

Binpack重写策略

默认的重写策略是binpack，它只需将较小的文件重写到目标大小，并在没有排序等额外优化的情况下协调任何删除文件。此策略是最快的，因此如果完成压缩所需的时间是一个考虑因素，那么这可能是您最好的选择。目标文件大小设置为默认为512MB的表设置，可以这样更改：

--将目标文件大小设置为128mbALTER TABLE catalog.db.table1 SET TBLPROPERTIES (    'write.target-file-size-bytes' = '134217728');

（注意：默认512MB是理想的，因为默认情况下目标行组大小为128MB，因此它仍将达到使用Parquet文件所需的并行度级别。）

如果您在流或微批处理中运行压缩，运行binpack可能是最快的策略，但您可能不想在整个表上运行压缩，只压缩上一个周期内摄入的数据，以避免小文件。

例如，以下代码段仅压缩过去一小时中创建的数据，假设我们的表结构包含一个“ingested_at”字段，该字段在数据被摄取时填充：

CALL catalog_name.system.rewrite_data_files(     table => 'db.sample',     where => 'ingested_at between "2022-06-30 10:00:00" and "2022-06-30 11:00:00"' )

这将导致一个更快的压缩作业，该作业不会压缩所有文件或协调每个删除文件，但仍然提供一些增强，直到一个更大的作业可以不那么定期地运行。

排序策略

排序策略不仅允许您优化文件大小，还允许您对数据进行排序，以对数据进行聚合，以获得更好的性能。将类似数据聚集在一起的好处是，与查询相关的数据文件越少，这意味着最小/最大过滤的好处将越大（要扫描的文件越少，速度越快）。

例如，不排序：

我们将文件的数量从三个减少到两个，但如果不排序，无论您可以查询哪个team，您都必须搜索这两个文件。这可以通过排序来改进，您可以按团队对数据进行聚类。

现在，所有绿色和黄色团队数据都仅限于一个文件，这将加快对这些团队成员的查询速度。红队被分成两个文件，但我们的情况还是比以前好。使用排序策略运行压缩看起来与binpack几乎相同，只是添加了一个“sort_order”参数。

CALL catalog.system.rewrite_data_files(    table => 'db.teams',       strategy => 'sort',       sort_order => 'team ASC NULLS LAST')

指定排序顺序时，您可以指定要排序的多个列，并且必须指定如何处理空值。因此，如果您想在初始团队排序后按每个团队的名称对每个团队进行排序，它将是这样的：

CALL catalog.system.rewrite_data_files(     table => 'db.teams',       strategy => 'sort',       sort_order => 'team ASC NULLS LAST, name DESC NULLS FIRST'
)

Z阶排序

Z阶簇是一个可以多维过滤来优化表的强大方法。Z阶排序与多列排序不同，因为Z阶对所有被排序的列的权重相等（相较多列排序他不是只执行一种排序it doesn’t do one sort than the other）。

为了说明这是如何工作的，假设您想按身高和年龄对表进行排序，然后将所有记录绘制成四个象限，如下所示：

您将所有记录放入这四个象限中，然后将它们写入相应的文件。当查询中涉及两个维度时，这将最大限度地发挥最小/最大筛选器的好处。因此，如果你搜索某个25岁且身高200厘米的人，你只需要定位到位于左下角象限中的记录所对应的文件。

Z阶排序可以重复多次，在一个象限内创建另外四个象限，用于进一步微调的簇。例如，如果左下角象限进一步Z阶排序，类似如下：

您可以随时按年龄和身高过滤，进行非常有效的文件调整。利用Z阶簇配置压缩作业，您只需这样运行压缩作业：

CALL catalog.system.rewrite_data_files(     table => 'db.people',       strategy => 'sort',       sort_order => 'zorder(height_in_cm, age)'
)

结论

在Apache Iceberg 上运行压缩作业可以帮助您提高它们的性能，但您必须考虑优化与需求的平衡。如果您运行频繁的压缩，需要快速完成，您最好避免排序，使用binpack策略。

不过，如果您希望更好地优化读取，使用排序可以最大限度地提高压缩的好处（当经常查询多个维度时，使用Z顺序）。Apache Iceberg为您提供了强大的压缩选项，以确保您的表性能在数据湖上迅速炽热。

END

最近文章