6
votes

HDFS distribué des lectures sans carte / réduction

est-il possible d'obtenir des lectures distribuées du cluster HDSF à l'aide d'un client HDFS sur une machine?

J'ai effectué une expérience avec un cluster composé de 3 nœuds de données (DN1, DN2, DN3). Ensuite, j'exécute 10 lectures simultanées à partir de 10 fichiers indépendants d'un programme client situé sur DN1, et il semblait ne pas lire que des données de DN1. D'autres nœuds de données (DN2, DN3) indiquaient une activité zéro (à en juger des journaux de débogage). p>

J'ai vérifié que tous les blocs de fichiers sont répliqués sur les 3 datanodes, de sorte que si je ferme le DN1, les données sont lues à partir de DN2 (DN2 uniquement). P>

Augmenter la quantité de Les données lues n'ont pas aidé (essayé de 2 Go à 30 Go). p>

Puisque j'ai besoin de lire plusieurs fichiers volumineux et d'extraire une petite quantité de données de celle-ci (peu de KB), je voudrais éviter d'utiliser la carte / réduire car elle nécessite des paramètres plus de services et également nécessite de rédiger la sortie de chaque tâche divisée vers HDFS. Il serait plutôt agréable d'avoir le résultat diffusé directement à mon programme client à partir des nœuds de données. P>

J'utilise Séquencefile code> pour la lecture / écriture de données, de cette mode (JDK7 ): P>

//Run in thread pool on multiple files simultaneously

List<String> result = new ArrayList<>();
LongWritable key = new LongWritable();
Text value = new Text();
try(SequenceFile.Reader reader = new SequenceFile.Reader(conf,
                                     SequenceFile.Reader.file(filePath)){
  reader.next(key);
  if(key.get() == ID_I_AM_LOOKING_FOR){
    reader.getCurrentValue(value);
    result.add(value.toString());
  }
}

return result; //results from multiple workers are merged later


0 commentaires

3 Réponses :


7
votes

J'ai bien peur que le comportement que vous voyez est la conception. De Document Hadoop :

Sélection de réplique

Pour minimiser la consommation de bande passante globale et lire la latence, HDFS Essai Pour satisfaire une demande de lecture d'une réplique la plus proche de la lecteur. S'il existe une réplique sur le même rack que le nœud Reader, Ensuite, cette réplique est préférable de satisfaire la demande de lecture. Si Angg / HDFS Cluster couvre plusieurs centres de données, puis une réplique qui est résident dans le centre de données local est préféré sur n'importe quelle télécommande. Réplique.

Il peut être confirmé plus en plus par correspondant code source Hadoop : xxx

c'est-à-dire, toutes les répliques disponibles sont essayées l'une après l'autre si l'ancien On échoue mais le plus proche est toujours le premier.

d'autre part, si vous accédez aux fichiers HDFS via HDFS proxy , il choisit des datanodes au hasard . Mais je ne pense pas que c'est ce que tu veux.


3 commentaires

Merci. Ceci explique cela! Merci pour la pointe proxy.


Comment Hadoop savait-il quel nœud est sur quel rack - Hadoop .apache.org / commun / docs / actuel / ...


Qu'est-ce que "Angg"?



3
votes

En plus de ce que Edwardw a déclaré noter que votre cluster actuel est très faible (seulement 3 nœuds) et dans ce cas, vous voyez les fichiers sur tous les nœuds. Cela se produit car le facteur de réplication par défaut de Hadoop est également 3. Dans un groupe plus important, vos fichiers ne seront pas disponibles sur chaque nœud et que vous accédez donc à plusieurs fichiers d'accéder à différents nœuds et à propager la charge.

Si vous travaillez avec des jeux de données plus petits, vous voudrez peut-être regarder HBASE, ce qui vous permet de travailler avec des morceaux plus petits et de propager la charge entre les nœuds (en divisant les régions)


1 commentaires

Vous avez raison. J'ai effectivement essayé de définir une réplication à 1 pour tenter de distribuer des blocs uniformément sur le cluster, mais cela vient de finir par écrire tous à DN1: ((Je suppose que j'ai besoin de plus de données et de blocages avant qu'il ne commence à les équilibrer sur différents nœuds. Merci pour le conseil Hbase, je peux emprunter des idées à partir de là.



0
votes

Je dirais que votre cas semble bon pour Mr. Si nous mettons de côté M. Computational Paradigm, nous pouvons dire que Hadoop est conçu pour apporter du code aux données, au lieu d'un contraire. Le changement de code dans les données est essentiel pour obtenir un traitement de données évolutif. de
En revanche, la mise en place de MapReduce est plus facile alors HDFS - puisque elle stocke Aucun état entre des emplois.
Dans le même temps - M. Framework se soucie de la transformation parallèle pour vous - quelque chose qu'il faudra du temps à faire correctement.
Un autre point - si les résultats du traitement de données sont si petits - il n'y aura pas d'impact significatif sur la performance si vous les combinerez ensemble dans le réducteur.
En d'autres termes - je suggérerais de reconsidérer l'utilisation de la MapReduce.


3 commentaires

Si vous me laissez tomber quelques informations, je vais essayer d'aider avec des estimations.


Merci. C'est assez simple, fondamentalement une recherche de Grep sur le (s) fichier (s) de données (s) de journal). Les données du journal peuvent être de contenu arbitraire. J'ai deux types de recherche: 1) Substring / Regex de type GREP sur le contenu 2) Cherchez à une position de journalisation connue (les positions / ID sont stockées séparément) et obtenez simplement le contenu. Vous pouvez supposer que le jeu de résultats sera toujours petit: 0 ~ 100 grumes. De plus, j'utilise la compression de bloc (en utilisant séquencefile API).


Pour les données du journal, il peut être convaincu de disposer d'une couche d'inrimalisation sous forme de formats d'entrée. Si vous souhaitez réduire les frais généraux d'analyse / de création d'objets - vous pouvez faire du filtrage lors de la lecture de données du flux HDFS dans la donnée RecordReader. Quelles sont vos exigences / attentes de performance?