Discussion :

[kasdo]

Bonjour,

je viens vers vous pour avoir vos avis et surtout vos retours d’expériences.

j'entends souvent dire que les jointures sont a proscrire dans le monde hadoop avec hive ou spark.

Cependant, je suis sur un projet ou je dois reprendre une partie de mon DWH de Teradata vers hadoop. Donc, j'aurai certainement un nombre assez important de jointure à faire sur une volumétrie importante.

Des conseils à me donner ?


Merci d'avance.

[grunt2000]

Bonjour,

En effet, les jointures sont à éviter.

Pour simplifier, si tu dis jointure, tu dis : "Aller chercher dans n serveurs tous les éléments qui ont pour clef A.CODE_ARTICLE = B.CODE_ARTICLE"
Le problème, est que rien ne dit que les données auront un index sur ce code article – il est possible, parfois selon les solutions, d'un faire générer un –,
et que si jamais il n'y a pas d'index, c'est une recherche séquentielle qui débuterait,
et une recherche séquentielle en Big Data équivaut à mort par épuisement du programme.

Et même si les index sont là, une jointure fera interroger :

"Serveur 1, donne-moi tous tes éléments avec CODE_ARTICLE = <ceci>"
"Serveur 2, donne-moi tous tes éléments avec CODE_ARTICLE = <ceci>"
"Serveur 3, donne-moi tous tes éléments avec CODE_ARTICLE = <ceci>"
"Serveur 4, donne-moi tous tes éléments avec CODE_ARTICLE = <ceci>"

et moi, je les rassemble.

On essaie d'éviter cela.
Mais c'est vrai qu'après ça, avec Pig par exemple, finalement,
on finit par donner des ordres qui provoquent cela, pour exploiter (=> requêter) ses données.

[dev_ggy]

De mon coté je ferais attention a ce qu'on appelle BigData. Si avec Hadoop/Hive il peut être compliqué de faire des fusions, mais pas impossible; selon la volumétrie et le type de fichiers présent. Concernant Spark nous ne travaillons plus en MAP-REDUCE, mais avec la RAM ce qui change tout de même beaucoup de choses.