如何找到最佳的 Spark-athena 文件大小

Question

我有一个写入 s3 存储桶的 spark 作业，并在此位置顶部有一个 athena 表。 该表已分区。 Spark 正在为每个分区写入 1GB 单个文件。我们试验了 maxRecordsPerFile 选项，因此每个文件只写入 500MB 数据。在上面的例子中，我们最终得到了 2 个文件，每个文件都带有 500MB 这在 EMR 上节省了 15 分钟的运行时间 但是，雅典娜出了问题。 Athena 查询 CPU 时间开始随着新的文件大小限制而变得更糟。 我尝试在执行前后将相同的数据与相同的查询进行比较，这是我发现的：

分区列 = source_system, execution_date, year_month_day

我们试过的查询：

select *
from dw.table
where source_system = 'SS1'
and year_month_day = '2022-09-14'
and product_vendor = 'PV1'
and execution_date = '2022-09-14'
and product_vendor_commission_amount is null
and order_confirmed_date is not null
and filter = 1
order by product_id 
limit 100;

执行时间处理时间： 之前：6.79s 之后：11.102s

Explain analyze 表明新结构必须扫描更多数据。 之前：CPU: 13.38s, Input: 2619584 rows (75.06MB), Data Scanned: 355.04MB; per task: std.dev.: 77434.54, Output: 18 rows (67.88kB)

之后：CPU: 20.23s, Input: 2619586 rows (74.87MB), Data Scanned: 631.62MB; per task: std.dev.: 193849.09, Output: 18 rows (67.76kB)

你能指导我为什么这需要两倍的时间吗？需要注意什么？文件大小是否有最适合 spark 和 athena 组合的最佳点？

Answer 1

一种假设是下推过滤器对单文件策略更有效。

来自 AWS 大数据博客帖子标题Top 10 Performance Tuning Tips for Amazon Athena：

Parquet 和 ORC 文件格式都支持谓词下推（也 称为谓词过滤）。两种格式都有数据块 表示列值。每个区块都保存着该区块的统计信息， 例如最大/最小值。运行查询时，这些统计信息 确定块是否应该被读取或跳过取决于 查询中使用的过滤器值。这有助于减少扫描的数据和 改进查询运行时。要使用此功能，请添加更多过滤器 在查询中（例如，使用 WHERE 子句）。

优化要跳过的块数的一种方法是识别 并在编写您的 ORC 或之前按常用过滤列排序 镶木地板文件。这确保了最小值和最大值之间的范围 块内的值在每个块内尽可能小。 这使它有更好的机会被修剪并减少数据 进一步扫描。

为了测试它，我建议如果可能的话再做一个实验。更改 spark 作业并对数据进行排序，然后再将其持久化到两个文件中。使用以下顺序： source_system、execution_date、year_month_day、product_vendor、product_vendor_commission_amount、order_confirmed_date、filter和product_id。然后检查查询统计信息。

至少数据集会针对呈现的用例进行优化。否则，根据最繁重的查询更改它。

该帖子也讨论了最佳文件大小，它给出了一般的经验法则。根据我的经验，Spark 适用于 128MB 到 2GB 之间的大小。它也适用于其他查询引擎，例如 Athena 使用的 Presto。

Answer 2

你能找到解决方案吗？我的建议是将 year_month_day/execution date（主要用于查询）拆分为 Year、Month 和 Day 分区，这将减少数据扫描量和高效过滤。