Bonjour,
En raison de l'absence de support OVH sur le service Data Processing du cloud public, je poste la description de mon problème ici, dans l'espoir que quelqu'un ayant rencontré le même problème ait trouvé une solution.
Je rencontre un problème avec le service Data Processing en Spark 2.4.3. J'ai une application Spark en Java qui importe des données de fichiers CSV pour les transformer en fichiers parquet stockés sur un object storage. J'utilise l'API S3 pour écrire les fichiers parquet sur l'object storage, comme décrit ici : https://docs.ovh.com/gb/en/data-processing/object-storage-java/
Dans certains cas, il manque des données dans les fichiers parquet à l'issue de l'import de ces données.
En investiguant, je me suis rendu compte qu'il manquait parfois 1 ou plusieurs fichiers parquet dans le répertoire cible à l'issue de l'import.
Exemple, pour l'un des fichiers CSV à importer, Spark crée 125 tâches lors de la génération des fichiers parquet, je devrais donc avoir autant de fichiers parquet que j'ai de tâches parallèles (avec un nom de fichier contenant l'indice de la tâche de 0 à 124), correspondant à la partition RDD associée à la tâche. Ici, il manque le fichier de la tâche 10:
13611878 2021-01-13 19:16:32 application/octet-stream importbda-staging/suivi_deploiement_variable/part-00008-caec139f-11c4-4746-bcc9-05f32d765622-c000.snappy.parquet
13773219 2021-01-13 19:16:35 application/octet-stream importbda-staging/suivi_deploiement_variable/part-00009-caec139f-11c4-4746-bcc9-05f32d765622-c000.snappy.parquet
13722628 2021-01-13 19:16:37 application/octet-stream importbda-staging/suivi_deploiement_variable/part-00011-caec139f-11c4-4746-bcc9-05f32d765622-c000.snappy.parquet
Il manque le fichier application/octet-stream importbda-staging/suivi_deploiement_variable/part-00010-caec139f-11c4-4746-bcc9-05f32d765622-c000.snappy.parquet
En listant les fichiers sur l'object storage pendant l'écriture des fichiers parquet, j'ai vu que le fichier généré par la tâche Spark d'indice 10 était resté dans un sous-répertoire _temporary sous le répertoire cible :
13695619 2021-01-13 19:14:00 application/octet-stream importbda-staging/suivi_deploiement_variable/_temporary/0/_temporary/attempt_20210113191334_0003_m_000010_137/part-00010-caec139f-11c4-4746-bcc9-05f32d765622-c000.snappy.parquet
Lorsque le traitement Spark s'est terminé, ce fichier avait disparu.
Ce problème ressemble à celui-ci : https://stackoverflow.com/questions/54082435/writing-many-files-to-parquet-from-spark-missing-some-parquet-files
Accessoirement, je constate que la phase de commit Spark (qui consiste à déplacer les fichiers générés dans le sous-répertoire _temporary vers le répertoire cible) peut être très lente, avec un temps qui peut aller de plusieurs minutes à plusieurs heures, et qui semble être lié au nombre de fichiers déplacés et qui n'est pas du tout corrélé à une activité CPU côté Spark (rien de flagrant côté Grafana, où il semble ne rien se passer sur le cluster Spark). Exemple, pour les 125 fichiers parquets générés et un volume total de 1.2Go, cette phase de commit dure 5mn (soit 4Mo/s). Ce problème de performance n'est pas forcément bloquant, mais peut-être est-ce lié à la perte de fichiers.
Je souhaite savoir comment résoudre ou contourner ce problème qui est totalement bloquant pour notre projet.
Notamment :
- y a-t-il une configuration Spark qui permettrait de contourner le bug ?
- si le problème vient d'un bug dans la version hadoop-aws, comment peut-on upgrader la version d'hadoop-aws (j'utilise la version 2.8.5 comme indiqué dans votre documentation) ?
- est-ce que vous avez un exemple de pom.xml compatible avec Spark 3.0.1 qui est maintenant disponible sur le service Data Processing ?
- y a-t-il une alternative à l'API S3 pour écrire sur un object storage OVH ?
Pascal Roche
