是否有用于分布式地理处理的体系结构？

假设我的局域网上有50台计算机。每台计算机都有一个地理数据库，用于存放美国特定州的所有宗地多边形。

我想编写一个地理处理任务，查找所有价值超过x $ /英亩的地块，该地块在另一个价值小于z $ /英亩的地块的y英尺内。

我想制定和运行此查询，而又不知道或不关心数据分布在50台计算机上。请记住边界条件：我还希望查询返回一种情况，即一种状态下的昂贵包裹接近另一种状态下的廉价包裹。

是否有支持这种分布式地理处理的体系结构？

可以抽象地描述该体系结构，也可以将其描述为Azure或Amazon Web Services的特定实现。或者，最好是作为典型的办公室，在该办公室中，计算机在夜间拥有大量ArcGIS桌面许可证而处于闲置状态。

1. 将所有包裹存储在一个中央数据库中
2. 在一侧用N英尺的正方形制成的美国上绘制网格，其中N使得适合N的地块数量不会耗尽您一个节点上的内存
3. 在数据库中创建一个表格，其中每个网格平方一行，一个id列，一个几何列和一个状态列
4. 每个节点运行一个小程序
   1. 找到下一个未处理的正方形
   2. 将其标记为进行中
   3. 拉出所有地块ST_DWithin（square，parcel，maxfeet）
   4. 进行实际查询
   5. 将查询答案写回到中央数据库中的解决方案表
   6. 将正方形标记为完整
   7. 返回1

显而易见的失败案例是，随着您在宗地查询中的关注半径变得足够大，您的数据集的很大一部分都是与每个宗地匹配的潜在候选者。

9月份在巴塞罗那的FOSS4G上有一个有趣的插槽：http ://2010.foss4g.org/presentations_show.php?id=3584

它变得不仅仅是小组讨论，而是演讲。

在此博客文章的中间，Paul Ramsey 对此做了一些总结。

也许看看esri白皮书上的白皮书“ ArcGIS Server in Practice Series：大批量地理编码” 。

它与地理编码有关，但是使用异步地理处理服务的一般过程可能适用于您的情况。

与该问题有关的第一件事是何时何地需要什么数据。为此，我通常从问题的愚蠢的串行版本开始。

查找所有x大于x $ /英亩的地块，它们与另一个地价小于z $ /英亩的地块y英尺之内。

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的副本。请注意，这些组不仅限于一台计算机，还可以跨越计算机边界。

该过程将执行该算法，从第1/50个宗地集合中获取p的宗地，从第1/8个宗地集合中获取q的宗地。内循环之后，同一台计算机上的所有进程将一起交谈以确定是否应发出包裹。

对于我的问题，我实现了与此类似的算法。您可以在此处找到源。

即使使用这种未优化的算法，我也可以获得令人印象深刻的结果，这些结果针对程序员的时间进行了高度优化（这意味着我可以编写一个愚蠢的简单算法，并且计算仍然足够快）。要优化的下一个位置（如果确实需要）是为每个过程设置第二个数据集（从中获取q）的四叉树索引。

回答原始问题。有一个体系结构：MPI + GEOS。从我的ClusterGIS实施中获得一点帮助，可以做很多事情。所有这些软件都可以作为开源软件找到，因此无需任何许可费用。当我在linux上工作时，我不确定它对Windows的可移植性（也许与Cygwin兼容）。该解决方案可以部署在EC2，Rackspace或任何可用的云上。当我开发它时，我正在大学中使用专用的计算集群。

传统的并行编程方法是只存储一个状态+在每个处理器上触摸过的包裹，然后很容易进行并行化。但是，鉴于美国各州大小的差异，您可以通过将国家划分为多个网格单元（同样具有包裹性的光环），并使用主从配置将每个网格单元发送给处理器，从而获得更好的性能。

您可能想给Appistry看看。它旨在实现将现有应用程序迁移到私有云基础架构。可能还有其他具有类似目标的项目：不是为每个应用程序一遍又一遍地找出将任务分解并分配给并行处理的非常复杂的螺母，而是创建一个自动执行此任务的库或平台。

对于此类问题，我将使用map / reduce框架。“原始” Appistry框架非常适合解决这个“尴尬的并行”问题。边缘条件不允许这样做。Map / Reduce（Google的分布式计算方法）非常适合此类问题。

自从08年论文发表以来，Appistry的最大进步是CloudIQ Storage产品的发布。这样就可以利用本地服务器上的磁盘来实现类似“ s3”的存储功能。然后，CloudIQ Engine产品可以启用任何类型的高容量服务或分散/收集样式的应用程序（我们已经使用ESRI运行时和其他开放源代码库证明了可扩展性）。如果您正在处理基于文件的数据，则可以使用CloudIQ Storage将其分发出去，并将处理作业路由到本地文件副本，这样就不必在网络上四处移动它们。（因此每个节点不需要所有数据）

对于Map / Reduce，您可以在CloudIQ Storage上叠加Hadoop（开源M / R框架）之类的内容。我将针对所述问题查看Hadoop，但您确实需要深入研究，入门起来并不容易，M / R令人费解。Cloudera还提供了商业支持的发行版。还有另外一个Appistry产品CloudIQ Manger，它是Hadoop（Cloudera或其他）的很好的补充，用于分发和管理。

我将从Hadoop（M / R和HDFS文件系统）开始，如果您需要更多商业支持的可伸缩解决方案，请与Apperary CloudIQ Manager和Storage以及Cloudera Hadoop发行版一起查看。

如果您想为“令人尴尬的并行”任务提供更简单的架构，请同时查看CloudIQ Engine。（引用的Kirk论文中概述的方法仍然有效）

看看OGSA-DQP。“ DQP允许使用SQL来查询来自多个分布式关系数据库的表，就像在一个数据库中有多个表一样。” http://ogsa-dai.sourceforge.net/documentation/ogsadai4.0/ogsadai4.0- axis / DQPOverview.html