Яка новинка у MapReduce?

Кілька років тому MapReduce був визнаний революцією розподіленого програмування. Також були критики, але, за великим рахунком, був захоплений галас. Це навіть запатентоване! [1]

Назва нагадує mapі reduceфункціональне програмування, але коли я читаю (Вікіпедія)

Крок карти: Головний вузол приймає вхід, ділить його на менші підпроблеми та розподіляє їх на робочі вузли. Робочий вузол може зробити це ще раз по черзі, що призводить до багаторівневої структури дерева. Робочий вузол обробляє меншу проблему і передає відповідь на свій головний вузол.

Крок зменшення: головний вузол потім збирає відповіді на всі підпроблеми та певним чином поєднує їх, щоб сформувати вихід - відповідь на проблему, яку спочатку намагалися вирішити.

або [2]

Внутрішня карта MAP: [...] MAP розбиває вхідне значення на слова. [...] MAP призначений для асоціації кожної заданої пари клавіш / значень вхідних даних з потенційно багатьма парами проміжних клавіш / значень.

Внутрішнє зменшення: [...] [ЗНИЖЕННЯ] виконує імперативну агрегацію (скажімо, зменшення): прийняти багато значень і зменшити їх до одного значення.

Я не можу не подумати: це розділення та підкорення (у сенсі Мергесорта), просто і просто! Отже, чи є десь (концептуальна) новинка у MapReduce чи це лише нова реалізація старих ідей, корисних у певних сценаріях?

1. Патент США 7 653 311: "Система та метод ефективної широкомасштабної обробки даних" (2010)
2. Модель програмування MapReduce від Google - Переглянуто Р. Леммелем (2007)

Я не можу не подумати: це ділити і перемогти, просто і просто!

M / R не ділиться і перемагає. Це не передбачає багаторазового застосування алгоритму до меншої підмножини попереднього вводу. Це конвеєр (функція, визначена як композиція з більш простих функцій), де стадії трубопроводу чергуються з картою та зменшують операції. На різних етапах можна виконувати різні операції.

Отже, чи є десь (концептуальна) новинка у MapReduce чи це лише нова реалізація старих ідей, корисних у певних сценаріях?

MapReduce не зламає нової основи в теорії обчислення - він не показує нового способу розкладання задачі на більш прості операції. Це показує, що конкретні простіші операції практичні для певного класу проблем.

У MapReduce газети внесок був

1. оцінювання конвеєра двох добре зрозумілих ортогональних операторів, які можуть бути розподілені ефективно та відмовно в залежності від конкретної проблеми: створення текстового покажчика великого корпусу
2. порівняльну карту - зменшіть цю проблему, щоб показати, скільки даних передається між вузлами та як різниці затримок на етапах впливають на загальну затримку
3. показує, як зробити систему відмовою, щоб відмови машини під час обчислення можна компенсувати автоматично
4. визначення конкретних корисних варіантів реалізації та оптимізації

Деякі критичні питання відносяться до цих класів:

1. "Карта / зменшення не порушує нову основу в теорії обчислення." Правда. Оригінальний вклад статті полягав у тому, що ці добре зрозумілі оператори з певним набором оптимізацій були успішно використані для вирішення реальних проблем легше та вірогідніше, ніж разові рішення.
2. "Це розподілене обчислення не легко розкладається на операції з картою та зменшенням". Досить справедливо, але багато хто робить.
3. "Трубопровід з n карти / зменшення етапів вимагає затримки, пропорційної кількості ступенів скорочення трубопроводу до отримання будь-яких результатів." Напевно, правда. Оператор скорочення повинен отримати весь свій внесок, перш ніж він зможе отримати повний вихід.
4. "Карта / зменшення є надмірною для цього випадку використання." Може бути. Коли інженери знаходять новий блискучий молоток, вони прагнуть шукати все, що схоже на цвях. Це не означає, що молоток не є добре виготовленим інструментом для певної ніші.
5. "Карта / зменшення є поганою заміною реляційної БД." Правда. Якщо реляційний БД масштабує ваш набір даних, то чудовий для вас - у вас є варіанти.

