Первое, о чем нужно беспокоиться, это то, какие данные нужны, где и когда. Для этого я обычно начинаю с глупой, серийной версии проблемы.
Найти все участки стоимостью более x $ / акр, которые находятся в пределах y футов от другого участка стоимостью менее z $ / акр.
foreach p in parcels {
if value(p) > x {
foreach q in parcels {
if (dist(p,q) <= y) and (value(q) < z) {
emit(p)
}
}
}
}
Хотя этот алгоритм не оптимизирован, он решит проблему.
Я решил аналогичную задачу для своей магистерской диссертации, которая нашла ближайшую посылку для каждой точки в наборе данных. Я реализовал решение в PostGIS , Hadoop
и MPI . Полная версия моей диссертации находится здесь , но я суммирую важные моменты, которые относятся к этой проблеме.
Уменьшение карты не является хорошей платформой для решения этой проблемы, поскольку для обработки одной посылки требуется доступ ко всему набору данных (или тщательно отобранному подмножеству). MapReduce плохо обрабатывает вторичные наборы данных.
MPI, однако, может решить эту проблему довольно легко. Сложнее всего определить, как разделить данные. Это разделение основано на том, сколько данных имеется, сколько процессоров вам нужно для этого и сколько памяти у вас на процессор. Для лучшего масштабирования (и, следовательно, производительности) вам необходимо иметь несколько копий набора данных участков в памяти (на всех ваших компьютерах) одновременно.
Чтобы объяснить, как это работает, я предполагаю, что каждый из ваших 50 компьютеров имеет 8 процессоров. Затем я назначу каждому компьютеру ответственность за проверку 1/50 посылок. Эта проверка будет выполняться 8 процессами на компьютере, каждый из которых имеет копию одной и той же 1/50 части участков и 1/8 набора данных участков. Обратите внимание, что группы не ограничены одной машиной, но могут пересекать границы машины.
Процесс выполнит алгоритм, получив посылки для p из 1/50 набора, а посылки для q из 1/8 набора. После внутреннего цикла все процессы на одном компьютере будут взаимодействовать, чтобы определить, следует ли отправлять посылку.
Я реализовал алгоритм, аналогичный этому для моей проблемы. Вы можете найти источник здесь .
Даже с этим неоптимизированным алгоритмом я смог получить впечатляющие результаты, которые были сильно оптимизированы для программиста (это означало, что я мог бы написать глупый простой алгоритм, и вычисления все равно были бы достаточно быстрыми). Следующее место, которое нужно оптимизировать (если оно вам действительно нужно), - это установить индекс дерева ветвей второго набора данных (откуда вы получаете q) для каждого процесса.
Чтобы ответить на оригинальный вопрос. Есть архитектура: MPI + GEOS. Добавьте небольшую помощь от моей реализации ClusterGIS, и многое можно сделать. Все это программное обеспечение можно найти как открытый исходный код, поэтому никаких лицензионных сборов. Я не уверен, насколько она совместима с Windows (возможно, с Cygwin), так как я работал над ней в Linux. Это решение может быть развернуто в EC2, Rackspace или любом другом доступном облаке. Когда я его разрабатывал, я использовал выделенный вычислительный кластер в университете.