분산 지오 프로세싱을위한 아키텍처가 있습니까?

24

LAN에 50 대의 컴퓨터가 있다고 가정합니다. 각 컴퓨터에는 미국의 특정 주에있는 모든 소포 다각형에 대한 지리 데이터베이스가 있습니다.

z $ / acre 미만의 다른 소포의 y 피트 내에있는 x $ / acre 이상의 모든 소포를 찾는 지오 프로세싱 작업을 작성하고 싶습니다 .

데이터가 50 대의 컴퓨터에 분산되어 있는지 알거나 신경 쓰지 않고이 쿼리를 공식화하고 실행하고 싶습니다. 경계 조건을 염두에 두십시오. 또한 한 상태에서 값 비싼 소포가 다른 상태에서는 저렴한 소포에 가까운 경우를 반환하도록 쿼리를 원합니다.

이런 종류의 분산 지오 프로세싱을 지원하는 아키텍처가 있습니까?

아키텍처는 추상적으로 또는 Azure 또는 Amazon Web Services에 특정한 구현으로 설명 될 수 있습니다. 또는 많은 ArcGIS 데스크탑 라이센스로 밤에 컴퓨터가 유휴 상태로있는 일반적인 사무실로 사용하는 것이 좋습니다.

geoprocessing  cloud-gis  amazon-web-services 
— 커크 쿠인 켄달
소스
1
좋은 질문. 이 특정 예제에서는 쿼드 트리와 같은 공간 데이터 구조의 사용과 건물을 자동으로 병렬화하는 방법이 필요합니다. 그렇게하지 않고 50 대의 컴퓨터에 무차별 검색을 배포하면 쿼리 속도를 높이기보다는 실제로 속도를 늦출 수 있습니다. 나는 이와 같은 일반적인 아키텍처가 아직 존재하지 않을 것이라고 확신하므로 먼저 분산 처리로 어떤 종류의 쿼리가 도움이 될지 고려한 다음 필요한 아키텍처를 살펴보면 더 나은 행운을 얻을 수 있습니다. 이 질문을 TCS 사이트에 게시 하시겠습니까?
— whuber
@ whuber 감사합니다. TCS 사이트 란 무엇입니까?
— Kirk Kuykendall
@Kirk는 비밀스러워서 미안하다. 게으르다. cstheory.stackexchange.com
— whuber
1
기본 CS 이론 아마하지 않습니다 도움으로 CS들 드물게 GET 공간 :-)
— 이안 Turton
1
@iant 분산 컴퓨팅의 기본 요소에 대해 많이 알고있는 GIS 직원은 그리 많지 않습니다 (저는이 사이트의 멤버에게는 예외적 인 예외는 없습니다). 나는 TCS 사람들 이 건축의 존재에 관한 원래의 질문에 대답 할 지식을 가질 것이라고 믿는다 . 내 유일한 관심사는 그들이 질문을 흥미롭게 찾을 수 있는지 여부입니다! 나는 그것이 올바른 방법으로 생각한다면 생각합니다. (예, 하나는 데이터 구조의 관점에서 그것을 재구성 수 있습니다.)
— whuber을

답변:

13
  1. 모든 소포를 하나의 중앙 데이터베이스에 저장
  2. 측면에 N 피트의 제곱으로 만들어진 미국에 그리드를 공식화하십시오. 여기서 N은 N 내에 맞는 소포 수가 노드 중 하나의 메모리를 날려 버리지 않습니다.
  3. 그리드 제곱 당 하나의 행, ID 열, 기하학 열 및 상태 열을 사용하여 데이터베이스에 테이블을 만듭니다.
  4. 각 노드는 작은 프로그램을 실행합니다.
    1. 처리되지 않은 다음 사각형을 찾으십시오.
    2. 공정 중으로 표시
    3. 모든 소포를 가져옵니다. ST_DWithin (square, parcel, maxfeet)
    4. 실제 쿼리를 수행
    5. 중앙 데이터베이스의 솔루션 테이블에 쿼리 응답을 다시 씁니다.
    6. 정사각형을 완료로 표시
    7. 1로 돌아 가기

명백한 실패 사례는 소포 쿼리의 관심 반경이 커져 데이터 세트의 많은 부분이 각 소포와 일치 할 수있는 후보가 될 수있을만큼 커집니다.

— 폴 램지
소스
고마워 Paul, 다른 노드의 코디네이터 역할을하는 하나의 노드가 필요합니까?
— Kirk Kuykendall
데이터베이스는 큐의 상태를 유지한다는 점에서 암시 적 "코디네이터"의 역할을하지만, 데이터베이스를 시작하고 가리 키지 않고 노드를 조정할 필요는 없습니다. 그것이 대답인지 확실하지 않습니다.
— Paul Ramsey
7

바르셀로나에서 9 월 FOSS4G에 흥미로운 슬롯이있었습니다 : http://2010.foss4g.org/presentations_show.php?id=3584

프리젠 테이션보다는 패널 토론이되었습니다.

이 블로그 포스트 의 한가운데서 Paul Ramsey는 이에 대한 요약을 제공합니다.

— 니클라스 아벤
소스
유망 해 보이는데 어디에서나 프레젠테이션을 게시 했습니까?
— Kirk Kuykendall
Schuyler Erle은 계획된 발표를 대신하는 대신 패널 토론의 중재자가 되었기 때문에 더 많은 정보가있을 것이라고 생각하지 않습니다. 그러나 Erle이이 프리젠 테이션을 계획 한 이후로 아마도 이에 대한 정보를 가지고있을 것입니다. 구글 검색을하면 그는 어디에나있다. 직접 물어 보는 것이 좋습니다. 모르겠어요 대부분의 토론은 제 이해력보다 높았 기 때문에 Paul이 블로그에서 한 것보다 더 나은 이력서를 줄 수 없었습니다.
— Nicklas Avén
4

