Проблемы с записью временного файла на узле данных с помощью Hadoop

Я хотел бы создать файл во время моей программы. Однако я хочу, чтобы этот файл был записан не в HDFS, а в файловой системе узла данных, где выполняется операция map.

Я попробовал следующий подход:

public void map(Object key, Text value, Context context)
        throws IOException, InterruptedException {
    // do some hadoop stuff, like counting words
    String path = "newFile.txt";
    try {
        File f = new File(path);
        f.createNewFile();
    } catch (IOException e) {
        System.out.println("Message easy to look up in the logs.");
        System.err.println("Error easy to look up in the logs.");
        e.printStackTrace();
        throw e;
    }
}

С абсолютным путем я получаю файл там, где он должен быть. Однако с относительным путем этот код не выдает никаких ошибок ни в консоли, из которой я запускаю программу, ни в журналах заданий. Однако мне не удается найти файл, который нужно создать (сейчас я работаю над локальным кластером).

Есть идеи, где найти файл или сообщение об ошибке? Если действительно есть сообщение об ошибке, как мне продолжить запись файлов в локальную файловую систему узлов данных?


person merours    schedule 07.08.2014    source источник
comment
Hadoop является распределенным, поэтому предположим, что вы запускаете его на кластере из 500 узлов, namenode случайным образом запускается на каком-то datanode. Поэтому я бы предпочел использовать namenode или edgenode в качестве места для создания файла.   -  person K S Nidhin    schedule 07.08.2014
comment
@KSNidhin Я знаю об этом, но цель здесь — создать временные файлы, прочитать их из внешнего инструмента, а затем удалить.   -  person merours    schedule 07.08.2014


Ответы (1)


newFile.txt — это относительный путь, поэтому файл будет отображаться относительно рабочего каталога процесса задачи карты. Это приземлится где-то в каталогах, используемых NodeManager для контейнеров. Это свойство конфигурации yarn.nodemanager.local-dirs в yarn-site.xml или значение по умолчанию, унаследованное от yarn-default.xml, которое находится в /tmp:

<property>
  <description>List of directories to store localized files in. An 
    application's localized file directory will be found in:
    ${yarn.nodemanager.local-dirs}/usercache/${user}/appcache/application_${appid}.
    Individual containers' work directories, called container_${contid}, will
    be subdirectories of this.
  </description>
  <name>yarn.nodemanager.local-dirs</name>
  <value>${hadoop.tmp.dir}/nm-local-dir</value>
</property>

Вот конкретный пример одного из таких каталогов в моей тестовой среде:

/tmp/hadoop-cnauroth/nm-local-dir/usercache/cnauroth/appcache/application_1363932793646_0002/container_1363932793646_0002_01_000001

Эти каталоги являются временным пространством для выполнения контейнера, поэтому вы не можете полагаться на их сохранение. Фоновый поток периодически удаляет эти файлы для завершенных контейнеров. Можно отложить очистку, установив свойство конфигурации yarn.nodemanager.delete.debug-delay-sec в yarn-site.xml:

<property>
  <description>
    Number of seconds after an application finishes before the nodemanager's 
    DeletionService will delete the application's localized file directory
    and log directory.

    To diagnose Yarn application problems, set this property's value large
    enough (for example, to 600 = 10 minutes) to permit examination of these
    directories. After changing the property's value, you must restart the 
    nodemanager in order for it to have an effect.

    The roots of Yarn applications' work directories is configurable with
    the yarn.nodemanager.local-dirs property (see below), and the roots
    of the Yarn applications' log directories is configurable with the 
    yarn.nodemanager.log-dirs property (see also below).
  </description>
  <name>yarn.nodemanager.delete.debug-delay-sec</name>
  <value>0</value>
</property>

Однако имейте в виду, что эта конфигурация предназначена только для устранения неполадок, чтобы вам было легче просматривать каталоги. Не рекомендуется в качестве постоянной производственной конфигурации. Если логика приложения зависит от задержки удаления, это, вероятно, вызовет состояние гонки между логикой приложения, пытающейся получить доступ к каталогу, и NodeManager, пытающимся удалить его. Если оставить файлы, оставшиеся после выполнения старых контейнеров, это также может привести к загромождению локального дискового пространства.

Сообщения журнала будут отправляться в stdout/stderr журналов задач карты, но я подозреваю, что выполнение не попадает в эти сообщения журнала. Вместо этого я подозреваю, что вы успешно создаете файл, но либо его нелегко найти (в структуре каталогов будут несколько непредсказуемые вещи, такие как идентификатор приложения и идентификатор контейнера, управляемые YARN), либо файл очищается, прежде чем вы сможете получить к этому.

Если вы изменили код, чтобы использовать абсолютный путь, указывающий на какой-то другой каталог, это помогло бы. Однако я не ожидаю, что этот подход будет хорошо работать на практике. Поскольку Hadoop является распределенным, вам может быть трудно найти, какой узел в кластере из сотен или тысяч содержит нужный вам локальный файл. Вместо этого вам может быть лучше записать в HDFS, а затем вытащить нужные файлы локально на узел, где вы запустили задание.

person Chris Nauroth    schedule 07.08.2014
comment
Спасибо за ответ, я сразу же проверю свои файлы конфигурации. FWIW, цель здесь состоит в том, чтобы записать некоторые данные в файл, сделать этот файл проанализированным каким-либо другим приложением и восстановить результат (все в той же операции map, поэтому постоянство не требуется (в любом случае, ненадолго). - person merours; 07.08.2014
comment
Я нашел каталог, но, насколько я могу судить, он очищается, как только работа завершена. Не знаете, как отключить эту очистку? - person merours; 07.08.2014
comment
Существует свойство конфигурации под названием yarn.nodemanager.delete.debug-delay-sec, которое может управлять очисткой. Я отредактировал свой ответ, включив в него дальнейшее обсуждение этого свойства. Обратите внимание на предупреждение о том, что это рекомендуется только для устранения неполадок, а не для регулярного использования в рабочей среде. - person Chris Nauroth; 07.08.2014