L'abus de Lexpage peut entraîner un épanouissement grave !    —  Sqweez

Discussions

Hadoop, Spark, Storm, Kafka, Akka, Mesos, Yarn, Hive, ...

yaug 1472 Spammeur
Reprise automatique du message précédent.
Désolé de recentrer le débat sur des trucs moins funcky que le rubiks cube, mais le sujet de base m'intéresse plus.
Devant gérer quelques serveurs costauds, je vais me pencher sur les diverses solutions techniques évoquées dans le titre, histoire de voir si ça me solutionnera quelques problématiques reloues.
A part kafka que je connais déjà (mais on a déjà rabbitmq à la place), les autres ne sont pour le moment que des noms pour moi... va falloir que je creuse :D
Guybrush 8433 Bob
J'avoue ne pas avoir vraiment avancé dans mes essais. J'ai pas mal joué avec Ansible pour essayer de me faciliter la vie si je dois reproduire les installations/configurations ultérieurement, mais il me faudrait déjà bien trop de temps pour maitriser Ansible au point de pouvoir réellement bénéficier de ses avantages, sans compte le temps qu'il me faudrait pour me focaliser juste sur la partie Hadoop/Spark.

En parallèle, je m'intéresse de plus en plus aux réseaux récurrents de neurones (RNN) et voir comment intégrer ça dans mon workflow habituel de machine learning (basé surtout sur Sklearn). Evidemment, se pencher sur les RNN est aussi un gros morceau, dans lequel le parallélisme intervient également mais plutôt au niveau local (ou sur GPU), ce qui fait que je me suis ensuite penché sur des trucs comme TensorFlow ou Theano (qui, fort heureusement, sont les deux backends qu'on peut utiliser avec Keras, une librairie Python pour construire "facilement" un RNN, et qui s'intègre pas trop mal avec Sklearn justement).

Vu que je serai le principal utilisateur de mon cluster de calcul, et que je travaille essentiellement en Python, je pense plutôt m'orienter vers une approche basée sur ipyparallel ou dask plutôt que Spark/Hadoop, notamment parce que la stack complète est déjà large (cuda pour Theano, Theano pour Keras, hdf5 pour Keras, Sklearn en surface, ipyparallel/dask dans le coin et Ansible pour supporter le tout). Si j'y ajoute Hadoop/HFS et Spark, je ne fais qu'ajouter une couche de complexité qui ne m'apporte rien (à part l'expérience de déployer une telle solution, ce qui compte, mais le temps ne me permet pas de tout faire, malheureusement).

Notamment, vu que le use case principal est de faire de l'exploration dans un cadre scientifique, j'ai besoin d'une grande souplesse au niveau du cluster (donc typiquement, j'oublie des solutions comme Celery, etc. qui nécessitent de déployer localement le code source) et je m'oriente plutôt sur un support pour les problèmes de type "embarrassingly parallel" ou les données sont plutôt centralisées et distribuées, plutôt que l'inverse (autrement dit, plutôt que ce qu'on va typiquement supporter via Hadoop/Spark).

Par ailleurs, les stacks usuelles en Python sont de mieux en mieux intégrées pour gérer ça. Par exemple, Sklearn repose sur Joblib pour gérer le parallélisme. Joblib étant une librairie assez sympa (que j'ai découverte par hasard et indépendamment il y a quelques temps) proposant une multitude de backend sympathiques pour gérer le parallélisme et, fort heureusement pour moi, notamment ipyparallel et dask, ce qui veut dire que l'effort pour faire du machine learning (sauf RNN pour l'instant) de façon parallèle est pratiquement nul. Pour la partie RNN, j'ai bon espoir que des solutions permettant de faire tourner Theano (et/ou TensorFlow) avec joblib apparaissent rapidement.


Ce message a été modifié 2 fois. Dernière modification : 27 février 2017 à 11:55 par Guybrush.

Répondre

Vous devez être inscrit et identifié.