Data science

เทคโนโลยีโอเพ่นซอร์สของ LinkedIn เบื้องหลังคลัสเตอร์ Hadoop 10,000 โหนด

LinkedIn เมื่อสัปดาห์ที่แล้วเปิดแหล่งที่มา DynoYARN ซึ่งเป็นเทคโนโลยีชิ้นสำคัญที่ช่วยให้คาดการณ์ว่าประสิทธิภาพของ appliacation จะได้รับผลกระทบอย่างไรเมื่อปรับขนาด Hadoop เป็นสัดส่วนที่ใหญ่โต ซึ่งรวมถึงหนึ่ง 000 – คลัสเตอร์โหนดที่อาจเป็นการใช้งาน Hadoop ที่ใหญ่ที่สุดในโลก Hadoop อาจไม่ได้อยู่ในข่าวอีกต่อไป แต่ก็ยังอยู่เบื้องหลังในสถานที่ต่างๆ เช่น LinkedIn ซึ่งเดิมพันอย่างมากกับเทคโนโลยีและยังคงใช้เป็นพื้นฐานสำหรับการวิเคราะห์ข้อมูลขนาดใหญ่และปริมาณงานการเรียนรู้ของเครื่อง LinkedIn จะเพิ่มขนาดของคลัสเตอร์ Hadoop เป็นสองเท่าทุกปีเพื่อให้ทันกับอัตราการเติบโตแบบทวีคูณของข้อมูล ตามการโพสต์บล็อกของ LinkedIn เมื่อสัปดาห์ที่แล้วโดยสี่วิศวกรของบริษัท Keqiu Hu, Jonathan Hung, Haibo Chen และ Sriram Rao บริษัท ซึ่งมีบทบาทอย่างมากในชุมชนโอเพ่นซอร์ส Hadoop เมื่อนานมาแล้วต้องจัดการกับข้อจำกัดใน Hadoop Distributed File System (HDFS) และโดยเฉพาะอย่างยิ่ง NameNode แต่ก็ยังไม่มีเหตุผลที่จะทำอะไรกับ YARN (Yet Another Resource Negotiator) ซึ่งจัดกำหนดการการดำเนินการงานบนคลัสเตอร์ แต่เมื่อเร็วๆ นี้ LinkedIn ตัดสินใจรวมโหนดคอมพิวท์ของคลัสเตอร์สองคลัสเตอร์ คลัสเตอร์หนึ่งที่ให้บริการการรับส่งข้อมูลหลัก และอีกอันที่ใช้สำหรับการทำให้ข้อมูลสับสน รอยร้าวเริ่มปรากฏใน YARN งานบางงานอาจต้องเผชิญกับความล่าช้าหลายชั่วโมงก่อนถึงกำหนด แม้ว่าจะมีความจุเพียงพอในคลัสเตอร์ก็ตาม กลุ่ม Hadoop ของ LinkedIn มีขนาดใหญ่ขึ้นเป็นสองเท่าทุกปี (ที่มา: LinkedIn) “เมื่อมองหาสาเหตุของความล่าช้า ตอนแรกเราคิดว่าตรรกะในการจัดการพาร์ติชั่นซอฟต์แวร์ใน Hadoop YARN นั้นมีปัญหา แต่เราไม่พบปัญหาใดๆ ในส่วนนั้น รหัสหลังจากการดีบักและการตรวจสอบ” วิศวกรเขียนไว้ในบล็อก “เรายังสงสัยว่าการเพิ่มขนาดของคลัสเตอร์โดย 50% ทำให้ตัวจัดการทรัพยากรโอเวอร์โหลด และผู้จัดกำหนดการไม่สามารถติดตามได้” ขณะที่วิศวกรตรวจสอบ พวกเขาพบว่า YARN อาจเสี่ยงต่อ “การหยุดชะงักชั่วคราว” ในการจัดสรรคอนเทนเนอร์ในเงื่อนไขบางประการ เช่น เมื่อคิวตัวจัดกำหนดการพบลักษณะปริมาณงานที่แตกต่างกัน “จากมุมมองของผู้สังเกตการณ์” วิศวกรเขียนว่า “ตัวจัดกำหนดการดูเหมือนจะติดขัดในการจัดกำหนดการปริมาณงานในคิว A ในขณะที่ปริมาณงานในคิว B ขาดแคลนทรัพยากร” จากการวิเคราะห์เพิ่มเติม พวกเขาพบว่าหนึ่งในคลัสเตอร์ที่ผสานรวมส่วนใหญ่ประกอบด้วยการทดลอง AI และการวิเคราะห์ข้อมูลที่นำไปใช้ในงาน Spark ที่รันนานกว่า ในขณะที่ปริมาณงานในคิวของพาร์ติชันรองส่วนใหญ่เป็น “งาน MapReduce ที่เร่งรีบ” “หากผู้จัดการทรัพยากรสามารถจัดกำหนดการคอนเทนเนอร์อย่างรวดเร็วตามอำเภอใจ สิ่งนี้จะไม่เป็นปัญหา” พวกเขาตั้งทฤษฎี “อย่างไรก็ตาม เนื่องจากการรวมคลัสเตอร์ลดความเร็วการจัดกำหนดการลงอย่างมาก ปัญหาความเป็นธรรมในการจัดสรรจึงปรากฏขึ้น” การเลือกคิวแบบสุ่มควรจัดการกับมัน พวกเขาพูด และมันก็เกิดขึ้นชั่วคราว พวกเขายังส่งการแก้ไขเป็นโปรแกรมแก้ไขสำหรับโครงการ Apache Hadoop อย่างไรก็ตาม มันไม่ได้กล่าวถึงต้นเหตุของความไร้ประสิทธิภาพ “เรารู้ว่ายังคงมีปัญหาการปรับขนาดที่ใกล้จะเกิดขึ้นในกลุ่ม YARN ของเราบนขอบฟ้า วิศวกรเขียน “เราต้องขุดให้ลึกกว่านี้!” และขุดพวกเขาทำ ในที่สุดพวกเขาก็ขจัดความไร้ประสิทธิภาพในตัวกำหนดตารางเวลาที่เกี่ยวข้องกับการตรวจสอบการเต้นของหัวใจและผลกระทบที่คิวที่จะกำหนดเวลางาน “เพื่อแก้ปัญหานี้ เราได้ปรับตรรกะให้เหมาะสมเพื่อที่ว่าถ้าโหนดจากพาร์ทิชันหลัก (หรือรอง) เต้นเป็น ผู้จัดการทรัพยากร ผู้จัดกำหนดการจะพิจารณาเฉพาะแอปพลิเคชันที่ส่งไปยังพาร์ติชันหลัก (หรือรอง) เมื่อจัดกำหนดการ” พวกเขาเขียน “หลังจากการเปลี่ยนแปลง เราสังเกตเห็นความเท่าเทียมกันในปริมาณงานเฉลี่ยทั้งหมดก่อนและหลังการรวม และการปรับปรุง 9 เท่าในสถานการณ์กรณีที่เลวร้ายที่สุดเมื่อทั้งสองพาร์ติชั่นกำลังปั่นป่วนไม่ว่าง!” ด้วยความมุ่งมั่นที่จะไม่เผชิญกับสถานการณ์เช่นนี้อีก บริษัทจึงตัดสินใจคิดค้นเครื่องมือเพื่อให้บริษัททราบถึงปัญหาความสามารถในการปรับขนาดที่ใกล้จะเกิดขึ้นในคลัสเตอร์ Hadoop คล้ายกับ Dynomometer ซึ่งสร้างขึ้นเพื่อจำลองประสิทธิภาพของ HDFS NameNode บริษัทได้สร้าง DynoYARN เพื่อหมุนคลัสเตอร์ YARN จำลองที่มีขนาดตามอำเภอใจและเล่นซ้ำปริมาณงานตามอำเภอใจบนคลัสเตอร์จำลอง DynoYARN คาดการณ์ว่าคลัสเตอร์ Hadoop ที่ใหญ่ที่สุดของ LinkedIn จะอยู่ที่โหนด 11, (ภาพ: LinkedIn) DynoYARN ช่วยให้ LinkedIn เห็นว่าการปรับขนาดปริมาณงานปัจจุบันของคลัสเตอร์ Hadoop จะส่งผลต่อความล่าช้าของแอปพลิเคชันอย่างไร วิศวกรป้อนตัวคูณ เช่น 1.5x หรือ 2.x ของปริมาณงานปัจจุบัน และ DynoYARN จะสร้างความล่าช้าของแอปพลิเคชันที่คาดการณ์ไว้ โดยอิงตามปริมาณงานจริง ด้วยการตั้งค่าปัจจุบัน คลัสเตอร์ของ LinkedIn สามารถปรับขนาดได้ถึงโหนด 11, ก่อนที่แอปพลิเคชันจะล่าช้าเกิน 11 นาที ซึ่งเป็นเป้าหมาย อย่างไรก็ตาม หากคลัสเตอร์ที่มีแอปพลิเคชันปัจจุบันเติบโตเป็นโหนด 12, ความล่าช้าที่คาดการณ์ไว้ จะใกล้เคียงกับ 11 นาที ทำลาย SLA DynoYARN ยังสามารถใช้เพื่อคาดการณ์ผลกระทบของแอปพลิเคชันใหม่ที่มีต่อประสิทธิภาพของคลัสเตอร์ เช่นเดียวกับที่ทำกับ Dynomometer LinkedIn เป็นโอเพ่นซอร์ส DynoYARN คุณสามารถค้นหาได้ที่ repo GitHub นี้ การทำงานของ LinkedIn บ่งบอกถึงการมีอยู่ของ cap ในความสามารถในการปรับขนาด Hadoop ด้วยสถาปัตยกรรมแบบเธรดเดียวของ YARN แต่ LinkedIn จะไม่ปล่อยให้สิ่งนั้นมาขวางทาง! เพื่อแก้ไขปัญหานี้ บริษัทในเครือของ Microsoft ได้เริ่มโครงการใหม่เพื่อสร้างคลัสเตอร์ออร์เคสตรา Robin ทำหน้าที่เป็น “ตัวโหลดบาลานซ์เพื่อแจกจ่ายแอปพลิเคชัน YARN ไปยังคลัสเตอร์ Hadoop หลายคลัสเตอร์แบบไดนามิก” บริษัทกล่าว “ในระดับสูง Robin มี REST API อย่างง่ายที่ส่งคืนคลัสเตอร์ YARN สำหรับงานที่กำหนด ก่อนส่งงาน ไคลเอนต์ YARN ตรวจสอบกับ Robin เพื่อกำหนดว่าควรกำหนดเส้นทางงานไปยังคลัสเตอร์ใด จากนั้นจึงส่งงานไปยังคลัสเตอร์ที่ถูกต้อง” LinkedIn มีมากขึ้นที่จะพูดเกี่ยวกับ DynoYARN, Robin และการโยกย้ายสินทรัพย์ Hadoop ไปยัง Azure บนบล็อก รายการที่เกี่ยวข้อง: LinkedIn โอเพ่นซอร์ส Dagli เพื่อลดความซับซ้อนของการสร้างไปป์ไลน์ ML LinkedIn โอเพ่นซอร์ส Kube2Hadoop LinkedIn ปลดปล่อยข้อมูล 'ใกล้'

  • บ้าน
  • Business
  • Data science
  • Marketing
  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    Back to top button