มีสถาปัตยกรรมสำหรับการประมวลผลเชิงภูมิศาสตร์แบบกระจายหรือไม่?


24

สมมติว่าฉันมี 50 เครื่องบน LAN ของฉัน คอมพิวเตอร์แต่ละเครื่องมีฐานข้อมูลภูมิศาสตร์สำหรับรูปหลายเหลี่ยมพัสดุทั้งหมดในสถานะเฉพาะในสหรัฐอเมริกา

ฉันต้องการเขียนงานการประมวลผลทางภูมิศาสตร์ที่พบพัสดุทั้งหมดที่มีมูลค่ามากกว่าx $ / เอเคอร์ที่อยู่ในระยะyฟุตของพัสดุอื่นที่มีมูลค่าน้อยกว่าz $ / เอเคอร์

ฉันต้องการกำหนดและเรียกใช้แบบสอบถามนี้โดยไม่ทราบหรือไม่ใส่ใจว่ามีการเผยแพร่ข้อมูลไปยังคอมพิวเตอร์ 50 เครื่อง โปรดจำไว้ว่าเงื่อนไขขอบเขต: ฉันต้องการให้แบบสอบถามส่งคืนกรณีที่พัสดุราคาแพงในรัฐหนึ่งอยู่ใกล้กับพัสดุราคาไม่แพงอีกแห่งหนึ่ง

มีสถาปัตยกรรมที่รองรับการประมวลผลทางภูมิศาสตร์แบบกระจายหรือไม่

สถาปัตยกรรมสามารถอธิบายได้อย่างเป็นนามธรรมหรือเป็นการใช้งานเฉพาะกับ Azure หรือ Amazon Web Services หรือโดยเฉพาะอย่างยิ่งเป็นสำนักงานทั่วไปที่คอมพิวเตอร์ไม่ได้ใช้งานในเวลากลางคืนพร้อมใบอนุญาตเดสก์ท็อป ArcGIS มากมาย


1
เป็นคำถามที่ดี ในตัวอย่างนี้คุณต้องใช้วิธีการขนานอาคารและใช้โครงสร้างข้อมูลเชิงพื้นที่เช่น quadtree โดยอัตโนมัติ หากคุณไม่ทำเช่นนั้นและเพียงกระจายการค้นหาที่โหดเหี้ยมไปยังคอมพิวเตอร์ 50 เครื่องแทนคุณอาจทำให้การสืบค้นช้าลงแทนที่จะเพิ่มความเร็ว ฉันค่อนข้างมั่นใจว่าสถาปัตยกรรมทั่วไปเช่นนี้ยังไม่มีอยู่ดังนั้นคุณอาจโชคดีขึ้นด้วยการไตร่ตรองก่อนว่าแบบสอบถามชนิดใดที่จะได้รับประโยชน์จากการประมวลผลแบบกระจายและจากนั้นดูสถาปัตยกรรมที่ต้องการ อาจโพสต์คำถามนี้ในเว็บไซต์ TCS?
whuber

@whuber ขอบคุณไซต์ TCS คืออะไร
Kirk Kuykendall

@ Kirk ขอโทษที่เป็นความลับ - ฉันขี้เกียจ cstheory.stackexchange.com
whuber

1
ทฤษฎี CS ขั้นพื้นฐานอาจจะไม่ช่วยได้เพราะพวก CS ไม่ค่อยได้รับมิติ:
Ian Turton

1
@iant มีคน GIS ไม่มากนักที่จะรู้เกี่ยวกับถั่วและกลอนของการคำนวณแบบกระจาย (ฉันไม่ได้แสดงความคิดเห็นเกี่ยวกับสมาชิกของเว็บไซต์นี้ที่เห็นได้ชัดมาก) ฉันเชื่อว่าผู้คนใน TCS จะมีความรู้ในการตอบคำถามดั้งเดิมเกี่ยวกับการมีอยู่ของสถาปัตยกรรม ข้อกังวลเดียวของฉันคือว่าพวกเขาจะพบคำถามที่น่าสนใจ! ฉันคิดว่าถ้ามันถูกวิธีที่พวกเขาอาจจะ (เช่นคนหนึ่งอาจวางกรอบใหม่ในแง่ของโครงสร้างข้อมูล)
whuber

คำตอบ:


