2016-03-29 5 views

Répondre

9

KryoKryo n'a pas d'impact majeur sur PySpark car il stocke simplement des données sous forme d'objets byte[], qui sont rapides à sérialiser même avec Java.

Mais cela vaut la peine d'essayer - il vous suffit de définir la configuration spark.serializer et de ne pas enregistrer de classe. Ce qui pourrait avoir plus d'impact est de stocker vos données sous MEMORY_ONLY_SER et d'activer spark.rdd.compress, ce qui les compressera.

Dans Java cela peut ajouter un peu au-dessus du processeur, mais Python fonctionne tout à fait un peu plus lent, il pourrait ne pas d'importance. Cela pourrait aussi accélérer le calcul en réduisant le nombre de GC ou en vous laissant mettre en cache plus de données.

Référence: Matei Zaharia's answer dans la liste de diffusion.

+0

Wow, une réponse détaillée si vite! Merci. Est-ce que la partie de "Que pourrait faire ..." se référant au sérialiseur, ou une suggestion indépendante pour l'optimisation? – Gerenuk

+0

c'est plus une suggestion d'optimisation puisque le Kryo n'aura pas d'impact sur PySpark. Je suggère de le tester en premier. Je n'utilise pas PySpark de manière excessive pour le tester et les performances peuvent dépendre de beaucoup de choses: configuration, cas d'utilisation, réseau, etc. – eliasah

4

Tout dépend de ce que vous voulez dire quand vous dites PySpark. Au cours des deux dernières années, le développement de PySpark, identique au développement Spark en général, est passé de l'API RDD de bas niveau à des API de haut niveau telles que DataFrame ou ML.

Ces API sont implémentées en mode natif sur JVM et le code Python est principalement limité à une série d'appels RPC exécutés sur le pilote. Tout le reste est à peu près le même que celui exécuté avec Scala ou Java, il devrait donc bénéficier de Kryo de la même manière que les applications natives.

Je dirais qu'à la fin de la journée, il n'y a pas grand chose à perdre lorsque vous utilisez Kryo avec PySpark et potentiellement quelque chose à gagner lorsque votre application dépend fortement des API «natives».