เทคนิคการปรับให้เหมาะสมสำหรับแพลตฟอร์มคอมพิวเตอร์ในหน่วยความจำแบบกระจายโดยการใช้ประโยชน์จาก SSD ตอนที่ 2

3.1. สภาพแวดล้อมคลัสเตอร์

รูปที่ 1 แสดงคลัสเตอร์ทดสอบของเราประกอบด้วยโหนดชื่อหนึ่งโหนด (ต้นแบบ) และโหนดข้อมูลสี่โหนด (สเลฟ) ในโหนดชื่อ (ต้นแบบ) เราได้กำหนดค่า NameNode และ NameNode รองของ Hadoop (HDFS) และโหนดไดรเวอร์ (โหนดหลัก) ของ Spark ในแต่ละโหนดข้อมูล เราเรียกใช้ DataNode ของ Hadoop (HDFS) และ Worker Node ของ Spark เครื่องโหนดชื่อและเครื่องโหนดข้อมูลมีสภาพแวดล้อม H/W เหมือนกัน (โปรเซสเซอร์ 3.4 GHz Xeon E3-1240 V3 QuadCore พร้อมไฮเปอร์เธรด) ยกเว้นจำนวนหน่วยความจำหลัก (8 GB สำหรับโหนดชื่อและ 4 GB สำหรับแต่ละโหนดข้อมูล)

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

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

หน่วยความจำของโหนด Namename ไม่เพียงแต่กำหนดจำนวนไฟล์ที่สามารถจัดการได้และขนาดของระบบไฟล์เท่านั้น แต่ยังส่งผลต่อประสิทธิภาพและความน่าเชื่อถือของคลัสเตอร์ Hadoop อีกด้วย หากโหนด Namename มีหน่วยความจำไม่เพียงพอ โหนดนั้นจะไม่สามารถตอบสนองคำขอของไคลเอ็นต์ได้อย่างรวดเร็ว ส่งผลให้ปริมาณงานของคลัสเตอร์ Hadoop ทั้งหมดลดลง นอกจากนี้ หากโหนด Namename ล้มเหลว ข้อมูลเมตาดาต้าที่เก็บไว้อาจสูญหาย ส่งผลให้ระบบไฟล์ HDFS ทั้งหมดไม่พร้อมใช้งาน

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

คลิกรู้อาหารเสริมเพื่อเพิ่มความจำ

เราใช้ SSD สองตัวเป็นพื้นที่จัดเก็บข้อมูลโดยที่ใช้ SATA3 SSD ขนาด 120 GB สำหรับระบบปฏิบัติการ และ SATA3 SSD ขนาด 512 GB ติดตั้งสำหรับ HDFS ตามลำดับ นอกจากนี้ 512 GB SATA3 SSD ยังสามารถใช้ประโยชน์ได้อย่างมีประสิทธิภาพเพื่อขยายแบนด์วิดท์ของหน่วยความจำหลักไม่เพียงพอที่จะแคช RDD ของ Spark โหนดทั้งหมด รวมถึงโหนดชื่อและโหนดข้อมูลเชื่อมต่อกันด้วยสวิตช์อีเทอร์เน็ต 1 Gb ดังแสดงในรูปที่ 1 ตารางที่ 2 แสดงข้อมูลสรุปของการกำหนดค่าฮาร์ดแวร์และซอฟต์แวร์ในแต่ละโหนดข้อมูลของคลัสเตอร์ทดสอบของเรา

3.2. จุดประกายฮีป JVM

งาน Spark ทำงานเป็นกระบวนการ Java บน Java Virtual Machine (JVM) และ Spark หาประโยชน์จาก Scala ซึ่งเป็นภาษาเชิงฟังก์ชันที่ขยายมาจาก Java กระบวนการของผู้ปฏิบัติงานของ Spark ยังทำงานบน JVM ของแต่ละโหนดข้อมูล ดังนั้นในแต่ละโหนดข้อมูล กระบวนการของผู้ปฏิบัติงานจะมีฮีป JVM ในหน่วยความจำหลักดังแสดงในรูปที่ 2 เมื่อ Spark ส่งงาน กระบวนการของผู้ปฏิบัติงานที่มี ฮีป JVM รันงานเป็นงานแบบกระจาย

เราสามารถปรับแต่งอัตราส่วนของขนาดฮีป JVM ของผู้ปฏิบัติงาน Spark ผ่านไฟล์การกำหนดค่าค่าเริ่มต้นของ Spark conf ในไดเร็กทอรี spark/conf/ ในไฟล์ spark defaults.conf ค่าของ spark.executor.memory คือขนาดฮีป JVM โดยค่าเริ่มต้นคือ 512 MB ซึ่งแต่ละโหนดของผู้ปฏิบัติงานสามารถนำไปใช้ในโหนดข้อมูลได้ นอกจากนี้ ค่าของ spark.storage.safetyFraction ได้รับการแก้ไขเป็น 0.9 ซึ่งหมายความว่า Spark สามารถใช้ขนาดฮีป JVM ได้ถึง 90% (หรือที่เรียกว่าพื้นที่ปลอดภัย) นี่เป็นการป้องกันไม่ให้ JVM สร้างข้อผิดพลาด OOM (หน่วยความจำไม่เพียงพอ) เนื่องจากไม่มีหน่วยความจำหลักที่พร้อมใช้งานในระหว่างการประมวลผลงาน

ในพื้นที่ความปลอดภัยนี้ พื้นที่ฮีป JVM โดยรวมถูกแบ่งออกเป็นสามภูมิภาคย่อย: พื้นที่ unroll หน่วยเก็บข้อมูล และ shuffle ดังแสดงใน รูปที่ 2 พื้นที่ unroll ใช้สำหรับ unrolling บล็อกข้อมูลในหน่วยความจำ เมื่อ RDD ถูกแคชไว้บนสื่อจัดเก็บข้อมูลอื่น เช่น SSD หรือ HDD ที่ไม่ได้อยู่ในหน่วยความจำหลัก RDD ควรถูกทำให้เป็นอนุกรม จากนั้น เมื่อ Spark อ่าน RDD นี้กลับไปยังหน่วยความจำ จะต้องคลี่ RDD ออก พื้นที่เก็บข้อมูลใช้สำหรับแคช RDD หากพื้นที่จัดเก็บข้อมูลไม่เพียงพอสำหรับการแคช RDD RDD บางส่วนสามารถถูกไล่ออกจากพื้นที่นี้ได้ตามนโยบาย LRU (ใช้น้อยที่สุด) หรือสามารถแคชไว้บนสื่อจัดเก็บข้อมูลอื่น เช่น SSD พื้นที่สับเปลี่ยนจะใช้สำหรับการสับข้อมูลระดับกลาง พื้นที่สับเปลี่ยนนี้สามารถมีบทบาทสำคัญในแอปพลิเคชันที่ต้องทำซ้ำ เช่น การเรียนรู้ของเครื่อง เนื่องจากอาจส่งผลกระทบอย่างมากต่อเวลาการทำงานโดยรวมให้เสร็จสิ้น

