J'ai vu un certain nombre de questions décrivant des problèmes lors de l'utilisation de S3 dans Spark :
- Les jobs Spark se terminent mais l'application met du temps à se fermer
- spark-1.4.1 saveAsTextFile to S3 est très lent sur emr-4.0.0
- L'écriture des points de contrôle Spark sur S3 est trop lente
plusieurs décrivant spécifiquement des problèmes liés aux fichiers Parquet :
- SaveAsParquetFile lent ou incomplet de EMR Spark vers S3
- Est-ce que Spark supporte l'élagage des partitions avec les fichiers Parquet ?
- Est-ce que Parquet predicate pushdown fonctionne sur S3 en utilisant Spark non EMR ?
- Délais importants pour traduire le DAG en tâches
- Comptage rapide des lignes Parquet dans Spark
ainsi que des sources externes faisant référence à d'autres problèmes liés aux combinaisons Spark - S3 - Parquet. Cela me fait penser que S3 avec Spark ou cette combinaison complète n'est peut-être pas le meilleur choix.
Suis-je sur la bonne voie ? Quelqu'un peut-il fournir une réponse officielle expliquant ce qu'il en est ?
- État actuel du support Parquet avec un focus sur S3.
- Est-ce que Spark (SQL) peut profiter pleinement des fonctionnalités de Parquet telles que l'élagage des partitions, le pushdown des prédicats (y compris les schémas profondément imbriqués) et les métadonnées Parquet ? Toutes ces fonctionnalités fonctionnent-elles comme prévu sur S3 (ou sur des solutions de stockage compatibles) ?
- Développements en cours et tickets JIRA ouverts.
- Existe-t-il des options de configuration dont il faut tenir compte lors de l'utilisation conjointe de ces trois éléments ?