13
  1. จัดเก็บพัสดุของคุณทั้งหมดในฐานข้อมูลส่วนกลางเดียว
  2. กำหนดตารางเหนือสหรัฐอเมริกาที่สร้างจากสี่เหลี่ยม N ฟุตที่ด้านข้างโดยที่ N เป็นเช่นนั้นจำนวนของพัสดุที่พอดีภายใน N จะไม่ทำให้หน่วยความจำในโหนดใดโหนดหนึ่งของคุณว่างเปล่า
  3. สร้างตารางในฐานข้อมูลของคุณด้วยหนึ่งแถวต่อตารางกริดคอลัมน์ id คอลัมน์รูปทรงเรขาคณิตและคอลัมน์สถานะ
  4. แต่ละโหนดรันโปรแกรมขนาดเล็กที่
    1. ค้นหาสแควร์ที่ยังไม่ได้ประมวลผลต่อไป
    2. ทำเครื่องหมายว่าเป็นในกระบวนการ
    3. ดึงพัสดุทั้งหมด ST_D ภายใน (สี่เหลี่ยมจัตุรัสพัสดุสูงสุดสูงสุด)
    4. ทำแบบสอบถามจริง
    5. เขียนคำตอบแบบสอบถามลงในตารางโซลูชันในฐานข้อมูลส่วนกลาง
    6. ทำเครื่องหมายสแควร์ว่าเสร็จสมบูรณ์
    7. กลับไปที่ 1

กรณีความล้มเหลวที่เห็นได้ชัดคือรัศมีที่คุณสนใจในข้อความค้นหาพัสดุมีขนาดใหญ่พอที่ชุดข้อมูลขนาดใหญ่ของคุณจะเป็นตัวเลือกที่มีศักยภาพในการจับคู่แต่ละพัสดุ


ขอบคุณ Paul ฉันจะต้องมีหนึ่งโหนดที่ทำหน้าที่เป็นผู้ประสานงานสำหรับโหนดอื่น ๆ หรือไม่
Kirk Kuykendall

ฐานข้อมูลทำหน้าที่เป็น "ผู้ประสานงาน" โดยนัยในการที่จะเก็บสถานะของคิว แต่โหนดไม่จำเป็นต้องประสานงานเกินกว่าที่จะเริ่มต้นขึ้นและชี้ไปที่ฐานข้อมูล ไม่แน่ใจว่าเป็นคำตอบหรือไม่
พอลแรมซีย์

7

มีสล็อตที่น่าสนใจใน FOSS4G ในเดือนกันยายนในบาร์เซโลนาเกี่ยวกับเรื่องนี้: http://2010.foss4g.org/presentations_show.php?id=3584

มันเป็นมากกว่าการอภิปรายมากกว่าการนำเสนอ

ในช่วงกลางของโพสต์บล็อกนี้ Paul Ramsey ให้สรุปบางอย่างจากที่


ดูเหมือนว่าพวกเขาจะโพสต์งานนำเสนอได้ทุกที่หรือไม่?
Kirk Kuykendall

ดีเนื่องจาก Schuyler Erle กลายเป็นผู้ดำเนินรายการอภิปรายแทนการกดปุ่มการนำเสนอที่วางแผนไว้ฉันไม่คิดว่าจะมีข้อมูลมากขึ้นเกี่ยวกับเรื่องนี้ แต่เนื่องจาก Erle ได้วางแผนการนำเสนอนั้นเขาอาจมีข้อมูลบางอย่างเกี่ยวกับมัน เขาอยู่ทุกหนทุกแห่งถ้าคุณค้นหาด้วยกูเกิ้ล มันอาจเป็นความคิดที่จะถามเขาโดยตรง ฉันไม่รู้ การอภิปรายส่วนใหญ่อยู่เหนือความเข้าใจของฉันดังนั้นฉันจึงไม่สามารถให้ประวัติย่อที่ดีกว่าที่ Paul ทำในบล็อกของเขา
Nicklas Avén

4

อาจจะดูที่กระดาษสีขาว "ArcGIS เซิร์ฟเวอร์ในชุดปฏิบัติงาน: ชุดใหญ่ระบุพิกัดทางภูมิศาสตร์" ที่เอกสารสีขาว ESRI

มันเกี่ยวกับการเข้ารหัสทางภูมิศาสตร์ แต่กระบวนการทั่วไปของการใช้บริการการประมวลผลทางภูมิศาสตร์แบบอะซิงโครนัสอาจใช้ได้กับกรณีของคุณ


