Запись в файл в HDFS в Hadoop

Я искал приложение Hadoop с интенсивным использованием диска, чтобы проверить активность ввода-вывода в Hadoop, но я не смог найти ни одного такого приложения, которое поддерживало бы использование диска выше, скажем, 50%, или какое-то подобное приложение, которое фактически держит диск занятым. Я попробовал randomwriter, но это, на удивление, не требует интенсивного дискового ввода-вывода.

Итак, я написал крошечную программу для создания файла в Mapper и записи в него текста. Это приложение работает хорошо, но загрузка высока только на главном узле, который также является узлом имени, средством отслеживания заданий и одним из подчиненных. В других средствах отслеживания задач использование диска равно нулю или незначительно. Я не могу понять, почему дисковый ввод-вывод так низок в трекерах задач. Может ли кто-нибудь подтолкнуть меня в правильном направлении, если я делаю что-то не так? Заранее спасибо.

Вот мой образец кода, который я написал в файле WordCount.java для создания и записи строки UTF в файл:

Configuration conf = new Configuration();
FileSystem fs = FileSystem.get(conf);
Path outFile;
while (itr.hasMoreTokens()) {
    word.set(itr.nextToken());
    context.write(word, one);
    outFile = new Path("./dummy"+ context.getTaskAttemptID());
    FSDataOutputStream out = fs.create(outFile);

    out.writeUTF("helloworld");
    out.close();
    fs.delete(outFile);
  }

person Gudda Bhoota    schedule 19.11.2012    source источник
comment
Для сравнительного анализа ввода-вывода вы также можете взглянуть на TestDFSIO: answers.oreilly.com/topic/460-how-to-benchmark-a-hadoop-cluster   -  person Lorand Bendig    schedule 19.11.2012
comment
@LorandBendig Да, самое высокое использование диска для TestDFSIO, которое я обнаружил для своего кластера из 14 узлов, составляет всего 2,4%, а в среднем около 0,07%. Я измеряю использование диска с помощью команды iostat, задание выполнялось около 300 с. Есть ли что-то действительно глупое, что я делаю и не знаю?   -  person Gudda Bhoota    schedule 20.11.2012
comment
Вы можете поиграть с параметрами (количество файлов, размер), но я думаю, что вы уже это сделали. Есть дополнительные тесты, которые вы можете попробовать, они очень хорошо описаны здесь: кластер-с-terasort-testdfsio-nnbench-mrbench/" rel="nofollow noreferrer">michael-noll.com/blog/2011/04/09/   -  person Lorand Bendig    schedule 20.11.2012
comment
@Lorand Я пробовал это. Я изменил коэффициент репликации на 1 и поэкспериментировал с параметрами, и даже после этого я увидел, что только главный узел (также подчиненный узел) слишком занят вводом-выводом (использование 100%!) И другие используют 0%!   -  person Gudda Bhoota    schedule 21.11.2012


Ответы (2)


Я думаю, что любой механизм, который создает java-объекты для каждой ячейки в каждой строке и запускает любую сериализацию java-объектов перед сохранением на диск, имеет мало шансов использовать IO.
По моему опыту, сериализация работает со скоростью несколько МБ в секунду или чуть больше, но не 100 МБ в секунду.
То, что вы сделали, избегая слоев Hadoop на выходном пути, совершенно правильно. Теперь давайте рассмотрим, как работает запись в HDFS. Данные записываются на локальный диск через локальную ноду данных, а затем синхронно на другие ноды в сети, в зависимости от вашего коэффициента репликации. В этом случае вы не можете записать в HDFS больше данных, чем пропускная способность вашей сети. Если ваш кластер относительно небольшой, то это стоит того. Для кластера из 3 узлов и тройной репликации вы будете направлять все данные на все узлы, поэтому пропускная способность записи HDFS для всего кластера будет около 1 Гбит — если у вас есть такая сеть.
Итак, я бы предложил:
а) Уменьшить коэффициент репликации до 1, таким образом, перестать быть привязанным к сети.
б) Записывать большие порции данных за один вызов картографа

person David Gruzman    schedule 20.11.2012
comment
Я изменил коэффициент репликации на 1 и изменил размер блока на 1 КБ и 1 МБ соответственно. Мои наблюдения заключаются в том, что уменьшение карты выполняется очень медленно, а IO снова высок только в главном узле. Я также пытался написать один раз в картографе, в отличие от приведенного выше кода, где я пишу в файл, когда каждое слово найдено. Тем не менее, поведение осталось прежним. - person Gudda Bhoota; 20.11.2012
comment
Сколько мапперов работает одновременно? и какова пропускная способность диска на узел, которую вы наблюдаете? - person David Gruzman; 21.11.2012
comment
Запущенные задачи карты = 3, Запущенные задачи сокращения = 1, mapred.tasktracker.map.tasks.maximum = 2, mapred.tasktracker.reduce.tasks.maximum = 2. Использование диска на 3 узлах почти 0, а на главном узле 100%. - person Gudda Bhoota; 21.11.2012
comment
Запущенная карта tasks=3 выглядит низкой - возможно, не хватает разделения ввода. Также убедитесь, что демоны datanode запущены на всех подчиненных узлах кластера. - person David Gruzman; 21.11.2012

OK. Должно быть, я был действительно глуп, что не проверил раньше. Настоящая проблема заключалась в том, что все мои узлы данных на самом деле не работали. Переформатировал namenode и все встало на свои места, утилизация стала 15-20% что неплохо для WC. Я запущу его для TestDFSIO и посмотрю, смогу ли я использовать диск еще больше.

person Gudda Bhoota    schedule 27.11.2012