Обработка большой набор мелких файлов с Hadoop
Я использую пример программы Hadoop WordCount для обработки большого набора небольших файлов / веб-страниц (cca. 2-3 КБ). Поскольку это далеко от оптимального размера файла для файлов hadoop, программа работает очень медленно. Я думаю, это потому, что стоимость установки и разрыва работы намного больше, чем сама работа. Такие небольшие файлы также вызывают истощение пространств имен для имен файлов.
Я читал, что в этом случае я должен использовать архив HDFS (HAR), но я не уверен, как изменить эту программу WordCount для чтения из этого архива. Может ли программа продолжать работать без изменений или необходима какая-то модификация?
даже если я упакую много файлов в архивах, остается вопрос, улучшит ли это производительность. Я читал, что даже если я упакую несколько файлов, эти файлы внутри одного архива будут обрабатываться не одним картографом, а многими, что в моем случае (я думаю) не улучшит производительность.
если этот вопрос слишком прост, пожалуйста, поймите, что я я новичок в Hadoop и имею очень маленький опыт работы с ним.
5 ответов
использование HDFS не изменит того, что вы заставляете hadoop обрабатывать большое количество небольших файлов. Лучшим вариантом в этом случае, вероятно, является cat файлы в один (или несколько крупных) файл(ы).
Это уменьшит количество картографов, которые у вас есть, что уменьшит количество вещей, необходимых для обработки.
использование HDFS может повысить производительность, если вы работаете в распределенной системе. Если вы делаете только psuedo-distributed (одна машина) , то HDFS не улучшит производительность. Ограничение-это машина.
когда вы работаете с большим количеством небольших файлов, для этого потребуется большое количество картографов и редукторов. Настройка / down может быть сопоставима со временем обработки самого файла, вызывая большие накладные расходы. cating файлы должны уменьшить количество картографов Hadoop работает для задания, что должно повысить производительность.
благо вы могли видеть с помощью HDFS в магазине файлы будут находиться в распределенном режиме, с несколькими машинами. Файлы будут храниться в блоках (по умолчанию 64 Мб) на разных машинах, и каждая машина будет способна обрабатывать блок данных, который находится на машине. Это уменьшает использование пропускной способности сети, поэтому она не становится узким местом в обработке.
Архивация файлов, если hadoop собирается разархивировать их, просто приведет к тому, что hadoop все еще будет иметь большое количество небольших файлов.
надеюсь, это поможет вашему понимание.
из моего все еще ограниченного понимания og Hadoop, я считаю, что правильным решением было бы создать SequenceFile(s), содержащий ваши HTML-файлы в качестве значений и, возможно, URL-адрес в качестве ключа. Если вы выполняете работу M/R над SequenceFile(s), каждый картограф будет обрабатывать много файлов (в зависимости от размера разделения). Каждый файл будет представлен функции карты как один вход.
Вы можете использовать SequenceFileAsTextInputFormat как InputFormat для чтения этих файлов.
Смотрите также: предоставление нескольких нетекстовых файлы на одну карту в Hadoop MapReduce
Я недавно заложил эту статью, чтобы прочитать ее позже и нашел тот же вопрос здесь :) запись немного старая, не совсем уверен, насколько она актуальна сейчас. Изменения в Hadoop происходят очень быстрыми темпами.
http://www.cloudera.com/blog/2009/02/the-small-files-problem/
запись в блоге Тома Уайта, который также является автором "Hadoop: The Definitive Guide, Second Edition", рекомендуемое чтение для тех, кто начинает работу с платформа Hadoop.
CombineFileInputFormat может быть использован в этом случае, который хорошо работает для больших numaber мелких файлов. Это пакеты много таких файлов в одном сплит, таким образом, каждый картограф имеет больше для обработки (1 split = 1 map task). Общее время обработки для mapreduce также будет также падать, так как работает меньшее количество картографов. Поскольку Ther не являются архивными inputformat с использованием CombineFileInputFormat улучшит производительность.