提高 Gzipped 文本文件的 Spark 读取和 Parquet 转换性能答案

【问题标题】：Increasing Spark Read and Parquet Conversion Performance for Gzipped Text File提高 Gzipped 文本文件的 Spark 读取和 Parquet 转换性能
【发布时间】：2018-02-04 14:40:03
【问题描述】：

用例： A> 在 AWS s3 位置有文本 Gzipped 文件 B> 在文件顶部创建 Hive 表，以表形式访问文件中的数据 C> 使用 Spark Dataframe 读取表格并通过 Snappy 压缩转换为 Parquet 数据 D>表中的字段数为25，其中包括2个分区列。数据类型是字符串，除了两个数据类型为小数的字段。

使用以下 Spark 选项：--executor-memory 37G --executor-cores 5 --num-executors 20

集群大小 - 10 个 r3.8xLarge 类型的数据节点

发现 AWS EMR 中使用的 vCore 数量始终等于文件数量，可能是因为 gzip 文件不可拆分。 Gzipped 文件来自不同的系统，文件大小约为 8 GB。

6 个文件的 Parquet 转换总时间超过 2 小时，总大小为 29.8GB。

有没有办法通过 Spark 提高性能，使用 2.0.2 版本？

代码片段：

val srcDF = spark.sql(stgQuery) srcDF.write.partitionBy("data_date","batch_number").options(Map("compression"->"snappy","spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version"->"2","spark.推测"->"false")).mode(SaveMode.Overwrite).parquet(finalPath)

【问题讨论】：

标签： apache-spark-sql

【解决方案1】：

无论您要求多少个节点，或者有多少个内核，如果您有 6 个文件，将分配六个线程来处理它们。尝试做一个

以可拆分的格式保存 (snappy)
获取保存数据的来源是许多较小的文件
随着您的进行，将一些增量转换为新格式（例如，单个 spark-streaming 核心轮询新 gzip 文件，然后在其他地方保存到 snappy 文件中。也许尝试使用 AWS-Lambda 作为触发器来保存将单个虚拟机专用于该任务。

【讨论】：

感谢史蒂夫，我们正在使用 Snappy 压缩转换为 Parquet。但是转换过程本身需要将近 2.5 小时，我试图找到一种加快速度的方法，因为 Source 不会很快改变。
我真的很惊讶它花了这么长时间。将单个文件 D/L 到您的桌面，在那里进行操作，将其用作参考“应该花费的时间”值。尝试不同阶段：CSV.gz -> CSV.snappy，然后执行 CSV.snappy -> Parquet.snappy 作为更并行的操作