ในการกำหนดค่า Spark เริ่มต้น พื้นที่จัดเก็บและพื้นที่สับเปลี่ยนของฮีป JVM มีอัตราส่วนเศษส่วนของความจุที่ {{0}}.6 และ 0.2 ตามลำดับ (เช่น 60 % ของพื้นที่ปลอดภัยสำหรับการจัดเก็บและ 20% สำหรับการสับเปลี่ยน) พื้นที่การคลายออกใช้ 20% ของพื้นที่เก็บข้อมูลตามค่าเริ่มต้น ความจุของทั้งสามช่องว่างของฮีป JVM สามารถตั้งค่าได้ด้วยประกายไฟ storage.unrollFraction, spark.storage.memoryFraction และ spark.shuffle.memoryFraction ตัวอย่างเช่น ในคลัสเตอร์ทดสอบของเรา เราสามารถตั้งค่า spark.executor.memory เป็น 2.6 GB ของหน่วยความจำ 4 GB ของโหนดผู้ปฏิบัติงาน ซึ่งหมายความว่าขนาดฮีป JVM ถูกกำหนดไว้ที่สูงสุด 2.6 GB จากนั้น ความจุจริงของพื้นที่เก็บข้อมูลและพื้นที่สับเปลี่ยนคือ 2.6 GB × 0.9 × 0.6 = 1.4 GB และ 2.6 GB × 0.9 × 0.2=0.46 GB, ตามลำดับ ดังนั้น พื้นที่ในการคลายออกจะใช้ 1.4 GB × 0.2=0.28 GB

3.3. นโยบายการแคช RDD

แพลตฟอร์ม Spark นำเสนอตัวเลือกแคช RDD ที่หลากหลายที่เกี่ยวข้องกับหน่วยความจำหลักและดิสก์ ตัวเลือกเริ่มต้นคือหน่วยความจำ_เท่านั้น โดยที่ RDD จะถูกเก็บรักษาไว้ในพื้นที่เก็บข้อมูลที่อธิบายไว้ในส่วนที่ 3.2 ว่าเป็นออบเจ็กต์ Java ที่ไม่ซีเรียลไลซ์ หากพื้นที่จัดเก็บข้อมูลนี้ไม่เพียงพอสำหรับการเก็บ RDD ทั้งหมด บางส่วนจะถูกไล่ออกจากหน่วยความจำหลักตามนโยบายการแทนที่แคชที่กำหนดไว้ล่วงหน้า อย่างไรก็ตาม เมื่อใดก็ตามที่จำเป็นต้องใช้ RDD ที่ไม่แคชสำหรับการประมวลผลงาน RDD นี้ควรถูกสร้างขึ้นใหม่โดยอิงตามข้อมูลเชื้อสาย ซึ่งอาจส่งผลให้ประสิทธิภาพลดลงอย่างมากในหน่วยความจำนี้_นโยบายการแคชเท่านั้น

นอกจากตัวเลือก MEMORY_ONLY แล้ว Spark ยังมีตัวเลือก MEMORY_AND_DISK, DISK_ONLY และ OFF_HEAP อีกด้วย ตัวเลือก MEMORY_AND_DISK จะจัดเก็บ RDD ไว้ในดิสก์แบบไม่ลบเลือน เมื่อพื้นที่เก็บข้อมูลไม่เพียงพอที่จะจัดเก็บ RDD ที่จำเป็นทั้งหมด ดิสก์อาจประกอบด้วย HDD หรือ SSD อย่างไรก็ตาม ดิสก์สปินเดิลปกติมีปริมาณงานการอ่าน/เขียนค่อนข้างต่ำ ดังนั้นเวลาดำเนินการโดยรวมอาจนานกว่าเวลาของตัวเลือกแคช MEMORY_ เท่านั้น เพื่อแก้ไขปัญหานี้ เราสามารถใช้ประโยชน์จาก SSD ได้อย่างมีประสิทธิภาพ ซึ่งอาจช่วยลดเวลาโดยรวมในการดำเนินการให้เสร็จสิ้นได้เมื่อเปรียบเทียบกับแนวทางที่ใช้ HDD ปกติ

ตัวเลือก DISK_ONLY จะจัดเก็บ RDD ไว้ในอุปกรณ์จัดเก็บข้อมูลแบบไม่ลบเลือนเท่านั้น เช่น HDD หรือ SSD กล่าวคือ ไม่ใช่ในหน่วยความจำหลัก คลัสเตอร์ที่มีหน่วยความจำไม่เพียงพอสามารถบรรลุประสิทธิภาพที่ดีได้ด้วยตัวเลือกนี้ ในกรณีนี้ เนื่องจาก RDD ถูกจัดเก็บไว้ในสื่อดิสก์เท่านั้น พื้นที่สับเปลี่ยนจึงสามารถขยายได้แทนที่จะใช้พื้นที่เก็บข้อมูลของหน่วยความจำ ด้วยเหตุนี้ เมื่อเรียกใช้แอปพลิเคชัน เช่น PageRank ซึ่งสร้างข้อมูลสับเปลี่ยนจำนวนมาก เราจะสังเกตเห็นประสิทธิภาพที่ดีกว่าในกรณีของหน่วยความจำ_เท่านั้น

ตัวเลือก OFF_HEAP ช่วยให้ Spark ใช้พื้นที่นอกฮีป ซึ่งอยู่นอกการจัดการของตัวรวบรวมขยะ Java ดังนั้น หากเราใช้พื้นที่นอกฮีป เราต้องจัดการกับการดำเนินการของหน่วยความจำที่ซับซ้อน เช่น การจัดสรร/การจัดสรรคืน และการทำให้เป็นอนุกรม/ดีซีเรียลไลซ์ ดังนั้นในทางปฏิบัติ เราจึงไม่ใช้การกำหนดค่า OFF_HEAP

3.4. วิธีการเพิ่มประสิทธิภาพ

ดังที่เราได้พูดคุยไปแล้วในส่วน 3.2 และ 3.3 วิธีการปรับให้เหมาะสมของเราประกอบด้วย (1) การกำหนดค่าฮีป Spark JVM และ (2) ตัวเลือกการทดลองของนโยบายการแคช RDD ดังนี้

1. การกำหนดค่าฮีป Spark JVM: เราตรวจสอบผลกระทบของการเปลี่ยนแปลงอัตราส่วนความจุของการสับเปลี่ยนและพื้นที่จัดเก็บข้อมูล อัตราส่วนของการสับเปลี่ยนและพื้นที่จัดเก็บคือ 60%:30%, 50%:40% และ 20%:60% ตามลำดับ อัตราส่วนการสุ่มและการจัดเก็บ "20%:60%" เป็นค่าเริ่มต้นในการตั้งค่า Spark เราเลือก "60%:30%" เพื่อเปรียบเทียบผลลัพธ์ด้วยพื้นที่สุ่มที่เพียงพอ และกำหนดค่า "50%:40%" เพื่อแสดงประสิทธิภาพอย่างสมดุล

2. นโยบายการแคช RDD: เรายังตรวจสอบผลกระทบของนโยบายการแคช RDD ที่แตกต่างกันด้วย เราเปรียบเทียบประสิทธิภาพของนโยบายต่างๆ เช่น OFF_HEAP, MEMORY_ONLY, MEMORY_AND_DISK และ DISK_ONLY โดยที่ DISK หมายถึง SSD ในการทดลองนี้

ตารางที่ 3 แสดงการกำหนดค่าการทดลองที่แตกต่างกันทั้งหมด 12 รูปแบบตามนโยบายการแคช RDD และอัตราส่วนเศษส่วนของความจุ Spark JVM ในการกำหนดค่าการทดลองที่มีป้ายกำกับด้วย "_1" (เช่น "N_1") เราได้ตั้งค่า 60% ของฮีป Spark JVM สำหรับการสับเปลี่ยนและ 30% สำหรับพื้นที่จัดเก็บข้อมูล ด้วยป้ายกำกับ "_2" เราได้ตั้งค่าฮีป Spark JVM 50% สำหรับการสับและ 40% สำหรับการจัดเก็บข้อมูล สุดท้ายนี้ สำหรับผู้ที่มีป้ายกำกับว่า "_3" เราได้ตั้งค่า 20% ของฮีป Spark JVM สำหรับการสับและ 60% สำหรับการจัดเก็บ ดังที่เห็นได้จากคอลัมน์ "ตัวเลือก", "สับเปลี่ยน" และ "การจัดเก็บ" ในตารางที่ 3 โปรดทราบว่าขนาดหน่วยความจำสูงสุดของคลัสเตอร์ทดสอบของเราคือ 2.7 GB กล่าวคือ แต่ละโหนดของผู้ปฏิบัติงานจะมี 2.7 GB เป็นขนาดฮีป Spark JVM

