ижче математична статистика, а не методи паралельного програмування? Швидше за все, типовий аналітик, якому буде запропоновано приступити до вирішення такого завдання, віддасть перевагу користуватися старими пакетами на своїй робочій станції, що занапастить всю ідею горизонтальній масштабованості. На перший погляд, проблема здається нерозв'язною, так само як нерозв'язною здається і більш загальна проблема забезпечення зручних і ефективних засобів паралельного програмування для програмістів широкого профілю. Нещодавно вдалося знайти підхід і до вирішення цієї проблеми, принаймні першій її частині (тут слід відзначити заслуги розробників паралельних СУБД Greenplum і Asterdata), - це MapReduce.
Технологія MapReduce з'явилася в надрах Google як заміна аналітичним паралельним СУБД для вирішення власних аналітичних завдань компанії. Технологія швидко знайшла популярність в середовищі практиків, але спочатку викликала глибоке обурення в співтоваристві розробників баз даних, авторитетні фахівці якого стверджували, що MapReduce - це повернення до доісторичного часу, коли для вирішення проблем управління даними вимагалося явне програмування, і дорікали прихильників MapReduce в невігластві і нерозумному запереченні результатів минулих років. Швидше за все, ці доводи правильні - MapReduce не може і не повинна замінити технологію баз даних. Але виявилося, що ця технологія може бути надзвичайно корисною, якщо застосувати її всередині самої паралельної аналітичної СУБД для підтримки паралельного програмування і виконання аналітичних функцій, що поставляються користувачами.
MapReduce концептуально незрівнянно простіше, ніж MPI, - програмісту потрібно розуміти тільки одну ідею того, що дані треба спочатку розподілити по вузлах кластера, а потім обробити. Результат обробки можна знову розподілити по вузлах кластера і знову обробити і т. д. Від програмістів додатків потрібно лише забезпечити код двох функцій: map - поділ даних по вузлах кластера і reduce - обробка даних в отриманих розділах. Така парадигма програмування набагато простіше, ніж MPI, але, що важливо, вона понятійно близька аналітикам.
Традиційна аналітика має справу з даними, явно чи неявно представляється у вигляді багатовимірного куба. Перший і, мабуть, революційний крок на шляху до забезпечення аналітичної обробки табличних SQL-орієнтованих даних свого часу забезпечувала робота Джима Грея, який запропонував оператор roll up динамічної побудови багатовимірного куба в реляційній базі даних. Саме Грей, по-перше, зрозумів, що традиційний оператор group by дозволяє отримати грань багатовимірного куба, а загальна процедура побудови багатовимірного куба зводиться до повторного виконання оператора group by доти, поки не буде отримано потрібне число вимірювань. По-друге, Грей першим зрозумів, що для виконання операції roll up потрібно стільки ж зусиль, скільки і для виконання простого group by. Що ж таке тоді аналітика в контексті SQL-орієнтованої СУБД? Грубо кажучи, вона зводиться до застосування різних агрегатних аналітичних функцій до граней куба.
Операцію group by можна було б з успіхом вважати операцією «партіціонірованія» таблиці у відповідності зі значеннями заданого стовпця угруповання, а після цього можна було б легко обробляти отримані групи паралельно. Можна вважати, що функція map в програмі MapReduce - це узагальнений оператор group by, що забезпечує поділ вихідних даних за деякими явно запрограмованим користувачем правилам. ...
