分散ジオプロセシングのアーキテクチャはありますか？

LANに50台のコンピューターがあるとします。各コンピューターには、米国の特定の州にあるすべてのパーセルポリゴン用のジオデータベースがあります。

z $ / acre 未満の値を持つ別のパーセルのyフィート以内にあるx $ / acre 以上の値を持つすべてのパーセルを検出するジオプロセシングタスクを作成します。

データが50台のコンピューターに分散されていることを知らず、気にせずに、このクエリを作成して実行したいと思います。境界条件に留意してください。また、ある状態の高価な区画が別の状態の安価な区画に近いケースを返すクエリも必要です。

このような分散ジオプロセシングをサポートするアーキテクチャはありますか？

アーキテクチャは、抽象的に記述することも、AzureまたはAmazon Web Servicesに固有の実装として記述することもできます。または、できれば、豊富なArcGISデスクトップライセンスを使用して、コンピューターが夜間にアイドル状態になる典型的なオフィスとして。

1. すべての区画を1つの中央データベースに保存する
2. 側面にNフィートの正方形で作られた米国上にグリッドを作成します。ここで、Nは、Nに収まる区画の数がノードのいずれかでメモリを消費しないようにするものです。
3. グリッドの正方形ごとに1行、id列、geometry列、およびstatus列を持つデータベースにテーブルを作成します
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：Large Batch Geocoding」をご覧ください。

これはジオコーディングに関するものですが、非同期ジオプロセシングサービスを使用する一般的なプロセスがケースに適用される場合があります。

この問題で最初に心配するのは、いつどこでどのデータが必要かということです。そうするために、私は通常、問題の馬鹿げたシリアルバージョンから始めます。

x $ /エーカー以上の値を持つすべての区画を、z $ / acre未満の値を持つ別の区画の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のパーセルを取得します。内側のループの後、同じコンピューター上のすべてのプロセスが対話して、小包を放出する必要があるかどうかを判断します。

私の問題のためにこれと同様のアルゴリズムを実装しました。ここでソースを見つけることができます。

この種の最適化されていないアルゴリズムを使用した場合でも、プログラマーの時間に対して高度に最適化された印象的な結果を得ることができました（つまり、愚かな単純なアルゴリズムを記述でき、計算はまだ十分高速です）。（本当に必要な場合）最適化する次のスポットは、各プロセスの2番目のデータセット（qを取得する場所）のクアッドツリーインデックスを設定することです。

元の質問に答えるため。アーキテクチャがあります：MPI + GEOS。ClusterGISの実装から少し助けてください。多くのことができます。このソフトウェアはすべてオープンソースとして入手できるため、ライセンス料はかかりません。linuxで作業していたため、Windowsにどれだけ移植性があるのか​​（Cygwinを使用した場合）わかりません。このソリューションは、EC2、Rackspace、または利用可能なクラウドに展開できます。私が開発したとき、私は大学の専用計算クラスタを使用していました。

古い学校の並列プログラミングの方法論では、各プロセッサに状態+それに触れる区画を保存するだけで、驚くほど簡単に並列化できます。しかし、米国の州の大きさのばらつきを考えると、国をグリッドセルに分割し（ここでも小包の接触するハローで）、マスタースレーブ構成を使用して各グリッドセルをプロセッサに送信することにより、パフォーマンスが向上します。

Appistryを見てみたいと思うかもしれません。既存のアプリケーションをプライベートクラウドインフラストラクチャに移行できるようにすることを目的としています。同様の目的を持つ他のプロジェクトがあるかもしれません：すべてのアプリケーションについて何度も何度もタスクを分解して並列処理に分配するという非常に複雑な要素を見つけ出すのではなく、それを自動的に行うライブラリまたはプラットフォームを作ります。

このタイプの問題には、map / reduceフレームワークを使用します。「生の」Appistryフレームワークは、これに近い「厄介な並列」問題に最適です。エッジ条件は、それを許可しません。Map / Reduce（分散コンピューティングに対するGoogleのアプローチ）は、この種の問題に最適です。

08紙以来のAppistryでの最大の進歩は、CloudIQストレージ製品のリリースです。これにより、ローカルサーバー上のディスクを利用するストレージファシリティのような「s3」が可能になります。次に、CloudIQエンジン製品は、大量のサービスやあらゆる種類のスキャッター/ギャザースタイルのアプリケーションを有効にできます（ESRIランタイムと他のオープンソースライブラリを使用してスケーラビリティを実証しました）。ファイルベースのデータを操作している場合は、CloudIQストレージを使用してデータを配布し、処理ジョブをローカルファイルのレプリカにルーティングして、ネットワーク上で移動する必要がないようにします。（したがって、すべてのノードがすべてのデータを必要とするわけではありません）

Map / Reduceの場合、Hadoop（オープンソースM / Rフレームワーク）のようなものをCloudIQストレージにレイヤー化できます。説明したように、問題についてHadoopを調べますが、実際に飛び込む必要があります。始めるのは簡単ではなく、M / Rは脳のベンダーです。Clouderaが提供する商業的にサポートされているディストリビューションもあります。別のAppistry製品であるCloudIQ Mangerがあります。これは、配布と管理のためのHadoop（Clouderaなど）を補完するものです。

私はHadoop（M / RおよびHDFSファイルシステム）から始めます。より商業的にサポートされたスケーラブルなソリューションが必要な場合は、Cloudera HadoopディストリビューションとともにAppistry CloudIQ ManagerおよびStorageをご覧ください。

「厄介な並列」タスクのためのよりシンプルなアーキテクチャが必要な場合は、CloudIQ Engineもご覧ください。（参照されているカークの論文で概説されているアプローチはまだ有効です）

OGSA-DQPをご覧ください。「DQPでは、単一のデータベースに複数のテーブルがあるかのように、SQLを使用して複数の分散リレーショナルデータベースのテーブルを照会できます」 http://ogsa-dai.sourceforge.net/documentation/ogsadai4.0/ogsadai4.0- axis / DQPOverview.html