Dağıtılmış coğrafi işlem için bir mimari var mı?


24

LAN'ımda 50 bilgisayar bulunduğunu varsayalım. Her bilgisayarın ABD'deki belirli bir eyaletteki tüm parsel çokgenleri için bir coğrafi veritabanı vardır.

Ben üzerinden değerli tüm parsellerin bulan bir coğrafi işlem görevi yazmak istiyorum x içindedir $ / dönümlük y az değerinde başka parselin ayakları z $ / dönüm.

Verilerin 50 bilgisayara dağıtıldığını bilmeden veya önemsemeden bu sorguyu formüle etmek ve çalıştırmak istiyorum. Sınır koşullarını aklınızda bulundurun: Sorgunun bir eyalette pahalı olan parsellerin diğerinde ucuz olan parsellere yakın olduğu durumları döndürmesini istiyorum.

Bu tür dağıtılmış coğrafi işlemeyi destekleyen bir mimari var mı?

Mimari soyut olarak veya Azure veya Amazon Web Hizmetlerine özgü bir uygulama olarak tanımlanabilir. Veya, tercihen, bilgisayarların geceleri boş ArcGIS masaüstü lisanslarıyla boşta durduğu tipik bir ofis olarak.


1
Güzel soru. Bu özel örnekte, bina ve otomatik bir dörtlü gibi bir mekansal veri yapısının kullanımı paralelleştirmek için bir yol gerekir. Bunu yapmazsanız ve bunun yerine sadece 50 bilgisayar üzerinde kaba kuvvet arama dağıtırsanız, sorguyu hızlandırmak yerine yavaşlatabilirsiniz. Bunun gibi bir genel mimarinin henüz var olmadığından eminim, bu nedenle ilk önce ne tür sorguların dağıtılmış işlemden yararlanabileceğini düşünerek ve daha sonra ihtiyaç duydukları mimarileri araştırarak daha iyi şanslara sahip olabilirsiniz. Belki bu soruyu TCS sitesine gönderebilirsin?
whuber

@whuber Teşekkürler, TCS sitesi nedir?
Kirk Kuykendall

@Kirk şifreli olduğu için özür dilerim - Tembeldim. cstheory.stackexchange.com
whuber

1
temel CS teorisi muhtemelen CS adamları nadiren mekansal olurken yardımcı olmaz :-)
Ian Turton