ในแง่ของนโยบายการแคช RDD ตัวเลือก "N" ไม่ใช่การแคช RDD ตัวเลือก "M" คือการแคช RDD บนหน่วยความจำเท่านั้น ตัวเลือก "M&S" คือการแคช RDD บนหน่วยความจำและ SSD ร่วมกัน และสุดท้ายตัวเลือก "S" ใช้สำหรับแคช RDD บน SSD เท่านั้น

จากการทดลองของเรา เราเสนอกลยุทธ์การปรับให้เหมาะสมที่สามารถบรรลุประสิทธิภาพที่ดีที่สุดจากคลัสเตอร์ซึ่งมีจำนวนหน่วยความจำไม่เพียงพอโดยการปรับการกำหนดค่าฮีป Spark JVM อย่างระมัดระวัง และใช้นโยบายการแคช RDD ที่มีประสิทธิผล ดังที่เราจะเห็นในส่วนที่ 4

4. ผลการทดลองและการวิเคราะห์

4.1. การทดสอบ PageRank ขนาด 500 MB

4.1.1. ผลลัพธ์ด้วยการเปลี่ยนการกำหนดค่า JVM Heap

รูปที่ 3 แสดงผลการทดลองของแต่ละขั้นตอนในปริมาณงาน PageRank โดยการเปลี่ยนขนาดฮีป JVM ในระยะที่แตกต่าง Spark จะอ่านข้อมูลอินพุตและแยกแยะ URL และลิงก์ ดังที่เราเห็นจากผลลัพธ์ของระยะ Distinct0 เวลาดำเนินการโดยรวมลดลงโดยการเปลี่ยนขนาดฮีป JVM จากตัวเลือก _1 และ _2 เป็น _3 เนื่องจากสาเหตุหลักมาจาก สู่การเก็บขยะ (GC) ตัวอย่างเช่น เวลา GC จะใช้เวลา 25 วินาที, 24 วินาที และ 16 วินาทีใน M&S_1, M&S_2 และ M&S{{10}} ตามลำดับ ดังนั้น ในระยะ Distinct0 เมื่อเราเพิ่มจำนวนพื้นที่เก็บข้อมูล เราก็สามารถปรับปรุงประสิทธิภาพโดยรวมได้โดยการลดเวลา GC ในทางกลับกัน ในระยะ Distinct1 เวลาดำเนินการโดยรวมจะเพิ่มขึ้นเมื่อเราเปลี่ยนตัวเลือกจาก _1 และ _2 เป็น _3 สาเหตุหลักมาจากการสุ่มหก เมื่อเราตรวจสอบ Spark web UI ข้อมูลสับเปลี่ยนจะรั่วไหลไปยังดิสก์เนื่องจากไม่มีพื้นที่หน่วยความจำสับเปลี่ยน ตัวอย่างเช่น ขนาดของข้อมูลการสุ่มแบบสุ่มบนดิสก์ใน M&S_1, M&S_2 และ M&S_3 คือ 0, 220 MB และ 376 MB ตามลำดับ เมื่อการสับเปลี่ยนแบบสุ่มเกิดขึ้น CPU โอเวอร์เฮดสำหรับการกระจายข้อมูลลงบนดิสก์จะเพิ่มขึ้นเนื่องจากข้อมูลจำเป็นต้องถูกทำให้เป็นอนุกรม

หลังจากด่าน Distinct จะมีด่าน flatMap ซ้ำๆ เพื่อรับอันดับ ขั้นตอน FlatMap สร้างข้อมูลสับเปลี่ยนจำนวนมาก ซึ่งอาจทำให้คลัสเตอร์ของเราขาดพื้นที่หน่วยความจำสับเปลี่ยนที่จำเป็น ดังนั้น เมื่อจำนวนพื้นที่สับเปลี่ยนที่มีอยู่ลดลง (ตามลำดับจากตัวเลือก _1, _2 และ _3) จึงอาจเกิดการรั่วไหลของสับเปลี่ยนได้มากขึ้น ซึ่งอาจส่งผลต่อการดำเนินงานโดยรวม เวลา (เช่น M&S ตัวเลือก flatMap2 stage _1: 37 วินาที, _2: 40 วินาที, _3: 49 วินาที) อย่างไรก็ตาม เมื่อข้อมูลถูกแคชไว้บนหน่วยความจำเท่านั้น (เช่น M_1, M_2 และ M_3) ข้อมูลเหล่านั้นจะแสดงรูปแบบอื่น สาเหตุหลักของลักษณะการทำงานนี้คือ Spark scheduler จัดกำหนดการงานไม่สม่ำเสมอ เนื่องจากไม่มีพื้นที่เก็บข้อมูลหน่วยความจำสำหรับแคช RDD บนตัวเลือก _1 และ _2 ถ้าผู้ปฏิบัติงานไม่มี RDD เขาจะถูกแยกออกจากกลุ่มการจัดกำหนดการ ดังนั้นผู้ปฏิบัติงานคนอื่นๆ จึงต้องจัดการงานเพิ่มเติมด้วยค่าโสหุ้ย GC ซึ่งอาจส่งผลต่อเวลาปฏิบัติงานทั้งหมด

4.1.2. ผลลัพธ์ด้วยการเปลี่ยนตัวเลือกการแคช RDD

ประการแรก ขั้นตอนที่แตกต่างจะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงนโยบายการแคช RDD แต่จะเกิดจากการใช้หน่วยความจำเท่านั้น ระยะที่ได้รับผลกระทบจากตัวเลือกการแคช RDD คือระยะ flatMap เนื่องจากในระหว่างเฟสสับเปลี่ยน RDD ที่แคชไว้จะถูกใช้อีกครั้ง

ในรูปที่ 4 กราฟจะถูกทำให้เป็นมาตรฐานด้วยตัวเลือก N_1 ที่ไม่แคชการกำหนดค่าหน่วยความจำ RDD และ _1 เพื่อตรวจสอบความแตกต่างด้านประสิทธิภาพ เมื่อเปรียบเทียบเฉพาะกราฟของ _1 ตามลำดับของ M_1, M&S_1 และ S_1 ประสิทธิภาพลดลง 32% ใน M{{8 }} และการปรับปรุงประสิทธิภาพ 30% และ 20% ด้วย M&S_1 และ S_1 ตามลำดับ ด้วยตัวเลือก M_1 สาเหตุของประสิทธิภาพที่ค่อนข้างต่ำก็คือ RDD ถูกแคชไม่สม่ำเสมอเนื่องจากไม่มีพื้นที่จัดเก็บ ซึ่งจะส่งผลให้กำหนดเวลาไม่สม่ำเสมอดังที่เราได้กล่าวไว้ก่อนหน้านี้ ซึ่งหมายความว่าพื้นที่ฮีป JVM ไม่เพียงพอสำหรับการสับข้อมูลและบันทึก RDD

