Автор: Curt Monash
Дата публикации оригинала: 2008-08-26
Перевод: Олег Кузьменко
Источник: Блог Курта Монаша

Как Greenplum, так и Aster Data только что объявили о том, что модель MapReduce была интегрирована в их MPP-системы хранилищ данных. Так почему я считаю, что это очень важное событие? Вот короткий ответ: «Да потому, что использование MapReduce приводит к гигантскому выигрышу в производительности в тех областях применения аналитических приложений, которые все еще нуждаются в улучшении производительности». Длинный ответ звучит вот так.

Основные идеи MapReduce таковы:

  • Для больших задач параллельная обработка наиболее эффективна с точки зрения затрат и/или является наиболее подходящей, чем все другие альтернативы
  • Если вам удается «втиснуть» программы в некоторую очень простую модель, а именно, в такую, в которой вы ограничены наличием только шагов map и reduce, то нетрудно построить универсальный «движок», который предоставляет параллелизм «задаром»
  • При помощи такой модели можно решить гораздо больше задач, чем можно было бы ожидать на первый взгляд

По существу, вы можете сделать все, что угодно с одной записью* - это шаг map. Но вы сильно ограничены в том, как вы можете объединить информацию о многих (часто промежуточных) записях – это шаг reduce. Тем не менее, шаг reduce позволяет вам выполнять подсчет, суммирование и другие операции агрегирования. Сей факт, вкупе с универсальной мощью шагов map, делает MapReduce полезным, по меньшей мере, для трех важных классов приложений:

  1. Выделение токенов из текста, индексирование и поиск по тексту
  2. Создание других структур данных (например, графов)
  3. Data mining и обучение машин

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

*Формально, MapReduce не допускает использование записей. Вместо этого вы обрабатываете пары «ключ-значение» и их списки. Но, насколько я могу сказать, между ними нет никакой разницы. LISP давно показал, что списки являются универсальной конструкцией.

MapReduce может быть лучшим средством, чем чистый SQL для этих прикладных областей, потому в них создаются такие структуры данных, которые трудно подогнать под парадигму «строки-и-таблицы» языка SQL. Текстовые индексы, построенные на основе инвертированного списка, просто не являются таблицами. Графы всегда можно представить в виде таблиц; но, тем не менее, если вы захотите пройти по графу через множество ребер, то использование реляционных структур может оказаться проблематичным делом. В data mining могут встречаться задачи, которые задействуют большое количество размерностей и используют сверхразреженные таблицы. И хотя полное извлечение фактов из текста в плоские таблицы работает хорошо, переход от него к практичным, понятным семантическим иерархиям может влечь за собой использование какого-нибудь неэлегантного, состряпанного на скорую руку приема.

Вот недавние линки по поводу MapReduce

Ссылки на статьи Курта по следующим категориям (на английском языке):
Analytic technologies, Data warehousing, MapReduce, Parallelization


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: