J'ai Spark 2.4.0 et Hadoop 3.1.1. Selon Documentation Hadoop, pour utiliser le nouveau committer Magic qui permet l'écriture cohérente des fichiers parquet sur S3, j'ai configuré ces valeurs dans conf/spark-default.conf:

spark.sql.sources.commitProtocolClass       com.hortonworks.spark.cloud.commit.PathOutputCommitProtocol
spark.sql.parquet.output.committer.class    org.apache.hadoop.mapreduce.lib.output.BindingPathOutputCommitter
spark.hadoop.mapreduce.outputcommitter.factory.scheme.s3a    org.apache.hadoop.fs.s3a.commit.S3ACommitterFactory
spark.hadoop.fs.s3a.committer.name          magic
spark.hadoop.fs.s3a.committer.magic.enabled true

En utilisant cette configuration, je me retrouve avec l'exception:

java.lang.ClassNotFoundException: com.hortonworks.spark.cloud.commit.PathOutputCommitProtocol

Ma question est double, est-ce que je comprends bien que Hadoop 3.1.1 autorise systématiquement l'écriture d'un fichier parquet sur S3?
Deuxièmement, si j'ai bien compris, comment utiliser correctement le nouveau committer de Spark?

2
Kiwy 20 nov. 2018 à 11:32

3 réponses

Meilleure réponse

Modifier:
OK, j'ai deux instances du serveur un étant un peu vieux maintenant, j'ai essayé d'utiliser la dernière version de minio avec ces paramètres:

sc.hadoopConfiguration.set("hadoop.fs.s3a.path.style.access","true")
sc.hadoopConfiguration.set("hadoop.fs.s3a.fast.upload","true")
sc.hadoopConfiguration.set("hadoop.fs.s3a.fast.upload.buffer","bytebuffer")
sc.hadoopConfiguration.set("fs.s3a.path.style.access","true")
sc.hadoopConfiguration.set("fs.s3a.multipart.size","128M")
sc.hadoopConfiguration.set("fs.s3a.fast.upload.active.blocks","4")
sc.hadoopConfiguration.set("fs.s3a.committer.name","partitioned")

Je suis capable d'écrire jusqu'à présent sans problème.
Cependant mon serveur swift qui est un peu plus ancien avec cette config:

sc.hadoopConfiguration.set("fs.s3a.signing-algorithm","S3SignerType")

Semble ne pas soutenir correctement le partionner.

Concernant "Hadoop S3guard":
Ce n'est pas possible actuellement, Hadoop S3guard qui conserve les métadonnées des fichiers S3 doit être activé dans Hadoop. Le S3guard s'appuie cependant sur DynamoDB, un service Amazon propriétaire.
Il n'y a pas d'alternative maintenant comme un fichier sqlite ou un autre système de base de données pour stocker les métadonnées.
Donc, si vous utilisez S3 avec minio ou toute autre implémentation S3, il vous manque DynamoDB.
Cet article explique joliment comment fonctionne S3guard

1
Kiwy 30 nov. 2018 à 08:12

Kiwy: c'est mon code: je peux vous aider. Certaines des classes ne sont pas entrées dans les versions Spark ASF, mais vous les trouverez dans les JAR Hadoop, et je pourrais essayer de créer la version ASF avec les dépendances pertinentes dans (je pourrais les mettre en aval; elles était là)

Vous n'avez pas besoin d'activer S3Guard pour utiliser le "committer de mise en scène"; c'est seulement la variante "magique" qui a besoin de listes de magasin d'objets cohérentes pendant la phase de validation.

1
Steve Loughran 20 nov. 2018 à 15:00

Toute la nouvelle documentation de configuration des committers que j'ai lue à jour, manque un fait fondamental:

Spark 2.x.x n'a pas besoin de classes de support pour faire fonctionner de nouveaux committers S3a.

Ils promettent que ces bibliothèques intégration cloud seront regroupées avec spark 3.0.0, mais pour l'instant, vous devez ajouter vous-même des bibliothèques.

Sous l 'intégration cloud maven repos, il existe plusieurs distributions soutenant les committers, j'ai trouvé un fonctionnant avec l'annuaire committer mais pas la magie.

En général, le committer d'annuaire est recommandé par rapport à la magie car il a été bien testé et essayé. Il nécessite un système de fichiers partagé (magic committer n'en a pas besoin, mais nécessite s3guard) tel que HDFS ou NFS (nous utilisons AWS EFS) pour coordonner les écritures de Spark Worker sur S3.

0
dovka 30 janv. 2020 à 09:22