1
votes

Pourquoi y a-t-il une masse de tâches pour charger un fichier CSV dans le compartiment S3?

J'ai un petit cluster autonome Spark avec une allocation de ressources dynamique qui utilise aws s3 comme stockage, puis je démarre un Spark SQL, crée une table externe Hive chargeant des données à partir d'un fichier csv de 779,3 Ko dans un compartiment s3, lorsque j'exécute un SQL "select count (1) from sales;", il y a exactement 798009 tâches dans le travail Spark SQL, tout comme une tâche par octet. Et "spark.default.parallelism" ne fonctionne pas. Y a-t-il des conseils?


0 commentaires

3 Réponses :


-1
votes

Essayez DF.repartition (1) avant d'exécuter la requête. Il doit y avoir trop de nombre de partitions lorsque vous exécutez cette commande.


0 commentaires

-1
votes

utilisez spark.sql.shuffle.partitions = 2


0 commentaires

3
votes

Si vous utilisez des fichiers JAR Hadoop 2.6, c'est un bogue dans cette version de s3a; si vous le voyez ailleurs, cela peut être un problème de configuration.

Votre fichier est divisé en une partition par octet parce que le système de fichiers dit "chaque partition fait un octet". Ce qui signifie que FileSystem.getBlockSize () renvoie la valeur "0" (cf. HADOOP-11584 : taille de bloc du fichier s3a définie sur 0 dans getFileStatus ).

Pour le connecteur s3a, assurez-vous que vous utilisez 2.7+, puis définissez fs.s3a.block.size sur quelque chose comme 33554432 (c'est-à-dire 32MB < / code>), à quel point votre fichier source ne sera pas du tout fractionné.

Si vous pouvez aller jusqu'à 2.8; nous avons beaucoup travaillé pour accélérer l'entrée et la sortie, en particulier avec le format de colonne IO et ses modèles de recherche.


0 commentaires