La première chose à se préoccuper de ce problème est de savoir quelles données sont nécessaires où et quand. Pour ce faire, je commence généralement par la version série stupide du problème.
Trouvez toutes les parcelles d'une valeur supérieure à x $ / acre qui se trouvent à moins de y pieds d'une autre parcelle d'une valeur inférieure à z $ / acre.
foreach p in parcels {
if value(p) > x {
foreach q in parcels {
if (dist(p,q) <= y) and (value(q) < z) {
emit(p)
}
}
}
}
Bien que cet algorithme ne soit pas optimisé, il résoudra le problème.
J'ai résolu un problème similaire pour ma thèse de maîtrise qui a trouvé la parcelle la plus proche pour chaque point d'un ensemble de données. J'ai implémenté la solution dans PostGIS , Hadoop
et MPI . La version complète de ma thèse est ici , mais je vais résumer les points importants en ce qui concerne ce problème.
MapReduce n'est pas une bonne plate-forme pour résoudre ce problème car il nécessite l'accès à l'ensemble de données (ou à un sous-ensemble soigneusement sélectionné) pour traiter une parcelle unique. MapReduce ne gère pas bien les jeux de données secondaires.
MPI, cependant, peut résoudre ce problème très facilement. La partie la plus difficile consiste à déterminer comment diviser les données. Cette répartition est basée sur la quantité de données, le nombre de processeurs sur lesquels vous devez les exécuter et la quantité de mémoire dont vous disposez par processeur. Pour une meilleure mise à l'échelle (et donc des performances), vous devrez disposer de plusieurs copies du jeu de données de parcelles en mémoire (sur tous vos ordinateurs) à la fois.
Pour expliquer comment cela fonctionne, je suppose que chacun de vos 50 ordinateurs possède 8 processeurs. J'attribuerai ensuite à chaque ordinateur la responsabilité de contrôler 1/50 des colis. Cette vérification sera exécutée par 8 processus sur l'ordinateur, chacun ayant une copie de la même partie 1/50 des colis et 1/8 du jeu de données de colis. Veuillez noter que les groupes ne sont pas limités à une seule machine, mais peuvent traverser les limites des machines.
Le processus exécutera l'algorithme, obtenant les parcelles pour p à partir du 1 / 50e ensemble de parcelles, et les parcelles pour q à partir du 1 / 8e ensemble. Après la boucle interne, tous les processus sur le même ordinateur parleront ensemble pour déterminer si le colis doit être émis.
J'ai implémenté un algorithme similaire à celui-ci pour mon problème. Vous pouvez trouver la source ici .
Même avec ce type d'algorithme non optimisé, j'ai pu obtenir des résultats impressionnants qui étaient hautement optimisés pour le temps du programmeur (ce qui signifie que je pouvais écrire un algorithme simple stupide et que le calcul serait encore assez rapide). Le point suivant à optimiser (si vous en avez vraiment besoin), est de configurer un index quadtree du deuxième ensemble de données (d'où vous obtenez q) pour chaque processus.
Pour répondre à la question d'origine. Il existe une architecture: MPI + GEOS. Ajoutez un peu d'aide de mon implémentation ClusterGIS et beaucoup peut être fait. Tous ces logiciels peuvent être trouvés en open source, donc pas de frais de licence. Je ne sais pas à quel point il est portable pour Windows (peut-être avec Cygwin) car j'ai travaillé dessus sous Linux. Cette solution peut être déployée sur EC2, Rackspace ou tout autre cloud disponible. Quand je l'ai développé, j'utilisais un cluster de calcul dédié dans une université.