Перше, що має хвилювати цю проблему, - які дані потрібні, де і коли. Для цього я зазвичай починаю з дурної, серійної версії проблеми.
Знайдіть усі посилки, оцінені понад x $ / акр, які знаходяться в межах футів іншої посилки, яка оцінюється менше ніж $ 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 не є хорошою платформою для вирішення цієї проблеми, оскільки для обробки посилки з гріха потрібен доступ до всього набору даних (або ретельно вибраного підмножини). 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 або будь-якій іншій хмарі. Коли я його розробив, я використовував спеціалізований обчислювальний кластер в університеті.