ความแปลกใหม่ใน MapReduce คืออะไร?

ไม่กี่ปีที่ผ่านมาMapReduceได้รับการยกย่องว่าเป็นการปฏิวัติการเขียนโปรแกรมแบบกระจาย นอกจากนี้ยังมีนักวิจารณ์แต่โดยมากแล้วก็มีโฆษณาที่กระตือรือร้น มันยังจดสิทธิบัตร! [1]

ชื่อนี้เป็นที่ระลึกถึงmapและreduceในการเขียนโปรแกรมการทำงาน แต่เมื่อฉันอ่าน (Wikipedia)

ขั้นตอนแผนที่:โหนดหลักจะรับอินพุตแบ่งเป็นปัญหาย่อยที่เล็กกว่าและกระจายไปยังโหนดผู้ปฏิบัติงาน โหนดผู้ปฏิบัติงานอาจทำสิ่งนี้อีกครั้งในทางกลับนำไปสู่โครงสร้างต้นไม้หลายระดับ โหนดผู้ปฏิบัติงานประมวลผลปัญหาที่เล็กกว่าและส่งคำตอบกลับไปที่โหนดหลัก

ลดขั้นตอน:โหนดหลักจะรวบรวมคำตอบสำหรับปัญหาย่อยทั้งหมดและรวมเข้าด้วยกันในรูปแบบเอาต์พุตบางส่วน - คำตอบสำหรับปัญหาที่พยายามแก้ไขในขั้นต้น

หรือ [2]

Internals of MAP: [... ] MAP แยกค่าอินพุตเป็นคำ [... ] MAP หมายถึงการเชื่อมโยงคู่คีย์ / ค่าที่กำหนดของอินพุตกับคู่กลางคีย์ / ค่าที่อาจเกิดขึ้น

Internals of REDUCE: [... ] [REDUCE] ดำเนินการรวมที่จำเป็น (พูดลด): รับค่าจำนวนมากและลดลงเป็นค่าเดียว

ฉันไม่สามารถช่วย แต่คิดว่า: นี่คือการแบ่ง & พิชิต (ในแง่ของการควบรวมกิจการ) ธรรมดาและเรียบง่าย! ดังนั้นมีความแปลกใหม่ (แนวคิด) ใน MapReduce ที่ไหนสักแห่งหรือเป็นเพียงการดำเนินการใหม่ของความคิดเก่าที่มีประโยชน์ในบางสถานการณ์?

1. สิทธิบัตรสหรัฐอเมริกา 7,650,331: "ระบบและวิธีการสำหรับการประมวลผลข้อมูลขนาดใหญ่ที่มีประสิทธิภาพ" (2010)
2. รูปแบบการเขียนโปรแกรม MapReduce ของ Google - เยี่ยมชมโดย R. Lämmel (2007)

ฉันไม่สามารถช่วย แต่คิดว่า: นี่คือการแบ่ง & พิชิตธรรมดาและเรียบง่าย!

M / R ไม่ได้แบ่ง & พิชิต ไม่เกี่ยวข้องกับแอปพลิเคชันซ้ำของอัลกอริทึมกับชุดย่อยขนาดเล็กของอินพุตก่อนหน้า เป็นไปป์ไลน์ (ฟังก์ชั่นที่ระบุไว้เป็นองค์ประกอบของฟังก์ชั่นที่ง่ายกว่า) ที่ขั้นตอนไปป์ไลน์กำลังสลับแผนที่และลดการดำเนินการ ขั้นตอนต่าง ๆ สามารถดำเนินการต่าง ๆ ได้

ดังนั้นมีความแปลกใหม่ (แนวคิด) ใน MapReduce ที่ไหนสักแห่งหรือเป็นเพียงการดำเนินการใหม่ของความคิดเก่าที่มีประโยชน์ในบางสถานการณ์?

MapReduce ไม่ทำลายพื้นใหม่ในทฤษฎีการคำนวณ - มันไม่ได้แสดงวิธีการใหม่ในการย่อยสลายปัญหาในการดำเนินงานที่ง่ายขึ้น มันแสดงให้เห็นว่าการดำเนินการที่เรียบง่ายโดยเฉพาะอย่างยิ่งเป็นประโยชน์สำหรับชั้นของปัญหาโดยเฉพาะ

ผลงานของMapReduce paperคือ

1. การประเมินไปป์ไลน์ของผู้ประกอบการ orthogonal สองคนที่เข้าใจได้ดีซึ่งสามารถแจกจ่ายได้อย่างมีประสิทธิภาพและความผิดพลาดอย่างอดทนต่อปัญหาเฉพาะ: การสร้างดัชนีข้อความของคลังข้อมูลขนาดใหญ่
2. การทำเบนช์มาร์กการเปรียบเทียบแผนที่เพื่อลดปัญหาที่เกิดขึ้นเพื่อแสดงว่ามีการถ่ายโอนข้อมูลระหว่างโหนดมากน้อยเพียงใด
3. แสดงวิธีที่จะทำให้ระบบทำงานผิดพลาดดังนั้นเครื่องขัดข้องระหว่างการคำนวณจึงสามารถชดเชยได้โดยอัตโนมัติ
4. ระบุตัวเลือกการใช้งานและการปรับให้เหมาะสมที่มีประโยชน์โดยเฉพาะ

บทวิจารณ์บางส่วนตกอยู่ในชั้นเรียนเหล่านี้:

