Discussion :

[bstevy]

Bonjour,


J'ai lu dernièrement un article assez interessant sur "A partir de quand utiliser Hadoop" (https://www.chrisstucchio.com/blog/2...op_hatred.html)

Mon problème est le suivant : Je suis dans une boite où ils veulent absolument utiliser Hadoop. Actuellement la volumétrie de donnée est ridicule. On est au maximum, en prenant vraiment tout tout tout à peut etre 2TO. Et pourtant, ils veulent utiliser hadoop car, soit disant, dans le futur, ils vont avoir de plus en plus de données.

A la lecture de l'article ci-dessus, on peut dire qu'a partir de 5TO, il est normal d'envisager d'utiliser Hadoop.
Si l'on considère qu'actuellement, j'ai donc 2TO de données, et que dans 5 ans, j'aurais peut etre 5-6 TO (peut-etre plus), est ce qu'il est raisonnable de penser que cette "limite" de 5TO à partir de laquelle on se doit d'utiliser Hadoop peut elle aussi augmenter ? Est ce que par exemple, dans 5 ans, on considèrera qu'Hadoop, c'est bien à partir de 10TO, ou de 25TO ? Ou est ce que cette limite risque de rester assez stable, et dans ce cas, passer maintenant à Hadoop peut etre un inverstissement interessant ?

C'est un peu "philosophique" comme question, mais si vous pouviez m'apporter des éléments de réponse, ca me serait d'une grande aide.


Merci d'avance pour vos retours.


Steven

[Moctezuma]

Salut,

il est vrai que quand on parle de Big Data, on pense tout de suite à la gestion d'un gros volume de données (plusieurs dizaines de To voir plus), mais pour ma part je pense qu'il ne faut pas uniquement s'arrêter sur cet aspect.

Il y a aussi un autre élément qui peut entrer en ligne de compte, à savoir la vélocité (un des fameux 3 V).
Après, je ne connais pas le contexte de ton entreprise, mais peut-être en auriez-vous le besoin?

[bstevy]

Sur ce point là, surtout si la volumétrie n'est pas très élevée, ne peut on pas s'en sortir avec par exemple un script python ?
Le truc des trois V pour moi, c'est qu'il faut les prendre ensemble... la vélocité sans le volume est déjà traité très facilement, il suffit de voir tout ce qui est système embarqué.

L'utilisation de Hadoop dans mon entreprise, c'est juste n'importe quoi... mais j'arrive pas à me faire entendre, et j'ai besoin d'arguments pour leur faire entendre raison.

[bordi]

L'utilisation de Hadoop dans mon entreprise, c'est juste n'importe quoi... mais j'arrive pas à me faire entendre, et j'ai besoin d'arguments pour leur faire entendre raison.

D'après l'état de mes connaissance, normalement, hadoop est fait d'abord pour gérer de la volumétrie, puis de la vitesse, puis la variété, les fameux 3V dans l'ordre, ca veut dire qu'on sacrifie la vitesse au profit de la masse, le volume cité, me semble faible.

comme il est dit si bien

« Utiliser Hadoop s'apparente à écrire à un correspondant, dit-il. Vous écrivez une lettre, vous l'envoyez, puis vous recevez une réponse. Mais c'est très différent de la [messagerie instantanée] ou de l'e-mail ».

hadoop c'est du batching, on peut adjoindre spark pour du "temps reel" par exemple, une requête sql prend 1 minutes en hadoop pour avoir la réponse le temps d'avoir l'agrégation des données venant des nodes géré par les mapreduce , alors que spark prend 0,6s, quand ils interrogent le cluster cela dépend ce que l'on veut faire et des besoins de votre application. l'un utilise la mémoire, l'autre le disque

Spark peut etre performant avec 200 nodes en utilisant les ressources mémoires pour ses RDD, et hadoop map reduce peut gerer des milliers de serveur nodes, compte tenu de la datamasse stockée sur les disques, l'un est fait pour la vitesse avec limitation vis à vis du volume, map reduce est fait pour la volumétrie avec limitation de la vitesse.

Hadoop a une grande de complexité de mise en oeuvre, de performance et de mise à niveau. cela nécessite pas mal de compétence

Avant je regarderai d'autre solution,

- mongodb et le nosql et les mécanisme de distribution des données et les langages classiques
- spark peut être une bonne alternative à hadoop, il peut être configurer en local, en cluster standalone, en cluster partagé avec hadoop
on peut programmer en scala,java,python, il peut travailler avec R et Mahout, éventuellement il peut être intégrer dans l'ecosystem hadoop.
- autres.

pour ca il faudrait faire des maquettes pour s'en rendre compte

Pour un petit cluster hadoop, volia la conf minimale pour travailler, mon expérience, il faut au moins ajouter au minimum 50%, voir 100%, de resources en plus, autant que possible, vaut mieux être à l'aise des le départ, que être dans les choux, lors de l'évolution des besoins, ca marche très bien au début, après paf! plus de ressources disponible, pour éviter les surprises.

Donc si on me dit 48Gb ram, vu mon expérience j'en mets 128, si 96Gb ram, j'en mets 256. j'hésite pas. quand on joue petit, on se fait avoir a cause d'aléas. par contre j'aligne les configuration en fonction de ce qui préconisé et des besoins réels. donc 48 GBram -8 pour l'Os ca met fait 20 conteneurs par node, avec l'adjonction des autres briques de l'écosystème de hadoop, comme hbase,spark et autres. nos serveurs sont toujours à 30% de ressources, quand l'un est arrête ou tombe, la charge bascule sur les autres, donc 3 serveurs, si 2 tombent, le dernier doit survivre, hadoop c'est juste plus gros. sans oublier les contraintes du load balancing.

Slaves
Balanced workload
Four to six 2 TB disks
One Quad
24 Mb ram
1 GB Ether*net all-to-all
HBase clus*ter
Six 2 TB disks
Dual Quad
48 Mb ram

Masters
Balanced and/or HBase clus*ter
Four to six 2 TB disks
Dual Quad
24 Mb ram



Pour un medium to large clusters (100s to 1000s nodes):

Machine Type
Workload Pattern/ Cluster Type
Storage
Processor (# of Cores)
Memory (GB)
Network
Slaves
Balanced workload
Four to six 1 TB disks
Dual Quad
24 ram mb
Dual 1 GB links for all nodes in a 20 node rack and 2 x 10 GB intercon*nect links per rack going to a pair of cen*tral switches.
Compute intensive workload
Four to six 1 TB or 2 TB disks
Dual Hexa Quad
24-48 ram
I/O inten*sive work*load
Twelve 1 TB disks
Dual Quad
24-48 Mb ram
HBase clus*ters
Twelve 1 TB disks
Dual Hexa Quad
48-96 Mb ram
Masters
All work*load pat*terns/HBase clusters
Four to six 2 TB disks
Dual Quad
Depends on number of file system objects to be created by NameNode.
For Further Reading

[bstevy]

Merci pour toutes ces informations, c'est vraiment très interessant.
Ca devrait m'être bien utile dans mes futurs discussions.