เพื่อแก้ไขปัญหานี้ เราได้กระจาย RDD ไปยังแคชทั้งบนหน่วยความจำและ SSD ซึ่งสามารถปรับปรุงประสิทธิภาพดังที่แสดงด้วยตัวเลือก M&S_1 การแคช RDD บนหน่วยความจำจะช่วยเพิ่มความเร็วในการเข้าถึงสำหรับ RDD และการแคช RDD บน SSD สามารถหลีกเลี่ยงปัญหาการสับเปลี่ยนได้โดยการขยายพื้นที่การสับเปลี่ยนที่มีอยู่ในหน่วยความจำอย่างมีประสิทธิภาพ ด้วยตัวเลือก S_1 ที่แสดงการปรับปรุงประสิทธิภาพ 20% RDD จะถูกแคชไว้บน SSD เท่านั้น การสุ่มแบบสุ่มจะลดลงโดยการแคช RDD บน SSD อย่างไรก็ตาม มีการปรับปรุงประสิทธิภาพที่ต่ำกว่า M&S_1 โดยที่ RDD ส่วนใหญ่จะแคชอยู่ในหน่วยความจำและนำกลับมาใช้ซ้ำจากหน่วยความจำ

ในการกำหนดค่าเริ่มต้นของ Spark ซึ่งก็คือตัวเลือก _3 เราจะเห็นว่าตามลำดับของ M_3, M&S_3, S_3 และ N{{4 }} ประสิทธิภาพโดยรวมลดลง ในการกำหนดค่าเริ่มต้น พื้นที่จัดเก็บของฮีป JVM นั้นเพียงพอสำหรับ RDD ที่จะแคชอย่างสมดุล ดังนั้นประสิทธิภาพโดยรวมจึงขึ้นอยู่กับประสิทธิภาพของอุปกรณ์หน่วยความจำที่ใช้เป็นหลัก อย่างไรก็ตาม เรายังคงเห็นประสิทธิภาพที่ดีที่สุดด้วยตัวเลือก M&S_1 เนื่องจากเราสามารถลดเวลา GC และการสุ่มแบบสุ่มได้อย่างมีประสิทธิภาพโดยการแคช RDD ทั้งในหน่วยความจำและ SSD

4.2. ประสิทธิภาพเพจแรงก์ 1 GB

เราทดลองกับปริมาณงาน PageRank โดยการเพิ่มขนาดข้อมูลจาก 500 MB เป็น 1 GB รูปที่ 5 แสดงพฤติกรรมที่แตกต่างกันของระบบเมื่อเปรียบเทียบกับ PageRank สำหรับชุดข้อมูลขนาด 500 MB เราจะเห็นงานที่ล้มเหลวบางงานที่ไม่สามารถทำงานให้สำเร็จได้จนกว่าจะถึงขั้นที่ 6 (เช่น N_1, N_2, M_1, M_2, M _3, M&S_3) ในบรรดางานที่ล้มเหลวเหล่านี้ มีงานที่ล้มเหลวในระยะ flatMap2 ซึ่งได้แก่ N_1, N_2 และ M_1 สาเหตุของความล้มเหลวของงานคือหน่วยความจำไม่เพียงพอ GC เกิดขึ้นเมื่อ RDD ถูกแคชไว้ในหน่วยความจำไม่เพียงพอ เนื่องจากค่าใช้จ่าย GC นี้ ตัวดำเนินการ Spark ได้รับข้อยกเว้น ExecutorLostFailure

M_2, M_3 และ M&S_3 สามารถดำเนินการประมวลผลต่อไปได้จนถึงระยะ flatMap2 อย่างไรก็ตาม หลังจากนี้ ความล้มเหลวก็เกิดขึ้น M&S_3 ทำงานคล้ายกับ M_3 จนถึงระยะ flatMap2 เพราะเมื่อใช้ตัวเลือก M&S_3 จะมีหน่วยความจำเพียงพอที่จะแคช RDD หลังจาก flatMap2 ข้อผิดพลาด OutOfMemory เกิดขึ้นเนื่องจากการไม่มีพื้นที่หน่วยความจำแบบสุ่มในระยะ flatMap3

4.2.1. ผลลัพธ์ด้วยการเปลี่ยนการกำหนดค่า JVM Heap

ระยะที่แตกต่าง0 แสดงผลลัพธ์ที่คล้ายกันมากกับชุดข้อมูล 500 MB และประสิทธิภาพโดยรวมได้รับการปรับปรุงตามลำดับตัวเลือก _1, _2 และ _3 เนื่องจากเวลา GC ลดลงเหลือ 78 วินาที, 59 วินาที และ 28 วินาที ตามลำดับ

ในทางกลับกัน ในระยะ Distinct1 จะแสดงผลลัพธ์ที่แตกต่างกันสำหรับชุดข้อมูล 500 MB ในการทดลองชุดข้อมูลขนาด 500 MB เราจะเห็นประสิทธิภาพที่เพิ่มขึ้นโดยการเพิ่มพื้นที่สับเปลี่ยนของหน่วยความจำ อย่างไรก็ตาม ในการทดลองชุดข้อมูล 1GB หน่วยความจำของผู้ดำเนินการของโหนดผู้ปฏิบัติงานไม่สามารถรองรับข้อมูลขนาดใหญ่ได้ ดังนั้นพื้นที่สับเปลี่ยนของหน่วยความจำจึงค่อนข้างไม่เพียงพอ ตัวอย่างเช่น จำนวนของการสับเปลี่ยนแบบสุ่มสำหรับตัวเลือก _1, _2 และ _3 คือ 575.5 MB, 813.8 MB และ 843.4 MB ตามลำดับ และเวลา GC ใช้เวลา 33 วินาที 10 s และ 8 ตามลำดับ ดังที่เราได้กล่าวไว้ก่อนหน้านี้ เมื่อเกิดการสุ่มแบบสุ่ม RDD จะต้องได้รับการซีเรียลไลซ์เพื่อให้สามารถคำนวณ CPU ได้มากขึ้น ซึ่งอาจส่งผลให้ประสิทธิภาพโดยรวมลดลง

4.2.2. ผลลัพธ์ของการเปลี่ยนแปลงนโยบายการแคช RDD

สำหรับการวิเคราะห์เวลาดำเนินการโดยการเปลี่ยนนโยบายการแคช RDD ดังที่เราเห็นจากรูปที่ 6 เราจะแยกขั้นตอนที่แตกต่างจากรูปที่ 5 เนื่องจากเราไม่จำเป็นต้องวิเคราะห์ขั้นตอนที่แตกต่างกันเนื่องจากไม่มีการเปลี่ยนแปลงที่เกิดจากการเปลี่ยนแปลงนโยบายการแคช RDD .

สิ่งที่น่าสนใจคือไม่มีการเปลี่ยนแปลงกับการกำหนดค่าฮีป JVM ต่างๆ ในขั้นตอน flatMap เมื่อเทียบกับกรณีของชุดข้อมูล 500 MB เหตุผลก็คือ Shuffle Spill เกิดขึ้นในการกำหนดค่าทั้งหมดเนื่องจากมีหน่วยความจำไม่เพียงพอ เวลาดำเนินการโดยรวมโดยการเปลี่ยนตัวเลือกการแคช RDD จะเพิ่มขึ้นตามลำดับของ M&S, S, N และ M (M&S เป็นตัวเลือกที่เร็วที่สุด) ในตัวเลือก N ข้อผิดพลาด ExecutorLostFailure เกิดขึ้นเนื่องจากมีพื้นที่หน่วยความจำไม่เพียงพอ ในตัวเลือก M เมื่อ RDD ถูกแคชไว้ในหน่วยความจำ โอเวอร์เฮดของ GC จะเกิดขึ้นเนื่องจากมีพื้นที่หน่วยความจำไม่เพียงพอ แม้ว่า RDD จะถูกแคชไว้ในหน่วยความจำ งานล้มเหลวเนื่องจากข้อผิดพลาด ExecutorLostFailure ที่เกิดขึ้นเมื่อพื้นที่หน่วยความจำสับเปลี่ยนไม่เพียงพอ (OutOfMemory)

