How to optimize Spark for writing large amounts of data to S3
我在 EMR 上使用 Apache Spark 进行了大量 ETL。
我对获得良好性能所需的大部分调整都相当满意，但我有一项工作似乎无法弄清楚。
基本上，我使用了大约 1 TB 的 parquet 数据 – 分布在 S3 中的数万个文件中 – 并添加了几列并将其写出，并按数据的日期属性之一进行分区 – 再次，parquet 格式在 S3 中。
我是这样跑的：
|
1
|
spark-submit –conf spark.dynamicAllocation.enabled=true –num-executors 1149 –conf spark.driver.memoryOverhead=5120 –conf spark.executor.memoryOverhead=5120 –conf spark.driver.maxResultSize=2g –conf spark.sql.shuffle.partitions=1600 –conf spark.default.parallelism=1600 –executor-memory 19G –driver-memory 19G –executor-cores 3 –driver-cores 3 —class com.my.class path.to.jar <program args>
|
集群的大小是根据输入数据集的大小动态确定的，num-executors、spark.sql.shuffle.partitions和spark.default.parallelism参数是根据输入数据集的大小来计算的集群。
代码大致是这样的：
|
1
2 3 4 5 6 7 8 9 |
va df = (read from s3 and add a few columns like timestamp and source file name)
val dfPartitioned = df.coalesce(numPartitions) val sqlDFProdDedup = spark.sql(s“”” (query to dedup against prod data”“”); sqlDFProdDedup.repartition($“partition_column”) |
当我查看神经节图时，我得到一个巨大的资源峰值，而重复数据删除逻辑运行和一些数据洗牌，但数据的实际写入只使用了一小部分资源并运行了几个小时.
我不认为主要问题是分区倾斜，因为数据应该公平地分布在所有分区中。
分区列本质上是一个月中的一天，因此每个作业通常只有 5-20 个分区，具体取决于输入数据集的跨度。每个分区通常在 10-20 个 parquet 文件中包含大约 100 GB 的数据。
我正在设置 spark.sql.files.maxRecordsPerFile 来管理这些输出文件的大小。
所以，我最大的问题是：如何提高这里的性能？
简单地添加资源似乎没有多大帮助。
我已经尝试让执行器更大(以减少洗牌)并增加每个执行器的 CPU 数量，但这似乎并不重要。
提前致谢！
- 一个后续说明：有问题的表有大约 80 行。其中 2 行是大字符串：一行大约 100 个字符，另一行大约 1000 个字符。根据经验，一旦采用(活泼的)镶木地板格式，如果没有这两列，数据大date小 1/3。不管那值多少钱…
Zack，我有一个类似的用例，每天要处理的文件要多”n”倍。我将假设您按原样使用上面的代码并尝试提高整体工作的性能。以下是我的一些观察：
不确定 coalesce(numPartitions) 数字实际上是什么以及为什么在重复数据删除过程之前使用它。您的 spark-submit 显示您正在创建 1600 个分区，这已经足够开始了。
如果您要在写入之前重新分区，那么上面的合并可能根本没有好处，因为重新分区会打乱数据。
由于您声称要编写 10-20 个 parquet 文件，这意味着您在工作的最后一部分中仅使用 10-20 个内核进行编写，这是其缓慢的主要原因。根据 100 GB 的估计，镶木地板文件的范围从大约 5GB 到 10 GB，这真的很大，我怀疑除非他们使用 EMR 或类似的设备(如果读取，执行程序内存很大整个文件或溢出到磁盘)，因为内存要求太高。我建议创建大约 1GB 的镶木地板文件以避免任何这些问题。
此外，如果您创建 1GB parquet 文件，您可能会将该过程加快 5 到 10 倍，因为您将使用更多的执行器/内核来并行编写它们。您实际上可以通过简单地使用默认分区编写数据帧来运行实验。
这让我明白了你真的不需要使用重新分区，因为你想 write.partitionBy(“partition_date”) 调用。您的 repartition() 调用实际上是强制数据帧最多只有 30-31 个分区，具体取决于该月的天数，这是驱动正在写入的文件数量的原因。 write.partitionBy(“partition_date”) 实际上是在 S3 分区中写入数据，如果您的数据帧有 90 个分区，它将写入速度快 3 倍(3 * 30)。 df.repartition() 迫使它放慢速度。您真的需要 5GB 或更大的文件吗？
另一个重点是 Spark 惰性求值有时过于聪明。在您的情况下，它很可能只使用基于 repartition(number) 的整个程序的执行程序数量。相反，您应该尝试 df.cache() -> df.count() and then df.write()。它的作用是强制 spark 使用所有可用的执行器核心。我假设您正在并行读取文件。在您当前的实现中，您可能使用 20-30 个内核。需要注意的是，当您使用 r4/r5 机器时，请随意将您的执行程序内存增加到 8 核的 48G。我发现 8 核比标准的 5 核推荐更快地完成我的任务。
另一个指针是尝试 ParallelGC 而不是 G1GC。对于像这样的用例，当您读取 1000 倍文件时，我注意到它的性能比 G1Gc 更好或不差。请试一试。
在我的工作负载中，我使用基于 coalesce(n) 的方法，其中 \\’n\\’ 给了我一个 1GB 的 parquet 文件。我使用集群上所有可用的内核并行读取文件。仅在写入部分，我的内核处于空闲状态，但您无法避免这种情况。
我不确定 spark.sql.files.maxRecordsPerFile 如何与 coalesce() or repartition() 结合使用，但我发现 1GB 似乎可以用于 pandas、Redshift 频谱、Athena 等。
希望对您有所帮助。
查鲁
这里有一些优化以加快运行速度。
(1) 文件提交者 – 这是 Spark 将部分文件读取到 S3 存储桶的方式。每个操作都是不同的，并且将基于
|
1
|
spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version 2
|
说明
这会将文件直接写入零件文件，或者最初将它们加载到临时文件并将它们复制到它们的最终状态零件文件中。
(2) 对于文件大小，您可以根据每条记录的平均字节数得出它。下面我计算每条记录的字节数以计算 1024 MB 的记录数。我会先尝试每个分区 1024MB，然后向上移动。
|
1
2 3 4 5 6 |
(3) [我还没有尝试过] EMR Committer – 如果您使用的是 EMR 5.19 或更高版本，因为您正在输出 Parquet。您可以将 Parquet 优化编写器设置为 TRUE。
|
1
|
- 谢谢。我会试试这些！
- 您可以尝试在写入之前对数据帧进行持久化和运行计数，以减少固有的 Spark I/O 操作。您还在使用 s3a、s3n 或 s3 策略进行写作吗？
- 策略 (1) 仍然是重命名提交，因此 O(data) – 并且具有错误的失败语义；如果您使用的是 Hadoop-3.1 JAR，您可以切换到 S3A 提交程序(也需要调整 spark 的版本来支持它)
- 从我在 google 上看到的情况来看，使用在 EMR 上本地运行的 Spark 包不支持 S3A – 我必须使用(并支付)来自 DataBricks 的优化 Spark。这听起来正确吗？
- 仅作为更新：我尝试了此处建议的所有优化，但没有明显的改进
来源：https://www.codenong.com/59628550/
