В будущем при конфигурировании сервера его администратор сможет добавить к обычному стеку серверного ПО, СУБД или инструментарию связующего слоя библиотеку MapReduce. Этот экземпляр MapReduce будет использоваться для анализа данных журнала и быстрого получения некоторых аналитических результатов. Такое заявление сделал на ежегодной технической конференции Usenix исследователь из Калифорнийского университета в Сан-Диего Дионисус Логотетис.

«При таком подходе, анализ выполняется не на выделенных кластерах, а на тех же серверах, на которых ведется журнал. Это позволит отказаться от обходящейся весьма дорого передачи больших объемов данных», — пояснил Логотетис. Описание предлагаемого метода опубликовано в материалах конференции в работе под названием In-situ MapReduce for Log Processing («Использование MapReduce на месте для обработки журналов»).

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

На коммерческих сайтах ведутся журналы, содержащие подробную информацию о посещающих их пользователях. Эти сведения используются, например, для целевой рекламы, мониторинга в целях обеспечения безопасности и при отладке.

Один сервер, на котором работает активно используемый сайт электронной коммерции, в секунду генерирует до 10 Мбайт данных журнала. За день объем этой информации достигает десятков терабайт. В среднем, тысяча серверов, генерирующих 1 Мбайт данных в секунду, за день формируют 86 Тбайт записей. Так, например, журнал Facebook генерирует около 100 Тбайт данных в день.

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

Подход к анализу данных журнала, который можно обозначить как «сначала запись, потом обработка», имеет свои недостатки. Передача данных с серверов требует огромной пропускной способности. «Это очень серьезно загружает сеть», — подчеркнул Логотетис.

Логотетис также обратил внимание, что Facebook игнорирует около 80% данных журнала, даже не пытаясь их анализировать. При предлагаемом им подходе это удастся преодолеть, поскольку в передаче данных необходимости не будет.

При традиционном подходе анализ данных происходит существенно позже их формирования, и это может иметь принципиальное значение при определенном характере данных.

В качестве альтернативы некоторые исследователи предлагают реализовать функции MapReduce на каждом сервере. На нем будет производиться некая первичная обработка, и на централизованный «пункт сбора» понадобится пересылать существенно меньший объем данных. Этот подход получил название in-situ MapReduce ("MapReduce на месте").

«iMR дополняет, а не заменяет традиционные архитектуры на базе кластеров. Он предполагает фильтрацию или преобразование данных журнала либо для немедленного использования, либо перед загрузкой в распределенную систему хранения. .. для последующего анализа» — поясняется в статье.

В iMR должны поддерживаться все API-интерфейсы MapReduce, эта система должна иметь аналогичную MapReduce функциональность, а именно, средства фильтрации данных и агрегирования результатов. Различие может состоять в том, что эта система сможет постоянно производить анализ самых последних данных.

Исследователи создали прототип iMR, использовав программное обеспечение для поддержки интегрированной модели бизнеса, с обслуживанием клиентов через интернет. С помощью iMR пользователь задает диапазон данных, подлежащих анализу в конкретном случае, скажем, все данные, собранные за последние 60 секунд. Пользователь определяет также, как часто результаты формируются и передаются, например, каждые 15 секунд.

Логотетис признал, что ресурсы веб-серверов в значительной степени задействованы для выполнения их прямых задач, то есть предоставления сервисов пользователям. Но iMR может использовать свободные циклы процессора для обработки данных журнала.

Исследователи предложили план, позволяющий найти компромисс между скоростью получения результатов анализа и их полнотой. Если организация хочет получать результаты быстро, каждый сервер может игнорировать определенные записи журнала в периоды пиковых загрузок. Резльтаты при этом останутся достоверными, но будут менее точны. Исчерпывающий анализ всех данных потребует большего времени и больших процессорных ресурсов.

Подход "MapReduce на месте" может и не дать существенного выигрыша организациям, использующим только несколько серверов, но для крупных проектов, таких как поисковые системы,социальные сети или сайты электронной коммерции, он несомненно полезен, считает Логотетис.