ในสถานการณ์ที่มีหน่วยความจำเหลือน้อย ตัวเลือก M&S และ S อาจเป็นทางเลือกที่มีประสิทธิภาพได้ ในตัวเลือก M&S{{0}} เราเพิ่มความสามารถในการเข้าถึงของ RDD โดยการแคช RDD โดยใช้ทั้งหน่วยความจำและ SSD ด้วยเหตุนี้ จึงมีการปรับปรุงประสิทธิภาพด้วยเหตุผลเดียวกันกับชุดข้อมูลขนาด 500 MB นอกจากนี้ ยังมีพื้นที่หน่วยความจำสับเปลี่ยนเพียงพอเนื่องจากการแคช RDD บน SSD ดังที่เห็นในรูปที่ 6 ตัวเลือก M&S_1 กลายเป็นตัวเลือกที่เร็วที่สุดในการทดลองนี้ (M&S_1:0.6, S_1:0.63, T_1 0.64)

4.3. การวิเคราะห์การทดลอง TC

รูปที่ 7 แสดงผลลัพธ์ของการทดลอง TC (การปิดสกรรมกริยา) ที่ใช้ข้อมูลอินพุตที่เกี่ยวข้องกับขอบ 50,000 และ 25,{4}} จุดยอดที่สร้างขึ้นโดยการสุ่ม หมายเลขการวนซ้ำคือ 10 ผ่านการวนซ้ำ จำนวนงานจะเพิ่มเป็นสองเท่าในแต่ละการวนซ้ำ ดังนั้น ขนาดของ RDD จะเพิ่มขึ้น และจำนวนการอ่านและเขียนแบบสุ่มก็เพิ่มขึ้นเช่นกัน ในการวนซ้ำครั้งล่าสุด จำนวนงานจะกลายเป็น 4096 เนื่องจากมีขั้นตอนการวนซ้ำมากขึ้น จึงมีผลกระทบมากขึ้นต่อเวลาดำเนินงานทั้งหมด และขั้นตอนการวนซ้ำครั้งสุดท้ายเป็นขั้นตอนที่ใหญ่ที่สุด ซึ่งประกอบด้วยงานจำนวนมากที่สามารถลดประสิทธิภาพโดยรวมลงได้ .

ดังที่เราเห็นจากรูปที่ 7 ประสิทธิภาพดีขึ้นตามลำดับ _3, _2 และ _1 บนตัวเลือก M, M&S และ S ซึ่งหมายความว่าได้รับการสับเปลี่ยนที่เพียงพอ หน่วยความจำของฮีป JVM นั้นมีประโยชน์ ด้วยตัวเลือก M ประสิทธิภาพของตัวเลือก _1 จะเร็วกว่าตัวเลือก _3 ถึง 18% ในขณะที่ในตัวเลือก M&S ประสิทธิภาพของตัวเลือก _1 จะเร็วกว่า {{9 3% }} ในตัวเลือก S ประสิทธิภาพของ _1 จะเร็วกว่า _3 2%

เมื่อเรามุ่งเน้นไปที่การเปลี่ยนตัวเลือกการแคช RDD ประสิทธิภาพของตัวเลือก S_1 จะเร็วกว่า N_1 ถึง 42% และยังเร็วกว่า M_1 ถึง 31% อีกด้วย เหตุผลในการเพิ่มประสิทธิภาพการทำงานของเวลาดำเนินงานขึ้นอยู่กับขั้นตอนการวนซ้ำครั้งล่าสุด ปัจจัยสำคัญที่ส่งผลต่อขั้นตอนการวนซ้ำครั้งล่าสุดคือเวลาที่บล็อกการอ่านแบบสุ่ม เวลาที่บล็อกการอ่านแบบสุ่มเกิดขึ้นเมื่อ RDD ที่ดำเนินการในขั้นตอนก่อนหน้าถูกอ่านจากโหนดของผู้ปฏิบัติงานอื่นผ่านเครือข่าย เนื่องจากไม่มีหน่วยความจำของตัวดำเนินการ

แม้ว่าแต่ละงานจะมีประสิทธิภาพเพิ่มขึ้นประมาณ 1–2 วินาทีผ่านการแก้ไขเวลาที่บล็อกการอ่านแบบสุ่ม เราก็สามารถบรรลุประสิทธิภาพที่เพิ่มขึ้นได้อย่างมีนัยสำคัญ เนื่องจากในสถานะสุดท้าย จำนวนงานค่อนข้างมาก (เช่น 4096) นอกจากนี้ ปัจจัยหลักประการหนึ่งที่ส่งผลต่อเวลาปฏิบัติงานคือขั้นตอนการนับ ซึ่งจะนับจำนวนขอบที่เมทริกซ์ TC มีในงานสุดท้าย

ด้วยตัวเลือก N เนื่องจากไม่มีการแคช RDD ในขั้นตอนการนับ Spark จะอ่านข้อมูลสับเปลี่ยนที่ดำเนินการจากขั้นตอนก่อนหน้า ซึ่งใช้เวลา 60 วินาที นอกจากนี้ ในตัวเลือก M RDD จะไม่ถูกแคชไว้ในหน่วยความจำเนื่องจากไม่มีหน่วยความจำที่เรียกใช้งาน เป็นผลให้ต้องใช้เวลา 60 วินาทีด้วย อย่างไรก็ตาม ในตัวเลือก M&S และ S นั้น RDD สามารถแคชไว้ในหน่วยความจำและ SSD ได้ เพื่อให้ใช้เวลาเพียง 2 วินาทีในการนับ

4.4. การวิเคราะห์การทดลอง TeraSort

รูปที่ 8 แสดงผลการทดลองของเกณฑ์มาตรฐาน TeraSort ที่ใช้ชุดข้อมูล 10 GB โดยการเปลี่ยนการกำหนดค่าฮีป JVM และตัวเลือกการแคช RDD กราฟนี้ทำให้เป็นมาตรฐานด้วยตัวเลือก N_1 เราจะเห็นได้ว่าเวลาปฏิบัติงานทั้งหมดจะใกล้เคียงกัน ความแตกต่างระหว่างพวกเขาน้อยกว่า 5% ในปริมาณงานของ TeraSort ไม่มีการปรับปรุงหรือลดประสิทธิภาพโดยการเปลี่ยนการกำหนดค่าและตัวเลือก ในขั้นตอนการเรียงลำดับ มีการสับเปลี่ยนเล็กน้อยผ่านเครือข่าย อย่างไรก็ตาม ขนาดของการอ่านแบบสุ่มและการเขียนแบบสุ่มคือ 25 MB ในแต่ละครั้ง ซึ่งค่อนข้างเล็กเมื่อเทียบกับ PageRank และ TC ดังนั้นการกำหนดค่าฮีป JVM และตัวเลือกการแคช RDD จึงไม่ส่งผลต่อประสิทธิภาพการทำงาน นอกจากนี้ ปริมาณงานของ TeraSort ไม่ได้ประกอบด้วยงานวนซ้ำเช่นเดียวกับการปิดสกรรมกริยา ดังนั้นจึงไม่ได้รับประโยชน์จากการแคช RDD ในขั้นตอนก่อนหน้า

4.5. การวิเคราะห์การทดลองการจัดกลุ่ม K-Means

