Lo primero que debe preocuparse con este problema es qué datos se necesitan dónde y cuándo. Para hacerlo, generalmente comienzo con la estúpida versión en serie del problema.
Encuentre todas las parcelas valoradas en x $ / acre que estén dentro de y pies de otra parcela valorada en menos de 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)
}
}
}
}
Si bien este algoritmo no está optimizado, resolverá el problema.
Resolví un problema similar para mi tesis de maestría que encontró el paquete más cercano para cada punto en un conjunto de datos. Implementé la solución en PostGIS , Hadoop
y MPI . La versión completa de mi tesis está aquí , pero resumiré los puntos importantes que se aplican a este problema.
MapReduce no es una buena plataforma para resolver este problema porque requiere acceso a todo el conjunto de datos (o un subconjunto cuidadosamente seleccionado) para procesar una parcela simple. MapReduce no maneja bien los conjuntos de datos secundarios.
MPI, sin embargo, puede resolver esto bastante fácilmente. La parte más difícil es determinar cómo dividir los datos. Esta división se basa en la cantidad de datos que hay, en cuántos procesadores tiene que ejecutarlos y cuánta memoria tiene por procesador. Para obtener la mejor escala (y, por lo tanto, el rendimiento), necesitará tener múltiples copias del conjunto de datos de las parcelas en la memoria (en todas sus computadoras) a la vez.
Para explicar cómo funciona esto, supondré que cada una de sus 50 computadoras tiene 8 procesadores. Luego asignaré a cada computadora la responsabilidad de verificar 1/50 de los paquetes. Esta verificación será ejecutada por 8 procesos en la computadora, cada uno de los cuales tiene una copia de la misma 1/50 parte de las parcelas y 1/8 del conjunto de datos de la parcela. Tenga en cuenta que los grupos no se limitan a una sola máquina, sino que pueden cruzar los límites de la máquina.
El proceso ejecutará el algoritmo, obteniendo las parcelas para p del 1/50 conjunto de parcelas, y las parcelas para q del 1/8 conjunto. Después del bucle interno, todos los procesos en la misma computadora hablarán juntos para determinar si se debe emitir el paquete.
Implementé un algoritmo similar a este para mi problema. Puedes encontrar la fuente aquí .
Incluso con este tipo de algoritmo no optimizado pude obtener resultados impresionantes que estaban altamente optimizados para el tiempo del programador (lo que significa que podría escribir un algoritmo simple estúpido y el cálculo aún sería lo suficientemente rápido). El siguiente punto para optimizar (si realmente lo necesita), es configurar un índice quadtree del segundo conjunto de datos (de donde obtiene q) para cada proceso.
Para responder la pregunta original. Hay una arquitectura: MPI + GEOS. Agregue un poco de ayuda de mi implementación de ClusterGIS y se puede hacer mucho. Todo este software se puede encontrar como código abierto, por lo que no hay tarifas de licencia. No estoy seguro de lo portátil que es Windows (tal vez con Cygwin) ya que trabajé en Linux. Esta solución se puede implementar en EC2, Rackspace o cualquier nube disponible. Cuando lo desarrollé estaba usando un clúster informático dedicado en una universidad.