ดูดีฉันสงสัยว่าสิ่งนี้สามารถนำไปใช้กับกระบวนการทางภูมิศาสตร์ในรูปแบบอื่น ๆ ได้หรือไม่ ดูเหมือนว่าฉันต้องการทับซ้อนระหว่างชุดข้อมูลของฉัน
Kirk Kuykendall

3

สิ่งแรกที่ต้องกังวลเกี่ยวกับปัญหานี้คือข้อมูลที่ต้องการในทุกที่และทุกเวลา หากต้องการทำเช่นนั้นฉันมักจะเริ่มต้นด้วยปัญหารุ่นที่โง่และอนุกรม

ค้นหาพัสดุทั้งหมดที่มีมูลค่ามากกว่า x $ / เอเคอร์ที่อยู่ในระยะ y ฟุตของพัสดุอื่นที่มีมูลค่าน้อยกว่า z $ / เอเคอร์

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 ของชุดข้อมูลพัสดุ โปรดทราบว่ากลุ่มไม่ จำกัด เพียงเครื่องเดียว แต่สามารถข้ามขอบเขตของเครื่องได้

กระบวนการจะดำเนินการอัลกอริทึมรับพัสดุสำหรับ p จากชุดที่ 1 / 50th และพัสดุสำหรับ q จากชุดที่ 1 / 8th หลังจากวนรอบด้านในกระบวนการทั้งหมดในคอมพิวเตอร์เครื่องเดียวกันจะพูดคุยกันเพื่อตรวจสอบว่าควรปล่อยพัสดุหรือไม่

ฉันใช้อัลกอริทึมที่คล้ายกันกับปัญหานี้ คุณสามารถค้นหาแหล่งที่มาที่นี่

แม้จะมีอัลกอริธึมที่ไม่ได้รับการเพิ่มประสิทธิภาพเช่นนี้ฉันก็ยังสามารถรับผลลัพธ์ที่น่าประทับใจซึ่งได้รับการปรับให้เหมาะสมอย่างมากสำหรับเวลาโปรแกรมเมอร์ จุดต่อไปในการปรับให้เหมาะสม (ถ้าคุณต้องการจริงๆ) คือการตั้งค่าดัชนีควอดทรีของชุดข้อมูลที่สอง (ซึ่งคุณได้รับ q จาก) สำหรับแต่ละกระบวนการ


เพื่อตอบคำถามเดิม มีสถาปัตยกรรม: MPI + GEOS โยนความช่วยเหลือเล็กน้อยจากการติดตั้ง ClusterGIS ของฉันและสามารถทำได้ค่อนข้างมาก ซอฟต์แวร์ทั้งหมดนี้สามารถพบได้ในฐานะโอเพ่นซอร์สดังนั้นจึงไม่มีค่าธรรมเนียมใบอนุญาต ฉันไม่แน่ใจว่าอุปกรณ์พกพาสำหรับ Windows เป็นอย่างไร (อาจใช้กับ Cygwin) ในขณะที่ฉันทำงานบน linux โซลูชันนี้สามารถปรับใช้บน EC2, Rackspace หรือคลาวด์ที่พร้อมใช้งาน เมื่อฉันพัฒนามันฉันใช้กลุ่มการคำนวณเฉพาะที่มหาวิทยาลัย


2

ระเบียบวิธีการเขียนโปรแกรมแบบขนานของโรงเรียนเก่าคือเพียงแค่เก็บสถานะ+ พัสดุที่สัมผัสกับโปรเซสเซอร์แต่ละตัวจากนั้นจึงเป็นเรื่องง่ายที่จะทำให้เป็นเส้นขนาน แต่เมื่อกำหนดขนาดของสหรัฐอเมริกาให้หลากหลายคุณจะได้ประสิทธิภาพที่ดีขึ้นโดยการแบ่งประเทศออกเป็นเซลล์กริด (อีกครั้งด้วยรัศมีสัมผัสของพัสดุ) และส่งแต่ละกริดเซลล์ไปยังโปรเซสเซอร์โดยใช้การกำหนดค่าสลาฟหลัก


แทนที่จะเป็นพัสดุที่แตะฉันต้องการพัสดุจากรัฐที่อยู่ติดกันภายในระยะทาง y
Kirk Kuykendall

ฉันคิดว่า Y นั้นเล็กกว่านั้นซึ่งมันไม่ใหญ่กว่าผืนเล็ก ๆ จำนวนมาก หากเป็นส่วนใหญ่ของรัฐคุณน่าจะดีที่สุดเพียงใช้กริดโดยพลการเพื่อทำการคำนวณ
Ian Turton

2