เวลาเสร็จสิ้นงานมาตรฐานของการจัดกลุ่มเคมีนสำหรับชุดข้อมูล 1.5 GB แสดงในรูปที่ 9 วัตถุประสงค์ของการจัดกลุ่มเคมีนคือการค้นหากลุ่ม k ในชุดข้อมูลโดยอาศัยการวัดระยะทาง (เช่น ระยะทางแบบยุคลิด) ในเวิร์กโหลดนี้ อัลกอริธึมจะลด SSE (ผลรวมของข้อผิดพลาดกำลังสอง) [24] โดยการวนซ้ำการคำนวณระยะทางระหว่างจุดศูนย์กลาง k และจุดข้อมูลแต่ละจุด ในการทดลองนี้ เราทำซ้ำกระบวนการนี้แปดครั้ง จำนวนข้อมูลที่จะสับเปลี่ยนมีน้อย เนื่องจากข้อมูลที่ต้องการจากขั้นตอนก่อนหน้าคือข้อมูลเกี่ยวกับจุดกึ่งกลางและ SSE ในแต่ละขั้นตอน ในปริมาณงานการทำคลัสเตอร์ k-mean ของเรา จำนวนสูงสุดของข้อมูลการอ่าน/เขียนแบบสุ่มคือ 1.0 MB และขั้นต่ำคือ 0.8 MB การสุ่มแบบสุ่มไม่เกิดขึ้นที่นี่เนื่องจากพื้นที่การสับเปลี่ยนเพียงพอในการตั้งค่าทั้งหมด ในการทดลองที่ไม่มีตัวเลือกแคช ไม่มีความแตกต่างระหว่างตัวเลือก _1, _2 และ _3 เนื่องจากการตั้งค่าเหล่านี้ไม่ได้แคช RDD ใดๆ และในการตั้งค่าทั้งสาม การสับเปลี่ยน พื้นที่เพียงพอ

เมื่อทำการแคช RDD ในหน่วยความจำหลักหรือหน่วยความจำและ SSD ยิ่งพื้นที่จัดเก็บข้อมูลสำหรับ RDD มากเท่าใด ประสิทธิภาพในเวลาดำเนินการก็จะดีขึ้นเท่านั้น เนื่องจากสามารถแคช RDD ได้มากขึ้นในพื้นที่จัดเก็บข้อมูล เมื่อเปรียบเทียบหน่วยความจำ_เฉพาะตัวเลือกและหน่วยความจำ_และ_ตัวเลือก SSD หน่วยความจำ_และ_ตัวเลือก SSD มีการปรับปรุงประสิทธิภาพที่ดีขึ้น เนื่องจากในตัวเลือกหน่วยความจำ_เท่านั้น พื้นที่เก็บข้อมูลไม่เพียงพอแม้จะอยู่ในตัวเลือก M_3 ก็ตาม นอกจากนี้ การแคช RDD บน SSD ยังช่วยแก้ปัญหาการขาดหน่วยความจำจัดเก็บข้อมูลดังกล่าว ตัวเลือกหน่วยความจำ_และ_SSD ปรับปรุงประสิทธิภาพโดยเฉลี่ย 10% เมื่อเทียบกับตัวเลือกหน่วยความจำ_เท่านั้น

โปรดทราบว่าปริมาณงานการทำคลัสเตอร์ k-means แสดงแนวโน้มประสิทธิภาพที่ตรงกันข้ามจากปริมาณเพจแรงก์และการปิดสกรรมกริยา เนื่องจากความแตกต่างในปริมาณข้อมูลสับเปลี่ยน เราจะหารือเรื่องนี้โดยละเอียดในส่วนย่อยต่อไปนี้

5. การอภิปรายและสรุป

5.1. การอภิปราย

เราวิเคราะห์ปัจจัยหลักของปัญหาการลดประสิทธิภาพที่อาจเกิดขึ้นโดยพิจารณาจากคุณลักษณะของปริมาณงานและขั้นตอนการประมวลผล ผลการทดลองที่ครอบคลุมของเราสรุปเกี่ยวกับการใช้เทคนิคการเพิ่มประสิทธิภาพการทำงานของแพลตฟอร์ม Spark สำหรับปริมาณงานต่างๆ ดังต่อไปนี้:

• ประสิทธิภาพลดลงโดยการรวบรวมขยะ Java: ในปริมาณงาน PageRank ที่มีชุดข้อมูล 500 MB และชุดข้อมูล 1GB GC จะเกิดขึ้นเมื่อมีพื้นที่เก็บข้อมูลของฮีป JVM ไม่เพียงพอในการจัดเก็บ RDD ในระยะ Distinct0 ซึ่งอ่านไฟล์อินพุตจาก HDFS และแคชลงใน RDD GC จะเกิดขึ้น เราขยายพื้นที่จัดเก็บข้อมูลของฮีป JVM ผ่านการกำหนดค่าเพื่อแก้ไขปัญหา GC นี้ เราสามารถปรับปรุงประสิทธิภาพเพื่อลด GC ได้เนื่องจากพื้นที่เก็บข้อมูลของฮีป JVM สามารถขยายได้ ในรูปที่ 3 และ 5 ด้วยตัวเลือกแคช RDD เดียวกัน การกำหนดค่า _3 จะแสดงประสิทธิภาพที่ดีที่สุดในระยะ Distinct0 นอกจากนี้ ใน PageRank ที่มีชุดข้อมูล 1 GB ตัวเลือกบางตัวจะล้มเหลวในระยะ flatMap เนื่องจากไม่มีหน่วยความจำ ค่าใช้จ่าย GC เพิ่มขึ้นมากจนขั้นตอนล้มเหลวหรือเข้าสู่วงวนไม่สิ้นสุด ดังนั้นเราจึงสร้างคลัสเตอร์ด้วย SSD เพื่อแก้ไขปัญหานี้ มันแสดงให้เห็นถึงการปรับปรุงประสิทธิภาพและประสบความสำเร็จในงานที่ล้มเหลวโดยใช้เพียงหน่วยความจำ ดังแสดงในรูปที่ 6, M&S_1 และ S_1

• ประสิทธิภาพลดลงเนื่องจากการสุ่มแบบสุ่ม: ในปริมาณงาน PageRank ที่มีชุดข้อมูล 500 MB และชุดข้อมูล 1 GB ในระยะ flatMap เราจะเห็นว่าตัวเลือก M&S_1 แสดงประสิทธิภาพที่ดีที่สุดเนื่องจากมีการสับเปลี่ยนน้อยที่สุด การรั่วไหล (รูปที่ 4: M&S_1 เร็วกว่า N_1 30%; รูปที่ 6: M&S_1 เร็วกว่า N_3 40%) PageRank มีงานสับเปลี่ยนมากมาย ดังนั้น เมื่อพื้นที่สับเปลี่ยนของฮีป JVM ไม่เพียงพอสำหรับการสับข้อมูลผ่านเครือข่าย การสับเปลี่ยนจะเกิดขึ้น ดังนั้น เพื่อลดการรั่วไหลของสับเปลี่ยน การขยายพื้นที่สับเปลี่ยนของฮีป JVM จึงกลายเป็นปัจจัยสำคัญของการปรับปรุงประสิทธิภาพ

นอกจากนี้ เราสามารถปรับปรุงประสิทธิภาพได้โดยการจัดเก็บ RDD ทั้งในหน่วยความจำและ SSD ซึ่งสามารถทำให้ผู้ดำเนินการขยายหน่วยความจำแบบสุ่มของฮีป JVM เพื่อลดการรั่วไหลแบบสุ่ม หากมีการวนซ้ำมากขึ้น ประสิทธิภาพจากระยะ flatMap จะเป็นจุดสำคัญของการปรับปรุงประสิทธิภาพ ในการทดสอบชุดข้อมูล 1GB เวลาดำเนินการงานของ S_3 เป็นตัวเลือกที่ดีที่สุด เนื่องจาก RDD จะถูกแคชไว้บน SSD เท่านั้น และมีหน่วยความจำฮีปเพียงพอบนตัวดำเนินการ ดังนั้นในตัวเลือก S_3 ระยะที่แตกต่างจึงเร็วกว่าตัวเลือกอื่นๆ อย่างไรก็ตาม หากจำนวนการวนซ้ำเพิ่มขึ้น ระยะ flatMap จะส่งผลต่อเวลาดำเนินงาน ดังนั้น ตัวเลือก M&S_1 จึงสามารถบรรลุประสิทธิภาพที่ยอดเยี่ยมในกรณีนี้ จากการวิเคราะห์เหล่านี้ เราสามารถระบุได้ว่าการสับเปลี่ยนมีผลกระทบสำคัญต่อเวลาที่งานเสร็จสมบูรณ์ ดังนั้น เราจะต้องขยายหน่วยความจำแบบสุ่มของฮีป JVM และแคช RDD ทั้งในหน่วยความจำและ SSD เพื่อให้ได้พื้นที่หน่วยความจำแบบสุ่มเพียงพอสำหรับการป้องกันการรั่วไหลแบบสุ่ม

