Hive union toute l'efficacité et les meilleures pratiques

Question

J'ai une question sur l'efficacité de la ruche. J'ai 2 requêtes massives qui doivent être filtrées, jointes à des tables de mappage et syndiquées. Toutes les jointures sont identiques pour les deux tables. Serait-il plus efficace de les unir avant d'appliquer les jointures à la table combinée ou d'appliquer individuellement les jointures à chaque requête massive, puis d'unir les résultats? Est-ce que cela fait une différence?

J'ai essayé la deuxième voie et la requête a couru pendant 24 heures avant que je le tuais. J'ai l'impression de faire tout mon possible pour l'optimiser, sauf éventuellement réorganiser la déclaration syndicale. D'une part, je pense que cela ne devrait pas avoir d'importance parce que le nombre de lignes jointes par la table de mappage est le même et puisque tout est palatalized, cela devrait prendre à peu près le même laps de temps. D'un autre côté, peut-être qu'en faisant d'abord l'union, il devrait garantir que les deux grosses requêtes reçoivent des ressources système complètes avant que les jointures soient exécutées. Là encore, cela peut signifier qu'il n'y a que deux tâches en cours d'exécution, ce qui fait que le système n'est pas entièrement utilisé ou quelque chose comme ça.

Je ne sais tout simplement pas assez sur la façon dont la ruche et il est des œuvres multi-threading. Quelqu'un a des idées?

Answer 1

Il n'y a pas les meilleures pratiques. Les deux approches sont applicables. Les sous-requêtes dans UNION ALL s'exécutent en tant que tâches parallèles. Donc se joindre avant que l'union ne fonctionne comme des tâches parallèles avec des jeux de données plus petits, tez peut optimiser l'exécution et les tables jointes communes ne seront lues qu'une seule fois dans l'étape de mappeur unique pour chaque table. Vous pouvez également éviter les jointures pour certaines sous-requêtes, par exemple si leurs clés ne sont pas applicables à la jointure.

JOIN avec jeu de données plus l'union-ed peut également fonctionner avec un parallélisme très élevé en fonction de vos paramètres (octets par réducteur, par exemple), optimiseur peut également réécrire plan de requête. Donc, je vous suggère de vérifier les deux méthodes, mesurer la vitesse, plan d'étude et vérifier si vous pouvez changer quelque chose. Changer, mesurer, étudier le plan ... répéter

Encore quelques suggestions: Essayez de limiter les jeux de données avant de les rejoindre. Si votre jointure multiplie les lignes, l'analyse et l'agrégation peuvent fonctionner plus lentement sur les ensembles de données plus volumineux et la première approche peut être préférable si vous pouvez appliquer l'analyse/l'agrégation avant l'union.