Hadoop Pipes: comment transmettre des enregistrements de données volumineux pour mapper/réduire des tâches

Question

J'essaie d'utiliser map/reduce pour traiter de grandes quantités de données binaires. L'application est caractérisée par ce qui suit: le nombre d'enregistrements est potentiellement important, de sorte que je ne veux pas vraiment stocker chaque enregistrement comme un fichier séparé dans HDFS (j'avais prévu de les concaténer tous dans un seul fichier de séquence binaire), et chaque enregistrement est un grand blob cohérent (c'est-à-dire non divisible), d'une taille comprise entre une et plusieurs centaines de Mo. Les enregistrements seront consommés et traités par un exécutable C++. S'il n'y avait pas la taille des enregistrements, l'API Hadoop Pipes irait bien: mais cela semble être basé sur le fait de passer l'entrée pour mapper/réduire des tâches comme un bloc contigu d'octets, ce qui n'est pas pratique dans ce cas.

Je ne suis pas sûr de la meilleure façon de le faire. Existe-t-il un type d'interface tamponnée qui permettrait à chaque tâche M/R d'extraire plusieurs blocs de données dans des blocs gérables? Sinon, je pense à transmettre des offsets de fichiers via l'API et à les diffuser dans les données brutes de HDFS côté C++.

Je voudrais avoir des opinions de quelqu'un qui a essayé quelque chose de similaire - je suis assez nouveau pour hadoop.

Answer 1

Hadoop n'est pas conçu pour les enregistrements d'une taille d'environ 100 Mo. Vous obtiendrez OutOfMemoryError et les divisions inégales, car certains enregistrements sont 1 Mo et certains sont 100 Mo. Par Ahmdal's Law votre parallélisme souffrira grandement, réduisant le débit.

Je vois deux options. Vous pouvez utiliser Hadoop streaming pour mapper vos fichiers volumineux dans votre exécutable C++ tel quel. Comme cela enverra vos données via stdin, il sera naturellement en streaming et tamponné. Votre première tâche cartographique doit diviser les données en plus petits enregistrements pour un traitement ultérieur. D'autres tâches fonctionnent ensuite sur les plus petits enregistrements.

Si vous ne pouvez vraiment pas le casser, faites en sorte que votre carte réduise le travail sur les noms de fichiers. Le premier mappeur obtient des noms de fichiers, les exécute en profondeur dans votre exécutable C++ mapper, les stocke dans plusieurs fichiers. Le réducteur reçoit tous les noms des fichiers de sortie, répétez avec un exécutable C++ réducteur. Cela ne manquera pas de mémoire, mais il sera lent. Outre le problème du parallélisme, les tâches de réduction ne sont pas planifiées sur les nœuds qui contiennent déjà les données, ce qui entraîne des lectures HDFS non locales.