esri 백서의 "실습 시리즈의 ArcGIS Server : 대규모 배치 지오 코딩" 백서를 참조하십시오 .

지오 코딩에 관한 것이지만 비동기 지오 프로세싱 서비스를 사용하는 일반적인 프로세스가 귀하의 경우에 적용될 수 있습니다.

좋아 보인다, 이것이 다른 형태의 지오 프로세싱에 일반화 될 수 있을지 궁금하다. 그래도 데이터 세트간에 겹칠 필요가있는 것 같습니다.
— Kirk Kuykendall
3

이 문제와 관련하여 가장 먼저 고려해야 할 것은 언제 어디서 데이터가 필요한지입니다. 그렇게하기 위해, 나는 보통 바보 같은 일련의 문제로 시작한다.

z $ / acre 미만의 다른 소포의 y 피트 내에있는 x $ / acre 이상의 모든 소포를 찾으십시오.

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 구현에서 약간의 도움을 받으면 많은 것을 할 수 있습니다. 이 모든 소프트웨어는 오픈 소스로 제공되므로 라이센스 비용이 없습니다. 리눅스에서 작업했을 때 Windows에 이식성이 있는지 확실하지 않습니다 (Cygwin과 함께). 이 솔루션은 EC2, Rackspace 또는 사용 가능한 모든 클라우드에 배포 할 수 있습니다. 제가 개발했을 때 저는 대학교에서 전용 컴퓨팅 클러스터를 사용하고있었습니다.

— 나단 커
소스
2

구식 병렬 프로그래밍 방법론은 상태 와 각 프로세서에 접촉하는 소포를 저장하는 것만으로도 병렬화가 매우 쉽습니다. 그러나 미국 주 규모의 변화에 ​​따라 국가를 그리드 셀로 분할하고 (마지막으로 후광이있는 경우) 마스터 슬레이브 구성을 사용하여 각 그리드 셀을 프로세서로 전송하면 성능이 향상됩니다.

— 이안 터턴
소스
만지는 소포 대신에 y 거리 내의 인접한 주에서 소포가 필요합니다.
— Kirk Kuykendall
나는 Y가 작은 수의 소포보다 크게 크지 않을 정도로 충분히 작다고 가정합니다. 상태의 큰 부분이라면 임의의 그리드를 사용하여 계산하는 것이 가장 좋습니다.
— Ian Turton
2

Appistry 에 모양 을 제공 할 수 있습니다 . 기존 애플리케이션을 프라이빗 클라우드 인프라로 마이그레이션 할 수 있습니다. 비슷한 목적을 가진 다른 프로젝트가있을 수 있습니다. 모든 응용 프로그램에 대해 병렬 처리로 작업을 분류하고 배포하는 매우 복잡한 너트를 반복해서 파악하는 대신 자동으로 수행하는 라이브러리 또는 플랫폼을 만드십시오.

— 매트 윌키
소스
고마워 매트, 유망 해 보인다. 내가 FedUC 2008 년이 프레젠테이션을 발견 인터넷 검색 proceedings.esri.com/library/userconf/feduc08/papers/... 나는 그들이 그 이후로 무슨 짓을했는지에 대한 업데이 트를보고 싶은데요.
— Kirk Kuykendall
2

이 유형의 문제에 대해서는 map / reduce 프레임 워크를 사용합니다. "원시"Appistry 프레임 워크는 "엄청나게 평행 한"문제에 적합합니다. 가장자리 조건으로는 허용되지 않습니다. Map / Reduce (분산 컴퓨팅에 대한 Google의 접근 방식)는 이러한 유형의 문제에서 훌륭합니다.

08 논문 이후 Appistry에서 가장 큰 발전은 CloudIQ 스토리지 제품의 출시입니다. 이를 통해 로컬 서버의 디스크를 활용하는 스토리지 기능과 같은 "s3"이 가능합니다. 그런 다음 CloudIQ Engine 제품은 모든 종류의 대용량 서비스 또는 분산 / 수집 스타일 애플리케이션을 지원할 수 있습니다 (ESRI 런타임 및 기타 오픈 소스 라이브러리를 사용하여 확장 성이 입증되었습니다). 파일 기반 데이터로 작업하는 경우 CloudIQ 스토리지를 사용하여 데이터를 배포하고 처리 작업을 로컬 파일 복제본으로 라우팅하여 네트워크에서 이동할 필요가 없습니다. (따라서 모든 노드에 모든 데이터가 필요한 것은 아닙니다)

Map / Reduce의 경우 CloudIQ 스토리지에서 Hadoop (오픈 소스 M / R 프레임 워크)과 같은 것을 계층화 할 수 있습니다. 설명 된대로 Hadoop을보고 문제를 찾아 보지만 실제로 다이빙을 시작해야하는 것은 쉽지 않으며 M / R은 두뇌 벤더입니다. Cloudera에서 제공하는 상업적으로 지원되는 배포판도 있습니다. 배포 및 관리를 위해 Hadoop (Cloudera 또는 기타)을 보완하는 또 다른 Appistry 제품인 CloudIQ Manger가 있습니다.

하둡 (M / R 및 HDFS 파일 시스템)으로 시작하고,보다 상업적으로 지원되는 확장 가능한 솔루션이 필요한 경우 Cloudera Hadoop 배포와 함께 Appistry CloudIQ Manager 및 스토리지를 살펴보십시오.

"엄청나게 평행 한"작업을위한 더 단순한 아키텍처를 원한다면 CloudIQ 엔진도 살펴보십시오. (Kirk가 참조한 논문에 요약 된 접근 방식은 여전히 ​​유효합니다)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.