Mise en cache des applications de cartes dans Hadoop MapReduce?

Question

En regardant la combinaison de MapReduce et HBase dans une perspective de flux de données, mon problème semble correspondre. J'ai un grand nombre de documents que je veux à la carte, combiner et réduire. Ma précédente implémentation SQL était de diviser la tâche en opérations par lots, le stockage de façon cumulative ce qui serait le résultat de la carte dans la table, puis d'effectuer l'équivalent d'une réduction. Cela a l'avantage que, à tout moment au cours de l'exécution (ou entre les exécutions), j'ai eu à ce moment les résultats de la carte.

Si je comprends bien, l'exécution de ce travail en tant que MapReduce nécessiterait toutes les fonctions de la carte pour exécuter chaque fois.

Mes fonctions de la carte (et en fait une fonction) donne toujours la même sortie pour une entrée donnée. Il n'y a tout simplement pas de point dans la production de recalcul si je n'ai pas. Mon entrée (un ensemble de documents) sera en croissance constante et je vais exécuter mon opération MapReduce périodiquement sur les données. Entre les exécutions je ne vraiment avoir à calculer les fonctions de la carte pour les documents nouvellement ajoutés.

Mes données seront probablement HBase -> MapReduce -> HBase. Étant donné que Hadoop est un écosystème, il peut être en mesure de savoir qu'une fonction donnée a été appliquée à une ligne avec une identité donnée. Je suppose des entrées immuables dans le tableau HBase. Ne / peut Hadoop en tenir compte?

Je suis mis au courant de peut être plus rapide que la persistance et la récupération de la classe de problème Hadoop est utilisé pour la documentation (en particulier les vidéos Cloudera) qui re-calcul (des données potentiellement redondantes).

Les commentaires / réponses?

Answer 1

Si vous cherchez à éviter de la carte à chaque fois que l'étape, divisez comme sa propre étape (soit en utilisant le IdentityReducer ou le réglage du nombre de réducteurs pour le travail à 0) et exécuter les étapes ultérieures utilisant la sortie votre étape de carte.

Que ce soit effectivement plus rapide que recalcul à partir des données brutes à chaque fois dépend du volume et de la forme des données d'entrée en fonction des données de sortie, la complexité de votre étape de carte est, etc.

Notez que l'exécution de votre mappeur sur les nouveaux ensembles de données ne sera pas ajouter à exécutions précédentes - mais vous pouvez contourner ce problème en utilisant un dossier daté de sortie. C'est-à-dire que vous pouvez stocker la sortie de mappage de votre premier lot de fichiers dans my_mapper_output/20091101, et le lot de la semaine prochaine à my_mapper_output/20091108, etc. Si vous voulez réduire sur l'ensemble, vous devriez être en mesure de passer my_mapper_output comme le filtre d'entrée, et la capture de tous les ensembles de sortie.

Answer 2

Pourquoi ne pas appliquer votre flux de travail SQL dans un environnement différent? Signification, ajouter une colonne « traitée » à votre table d'entrée. Lorsque vient le temps d'exécuter un résumé, exécutez un pipeline qui va quelque chose comme:

carte (map_function) le (traité table d'entrée filtré par!); stocker dans map_outputs soit dans HBase ou HDFS simplement.

carte (fonction de réduire) le (map_outputs); stocker dans HBase.

Vous pouvez rendre la vie un peu plus facile, en supposant que vous stockez vos données dans Hbase triées par date d'insertion, si vous enregistrez quelque part horodatages de pistes sommaires avec succès, et ouvrez le filtre sur les entrées qui sont datées au plus tard le dernier résumé réussi - vous gagnerez un peu de temps de balayage important.

Voici une présentation intéressante qui montre comment une entreprise architecturé leur flux de travail (bien qu'ils n'utilisent pas Hbase): http: //www.scribd. com / doc / 20971412 / Hadoop-World-production-profonde plongée avec-haute disponibilité