• ประสิทธิภาพลดลงเนื่องจากเวลาในการบล็อกการอ่านแบบสุ่ม: มีเวลาบล็อกการอ่านแบบสุ่มบนภาระงาน TC มันเกิดขึ้นเมื่อมีงานจำนวนมากในขั้นตอน และแต่ละงานจำเป็นต้องอ่าน RDD ก่อนหน้าผ่านเครือข่าย จากการทดลอง TC (รูปที่ 7) ตัวเลือก M&S จะเร็วกว่าตัวเลือก M ในตัวเลือกการแคช RDD เดียวกัน การขยายพื้นที่สับเปลี่ยนของฮีป JVM จะเร็วกว่าการขยายพื้นที่จัดเก็บข้อมูล เหตุผลในการปรับปรุงประสิทธิภาพคือการขยายพื้นที่สับเปลี่ยนของฮีป JVM เวลาในการบล็อกการอ่านสับเปลี่ยนจะลดลงในแต่ละงาน

5.2. สรุป: วิธีไหนดีที่สุด?

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

• การกำหนดค่าฮีป Spark JVM—พื้นที่สับเปลี่ยนเทียบกับพื้นที่จัดเก็บข้อมูล: จากผลการทดลองของปริมาณงานที่แตกต่างกันสี่รายการ เราสามารถสังเกตความแตกต่างของประสิทธิภาพได้ขึ้นอยู่กับลักษณะเฉพาะของปริมาณงาน ตัวอย่างเช่น PageRank เป็นตัวอย่างทั่วไปของการมีข้อมูลสับเปลี่ยนจำนวนมาก ดังนั้นการจัดสรรหน่วยความจำเพิ่มเติมให้กับส่วนสับเปลี่ยนจะช่วยปรับปรุงประสิทธิภาพโดยรวม อย่างไรก็ตาม ในกรณีของการจัดกลุ่มแบบเคมีน ยิ่งเราจัดสรรให้กับหน่วยความจำหน่วยเก็บข้อมูลมากเท่าไร ตรงกันข้ามกับหน่วยความจำแบบสับเปลี่ยน เวลาในการดำเนินการก็จะน้อยลง ดังนั้น หากเราสามารถปรับเปอร์เซ็นต์การจัดสรรหน่วยความจำ JVM แบบไดนามิกตามคุณลักษณะของเวิร์กโหลด เราก็สามารถปรับเวลาดำเนินการทั้งหมดให้เหมาะสมได้ Hadoop YARN [25] ช่วยให้เราสามารถมอบหมายงานให้กับคลัสเตอร์ประเภทต่างๆ (การกำหนดค่า) เพื่อให้เราสามารถนำแนวคิดนี้ไปใช้กับคลัสเตอร์ Hadoop ขนาดใหญ่เพื่อให้ตรงตามคุณลักษณะของหน่วยความจำสำหรับงานประเภทต่างๆ

• นโยบายการแคช RDD—หน่วยความจำเทียบกับ SSD: ในกรณีส่วนใหญ่ การแคชหน่วยความจำที่สนับสนุน SSD จะแสดงประสิทธิภาพที่ดีที่สุด เว้นแต่ RDD ทั้งหมดจะสามารถใส่ลงในหน่วยความจำหลักจริงได้ ดังนั้น นโยบายการแคชหน่วยความจำที่ใช้ SSD จึงเป็นทางเลือกที่เหมาะสมสำหรับเวิร์กโหลดที่ท้าทาย ซึ่งต้องใช้หน่วยความจำหลักจำนวนมากซึ่งโหนดเดียวในคลัสเตอร์ไม่สามารถตอบสนองได้

6. ข้อสรุป

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

การรวบรวมขยะ Java เกิดขึ้นเมื่อพื้นที่เก็บข้อมูลของฮีป JVM ไม่เพียงพอเนื่องจากไม่มีหน่วยความจำกายภาพ Java GC ทำให้งานรอการรวบรวมขยะเพื่อเพิ่มเวลาทำให้งานเสร็จโดยรวมเพิ่มขึ้น การรั่วไหลแบบสุ่มเกิดขึ้นเมื่อพื้นที่สับเปลี่ยนของฮีป JVM ไม่เพียงพอในระหว่างขั้นตอนการสับเปลี่ยน การสุ่มแบบสุ่มจะเพิ่มโอเวอร์เฮดของ CPU เพื่อดำเนินการซีเรียลไลซ์ข้อมูลสำหรับการสุ่มข้อมูลระดับกลางที่รั่วไหลไปยังดิสก์ เนื่องจากไม่มีพื้นที่สุ่ม ในการทดสอบปริมาณงาน TC เวลาที่บล็อคการอ่านแบบสุ่มจะทำให้งานรอการอ่านข้อมูลแบบสุ่มผ่านเครือข่าย เนื่องจากไม่มีพื้นที่สุ่ม ปัจจัยทั้งหมดเหล่านี้อาจเพิ่มเวลาการทำงานโดยรวมให้เสร็จสิ้น ซึ่งอาจส่งผลกระทบร้ายแรงต่อประสิทธิภาพของระบบ Spark

เพื่อแก้ไขปัญหาเหล่านี้ เราสร้างคลัสเตอร์ที่มี SSD และแคช RDD ทั้งในหน่วยความจำและ SSD แยกกันโดยใช้ SSD เพื่อเสริมพื้นที่จัดเก็บข้อมูลของหน่วยความจำ นอกจากนี้ เรายังปรับการกำหนดค่าฮีป JVM เพื่อขยายพื้นที่สับเปลี่ยน เป็นผลให้เราสามารถบรรลุการปรับปรุงประสิทธิภาพ 30% สำหรับปริมาณงาน PageRank และการปรับปรุงประสิทธิภาพ 42% สำหรับปริมาณงาน TC เราได้ระบุแล้วว่าการสุ่มแบบสุ่มอาจเป็นปัจจัยสำคัญของการลดประสิทธิภาพการทำงาน และแสดงให้เห็นผ่านการทดลองว่าในปริมาณงานที่ประกอบด้วยการวนซ้ำและการสับเปลี่ยนหลายครั้ง การขยายพื้นที่การสับเปลี่ยนสามารถให้ประสิทธิภาพที่เพิ่มขึ้นอย่างมีนัยสำคัญ นอกจากนี้ เราพบว่ารูปแบบการใช้หน่วยความจำที่แตกต่างกันของงานอาจส่งผลต่อเวลาดำเนินการทั้งหมด ขึ้นอยู่กับการจัดสรรเปอร์เซ็นต์หน่วยความจำของการจัดเก็บ/สับเปลี่ยนใน JVM จากการวิเคราะห์ประสิทธิภาพของการทำคลัสเตอร์ PageRank และ k-mean การจัดสรรหน่วยความจำใน JVM ที่ได้รับการปรับให้เข้ากับลักษณะปริมาณงานอย่างดีสามารถปรับปรุงเวลาทำงานให้เสร็จสิ้นได้อย่างมาก

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

ผลงานของผู้เขียน:

