使用案例：A>在AWS s3位置B中创建文本Gzip文件>在文件顶部创建Hive表，从表C中访问文件中的数据>使用Spark Dataframe读取表并使用Snappy压缩转换为Parquet数据D>表中的字段数为25，其中包括2个分区列 . 数据类型是字符串，但两个字段除外，其中Decimal作为数据类型 .
使用以下Spark选项： - executor-memory 37G --executor-cores 5 --num-executors 20
簇大小 - 类型为r3.8xLarge的10个数据节点
发现AWS EMR中使用的vCore数量始终等于文件数量，可能是因为gzip文件不可拆分 . Gzip文件来自不同的系统，文件大小约为8 GB .
Parquet转换所花费的总时间超过2小时，共有6个文件，总大小为29.8GB .
有没有办法使用版本2.0.2通过Spark提高性能？
代码片段：
val srcDF = spark.sql（stgQuery）srcDF.write.partitionBy（“data_date”，“batch_number”） . options（Map（“compression” - >“snappy”，“spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version”） - > “2”， “spark.speculation” - > “假”））模式（SaveMode.Overwrite）.parquet（finalPath）
1 回答
无论您要求多少个节点，或者有多少个核心，如果您有6个文件，将分配六个线程来处理它们 . 尝试做其中一个
以可拆分格式保存（snappy）
获取保存数据的源是很多较小的文件
在你进行时进行一些新格式的增量转换（例如，对新的gzip文件进行单一的火花流式核心轮询，然后将其他地方保存到snappy文件中 . 也许尝试使用AWS-Lambda作为触发器，以节省专用的单个VM到任务 .