Повторное использование файлов в распределенном кэше Hadoop
Мне интересно, если кто-то может объяснить, как распределенный кеш работает в Hadoop. Я выполняю задание много раз, и после каждого запуска я замечаю, что размер папки локального распределенного кэша на каждом узле увеличивается.
Есть ли способ для нескольких заданий повторно использовать один и тот же файл в распределенном кеше? Или распределенный кеш действителен только на время существования какой-либо отдельной работы?
Причина, по которой я запутался, заключается в том, что в документации Hadoop упоминается, что "DistributedCache отслеживает временные метки изменения файлов кеша", поэтому я полагаю, что если временная метка не изменилась, то ей не нужно повторно кэшировать или повторно -копировать файлы на узлы.
Я успешно добавляю файлы в распределенный кеш, используя:
DistributedCache.addFileToClassPath(hdfsPath, conf);
3 ответа
DistributedCache использует подсчет ссылок для управления кешами. org.apache.hadoop.filecache.TrackerDistributedCacheManager.CleanupThread отвечает за очистку CacheDirs, чей счетчик ссылок равен 0. Он будет проверять каждую минуту (период по умолчанию составляет 1 минуту, вы можете установить его с помощью "mapreduce.tasktracker.distributedcache.checkperiod").
Когда работа заканчивается или не удается, JobTracker отправит org.apache.hadoop.mapred.KillJobAction на треккеры. Затем, если TaskTracker получает действие KillJobAction, он помещает действие в tasksToCleanup. В TaskTracker есть фоновый поток с именем taskCleanupThread, который выполняет действие из tasksToCleanup и выполняет очистку. Для действия KillJobAction он вызовет purgeJob для очистки задания. В этом методе будет уменьшен счетчик ссылок, используемый этим заданием (rjob.distCacheMgr.release();).
Приведенный выше анализ основан на hadoop-core-2.0.0-mr1-cdh4.2.1-sources.jar, Я также проверил hadoop-core-0.20.2-cdh3u1-sources.jar и обнаружил небольшую разницу между этими двумя версиями. Например, не было org.apache.hadoop.filecache.TrackerDistributedCacheManager.CleanupThread в 0.20.2-cdh3u1, При инициализации задания TrackerDistributedCacheManager проверит, достаточно ли места для размещения новых файлов кэшей для этого задания. Если нет, он удалит кэши, которые имеют 0 ссылок.
Если вы используете cdh4.2.1, вы можете увеличить "mapreduce.tasktracker.distributedcache.checkperiod", чтобы очистить задержку работы. Тогда вероятность того, что несколько заданий используют один и тот же распределенный кеш, увеличивается.
Если вы используете cdh3u1, вы можете увеличить ограничение размера кэша ("local.cache.size", по умолчанию 10G) и максимум каталогов для кэшей ("mapreduce.tasktracker.cache.local.numberdirectories", по умолчанию 10000). Это также может быть применено к cdh4.2.1.
Если вы внимательно посмотрите на то, что написано в этой книге, то есть ли предел того, что может храниться в распределенном кэше. По умолчанию это 10 ГБ (настраивается). В кластере может одновременно работать несколько разных заданий. Кроме того, Hadoop гарантирует, что файлы останутся доступными в кеше для одного задания, так как оно поддерживается счетчиком ссылок, выполненным программой отслеживания задач для различных задач, обращающихся к файлам в кэше. В вашем случае для последующих заданий файлы могут отсутствовать, так как они уже помечены для удаления.
Пожалуйста, поправьте меня, если вы не согласны. Я буду рад обсудить это дальше.
Согласно этому: http://www.datasalt.com/2011/05/handling-dependencies-and-configuration-in-java-hadoop-projects-efficiently/
Вы должны быть в состоянии сделать это через API DistributedCache вместо "-libjars"