คุณอาจต้องการให้Appistryดู มีวัตถุประสงค์เพื่อเปิดใช้งานการย้ายแอปพลิเคชันที่มีอยู่ไปยังโครงสร้างพื้นฐานคลาวด์ส่วนตัว อาจมีโครงการอื่น ๆ ที่มีเป้าหมายคล้ายกัน: แทนที่จะค้นหาซ้ำแล้วซ้ำเล่าสำหรับทุกแอปพลิเคชันที่ซับซ้อนมากของการแบ่งย่อยและกระจายงานไปยังการประมวลผลแบบขนานทำให้ไลบรารีหรือแพลตฟอร์มที่ทำโดยอัตโนมัติ


ขอบคุณ Matt ที่ดูมีแนวโน้ม Googling ผมพบว่านำเสนอนี้จาก FedUC 2008 proceedings.esri.com/library/userconf/feduc08/papers/... ฉันจะอยากรู้อยากเห็นการปรับปรุงในสิ่งที่พวกเขาได้ทำตั้งแต่นั้นมา
Kirk Kuykendall

2

สำหรับปัญหาประเภทนี้ฉันจะใช้แผนที่ / ลดกรอบงาน กรอบการทำงานแบบ "ดิบ" นั้นยอดเยี่ยมสำหรับปัญหา "ขนานที่น่าอับอาย" ซึ่งปัญหานี้อยู่ใกล้ เงื่อนไขขอบไม่อนุญาตให้เป็น แผนที่ / การลด (วิธีการของ Google ในการคำนวณแบบกระจาย) นั้นยอดเยี่ยมสำหรับปัญหาประเภทนี้

ความก้าวหน้าที่ยิ่งใหญ่ที่สุดของ Appistry เนื่องจากกระดาษ 08 คือการเปิดตัวผลิตภัณฑ์ CloudIQ Storage สิ่งนี้จะช่วยให้ "s3" เช่นสถานที่จัดเก็บใช้ดิสก์บนเซิร์ฟเวอร์ในประเทศของคุณ จากนั้นผลิตภัณฑ์ CloudIQ Engine สามารถเปิดใช้งานบริการปริมาณสูงหรือกระจาย / รวบรวมแอปพลิเคชันสไตล์ทุกประเภท (เราได้พิสูจน์ความสามารถในการปรับขยายได้โดยใช้ ESRI runtime และ libs โอเพ่นซอร์สอื่น ๆ ) หากคุณกำลังทำงานกับข้อมูลจากไฟล์คุณเผยแพร่โดยใช้ที่เก็บ CloudIQ และงานการประมวลผลเส้นทางไปยังเรพลิกาไฟล์โลคัลดังนั้นจึงไม่จำเป็นต้องย้ายไปมาบนเครือข่าย (ดังนั้นทุกโหนดไม่ต้องการข้อมูลทั้งหมด)

สำหรับ Map / Reduce คุณสามารถเลเยอร์บางสิ่งบางอย่างเช่น Hadoop (กรอบโอเพ่นซอร์ส M / R) บนที่เก็บ CloudIQ ฉันจะดูที่ Hadoop สำหรับปัญหาดังที่อธิบายไว้ แต่คุณจำเป็นต้องดำน้ำจริง ๆ ไม่ใช่เรื่องง่ายที่จะเริ่มต้นและ M / R เป็นสมองที่อันตราย นอกจากนี้ยังมีการจัดจำหน่ายที่ได้รับการสนับสนุนในเชิงพาณิชย์โดย Cloudera มีผลิตภัณฑ์ Appistry อีกตัวหนึ่งคือ CloudIQ Manger ซึ่งเป็นส่วนประกอบที่ดีของ Hadoop (Cloudera หรืออย่างอื่น) สำหรับการจัดจำหน่ายและการจัดการ

ฉันจะเริ่มต้นด้วยระบบไฟล์ Hadoop (M / R และ HDFS) และหากคุณต้องการโซลูชันที่ปรับขยายได้ที่รองรับการใช้งานเชิงพาณิชย์มากขึ้นให้ดูที่ Appistry CloudIQ Manager and Storage พร้อมกับ Cloudera Hadoop distro

หากคุณต้องการสถาปัตยกรรมที่ง่ายกว่าสำหรับงาน "ขนานที่น่าอาย" ให้ดูที่ CloudIQ Engine เช่นกัน (วิธีการที่อธิบายไว้ในกระดาษ Kirk อ้างอิงยังคงถูกต้อง)


โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.