Почему MapReduce является хорошим методом для анализа журналов http-сервера?

Я некоторое время присматривался к MapReduce, и мне кажется, что это очень хороший способ реализации отказоустойчивых распределенных вычислений. Я прочитал много документов и статей на эту тему, установил Hadoop на массив виртуальных машин и провел несколько очень интересных тестов. Я действительно думаю, что понимаю шаги Map и Reduce.

Но вот моя проблема: Я не могу понять, как это может помочь с анализом журналов HTTP-сервера.

Насколько я понимаю, крупные компании (например, Facebook) используют MapReduce для вычисления своих http-логов, чтобы ускорить процесс извлечения из них статистики аудитории. Компания, в которой я работаю, хотя и меньше, чем Facebook, имеет большой объем веб-журналов для ежедневного вычисления (100Go растет на 5–10 процентов каждый месяц). Сейчас мы обрабатываем эти журналы на одном сервере, и он отлично работает. Но сразу же приходит на ум распределение вычислительных заданий как полезная оптимизация.

Вот вопросы, на которые я не могу ответить прямо сейчас, любая помощь будет принята с благодарностью:

  • Можно ли действительно применить концепцию MapReduce к анализу веб-блогов?
  • Является ли MapReduce самым умным способом сделать это?
  • Как бы вы разделили файлы веб-журнала между различными вычислительными экземплярами?

Спасибо.
Николай


mapreduce distributed logfile-analysis
person Nicolas    schedule 02.06.2009    source источник

Ответы (2)


arrow_upward
16
arrow_downward

Можно ли действительно применить концепцию MapReduce к анализу веб-блогов?

да.

Вы можете разбить файл журнала hudge на куски, скажем, по 10 000 или 1 000 000 строк (независимо от того, что является хорошим фрагментом для вашего типа файла журнала - для файлов журнала Apache я бы выбрал большее число), передать их некоторым преобразователям, которые извлекут что-то конкретное ( например Браузер, IP-адрес, ..., Имя пользователя, ... ) из каждой строки журнала, затем уменьшите, подсчитав количество раз, когда каждый из них появлялся (упрощенно):

  192.168.1.1,FireFox x.x,username1
  192.168.1.1,FireFox x.x,username1
  192.168.1.2,FireFox y.y,username1
  192.168.1.7,IE 7.0,username1

Вы можете извлечь браузеры, игнорируя версию, используя операцию карты, чтобы получить этот список:

FireFox
FireFox
FireFox
IE

Затем уменьшите, чтобы получить это: FireFox,3 IE,1

Является ли MapReduce самым умным способом сделать это?

Это умно, но вам нужно быть очень большим, чтобы получить какую-либо выгоду... Разделение ПЕТАБАЙТОВ журналов.

Для этого я бы предпочел использовать очереди сообщений и согласованный механизм хранения (например, базу данных) с обрабатывающими клиентами, которые извлекают работу из очередей, выполняют задание и помещают результаты в другую очередь, а задания не выполняется в определенный период времени, доступный для обработки другими. Эти клиенты будут небольшими программами, которые делают что-то конкретное.

Вы можете начать с 1 клиента и расширить до 1000... У вас может быть даже клиент, который работает как заставка на всех компьютерах в локальной сети, и запускать 8 клиентов на ваших 8-ядерных серверах, 2 на ваших двухъядерных ПК. ...

С Pull: у вас может работать 100 или 10 клиентов, на многоядерных машинах может работать несколько клиентов, и все, что завершит клиент, будет доступно для следующего шага. И вам не нужно выполнять какое-либо хэширование или присваивание для выполнения работы. Это 100% динамика.

http://img355.imageshack.us/img355/7355/mqlogs.png

Как бы вы разделили файлы веб-журнала между различными вычислительными экземплярами?

По количеству элементов или строк, если это текстовый файл журнала.

Чтобы протестировать MapReduce, я хотел бы предложить вам поиграть с Hadoop.

person Osama Al-Maadeed    schedule 02.06.2009
comment
Прежде всего, извините за задержку. Большое спасибо за ваш очень качественный ответ. Это очень помогает! - person Nicolas; 11.06.2009
comment
В качестве альтернативы разделению файлов журнала вы можете распараллелить сценарий анализа журнала на n ядрах. И если вы запустите этот скрипт на виртуализированном кластере (скажем, 96 ядер), ваш код будет работать безупречно без каких-либо изменений. Вам необходимо определить и изолировать наименьшую единицу работы, не имеющую побочных эффектов и работающую с неизменяемыми данными. Возможно, это потребует от вас перепроектирования кода. Кроме того, Hadoop сравнительно сложнее настроить (и там, где я живу, труднее найти специалистов). - person Imran.Fanaswala; 11.04.2010

arrow_upward
1
arrow_downward

  • Можно ли действительно применить концепцию MapReduce к анализу блогов?

Конечно. Какие данные вы храните?

  • Является ли MapReduce самым умным способом сделать это?

Это позволит вам одновременно запрашивать множество обычных машин, так что да, это может быть полезно. В качестве альтернативы вы можете попробовать сегментирование.

  • Как бы вы разделили файлы веб-журнала между различными вычислительными экземплярами?

Как правило, вы распространяете свои данные, используя алгоритм последовательного хеширования, поэтому позже вы можете легко добавить больше экземпляров. . Вы должны хешировать то, что будет вашим первичным ключом в обычной базе данных. Это может быть идентификатор пользователя, IP-адрес, реферер, страница, реклама; какой бы ни была тема вашего ведения журнала.

person Nick Retallack    schedule 02.06.2009
comment
Здесь вы найдете отличное объяснение последовательного хеширования: michaelnielsen.org/blog/?p=613 - person tuinstoel; 24.07.2009