A un demi-siècle près, Turing aurait lui-même inventé Lexpage !
—
Guybrush
Discussions
Hadoop, Spark, Storm, Kafka, Akka, Mesos, Yarn, Hive, ...
Amis geeks, bonjour !
J'ai à ma disposition, au boulot, plusieurs serveurs relativement puissants qu'on utilise actuellement "individuellement" pour faire nos analyses et calculs (on parle d'un bon facteur 100 à 1000 par rapport à un laptop en terme de vitesse, et 32go de RAM pour faire tenir nos dataframes en mémoire). Le truc, c'est que je trouve ça con qu'on soit 3-4 personnes à utiliser sporadiquement l'un ou l'autre de ces serveurs pour travailler, et donc qu'ils soient idle 90% du temps, même quand on fait nos calculs dessus.
Vu que j'ai obtenu un nouveau financement (merci l'Europe, j'peux nourrir ma famille pendant 2 ans encore
), et que ce financement concerne des problématiques de data quality et de big data (ce qui veut à la fois tout dire et rien dire, pratique), je compte consacrer un peu de mon temps à découvrir et manipuler ces fameux outils de "big data".
Alors, le hic, c'est qu'on trouve de tout. Et surtout en grande quantité. A la base, je pars d'Hadoop (à peu près le seul que je connaissais vaguement). Puis, on découvre qu'y a Spark qui existe, puis Storm, puis on te parle de SMACK (Spark, Mesos, Akka, Cassandra, Kafka) et après avoir passé du temps à Googler tout ça, on te parle de Hive, de Storm+Yarn, ce dernier visant à "remplacer" (??) Mesos, etc. etc. etc.
Bref, c'est la jungle, et j'ai bien du mal à y voir clair, alors je fais appels aux plus geeks des Lexpagiens qui ont eu l'occasion d'en apprendre un peu sur le sujet, et voir dans quelle mesure vous pouvez partager votre expérience ici
J'ai à ma disposition, au boulot, plusieurs serveurs relativement puissants qu'on utilise actuellement "individuellement" pour faire nos analyses et calculs (on parle d'un bon facteur 100 à 1000 par rapport à un laptop en terme de vitesse, et 32go de RAM pour faire tenir nos dataframes en mémoire). Le truc, c'est que je trouve ça con qu'on soit 3-4 personnes à utiliser sporadiquement l'un ou l'autre de ces serveurs pour travailler, et donc qu'ils soient idle 90% du temps, même quand on fait nos calculs dessus.
Vu que j'ai obtenu un nouveau financement (merci l'Europe, j'peux nourrir ma famille pendant 2 ans encore
), et que ce financement concerne des problématiques de data quality et de big data (ce qui veut à la fois tout dire et rien dire, pratique), je compte consacrer un peu de mon temps à découvrir et manipuler ces fameux outils de "big data". Alors, le hic, c'est qu'on trouve de tout. Et surtout en grande quantité. A la base, je pars d'Hadoop (à peu près le seul que je connaissais vaguement). Puis, on découvre qu'y a Spark qui existe, puis Storm, puis on te parle de SMACK (Spark, Mesos, Akka, Cassandra, Kafka) et après avoir passé du temps à Googler tout ça, on te parle de Hive, de Storm+Yarn, ce dernier visant à "remplacer" (??) Mesos, etc. etc. etc.
Bref, c'est la jungle, et j'ai bien du mal à y voir clair, alors je fais appels aux plus geeks des Lexpagiens qui ont eu l'occasion d'en apprendre un peu sur le sujet, et voir dans quelle mesure vous pouvez partager votre expérience ici
Je vais pas t'aider beaucoup (ha le spoil !) mais...
Il y a moyen de faire les paroles d'une nouvelle bande son pour Civ6 avec ton titre de topic !
Il y a moyen de faire les paroles d'une nouvelle bande son pour Civ6 avec ton titre de topic !
Tu seras fouettée sur la place publique, cul nu à la Sysson, lors de la prochaine IRL pour avoir osé sous-entendre que Baba Yatu ressemblait au titre de ce topic !
Comme tu l'as dit c'est la jungle mais surtout parce que chaque outil est sur son propre créneau.
Perso il y en a certain que je connais un peu, d'autres que je connais de nom et de concept et d'autres pas du tout.
Ce serait plus simple si tu avais un use case parce que effectivement avec tout ce que tu as cité, on peut construire absolument tout et n'importe quoi
Perso il y en a certain que je connais un peu, d'autres que je connais de nom et de concept et d'autres pas du tout.
Ce serait plus simple si tu avais un use case parce que effectivement avec tout ce que tu as cité, on peut construire absolument tout et n'importe quoi
Guybrushdata quality et de big dataEt le machine learning alors ?
Ce message a été modifié 1 fois.
Dernière modification : 2 février 2017
à 14:21 par
Fabe.
Machine learning, c'est dépassé comme buzz word, maintenant on se focalise sur du "deep learning", parce qu'on peut déduire l'univers en cliquant sur le bouton "deep learning", si si ! Sur l'échelle du bullshit, c'est en bonne position à coté de "big data"
Sinon, le use-case me concernant est simple : j'utilise Python 90% du temps, et je lance mes calculs typiquement en multiprocessing ou dans un cluster Jupyter (grosso-modo, la même interface que du multiprocessing), c'est à dire un bête "map" parallélisé sur une donnée distribuée à la volée. 50% du temps, j'ai peu de données mais des calculs lourds, et 50% du temps, j'ai beaucoup de données mais des calculs relativement légers.
Si je me contente de Python, il y a plein de solutions (des petites à la joblib, MrJob over Hadoop, ou encore Celery (j'aime bien !) ou IPythoncluster), mais ça se limite à du Python, et mes collègues risquent de râler si je leur impose ça Donc l'idée, c'est de partir vers Hadoop/Spark pour aller vers quelque chose de moins "orienté Python" (et Spark supporte Python notamment, et ce sera pour moi l'occasion de faire aussi un peu de Scala). Le souci, c'est que je nage en plein océan d'ignorance dans ce domaine
Au niveau architecture, je dispose de plusieurs machines qui vont servir à tout ce bouzin :
- Mon laptop, forcément, depuis lequel j'aimerai soumettre les batchs, mais qui ne va pas servir aux calculs.
- Deux hexacoeurs avec 32go de RAM, un SSD de 256go et un HD de 2To.
- Deux machines virtuelles (Debian 7 sur openVZ) avec 4 coeurs virtuels, 4go de RAM et 5go de HD (pas besoin de davantage), sur un même serveur (physiquement différent des deux hexacoeurs ci-dessus, mais du même acabit). L'idée de ces deux machines, c'est simplement d'avoir des noeuds "en plus", même si je sais que je ne gagne rien à utiliser 2 machines de 4 coeurs plutôt qu'une de 8 coeurs :)
Les serveurs physiques, réels, s'appellent ecos0 et ecos2 (j'ai du laisser ecos1 à mes collègues), et les serveurs virtuels s'appellent vecos0 et vecos1. C'est pour pouvoir les nommer plus facilement dans ce qui suit.
A priori, je comptais partir sur le déploiement d'un HDFS sur ecos0 et ecos2, qui ont de l'espace de stockage en suffisance, et je comptais déployer Spark sur ecos0, ecos2, vecos0 et vecos1. En parallèle, j'aurai bien aimé mettre Cassandra dans le tas également (mais je ne sais pas encore si je me limite à ecos0 et 2, ou si je prends les vecos* en plus, vu la faible quantité d'espace disponible, pas sûr que ça soit utile). Ma crainte est la suivante (et peut-être infondée) : est-ce que le fait que l'HDFS/Cassandra ne soit pas sur les vecos* représente un souci lorsque je vais balancer des calculs avec Spark ? Je lis qu'en général, avec Hadoop, c'est simple : les calculs se font là où sont les données. Est-ce le cas avec Spark également ? Est-ce qu'il est possible d'utiliser des machines uniquement pour la puissance de calcul, et d'autres machines uniquement pour le stockage des données ? Vu que Spark travaille en mémoire, je suppose que ce n'est pas un souci, mais je n'en suis pas sûr...
Autre chose : est-ce que Spark gère automatiquement le balancing entre les machines en fonction de l'usage "global" de ces machines ? Je veux dire : il est probable que des collègues utilisent Hadoop, donc uniquement ecos0 et ecos2. Si je lance un batch Spark (qui utilise normalement les 4 machines), est-ce qu'il va (ou peut ?) automatiquement privilégier vecos0 et vecos1 s'il voit qu'ecos0 et ecos2 sont occupés à faire autre chose ?
J'ai cru comprendre (mais je me trompe peut-être) que c'est typiquement le job de Yarn/Mesos de s'occuper de ce genre de choses, et dans ce cas, je suppose qu'on "monte" Hadoop et Spark au dessus de Mesos ?
Sur l'échelle du bullshit, c'est en bonne position à coté de "big data" Sinon, le use-case me concernant est simple : j'utilise Python 90% du temps, et je lance mes calculs typiquement en multiprocessing ou dans un cluster Jupyter (grosso-modo, la même interface que du multiprocessing), c'est à dire un bête "map" parallélisé sur une donnée distribuée à la volée. 50% du temps, j'ai peu de données mais des calculs lourds, et 50% du temps, j'ai beaucoup de données mais des calculs relativement légers.
Si je me contente de Python, il y a plein de solutions (des petites à la joblib, MrJob over Hadoop, ou encore Celery (j'aime bien !) ou IPythoncluster), mais ça se limite à du Python, et mes collègues risquent de râler si je leur impose ça
Donc l'idée, c'est de partir vers Hadoop/Spark pour aller vers quelque chose de moins "orienté Python" (et Spark supporte Python notamment, et ce sera pour moi l'occasion de faire aussi un peu de Scala). Le souci, c'est que je nage en plein océan d'ignorance dans ce domaine Au niveau architecture, je dispose de plusieurs machines qui vont servir à tout ce bouzin :
- Mon laptop, forcément, depuis lequel j'aimerai soumettre les batchs, mais qui ne va pas servir aux calculs.
- Deux hexacoeurs avec 32go de RAM, un SSD de 256go et un HD de 2To.
- Deux machines virtuelles (Debian 7 sur openVZ) avec 4 coeurs virtuels, 4go de RAM et 5go de HD (pas besoin de davantage), sur un même serveur (physiquement différent des deux hexacoeurs ci-dessus, mais du même acabit). L'idée de ces deux machines, c'est simplement d'avoir des noeuds "en plus", même si je sais que je ne gagne rien à utiliser 2 machines de 4 coeurs plutôt qu'une de 8 coeurs :)
Les serveurs physiques, réels, s'appellent ecos0 et ecos2 (j'ai du laisser ecos1 à mes collègues
), et les serveurs virtuels s'appellent vecos0 et vecos1. C'est pour pouvoir les nommer plus facilement dans ce qui suit. A priori, je comptais partir sur le déploiement d'un HDFS sur ecos0 et ecos2, qui ont de l'espace de stockage en suffisance, et je comptais déployer Spark sur ecos0, ecos2, vecos0 et vecos1. En parallèle, j'aurai bien aimé mettre Cassandra dans le tas également (mais je ne sais pas encore si je me limite à ecos0 et 2, ou si je prends les vecos* en plus, vu la faible quantité d'espace disponible, pas sûr que ça soit utile). Ma crainte est la suivante (et peut-être infondée) : est-ce que le fait que l'HDFS/Cassandra ne soit pas sur les vecos* représente un souci lorsque je vais balancer des calculs avec Spark ? Je lis qu'en général, avec Hadoop, c'est simple : les calculs se font là où sont les données. Est-ce le cas avec Spark également ? Est-ce qu'il est possible d'utiliser des machines uniquement pour la puissance de calcul, et d'autres machines uniquement pour le stockage des données ? Vu que Spark travaille en mémoire, je suppose que ce n'est pas un souci, mais je n'en suis pas sûr...
Autre chose : est-ce que Spark gère automatiquement le balancing entre les machines en fonction de l'usage "global" de ces machines ? Je veux dire : il est probable que des collègues utilisent Hadoop, donc uniquement ecos0 et ecos2. Si je lance un batch Spark (qui utilise normalement les 4 machines), est-ce qu'il va (ou peut ?) automatiquement privilégier vecos0 et vecos1 s'il voit qu'ecos0 et ecos2 sont occupés à faire autre chose ?
J'ai cru comprendre (mais je me trompe peut-être) que c'est typiquement le job de Yarn/Mesos de s'occuper de ce genre de choses, et dans ce cas, je suppose qu'on "monte" Hadoop et Spark au dessus de Mesos ?
Ca doit être faisable
Bon, sinon, première chose : je vais devoir virer Debian parce qu'Hadoop et Debian (7 au moins), ça ne fait pas bon ménage visiblement. Je vais donc mettre une CentOS sur ecos2 (actuellement, c'est une Ubuntu) pour que ça colle avec ce que j'ai sur ecos0, et je vais devoir passer à KVM pour les deux machines virtuelles, parce qu'il m'est impossible d'avoir autre chose que Debian 7 sous OpenVZ... Shit.
Bon, sinon, première chose : je vais devoir virer Debian parce qu'Hadoop et Debian (7 au moins), ça ne fait pas bon ménage visiblement. Je vais donc mettre une CentOS sur ecos2 (actuellement, c'est une Ubuntu) pour que ça colle avec ce que j'ai sur ecos0, et je vais devoir passer à KVM pour les deux machines virtuelles, parce qu'il m'est impossible d'avoir autre chose que Debian 7 sous OpenVZ... Shit.