EDIT (березень 2014 р.) Я повинен сказати, що з тих пір я більше працював над алгоритмами для обчислень моделей типу MapReduce, і мені здається, що я надмірно негативний. Техніка Divide-Compress-Conquer, про яку я розповідаю нижче, напрочуд універсальна, і може стати основою алгоритмів, які я вважаю нетривіальними та цікавими.

Дозвольте запропонувати відповідь, яка буде значно поступатися Майку за масштабністю, але з точки зору обчислення / алгоритмічної теорії.

$O(n^\epsilon)$$o(\log n)$

$O(1)$

• Розділіть проблемний примірник (часто випадковим чином)
• Зробіть кілька обчислень на кожному розділі паралельно і представляйте результат обчислення компактно
• Об'єднайте всі компактно представлені рішення підпроблем на одному процесорі і закінчіть обчислення там

$n$$O(\sqrt{n})$$\sqrt{n}$

Тепер я думаю, що це насправді цікавий поворот на поділ і підкорення. Поворот полягає в тому, що після етапу розділення вам потрібно стиснути рішення підпроблем, щоб один процесор міг перемогти. Однак, справді, здається, це єдина методика, яку ми придумали поки що. Він не вдається при проблемах із розрідженими графіками, як, наприклад, розріджене підключення. Порівнюйте це з потоковою моделлю, яка призвела до безлічі нових ідей, як-от геніальний алгоритм вибірки Флайолета та Мартіна, алгоритм детермінованого сполучення Місри та Гріса, потужність простих ескізних методів тощо.

Як парадигма програмування, зменшення карт було дуже успішним. Мої коментарі розглядають зменшення карти як цікаву модель обчислення. Хороші теоретичні моделі трохи дивні. Якщо вони слідують дійсності занадто уважно, вони є непростими, але що ще важливіше (запозичити термін з машинного навчання) теореми, доведені для моделей, які є надто специфічними, не узагальнюють, тобто не містять інших моделей. Ось чому ми хочемо абстрагувати якомога більше деталей, залишаючи при цьому достатньо, щоб викликати нові алгоритми. Нарешті, ці нові ідеї повинні мати можливість врешті знайти свій шлях до реального світу. PRAM - це одна нереальна модель, яка призводила до цікавих ідей, але ці ідеї виявлялися рідко застосовними до паралельних обчислень реального світу. З іншого боку, трансляція також нереальна, але це надихнуло алгоритмічні ідеї, які фактично використовуються в реальному світі. Побачитиескіз кол-хв . Методи ескізів фактично також використовуються в системах, заснованих на зменшенні карт.

Я повністю з вами згоден. З концептуальної точки зору, насправді немає нічого нового: Map / Reduce спочатку було відоме в Parallel Computing як модель програмування потоку даних. Однак, з практичної точки зору, Map / Reduce, як було запропоновано Google, і з подальшими реалізаціями з відкритим кодом, також розширило хмарні обчислення і тепер є досить популярним для дуже простих паралельних розкладу та обробки. Звичайно, він не підходить ні для чого іншого, що вимагає складних доменних чи функціональних розкладок.

Я думаю, що ти своїм коментарем вдарив цвях по голові.

Неправда, що в будь-якій функціональній мові карти можна паралелізувати - мова повинна бути чистою . (Я вважаю, що Haskell є єдиною розпливчастою основною чисто функціональною мовою. Lisp, OCaml і Scala - все це не чисто.)

Про переваги чистого коду ми знаємо ще з часів дочасного обміну, коли інженери вперше конвеювали свої процесори. То як же ніхто не використовує чистої мови?

Це справді, справді, дуже важко. Програмування чистою мовою часто відчуває себе програмуванням обома руками, зав'язаними за спиною.

Що робить MR, це дещо послабити обмеження чистоти та створити рамки для інших творів (як-от фаза перетасовки), що полегшує написання розподільного коду для великої частки проблем.

$NC=P$