performance - 如何找到最佳的 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，输入:2619584 行(75.06MB)，扫描数据:355.04MB；每个任务:std.dev.: 77434.54，输出:18 行 (67.88kB)

之后:CPU:20.23s，输入:2619586 行(74.87MB)，扫描数据:631.62MB；每个任务:std.dev.: 193849.09，输出:18 行 (67.76kB)

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

Answer 1

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

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

Parquet and ORC file formats both support predicate pushdown (alsocalled predicate filtering). Both formats have blocks of data thatrepresent column values. Each block holds statistics for the block,such as max/min values. When a query is being run, these statisticsdetermine whether the block should be read or skipped depending on thefilter value used in the query. This helps reduce data scanned andimproves the query runtime. To use this capability, add more filtersin the query (for example, using a WHERE clause).

One way to optimize the number of blocks to be skipped is to identifyand sort by a commonly filtered column before writing your ORC orParquet files. This ensures that the range between the min and max ofvalues within the block are as small as possible within each block.This gives it a better chance to be pruned and also reduces datascanned further.

为了测试它，如果可能的话，我建议再做一个实验。更改 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。