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