Posté par ckyl .
En réponse au journal Data Warehouse.
Évalué à 2.
Dernière modification le 10 juillet 2017 à 16:10.
Tu confonds Hadoop et Hive.
J'ai essayé de trouver d'où tu étais parti pour faire cette réponse et je n'ai pas pu trouver :)
Hive est un moteur de requêtage MapReduce en mode disque.
Non.
"The Apache HiveTM data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax."
Si on vulgarise beaucoup Hive c'est:
un metastore qui gère les db & tables
un compilateur qui transforme une requête SQL en un plan d'exécution
un moteur d'exécution qui va transformer le plan d'exécution en une serie d'opération
un driver qui est l'orchestrateur de tout ca
Historiquement le moteur d'exécution par défaut est MapReduce, c'est a dire que le moteur d'exécution transforme le plan d'exécution en une série de jobs MR. Un MR Hadoop "bête et méchant" a pour lui deux inconvénients d'un point de vue perf:
Le paradigme MR tire sa robustesse des checkpoints entre chaque phase. Par défaut Hadoop fait ça sur disque et quand les phases sont légères et nombreuses les IO deviennent le facteur nettement dominant.
La soumission d'un job Hadoop MR est très lente (~10s), c'est "juste" un problème d'implémentation.
Ça explique très certainement ton raccourci grossier, qui oubli aussi que ce que tu perds d'un côté tu le gagnes de l'autre (ex: espace d’adressage partagé et survivant entre traitements = Possibilités d'optimisations VS difficulté de gestion des ressources et instrumentation VS coûts ressources).
Mais MR n'est qu'un moteur d'exécution comme un autre. Tu peux brancher le moteur d'exécution que tu veux, il existe aussi des moteurs au dessus de Tez et de Spark. Au cours d'une requête tu peux parfaitement t'affranchir d'aller toucher le disque si tu veux, à l'exception de la lecture des données d'entrées et de l'écriture des résultats.
Si tu veux aussi éviter ces IO, comme tu le ferais avec des executors Spark peristant avec une RDD caché sur lequel tu fais de nombreuses requêtes SQL, tu peux aller voir LLAP. Rien de magique, tu ajoutes des démons qui survivent entre les requêtes et qui permettent de garder les données quelques part dans un espace d’adressage. Ça te permet supprimer des IO contre un coût de ressource plus important. Intéressant dans certains cas et pas dans d'autres.
Les concepts sont toujours les mêmes et on les réimplémente à tous les niveaux de la stack.
Spark en mode mémoire
C'est un raccourci tellement grossier qu'il n'est absolument d'aucune utilité.
Donc oui, Spark est plus rapide que Hive.
Soupir.
Le monde est malheureusement compliqué; tant sur le fait que de telles généralités sont toujours fausses que sur le fait que la latence d'une requête n'est qu'un ility parmi d'autres.
[^] # Re: Hadoop ?
Posté par ckyl . En réponse au journal Data Warehouse. Évalué à 2. Dernière modification le 10 juillet 2017 à 16:10.
J'ai essayé de trouver d'où tu étais parti pour faire cette réponse et je n'ai pas pu trouver :)
Non.
"The Apache HiveTM data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax."
Si on vulgarise beaucoup Hive c'est:
Historiquement le moteur d'exécution par défaut est MapReduce, c'est a dire que le moteur d'exécution transforme le plan d'exécution en une série de jobs MR. Un MR Hadoop "bête et méchant" a pour lui deux inconvénients d'un point de vue perf:
Ça explique très certainement ton raccourci grossier, qui oubli aussi que ce que tu perds d'un côté tu le gagnes de l'autre (ex: espace d’adressage partagé et survivant entre traitements = Possibilités d'optimisations VS difficulté de gestion des ressources et instrumentation VS coûts ressources).
Mais MR n'est qu'un moteur d'exécution comme un autre. Tu peux brancher le moteur d'exécution que tu veux, il existe aussi des moteurs au dessus de Tez et de Spark. Au cours d'une requête tu peux parfaitement t'affranchir d'aller toucher le disque si tu veux, à l'exception de la lecture des données d'entrées et de l'écriture des résultats.
Si tu veux aussi éviter ces IO, comme tu le ferais avec des executors Spark peristant avec une RDD caché sur lequel tu fais de nombreuses requêtes SQL, tu peux aller voir LLAP. Rien de magique, tu ajoutes des démons qui survivent entre les requêtes et qui permettent de garder les données quelques part dans un espace d’adressage. Ça te permet supprimer des IO contre un coût de ressource plus important. Intéressant dans certains cas et pas dans d'autres.
Les concepts sont toujours les mêmes et on les réimplémente à tous les niveaux de la stack.
C'est un raccourci tellement grossier qu'il n'est absolument d'aucune utilité.
Soupir.
Le monde est malheureusement compliqué; tant sur le fait que de telles généralités sont toujours fausses que sur le fait que la latence d'une requête n'est qu'un ility parmi d'autres.