Comment faire pour remplacer/réutilisation de l'existant chemin de sortie pour Hadoop emplois de nouveau et une

Je veux remplacer/réutilisation de l'existant répertoire de sortie quand je lance mon Hadoop travail au quotidien.
En fait le répertoire de sortie sera de stocker des résumés de sortie de chaque jour de l'exécution de la tâche des résultats.
Si je précise le même répertoire de sortie il donne l'erreur "répertoire de sortie existe déjà".

Comment contourner cette validation?

InformationsquelleAutor yogesh | 2011-10-10

14

Ce sujet de la suppression de l'annuaire avant d'exécuter le travail?

Vous pouvez le faire via le shell:
```
hadoop fs -rmr /path/to/your/output/
```
ou via l'API Java:
```
//configuration should contain reference to your namenode
FileSystem fs = FileSystem.get(new Configuration());
//true stands for recursively deleting the folder you gave
fs.delete(new Path("/path/to/your/output"), true);
```
- Merci Thomas pour la réponse. Le Seul problème que j'ai c'est que je ne veux pas supprimer le répertoire de sortie. Chaque jour quand je vais courir mon travail, je veux sa sortie à être fusionné avec sortie existant(ancien). La solution je pense est de générer/magasin de sortie de travail quotidien dans certaines répertoire temp et copier coller que le dossier temp dans la structure du vieux répertoire de sortie par un script.
- Ensuite, vous devez utiliser un dossier que vous pouvez copier toutes les sorties. Cela peut être fait avec un shellscript, aussi, Il n'y a pas de solution pour ce problème.
InformationsquelleAutor Thomas Jungblut
11

Jungblut la réponse est votre solution directe. Depuis que j'ai jamais confiance à des processus automatisés pour supprimer des choses (moi personnellement), je vais proposer une alternative:

Au lieu d'essayer de remplacer, je vous suggère de faire le nom de la sortie de votre travail dynamique, y compris le temps dans lequel il a couru.

Quelque chose comme "/path/to/your/output-2011-10-09-23-04/". De cette façon, vous pouvez conserver votre ancien emploi de sortie dans le cas où vous avez besoin de revoir en. Dans mon système, qui fonctionne 10+ travail quotidien, nous avons la structure de la production: /output/job1/2011/10/09/job1out/part-r-xxxxx, /output/job1/2011/10/10/job1out/part-r-xxxxx, etc.
- +1 c'est à dire le traitement des données de l'approche. Mais assurez-vous qu'il y a une collecte des ordures démon qui rassemble tous les répertoires obsolètes. Sinon, votre HDFS débordement ;)).
- En effet! En général, nous pouvons supprimer des choses après une semaine.
- Merci pour la réponse. Le Seul problème que j'ai - je ne veux pas supprimer le répertoire de sortie. Chaque jour quand je vais courir mon travail, je veux sa sortie à être fusionné avec sortie existant(ancien). La solution je pense est de générer/magasin de sortie de travail quotidien dans certaines répertoire temp et copier coller que le dossier temp dans la structure du vieux répertoire de sortie par un script. J'ai structure des dossiers sur s3 comme "Campaign_Id/Année/Mois/jour"
InformationsquelleAutor Donald Miner
5