1. "แผนที่ / การลดไม่ทำให้เกิดพื้นใหม่ในทฤษฎีการคำนวณ" จริง การมีส่วนร่วมของกระดาษต้นฉบับคือผู้ประกอบการเหล่านี้มีความเข้าใจดีกับชุดของการเพิ่มประสิทธิภาพเฉพาะถูกนำมาใช้ในการแก้ปัญหาจริงได้ง่ายขึ้นและทนต่อความผิดพลาดกว่าโซลูชั่นแบบครั้งเดียว
2. "การคำนวณแบบกระจายนี้ไม่สามารถย่อยสลายในแผนที่ได้ง่ายและลดการทำงาน" ยุติธรรมเพียงพอ แต่หลายคนทำ
3. "ไปป์ไลน์ของแผนที่ n / ลดขั้นตอนต้องใช้เวลาแฝงเป็นสัดส่วนกับจำนวนของขั้นตอนการลดของไปป์ไลน์ก่อนที่จะสร้างผลลัพธ์ใด ๆ " อาจเป็นจริง ตัวดำเนินการลดจะต้องรับอินพุตทั้งหมดก่อนจึงจะสามารถสร้างเอาต์พุตที่สมบูรณ์ได้
4. "แผนที่ / ลดมากเกินไปสำหรับกรณีการใช้งานนี้" อาจจะ. เมื่อวิศวกรพบค้อนใหม่ที่เป็นประกายพวกเขามักจะมองหาสิ่งที่ดูเหมือนเล็บ ไม่ได้หมายความว่าค้อนไม่ใช่เครื่องมือที่ได้รับการออกแบบมาเป็นอย่างดีสำหรับบางช่อง
5. "Map / ลดเป็นการแทนที่ที่ดีสำหรับฐานข้อมูลเชิงสัมพันธ์" จริง หากฐานข้อมูลเชิงสัมพันธ์ปรับขนาดไปที่ชุดข้อมูลของคุณคุณจะมีตัวเลือกมากมาย

แก้ไข (มีนาคม 2014) ฉันควรจะบอกว่าฉันได้ทำงานเกี่ยวกับอัลกอริธึมสำหรับแบบจำลองการคำนวณแบบ MapReduce มากขึ้นและฉันรู้สึกว่าตัวเองถูกลบมากเกินไป เทคนิค Divide-Compress-Conquer ที่ฉันพูดถึงด้านล่างนั้นมีความหลากหลายอย่างน่าประหลาดใจและสามารถเป็นพื้นฐานของอัลกอริทึมที่ฉันคิดว่าไม่สำคัญและน่าสนใจ

ให้ฉันเสนอคำตอบที่จะด้อยกว่ามากของ Mike ในแง่ของความครอบคลุม แต่จากรูปแบบของมุมมองทฤษฎีการคำนวณ / อัลกอริทึม

$O(n^\epsilon)$$o(\log n)$

$O(1)$

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

$n$$O(\sqrt{n})$$\sqrt{n}$

ตอนนี้ฉันคิดว่านี่เป็นเกลียวที่น่าสนใจในการแบ่งและพิชิตการบิดที่เกิดขึ้นหลังจากขั้นตอนการหารคุณต้องบีบอัดโซลูชันย่อยเพื่อให้โปรเซสเซอร์เดียวสามารถพิชิตได้ อย่างไรก็ตามนี่ดูเหมือนจะเป็นเทคนิคเดียวที่เราเคยทำมาจนถึงตอนนี้ มันล้มเหลวในปัญหาเกี่ยวกับกราฟหร็อมแหร็มเช่นการเชื่อมต่อกระจัดกระจายเช่น เปรียบเทียบสิ่งนี้กับรูปแบบการสตรีมซึ่งนำไปสู่ความคิดใหม่ ๆ มากมายเช่นอัลกอริธึมการสุ่มตัวอย่างอันชาญฉลาดของ Flajolet และ Martin ซึ่งเป็นอัลกอริธึมการจับคู่ที่กำหนดขึ้นอย่างยากลำบากของ Misra and Gries พลังของเทคนิคการร่างอย่างง่าย ฯลฯ

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

ฉันเห็นด้วยกับคุณอย่างเต็มที่ จากมุมมองแนวคิดไม่มีอะไรใหม่จริง ๆ : แผนที่ / ย่อเดิมเป็นที่รู้จักใน Parallel Computing เป็นรูปแบบการเขียนโปรแกรมการไหลของข้อมูล อย่างไรก็ตามจากมุมมองที่ใช้งานได้จริงแผนที่ / การลดขนาดตามที่เสนอโดย Google และด้วยการใช้งานโอเพ่นซอร์สก็ทำให้การใช้งาน Cloud Computing และเป็นที่นิยมอย่างมากสำหรับการแยกย่อยและการประมวลผลแบบขนาน แน่นอนว่ามันไม่เหมาะสำหรับสิ่งอื่นที่ต้องการโดเมนที่ซับซ้อนหรือการสลายตัวทางหน้าที่

ฉันคิดว่าคุณโดนตะปูที่หัวด้วยความคิดเห็นของคุณ

มันไม่ได้เป็นความจริงว่าในแผนที่ภาษาการทำงานใด ๆ ที่สามารถ parallelized - ภาษาที่จะต้องบริสุทธิ์ (ฉันเชื่อว่า Haskell เป็นภาษาหลักที่ใช้งานได้เพียงภาษาเดียวเท่านั้น Lisp, OCaml และ Scala ล้วน แต่ไม่บริสุทธิ์)

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

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

สิ่งที่ MR ทำคือผ่อนคลายข้อ จำกัด ด้านความบริสุทธิ์บ้างและจัดทำกรอบสำหรับชิ้นส่วนอื่น ๆ (เช่นเฟสสลับ) ทำให้ง่ายต่อการเขียนรหัสที่สามารถแจกจ่ายต่อได้สำหรับปัญหาส่วนใหญ่

$NC=P$