Có một kiến ​​trúc cho địa lý phân phối?


24

Giả sử tôi có 50 máy tính trong mạng LAN của mình. Mỗi máy tính có một cơ sở dữ liệu địa lý cho tất cả các đa giác bưu kiện ở một tiểu bang cụ thể ở Hoa Kỳ.

Tôi muốn viết một nhiệm vụ xử lý địa lý tìm thấy tất cả các bưu kiện có giá trị trên x $ / mẫu Anh nằm trong phạm vi y của một bưu kiện khác có giá trị dưới z $ / mẫu.

Tôi muốn xây dựng và chạy truy vấn này mà không biết hoặc quan tâm rằng dữ liệu được phân phối trên 50 máy tính. Hãy ghi nhớ các điều kiện biên: Tôi cũng muốn truy vấn trả về các trường hợp trong đó các bưu kiện đắt tiền ở một tiểu bang gần các bưu kiện rẻ tiền ở một tiểu bang khác.

Có một kiến ​​trúc hỗ trợ loại địa vật lý phân tán này không?

Kiến trúc có thể được mô tả một cách trừu tượng hoặc như một triển khai cụ thể cho Azure hoặc Amazon Web Services. Hoặc, tốt nhất, là một văn phòng điển hình nơi máy tính không hoạt động vào ban đêm với giấy phép máy tính để bàn ArcGIS dồi dào.


1
Câu hỏi hay. Trong ví dụ cụ thể này, bạn cần một cách để tự động song song hóa việc xây dựng và sử dụng cấu trúc dữ liệu không gian, chẳng hạn như một phần tư. Nếu bạn không làm điều đó và thay vào đó chỉ phân phối một tìm kiếm vũ phu trên 50 máy tính, bạn thực sự có thể làm chậm truy vấn hơn là tăng tốc nó. Tôi khá chắc chắn rằng một kiến ​​trúc chung như thế này chưa tồn tại, vì vậy bạn có thể gặp may mắn hơn bằng cách đầu tiên xem xét loại truy vấn nào có thể được hưởng lợi từ xử lý phân tán và sau đó xem xét các kiến ​​trúc mà chúng yêu cầu. Có thể gửi câu hỏi này trên trang web TCS?
whuber

@whuber Cảm ơn, trang TCS là gì?
Kirk Kuykendall

@Kirk xin lỗi vì khó hiểu - Tôi lười biếng. cstheory.stackexchange.com
whuber

1
lý thuyết CS cơ bản có lẽ sẽ không giúp ích gì vì những người CS hiếm khi có được không gian :-)
Ian Turton

1
@iant Không có quá nhiều người GIS ngoài kia, những người sẽ biết nhiều về các loại hạt và bu lông của điện toán phân tán (Tôi không có tham vọng về các thành viên của trang web này, những người rõ ràng là đặc biệt). Tôi tin rằng người TCS sẽ có kiến ​​thức để trả lời câu hỏi ban đầu liên quan đến sự tồn tại của một kiến ​​trúc. Mối quan tâm duy nhất của tôi là liệu họ có tìm thấy câu hỏi thú vị không! Tôi nghĩ rằng nếu nó đặt đúng cách họ có thể. (Ví dụ: người ta có thể điều chỉnh lại nó theo cấu trúc dữ liệu.)
whuber

Câu trả lời:


13
  1. lưu trữ tất cả bưu kiện của bạn trong một cơ sở dữ liệu trung tâm
  2. xây dựng một mạng lưới trên Hoa Kỳ được tạo bởi các hình vuông N feet ở một bên, trong đó N sao cho số lượng bưu kiện phù hợp trong N sẽ không làm mất bộ nhớ trên một trong các nút của bạn
  3. tạo một bảng trong cơ sở dữ liệu của bạn với một hàng trên mỗi ô vuông, một cột id một cột hình học và một cột trạng thái
  4. mỗi nút chạy một chương trình nhỏ
    1. tìm hình vuông chưa xử lý tiếp theo
    2. đánh dấu nó là trong quá trình
    3. kéo tất cả các bưu kiện ST_DWithin (hình vuông, bưu kiện, maxfeet)
    4. truy vấn thực tế
    5. ghi lại câu trả lời truy vấn vào bảng giải pháp trong cơ sở dữ liệu trung tâm
    6. đánh dấu hình vuông là hoàn thành
    7. trở về 1

