Коммивояжер и карта/уменьшение: отказ от канала

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

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

Один из подходов, который сразу приходит на ум, заключается в том, что у редюсера есть средства для обеспечения обратной связи с картографом. Представьте, если бы у нас было 100 узлов и миллионы путей, переданных им картографом. Если редюсер передает наилучший результат картографу, это значение может быть включено в качестве аргумента вместе с каждым новым путем (подмножество проблемы). В этом подходе степень детализации довольно грубая ... каждый из 100 узлов будет продолжать работать над своим разделом проблемы до завершения и получит новый минимум только со своим следующим запросом от картографа. (Для небольшого числа узлов и огромного количества проблемных разделов/подмножеств работать с такой степенью детализации было бы несущественно; также вполне вероятно, что можно было бы применить эвристику к последовательности, в которой возможные маршруты или подмножества проблем передаются узлам для получить быструю сходимость к оптимуму и, таким образом, свести к минимуму количество «пустых» вычислений, выполняемых узлами).

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

Итак, мои вопросы:

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

person Jim Dennis    schedule 24.05.2011    source источник


Ответы (2)


это крутая тема, по ней не так много литературы, которая была написана по ней раньше. Так что это в значительной степени пост для мозгового штурма, а не ответ на все ваши проблемы;)

Таким образом, каждый TSP может быть представлен в виде графика, похожего на этот: (взято из немецкой Википедии)

График TSP

Теперь вы можете запустить на нем алгоритм графа. MapReduce вполне можно использовать для обработки графов, хотя это требует больших накладных расходов.
Вам нужна парадигма, которая называется "Передача сообщений". Это было описано в этой статье здесь: Документ.
И я написал об этом в блоге с точки зрения исследования графа, там довольно просто рассказывается, как это работает. Мой пост в блоге

Таким образом вы можете сообщить картографу, каков текущий минимальный результат (возможно, только для самой вершины).

Со всеми знаниями в глубине души должно быть довольно стандартно думать о алгоритм ветвей и границ (который вы описали), чтобы добраться до цели. Например, иметь случайную начальную вершину и ветвление к каждой соседней вершине. Это приводит к тому, что каждому из этих смежных узлов отправляется сообщение со стоимостью, с которой они могут быть достигнуты из начальной вершины (шаг карты). Сама вершина обновляет свою стоимость только в том случае, если она ниже текущей сохраненной стоимости (шаг уменьшения). Первоначально это должно быть установлено на бесконечность.
Вы делаете это снова и снова, пока снова не достигнете начальной вершины (очевидно, после того, как вы посетили все остальные вершины). Таким образом, вы должны каким-то образом отслеживать лучший на данный момент способ достижения вершины, это также может быть сохранено в самой вершине. И время от времени вам приходится связывать это ветвление и отрезать ветки, которые слишком затратны, это можно сделать на шаге сокращения после прочтения сообщений. По сути, это просто смесь алгоритмов графа в MapReduce и своего рода кратчайших путей.
Обратите внимание, что это не уступает оптимальному пути между узлами, это все еще эвристика. И вы просто парализуете NP-сложную проблему.

НО снова немного саморекламы, может быть, вы уже читали это в сообщении в блоге, на которое я дал ссылку, существует абстракция для MapReduce, которая имеет гораздо меньшие накладные расходы при таком виде обработки графа. . Он называется BSP (Bulk synchonous parallel). Это более свободно в общении и его вычислительная модель. Поэтому я уверен, что это может быть намного лучше реализовано с помощью BSP, чем MapReduce. С его помощью вы можете лучше реализовать эти каналы, о которых вы говорили.

В настоящее время я участвую в проекте Summer of Code, который нацелен на эти проблемы SSSP с BSP. Может быть, вы хотите посетить, если вам интересно. Тогда это может быть частичным решением, оно также очень хорошо описано в моем блоге. SSSP в моем блоге

Я рад услышать отзывы ;)

person Thomas Jungblut    schedule 24.05.2011

Кажется, Storm реализует то, о чем я думал. По сути, это вычислительная топология (подумайте о том, как каждый вычислительный узел может направлять результаты на основе ключа/функции хэширования в определенные преобразователи).

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

person Jim Dennis    schedule 05.06.2012