retards énormes traduisant la DAG à des tâches

Question

ce sont mes pas:

1. Soumettre l'application étincelle à un cluster DME
2. Le pilote démarre et je peux voir le Spark-ui (aucune étape n'a encore été créé
3. Le pilote lit un fichier orc avec ~ 3000 parties de s3, effectue quelques transformations et le sauvegarde dans s3
4. L'exécution de la sauvegarde devrait créer quelques étapes dans le spark-ui mais les étapes prennent beaucoup de temps apparaître dans l'étincelle-ui
5. Les étapes apparaissent et commencent l'exécution

Pourquoi est-ce que j'obtiens ce délai énorme à l'étape 4? Pendant ce temps, le groupe attend apparemment quelque chose et l'utilisation du processeur est 0%

Merci

Answer 1

Malgré ses mérites S3 n'est pas un système de fichiers et il fait un choix suboptimale pour travailler avec des formats binaires complexes qui sont typiquement conçu avec le système de fichiers réel à l'esprit. Dans de nombreux cas, les tâches secondaires (comme les métadonnées de lecture) sont plus coûteuses que la récupération de données réelle.

Answer 2

C'est probablement le processus de validation entre 3 & 4; le Hadoop MR et les committers d'étincelles supposent que le renommage est une opération atomique O (1), et s'appuient dessus pour faire des commits atomiques de travail. Sur S3, renommer est O (données) et non-atomique lorsque plusieurs fichiers dans un répertoire sont impliqués. la charge de 0-CPU est le cadeau: le client attend une réponse de S3, qui effectue la COPY en interne à 6-10 MB/S

Il y a un travail en cours dans HADOOP-13345 pour faire un 0-rename commit en S3 . Pour l'instant, vous pouvez rechercher le Committer Direct de Databricks, célèbre mais échoué. Une autre chose: assurez-vous que vous utilisez "algorithme 2" pour la validation, car l'algorithme 1 fait beaucoup plus de renommage dans la validation finale du maître de travail. Mon paramètre complet recommandé pour ORC/Parquet perf sur Hadoop 2.7 est (avec l'utilisation s3a: urls):