แนวความคิด, JL (แจฮวาน ลี); ระเบียบวิธี JL (Jaehwan Lee) และ JC; ซอฟต์แวร์, JC และ JL (แจฮยอนลี); การตรวจสอบความถูกต้อง, JC, JL (แจฮยอนลี) และ JL (แจฮวานลี); การสอบสวน JL (Jaehwan Lee) และ J.-SK; ทรัพยากร JL (Jaehwan Lee) และ J.-SK; การดูแลจัดการข้อมูล JC และ JL (Jaehyun Lee); การเขียน—การเตรียมร่างต้นฉบับ, JC และ JL (แจฮยอน ลี); การเขียน— ทบทวนและเรียบเรียง, JL (Jaehwan Lee) และ J.-SK; การสร้างภาพ, JL (แจฮยอนลี); การกำกับดูแล JL (Jaehwan Lee) และ J.-SK; การบริหารโครงการ JL (Jaehwan Lee) และ J.-SK; การจัดหาเงินทุน JL (Jaehwan Lee) ผู้เขียนทุกคนได้อ่านและยอมรับต้นฉบับฉบับตีพิมพ์แล้ว

เงินทุน:

งานวิจัยนี้ได้รับการสนับสนุนจากโครงการวิจัยวิทยาศาสตร์ขั้นพื้นฐาน (NRF-2020R1F1A1072696) ผ่านทางมูลนิธิการวิจัยแห่งชาติเกาหลี (NRF) ซึ่งได้รับทุนสนับสนุนจากกระทรวงวิทยาศาสตร์และ ICT โครงการ GRRC ของจังหวัดคยองกี (หมายเลข GRRC-KAU{ {5}}B01 "การศึกษาเกี่ยวกับแพลตฟอร์มการบรรจบกันของวิดีโอและอวกาศสำหรับบริการ 360VR") และโปรแกรมสนับสนุน ITRC (ศูนย์วิจัยเทคโนโลยีสารสนเทศ) (IITP-2021-2018-0-01423)

คำแถลงของคณะกรรมการพิจารณาสถาบัน:

ไม่สามารถใช้ได้.

คำชี้แจงความยินยอม:

ไม่สามารถใช้ได้.

คำชี้แจงความพร้อมของข้อมูล:

เข้าถึงได้เมื่อมีการขอใช้.

ผลประโยชน์ทับซ้อน:

ผู้เขียนขอประกาศว่าไม่มีความขัดแย้งทางผลประโยชน์

อ้างอิง

1. คณบดี เจ.; Ghemawat, S. MapReduce: การประมวลผลข้อมูลแบบง่ายบนคลัสเตอร์ขนาดใหญ่ ชุมชน พลอากาศเอก 2008, 51, 107–113. [ครอสอ้างอิง]

2. โครงการ Apache Hadoop: ซอฟต์แวร์โอเพ่นซอร์สสำหรับคอมพิวเตอร์แบบกระจายที่เชื่อถือได้ ปรับขนาดได้ และกระจาย พร้อมใช้งานออนไลน์: https: //hadoop.apache.org/ (เข้าถึงเมื่อ 10 กันยายน 2021)

3. ชวาชโก, เค.; กวง ฮ.; เรเดีย ส.; Chansler, R. ระบบไฟล์แบบกระจาย Hadoop ใน รายงานการประชุมสัมมนา IEEE ครั้งที่ 26 เรื่องระบบจัดเก็บข้อมูลและเทคโนโลยี (MSST) ประจำปี 2010, Incline Village, NV, สหรัฐอเมริกา, 3–7 พฤษภาคม 2010; หน้า 1–10.

4. ซาฮาเรีย ม.; เชาดูรี่ ม.; แฟรงคลิน เอ็มเจ; เชนเกอร์ ส.; Stoica, I. Spark: การประมวลผลคลัสเตอร์พร้อมชุดการทำงาน ฮอตคลาวด์ 2010, 10, 95.

5. อูสเตอร์เฮาต์, เค.; ราสติ ร.; รัตนซามี ส.; เชนเกอร์ ส.; Chun, BG เข้าใจถึงประสิทธิภาพในกรอบการวิเคราะห์ข้อมูล ใน การดำเนินการของการประชุม USENIX Symposium ครั้งที่ 12 เกี่ยวกับการออกแบบและการใช้งานระบบเครือข่าย (NSDI), โอ๊คแลนด์, แคลิฟอร์เนีย, สหรัฐอเมริกา, 4-6 พฤษภาคม 2558; หน้า 293–307.

6. ซิง ว.; Ghorbani, A. อัลกอริทึม PageRank แบบถ่วงน้ำหนัก ใน Proceedings of the IEEE Second Annual Conference on Communication Networks and Services Research, Fredericton, NB, Canada, 21 พฤษภาคม 2547; หน้า 305–314.

7. จักรธาร, ST; อกราวาล, วีดี; Rothweiler, SG อัลกอริธึมการปิดสกรรมกริยาสำหรับการสร้างการทดสอบ IEEE ทรานส์ คอมพิวเตอร์-ช่วย Des. อินทิเกรต ระบบวงจร 1993, 12, 1015–1028. [ครอสอ้างอิง]

8. O'Malley, O. Terabyte เรียงลำดับบน Apache Hadoop ยาฮู. พฤษภาคม 2008 หน้า 1–3 พร้อมใช้งานออนไลน์: http://sortbenchmark.org/ YahooHadoop.pdf (เข้าถึงเมื่อ 10 กันยายน 2021)

9. การจัดกลุ่ม K-Means พร้อมใช้งานออนไลน์: https://en.wikipedia.org/wiki/K-means_การทำคลัสเตอร์ (เข้าถึงเมื่อ 10 กันยายน 2021)

10. ซาฮาเรีย ม.; เชาดูรี่ ม.; ดาส ต.; เดฟ, อ.; แม่เจ.; แมคคอลี ม.; แฟรงคลิน เอ็มเจ; เชนเกอร์ ส.; Stoica, I. ชุดข้อมูลแบบกระจายแบบยืดหยุ่น: นามธรรมที่ทนทานต่อข้อผิดพลาดสำหรับการประมวลผลคลัสเตอร์ในหน่วยความจำ ใน การดำเนินการของการประชุม USENIX Symposium ครั้งที่ 9 เกี่ยวกับการออกแบบและการใช้งานระบบเครือข่าย (NSDI), ซานโฮเซ่, แคลิฟอร์เนีย, สหรัฐอเมริกา, 25–27 เมษายน 2555; หน้า 15–28.

11. เดวิดสัน อ.; หรือ A. การเพิ่มประสิทธิภาพการสับเปลี่ยนใน Spark; รายงานทางเทคนิค; Berkeley-Department of Electrical Engineering and Computer Sciences, University of California: Berkeley, CA, USA, 2013.

12. นิโคเล บ.; คอสตา, CHA; มิซาเล, ค.; แคทรินิส, เค.; Park, Y. ใช้ประโยชน์จาก Adaptive I/O เพื่อปรับรูปแบบการสับเปลี่ยนข้อมูลโดยรวมให้เหมาะสมสำหรับการวิเคราะห์ Big Data IEEE ทรานส์ การกระจายแบบขนาน ระบบ 2017, 28, 1663–1674. [ครอสอ้างอิง]

13. จาง ฮ.; โช บ.; เซย์เฟ อี.; ชิง, อ.; Freedman, MJ Riffle: บริการสับเปลี่ยนที่ได้รับการปรับปรุงสำหรับการวิเคราะห์ข้อมูลขนาดใหญ่ ในการประชุม EuroSys ครั้งที่ 13; ยูโรซิส '18; สมาคมเครื่องจักรคอมพิวเตอร์: New York, NY, USA, 2018 [CrossRef]

For more information:1950477648nn@gmail.com