Metody optymalizacji przetwarzania wielu wyników w ArcGIS

12

Interesuję się metodami uczenia się, aby w pełni wykorzystać moc przetwarzania wielordzeniowego dostępnego na komputerze stacjonarnym. Arc stwierdza, że ​​geoprzetwarzanie w tle pozwala użytkownikowi na wykorzystanie wielu rdzeni, jednak zadania zasadniczo muszą czekać w kolejce na zakończenie poprzedniego zadania.

Czy ktoś opracował równoległe lub wielowątkowe metody geoprzetwarzania w Arc / Python? Czy są jakieś wąskie gardła sprzętowe, które uniemożliwiają przetwarzanie wielordzeniowe przy poszczególnych zadaniach?

Znalazłem interesujący przykład w Stackoverflow, który wzbudził moje zainteresowanie, chociaż nie jest to przykład geoprzetwarzania:

from multiprocessing import Pool
import numpy

numToFactor = 976

def isFactor(x):
    result = None
    div = (numToFactor / x)
    if div*x == numToFactor:
        result = (x,div)
    return result

if __name__ == '__main__':
    pool = Pool(processes=4)
    possibleFactors = range(1,int(numpy.floor(numpy.sqrt(numToFactor)))+1)
    print 'Checking ', possibleFactors
    result = pool.map(isFactor, possibleFactors)
    cleaned = [x for x in result if not x is None]
    print 'Factors are', cleaned
Aaron
źródło
1
Z mojego doświadczenia Arc wynika, że ​​prawie zawsze sprowadza się to albo do 1) podzielenia twoich danych na {porcje} części, przetwarzanie i ponowny montaż lub 2) wczytania wszystkiego do pamięci i umożliwienia x API obsługi wątkowania. zwróć uwagę, że this is not meant to discourage.
valveLondon
Dzięki zawór Londyn. Być może nowsza technologia Ivy Bridge i procesor graficzny Kepler pozwolą na bardziej wyrafinowane metody przetwarzania.
Aaron
Oto link do przydatnego bloga na temat wieloprocesowego przetwarzania w języku Python od inżyniera produktu w zespole ds. Analizy i geoprzetwarzania ESRI. blogs.esri.com/esri/arcgis/2011/08/29/multiprocessing
Aaron

Odpowiedzi:

11

Z mojego doświadczenia wynika, że ​​największym problemem jest zarządzanie stabilnością. Jeśli wykonasz sześć tygodni przetwarzania w ciągu jednej nocy, będziesz mieć również sześć tygodni niewytłumaczalnych błędów i błędów.

Alternatywnym podejściem jest opracowanie samodzielnych skryptów, które mogą działać niezależnie i nie mogą powodować problemów:

  • Podziel dane na części, które pojedynczy rdzeń może przetworzyć w <20 minut (zadania).
  • Zbuduj samodzielny skrypt Arcpy, który może przetwarzać pojedyncze zadanie i jest tak prosty, jak to tylko możliwe (pracownik).
  • Opracuj mechanizm uruchamiania zadań. Istnieje wiele wcześniej istniejących rozwiązań w języku Python. Alternatywnie możesz stworzyć własny w prostej kolejce.
  • Napisz kod, aby sprawdzić, czy zadania zostały zakończone. Może to być tak proste, jak sprawdzenie, czy plik wyjściowy został zapisany.
  • Scal dane z powrotem razem.
Matthew Snape
źródło
1
Przekonałem się, że to podejście, które może obejmować użycie modułu wieloprocesowego, jest dobre - niektóre rozszerzenia, takie jak analityk przestrzenny, nie działają zbyt dobrze, jeśli masz wiele kopii tej samej funkcji działających jednocześnie, więc coś w stylu to, co opisujesz, co pozwala na kontrolowaną przez użytkownika formę kolejkowania (tj. pozwala uniknąć planowania tych zadań w tym samym czasie lub unikanie jednoczesnego korzystania z tej samej geobazy w celu zablokowania plików) będzie najlepsze.
nicksan