Trường hợp thất bại rõ ràng là khi bán kính quan tâm của bạn trong truy vấn bưu kiện đủ lớn để các phần lớn của tập dữ liệu của bạn là ứng viên tiềm năng phù hợp với từng bưu kiện.


Cảm ơn Paul, tôi có cần một nút đóng vai trò điều phối viên cho các nút khác không?
Kirk Kuykendall

Cơ sở dữ liệu hoạt động như một "điều phối viên" ẩn trong đó nó giữ trạng thái của hàng đợi, nhưng các nút không cần phải được phối hợp ngoài việc được khởi động và chỉ vào cơ sở dữ liệu. Không chắc đó có phải là câu trả lời hay không.
Paul Ramsey

7

Có một vị trí thú vị trên FOSS4G vào tháng 9 tại Barcelona về điều này: http://2010.foss4g.org/presentations_show.php?id=3584

Nó trở thành một cuộc thảo luận của hội thảo hơn là một bài thuyết trình.

Ở giữa bài viết trên blog này, Paul Ramsey đưa ra một số loại tóm tắt từ đó.


Điều đó có vẻ hứa hẹn, họ đã đăng bài thuyết trình ở bất cứ đâu?
Kirk Kuykendall

Chà, kể từ khi Schuyler Erle trở thành người điều hành cho cuộc thảo luận của hội thảo thay vì mã hóa bài thuyết trình theo kế hoạch, tôi không nghĩ sẽ có nhiều thông tin hơn về nó. Nhưng vì Erle đã lên kế hoạch cho bài thuyết trình đó nên có lẽ anh ta có một số thông tin về nó. Anh ấy ở khắp mọi nơi nếu bạn thực hiện tìm kiếm google. Nó có thể là một ý tưởng để hỏi anh ta trực tiếp. Tôi không biết. Hầu hết các cuộc thảo luận đều nằm trên sự hiểu biết của tôi vì vậy tôi không thể đưa ra bất kỳ sơ yếu lý lịch nào tốt hơn Paul đã làm trong blog của mình.
Nicklas Avén

4

Có thể hãy xem cuốn sách trắng "Máy chủ ArcGIS trong Tập thực hành: Mã hóa địa lý hàng loạt lớn" tại các trang giấy trắng esri .

Đó là về mã hóa địa lý nhưng quy trình chung sử dụng dịch vụ xử lý địa lý không đồng bộ có thể được áp dụng cho trường hợp của bạn.


Có vẻ tốt, tôi tự hỏi nếu điều này có thể được khái quát cho các hình thức xử lý địa lý khác. Có vẻ như tôi cần sự chồng chéo giữa các tập dữ liệu của mình.
Kirk Kuykendall

3

Điều đầu tiên cần quan tâm với vấn đề này là dữ liệu nào là cần thiết ở đâu và khi nào. Để làm như vậy, tôi thường bắt đầu với phiên bản nối tiếp ngu ngốc của vấn đề.

Tìm tất cả các bưu kiện có giá trị trên x $ / mẫu Anh trong phạm vi y của một bưu kiện khác có giá trị nhỏ hơn z $ / mẫu.

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

Trong khi thuật toán này không được tối ưu hóa, nó sẽ giải quyết vấn đề.

Tôi đã giải quyết một vấn đề tương tự cho luận án thạc sĩ của tôi, trong đó tìm thấy bưu kiện gần nhất cho mọi điểm trong bộ dữ liệu. Tôi đã triển khai giải pháp trong PostGIS , HadoopMPI . Phiên bản đầy đủ của luận án của tôi ở đây , nhưng tôi sẽ tóm tắt những điểm quan trọng khi nó áp dụng cho vấn đề này.