1
@iant Dışarıda dağıtılmış hesaplamanın somunları ve cıvataları hakkında çok fazla şey bilecek çok fazla GIS çalışanı yok (bu sitenin üyelerine istisnai durumdakiler için hiçbir belirsizlik yapmadım). TCS insanlarının , mimarlığın varlığıyla ilgili orijinal soruya cevap verecek bilgiye sahip olacağına inanıyorum . Tek endişem, soruyu ilginç bulup bulmayacakları! Bence onlar doğru yolu koyarsa. (Örneğin, bir veri yapıları açısından yeniden
canlandırabilir

Yanıtlar:


13
  1. tüm parsellerinizi merkezi bir veritabanında saklayın
  2. ABD’de bir ızgarayı formüle ederek, bir taraftaki N feet karelerden oluştu; N, N içerisine sığacak parsel sayısının düğümlerinizin birindeki hafızayı boşaltmayacağı şekilde
  3. Veritabanınızda grid kare başına bir satır, bir id sütunu, bir geometri sütunu ve bir durum sütunu içeren bir tablo oluşturun
  4. Her düğüm küçük bir program çalıştırır.
    1. bir sonraki işlenmemiş kareyi bulmak
    2. süreç içi olarak işaretler
    3. tüm parselleri ST_DWithin ile çeker (kare, parsel, maxfeet)
    4. gerçek sorgu mu
    5. Sorgu cevabını merkezi veritabanındaki bir çözüm tablosuna yazar.
    6. kareyi tam olarak işaretler
    7. 1’e geri dön

Kesin başarısızlık durumu, parsel sorgusundaki ilgi yarıçapınız, veri kümenizin büyük bölümlerinin her parselle eşleşebilecek potansiyel adaylar olacağı kadar büyür.


Teşekkürler Paul, diğer düğümler için koordinatör olarak görev yapan bir düğüme ihtiyacım olur mu?
Kirk Kuykendall

Veri tabanı, sıranın durumunu elinde tutması nedeniyle açık bir "koordinatör" olarak işlev görür, ancak düğümlerin başlatılmadan ve veritabanında işaret edilmekten öteye koordine edilmesi gerekmez. Bunun bir cevap olup olmadığından emin değilim.
Paul Ramsey

7

Eylül ayında Barselona’da FOSS4G’de bu konuda ilginç bir konu vardı: http://2010.foss4g.org/presentations_show.php?id=3584

Bir sunumdan çok bir panel tartışması haline geldi.

Bu blog yazısının ortasında Paul Ramsey bundan bir tür özet veriyor.


Bu umut verici görünüyor, sunumları herhangi bir yere gönderdiler mi?
Kirk Kuykendall

Eh, Schuyler Erle planlanan sunumu desteklemek yerine panel tartışmaları için moderatör haline geldiğinden, bu konuda daha fazla bilgi olacağını sanmıyorum. Ancak Erle bu sunumu planladığından beri muhtemelen biraz bilgi sahibi. Google'da arama yaparsanız her yerdedir. Doğrudan ona sormak bir fikir olabilir. Bilmiyorum. Tartışmaların çoğu benim anlayışımın üstündeydi, bu yüzden Paul'un blogunda olduğundan daha iyi bir özgeçmiş veremem.
Nicklas Avén

4

Belki de esri tanıtım kâğıtlarındaki "Uygulama Serilerinde ArcGIS Sunucusu: Büyük Toplu Kodlama" adlı beyaz kağıda bakınız .

Bu coğrafi kodlama ile ilgilidir, ancak asenkronize bir coğrafi işlem hizmeti kullanma genel süreci sizin durumunuz için geçerli olabilir.


İyi görünüyor, bunun diğer coğrafi işlem biçimlerine genelleştirilip genelleştirilemeyeceğini merak ediyorum. Yine de veri kümelerim arasında örtüşmem gerek gibi görünüyor.
Kirk Kuykendall

3

Bu sorunla ilgilenmesi gereken ilk şey, nerede ve ne zaman hangi verilere ihtiyaç duyulduğudur. Bunu yapmak için genellikle problemin aptal, seri versiyonuyla başlarım.

Z $ / acre değerinden daha düşük değere sahip başka bir parselin bir metre karesinde bulunan x $ / acre değerinde olan tüm parselleri bulun.

foreach p in parcels {
  if value(p) > x {
    foreach q in parcels {
      if (dist(p,q) <= y) and (value(q) < z) {
        emit(p)
      }
    }
  }
}

Bu algoritma optimize edilmemiş olsa da problemi çözecektir.

Bir veri setindeki her nokta için en yakın paketi bulan yüksek lisans tezi için de benzer bir sorunu çözdüm. Ben de çözümünü uygulamaya PostGIS , Hadoop'un ve MPI . Tezimin tam sürümü burada , ancak bu soruna uygulanan önemli noktaları özetleyeceğim.

MapReduce bu problemi çözmek için iyi bir platform değil çünkü günah paketini işlemek için tüm veri setine (veya dikkatlice seçilmiş bir altküme) erişim gerektiriyor. MapReduce ikincil veri kümelerini iyi işlemez.

Ancak, MPI bunu oldukça kolay bir şekilde çözebilir. En zor kısım, verilerin nasıl bölüneceğini belirlemektir. Bu bölme, ne kadar veri bulunduğuna, kaç tane işlemci kullanmanız gerektiğine ve işlemci başına ne kadar belleğe sahip olduğunuza dayanır. En iyi ölçeklendirme (ve dolayısıyla performans) için, parsel veri setinin bellekte (tüm bilgisayarlarınızda) birden fazla kopyasının aynı anda olması gerekir.

Bunun nasıl çalıştığını açıklamak için, 50 bilgisayarınızın her birinin 8 işlemcisi olduğunu varsayacağım. Daha sonra her bir bilgisayara parsellerin 1 / 50'sini kontrol etme sorumluluğu vereceğim. Bu kontrol, her biri parsellerin aynı 1 / 50'sinin ve parsel veri setinin 1 / 8'inin birer kopyasına sahip olan bilgisayarda 8 işlemle gerçekleştirilecektir. Grupların tek bir makine ile sınırlı olmadığını, makine sınırlarını geçebileceğini lütfen unutmayın.

İşlem, algoritmayı çalıştıracak ve 1/50 nci parseller için p parselleri ve 1 / 8'inci parsellerin q için parsellerini alacaktır. İç döngüden sonra, aynı bilgisayardaki tüm işlemler parselin yayınlanıp yayınlanmayacağını belirlemek için birlikte konuşacaktır.

Benim sorunumda buna benzer bir algoritma kullandım. Kaynağı burada bulabilirsiniz .

Bu tür optimize edilmemiş algoritmalarla bile, programcı zamanı için son derece optimize edilmiş etkileyici sonuçlar elde ettim (aptal basit bir algoritma yazabildiğim ve hesaplama hala yeterince hızlı olacağı için). Optimize etmek için bir sonraki nokta (gerçekten ihtiyacınız varsa), her bir işlem için ikinci veri setinin dörtlü bir dizinini (q'dan nereden alacağınız) ayarlamaktır.


Asıl soruya cevap vermek için. Bir mimarisi var: MPI + GEOS. ClusterGIS uygulamamdan biraz yardım alın ve çok şey yapılabilir. Tüm bu yazılımlar açık kaynaklı olarak bulunabilir, bu nedenle lisans ücreti alınmaz. Linux üzerinde çalıştığım için Windows'un ne kadar taşınabilir olduğundan (belki Cygwin ile) emin değilim. Bu çözüm EC2, Rackspace veya mevcut olan bulutlara dağıtılabilir. Geliştirdiğimde bir Üniversitede özel bir bilgi işlem kümesi kullanıyordum.


2

Eski okul paralel programlama metodolojisi, sadece bir işlemciyi + her bir işlemciye dokunan parselleri depolamak , sonra paralelleştirmek utanç verici derecede kolaydır. Ancak ABD eyaletlerinin boyutlarındaki değişiklik göz önüne alındığında, ülkeyi ızgara hücrelerine bölerek (yine parsellerin dokunaklı haliyle) ve her bir ızgara hücresini bir ana köle yapılandırması kullanarak işlemcilere göndererek daha iyi performans elde edersiniz.


Dokunan parseller yerine, yakın mesafedeki parsellere ihtiyacım var.
Kirk Kuykendall

Y'nin az sayıdaki parselden önemli ölçüde daha büyük olmadığı için daha küçük olduğunu varsayıyorum. Eğer bir devletin büyük bir kesriyse, muhtemelen hesaplamaları yapmak için rasgele bir ızgara kullanmak en iyisidir.
Ian Turton

2

Appistry'ye bir bakış atmak isteyebilirsiniz . Mevcut uygulamaların özel bulut altyapılarına geçirilmesini mümkün kılıyor. Benzer bir amaç için başka projeler olabilir: her uygulama için tekrar tekrar tekrar bulmak ve görevleri paralel işleme dağıtmak ve bunu otomatik olarak yapan bir kütüphane veya platform yapmak için çok karmaşık bir somunu bulmak yerine.


Teşekkürler Matt, bu umut verici görünüyor. Googling Bu sunumu FedUC 2008'den buldum ilerlemelerde.esri.com/library/userconf/feduc08/papers/… O zamandan beri neler yaptıkları hakkında bir güncelleme görmek isterim.
Kirk Kuykendall

2

Bu tür bir problem için, bir harita / küçültme çerçevesi kullanırdım. "Ham" Appistry çerçevesi, buna yakın olan "utanç verici paralel" problemler için mükemmeldir. Kenar şartları buna izin vermiyor. Harita / Azaltma (Google, dağıtılmış hesaplamaya yaklaşım) bu tür bir sorun için mükemmeldir.

Appistry’de 08 yazıdan bu yana yaşanan en büyük gelişme, CloudIQ Storage ürününün piyasaya sürülmesidir. Bu, yerel sunucularınızdaki diskleri kullanan "s3" benzeri bir depolama tesisi sağlar. Ardından, CloudIQ Engine ürünü yüksek hacimli hizmetler sunabilir veya her çeşit dağınık / toplanabilen stil uygulamalarını sağlayabilir (ESRI çalışma zamanı ve diğer açık kaynaklı kitaplıkları kullanarak ölçeklenebilirliği kanıtladık). Dosya tabanlı veriler üzerinde çalışıyorsanız, CloudIQ Storage kullanarak dağıtın ve işlem işlerini yerel dosya kopyalarına yönlendirin, böylece ağ üzerinde hareket etmeleri gerekmez. (yani her düğüm tüm verilere ihtiyaç duymaz)

Harita / Azaltma için, CloudIQ Storage'da Hadoop (açık kaynaklı M / R çerçevesi) gibi bir şey katmanlandırabilirsiniz. Açıklandığı gibi problem için Hadoop'a bakardım, ama gerçekten dalmanız gerekiyor, başlamak kolay değil ve M / R bir beyin bükücü. Cloudera tarafından sunulan ticari olarak desteklenen bir dağıtım da vardır. Dağıtım ve yönetim için Hadoop'a (Cloudera veya başka bir şekilde) güzel bir tamamlayıcı olan başka bir Appistry ürünü CloudIQ Manger var.

Hadoop (M / R ve HDFS dosya sistemi) ile başlardım ve daha ticari olarak desteklenen ölçeklenebilir bir çözüme ihtiyacınız varsa, Cloudera Hadoop dağıtımıyla birlikte Appistry CloudIQ Manager ve Storage'a bakın.

"Utanç verici derecede paralel" görevler için daha basit bir mimari istiyorsanız, CloudIQ Motoru'na da bakın. (Kirk'ün referans aldığı belgede belirtilen yaklaşımlar hala geçerlidir)


Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.