Hadoop est TextInputFormat (ce qui, j'imagine que vous utilisez), ne permet pas écraser un répertoire existant. Probablement à vous excuser la douleur de trouver vous avez supprimé accidentellement quelque chose que vous (et votre cluster) a travaillé très dur sur.

Toutefois, Si vous êtes certain que vous voulez que votre dossier de sortie pour être remplacé par le travail, je crois que la façon la plus propre est de changer TextOutputFormat un peu comme ceci:
```
public class OverwriteTextOutputFormat<K, V> extends TextOutputFormat<K, V>
{
      public RecordWriter<K, V> 
      getRecordWriter(TaskAttemptContext job) throws IOException, InterruptedException 
      {
          Configuration conf = job.getConfiguration();
          boolean isCompressed = getCompressOutput(job);
          String keyValueSeparator= conf.get("mapred.textoutputformat.separator","\t");
          CompressionCodec codec = null;
          String extension = "";
          if (isCompressed) 
          {
              Class<? extends CompressionCodec> codecClass = 
                      getOutputCompressorClass(job, GzipCodec.class);
              codec = (CompressionCodec) ReflectionUtils.newInstance(codecClass, conf);
              extension = codec.getDefaultExtension();
          }
          Path file = getDefaultWorkFile(job, extension);
          FileSystem fs = file.getFileSystem(conf);
          FSDataOutputStream fileOut = fs.create(file, true);
          if (!isCompressed) 
          {
              return new LineRecordWriter<K, V>(fileOut, keyValueSeparator);
          } 
          else 
          {
              return new LineRecordWriter<K, V>(new DataOutputStream(codec.createOutputStream(fileOut)),keyValueSeparator);
          }
      }
}
```
Maintenant, vous êtes à la création de la FSDataOutputStream (fs.create(file, true)) réécriture=true.
- Cette solution proposée n'est pas seulement sur le plan conceptuel problématique, mais aussi de ne pas travailler sans modification -- un chèque en FileOutputFormat assure sur les emplois d'initialisation que le répertoire de sortie n'existe pas.
- J'ai essayé de proposer des solutions en plus de l'évident "supprimer le dossier avant de le métier. Avec un mot de prudence. Est-ce toujours recommandé? probablement pas, c'est une option intéressante qui vaut la peine de mentionner, de l'OMI, oui. Et cela a fonctionné dans le passé, ce n'est pas sûr qu'il fonctionne maintenant.
- Je pense que la réponse avec attention devient de plus en plus appropriée à la question de la sophistication. Pour un évidemment question de newbie c'est à mon humble avis, mieux vaut éviter de pointage dans la mauvaise direction.
- Et re: travailler dans le passé, peut-être mapred vs mapreduce Api? Mon commentaire est à propos de ces derniers.
InformationsquelleAutor harel
1

Hadoop soutient déjà l'effet que vous semblez essayer de réaliser en permettant à de multiples chemins d'entrée à un emploi. Au lieu d'essayer d'avoir un seul répertoire de fichiers à laquelle vous pouvez ajouter plusieurs fichiers, un répertoire des répertoires auxquels vous ajoutez de nouveaux répertoires. Pour utiliser le résultat de l'agrégation en entrée, il suffit de spécifier l'entrée glob comme un caractère générique au cours de la sous-répertoires (par exemple, my-aggregate-output/*). "Annexer" de nouvelles données à l'ensemble de la sortie, il suffit de spécifier un unique sous-répertoire de la somme que le répertoire de sortie, généralement à l'aide d'un timestamp ou certains numéro de séquence dérivée à partir de votre entrée de données (par exemple,my-aggregate-output/20140415154424).

InformationsquelleAutor llasram
0

Vous pouvez créer un sous-répertoire de sortie pour chaque exécution par le temps. Par exemple, disons que vous attendez que le répertoire de sortie de l'utilisateur et ensuite définie comme suit:
```
FileOutputFormat.setOutputPath(job, new Path(args[1]);
```
Changer cela par les lignes suivantes:
```
String timeStamp = new SimpleDateFormat("yyyy.MM.dd.HH.mm.ss", Locale.US).format(new Timestamp(System.currentTimeMillis()));
FileOutputFormat.setOutputPath(job, new Path(args[1] + "/" + timeStamp));
```
InformationsquelleAutor Tahsin Turkoz
0

J'ai eu un semblable de cas d'utilisation, j'utilise MultipleOutputs pour résoudre ce problème.

Par exemple, si je veux les différentes tâches MapReduce pour écrire dans le même répertoire /outputDir/. Travail 1 écrit de /outputDir/job1-part1.txt, job 2 écrit à /outputDir/job1-part2.txt (sans supprimer les fichiers de sortie).

Dans la main, définir le répertoire de sortie d'un un au hasard (il peut être supprimé avant qu'un nouveau travail s'exécute)
```
FileInputFormat.addInputPath(job, new Path("/randomPath"));
```
Dans le réducteur/mapper, utilisez MultipleOutputs et de l'ensemble de l'écrivain d'écrire dans le répertoire désiré:
```
public void setup(Context context) {
    MultipleOutputs mos = new MultipleOutputs(context);
}
```
et:
```
mos.write(key, value, "/outputDir/fileOfJobX.txt")
```
Cependant, mon cas d'utilisation est un peu compliquée que cela. Si c'est juste pour écrire dans le même répertoire, vous pouvez écrire dans un répertoire différent et exécute un script pour migrer les fichiers, comme: hadoop fs -mv /tmp/* /outputDir

Dans mon cas d'utilisation, chaque travail de MapReduce écrit pour différents sous-répertoires en fonction de la valeur du message en cours d'écriture. La structure de répertoire peut être multi-couches, comme:
```
/outputDir/
    messageTypeA/
        messageSubTypeA1/
            job1Output/
                job1-part1.txt
                job1-part2.txt
                ...
            job2Output/
                job2-part1.txt
                ...

        messageSubTypeA2/
        ...
    messageTypeB/
    ...
```
Chaque travail de Mapreduce peut écrire à des milliers de sous-répertoires. Et le coût de la rédaction d'un tmp dir et le déplacement de chacun des fichiers dans le répertoire correct est élevé.

InformationsquelleAutor phanhuy152
0

Si est de charger le fichier d'entrée (avec, par exemple, ajouté des entrées) à partir du système de fichiers local pour hadoop distributed file system en tant que tel:
```
hdfs dfs -put  /mylocalfile /user/cloudera/purchase
```
Alors on peut aussi remplacer/réutilisation de l'existant répertoire de sortie avec -f. Pas besoin de supprimer ou de re-créer le dossier
```
hdfs dfs -put -f  /updated_mylocalfile /user/cloudera/purchase
```
InformationsquelleAutor Laenka-Oss
0

Hadoop suit la philosophie Write Once, Read many times. Ainsi, lorsque vous essayez d'écrire dans le répertoire de nouveau, il suppose qu'il a de faire un nouveau (Écrire une fois), mais il existe déjà, et il se plaint. Vous pouvez le supprimer via hadoop fs -rmr /path/to/your/output/. Il est préférable de créer une dynamique de répertoire (par exemple,basé sur l'horodatage ou de la valeur de hachage) afin de préserver les données.

InformationsquelleAutor Fabulous

Vous devez vous connecter pour publier un commentaire.