MapReduce không phải là một nền tảng tốt để giải quyết vấn đề này bởi vì nó yêu cầu quyền truy cập vào toàn bộ tập dữ liệu (hoặc một tập hợp con được chọn cẩn thận) để xử lý một bưu kiện tội lỗi. MapReduce không xử lý tốt các bộ dữ liệu thứ cấp.

MPI, tuy nhiên, có thể giải quyết điều này khá thủ công. Phần khó nhất là xác định cách phân chia dữ liệu. Sự phân chia này dựa trên số lượng dữ liệu, bao nhiêu p ressess bạn phải chạy nó và bao nhiêu bộ nhớ cho mỗi bộ xử lý. Để mở rộng tốt nhất (và do đó hiệu suất), bạn sẽ cần phải có nhiều bản sao của tập dữ liệu bưu kiện trong bộ nhớ (trên tất cả các máy tính của bạn) cùng một lúc.

Để giải thích cách thức hoạt động của nó, tôi sẽ giả sử rằng mỗi 50 máy tính của bạn có 8 bộ xử lý. Sau đó tôi sẽ giao cho mỗi máy tính trách nhiệm kiểm tra 1/50 bưu kiện. Việc kiểm tra này sẽ được thực hiện bởi 8 quy trình trên máy tính, mỗi quy trình có một bản sao của cùng một phần 1/50 của bưu kiện và 1/8 bộ dữ liệu bưu kiện. Xin lưu ý rằng các nhóm không giới hạn trong một máy, nhưng có thể vượt qua ranh giới máy.

Quá trình sẽ thực hiện thuật toán, lấy các bưu kiện cho p từ bộ bưu kiện 1/50 và bưu kiện cho q từ bộ 1/8. Sau vòng lặp bên trong, tất cả các quy trình trên cùng một máy tính sẽ nói chuyện với nhau để xác định xem có nên phát ra bưu kiện hay không.

Tôi đã thực hiện một thuật toán tương tự như vậy cho vấn đề của tôi. Bạn có thể tìm thấy nguồn ở đây .

Ngay cả với loại thuật toán không được tối ưu hóa này, tôi đã có thể thu được kết quả ấn tượng được tối ưu hóa cao cho thời gian lập trình viên (có nghĩa là tôi có thể viết một thuật toán đơn giản ngu ngốc và tính toán vẫn đủ nhanh). Điểm tiếp theo để tối ưu hóa (nếu bạn thực sự cần nó), là thiết lập một chỉ mục tứ giác của tập dữ liệu thứ hai (nơi bạn nhận q từ) cho mỗi quy trình.


Để trả lời câu hỏi ban đầu. Có một kiến ​​trúc: MPI + GEOS. Sử dụng một chút trợ giúp từ việc triển khai ClusterGIS của tôi và có thể thực hiện được rất nhiều việc. Tất cả phần mềm này có thể được tìm thấy dưới dạng nguồn mở, do đó không có phí cấp phép. Tôi không chắc nó có khả năng di động với Windows như thế nào (có thể với Cygwin) khi tôi làm việc với nó trong linux. Giải pháp này có thể được triển khai trên EC2, Rackspace hoặc bất kỳ đám mây nào có sẵn. Khi tôi phát triển nó, tôi đang sử dụng một cụm tính toán chuyên dụng tại một trường đại học.


2

Phương pháp lập trình song song của trường học cũ là chỉ lưu trữ một trạng thái + các bưu kiện chạm vào trên mỗi bộ xử lý thì thật dễ dàng để song song hóa. Nhưng với sự khác biệt về kích thước của các tiểu bang Hoa Kỳ, bạn sẽ có hiệu suất tốt hơn bằng cách chia quốc gia thành các ô lưới (một lần nữa với quầng sáng của bưu kiện) và gửi từng ô lưới tới bộ xử lý bằng cấu hình nô lệ chính.


Thay vì bưu kiện chạm vào, tôi cần bưu kiện từ các quốc gia lân cận trong khoảng cách y.
Kirk Kuykendall

Tôi cho rằng Y đủ nhỏ để nó không lớn hơn đáng kể so với một số lượng nhỏ bưu kiện. Nếu đó là một phần lớn của trạng thái thì có lẽ tốt nhất bạn chỉ nên sử dụng lưới tùy ý để thực hiện các phép tính.
Ian Turton

2

Bạn có thể muốn cung cấp cho Appology một cái nhìn. Nó có ý định cho phép di chuyển các ứng dụng hiện có sang cơ sở hạ tầng đám mây riêng. Có thể có các dự án khác có mục đích tương tự: thay vì lặp đi lặp lại cho mọi ứng dụng, việc phân tích và phân phối các nhiệm vụ rất phức tạp để xử lý song song, tạo một thư viện hoặc nền tảng tự động thực hiện.


Cảm ơn Matt, điều đó có vẻ đầy hứa hẹn. Googling Tôi đã tìm thấy bản trình bày này từ các thủ tục của FedUC 2008.esri.com / l Library / userconf / fucuc08 / con / tôi sẽ tò mò muốn xem một bản cập nhật về những gì họ đã làm kể từ đó.
Kirk Kuykendall

2

Đối với loại vấn đề này, tôi sẽ sử dụng khung bản đồ / thu nhỏ. Khung Ứng dụng "thô" là tuyệt vời cho các vấn đề "song song lúng túng", mà vấn đề này gần với. Các điều kiện cạnh không cho phép nó được. Map / Giảm (cách tiếp cận của Google đối với điện toán phân tán) rất tốt ở loại vấn đề này.

Bước tiến lớn nhất tại Appology kể từ bài 08 là phát hành sản phẩm CloudIQ Storage. Điều này cho phép "s3" giống như cơ sở lưu trữ sử dụng các đĩa trên máy chủ cục bộ của bạn. Sau đó, sản phẩm CloudIQ Engine có thể cho phép các dịch vụ khối lượng lớn hoặc phân tán / thu thập các ứng dụng kiểu bất kỳ loại nào (chúng tôi đã chứng minh khả năng mở rộng bằng cách sử dụng thời gian chạy ESRI và các lib nguồn mở khác). Nếu bạn đang vận hành dữ liệu dựa trên tệp, bạn phân phối nó ra bằng CloudIQ Storage và định tuyến các công việc xử lý tới các bản sao tệp cục bộ để chúng không phải di chuyển trên mạng. (vì vậy mọi nút không cần tất cả dữ liệu)

Đối với Bản đồ / Thu nhỏ, bạn có thể lớp một cái gì đó như Hadoop (khung M / R nguồn mở) trên CloudIQ Storage. Tôi sẽ xem xét Hadoop cho vấn đề như được mô tả, nhưng bạn thực sự cần phải đi sâu vào, không dễ để bắt đầu, và M / R là một bộ não. Ngoài ra còn có một phân phối được hỗ trợ thương mại được cung cấp bởi Cloudera. Có một sản phẩm Ứng dụng khác, CloudIQ Manger, một sản phẩm bổ sung tuyệt vời cho Hadoop (Cloudera hay nói cách khác) để phân phối và quản lý.

Tôi sẽ bắt đầu với Hadoop (hệ thống tập tin M / R và HDFS) và nếu bạn cần một giải pháp mở rộng được hỗ trợ thương mại hơn, hãy xem Trình quản lý và lưu trữ ứng dụng CloudIQ, kết hợp với bản phân phối Cloudera Hadoop.

Nếu bạn muốn có kiến ​​trúc đơn giản hơn cho các tác vụ "song song lúng túng", hãy xem CloudIQ Engine. (các cách tiếp cận được nêu trong bài báo mà Kirk tham chiếu vẫn còn hiệu lực)


Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.