ตลาดสำหรับการประมวลผลแบบกระจายและข้อมูลขนาดใหญ่ตาม มีการเติบโตที่ 18-19% ต่อปี ซึ่งหมายความว่าปัญหาของการเลือกซอฟต์แวร์สำหรับวัตถุประสงค์เหล่านี้ยังคงมีความเกี่ยวข้อง ในโพสต์นี้ เราจะเริ่มต้นด้วยสาเหตุที่เราต้องมีการประมวลผลแบบกระจาย เราจะพูดถึงรายละเอียดเพิ่มเติมเกี่ยวกับตัวเลือกของซอฟต์แวร์ เราจะพูดถึงการใช้ Hadoop กับ Cloudera และสุดท้าย เราจะพูดถึงการเลือกใช้ฮาร์ดแวร์และผลกระทบต่อประสิทธิภาพการทำงานอย่างไร ในทางที่แตกต่าง.
เหตุใดเราจึงต้องใช้คอมพิวเตอร์แบบกระจายในธุรกิจทั่วไป ทุกอย่างเรียบง่ายและซับซ้อนในเวลาเดียวกัน ง่าย - เนื่องจากในกรณีส่วนใหญ่ เราจะทำการคำนวณที่ค่อนข้างง่ายต่อหน่วยข้อมูล ยาก - เนื่องจากมีข้อมูลจำนวนมาก มากมาย. เป็นผลให้เราต้อง . ดังนั้น กรณีการใช้งานจึงค่อนข้างเป็นสากล: สามารถใช้การคำนวณได้ทุกที่ที่ต้องคำนึงถึงเมตริกจำนวนมากในอาร์เรย์ข้อมูลที่มีขนาดใหญ่กว่า
ตัวอย่างล่าสุด: Dodo Pizza จากการวิเคราะห์ฐานการสั่งซื้อของลูกค้า ในการเลือกพิซซ่าที่มีท็อปปิ้งตามอำเภอใจ ผู้ใช้มักจะใช้ส่วนผสมพื้นฐานเพียง XNUMX ชุด บวกกับส่วนผสมแบบสุ่มอีกสองสามชุด ดังนั้นร้านพิชซ่าจึงปรับการซื้อ นอกจากนี้ยังสามารถแนะนำผลิตภัณฑ์เพิ่มเติมที่นำเสนอในขั้นตอนการสั่งซื้อให้กับผู้ใช้ได้ดีขึ้น ซึ่งช่วยเพิ่มผลกำไร
อีกหนึ่งตัวอย่าง: สินค้าอนุญาตให้ H&M ลดการแบ่งประเภทในแต่ละร้านลง 40% ในขณะที่รักษาระดับการขาย สิ่งนี้ทำได้โดยการยกเว้นตำแหน่งที่ขายไม่ดี และคำนึงถึงฤดูกาลในการคำนวณ
การเลือกเครื่องมือ
มาตรฐานอุตสาหกรรมสำหรับการประมวลผลประเภทนี้คือ Hadoop ทำไม เนื่องจาก Hadoop เป็นเฟรมเวิร์กที่ยอดเยี่ยมและมีเอกสารครบถ้วน (Habr เดียวกันนี้ให้บทความที่มีรายละเอียดมากมายเกี่ยวกับหัวข้อนี้) ซึ่งมาพร้อมกับยูทิลิตี้และไลบรารีทั้งชุด คุณสามารถส่งข้อมูลทั้งที่มีโครงสร้างและไม่มีโครงสร้างชุดใหญ่เป็นอินพุต และระบบจะกระจายข้อมูลเหล่านั้นระหว่างกำลังการประมวลผล ยิ่งไปกว่านั้น ความสามารถเดียวกันนี้สามารถเพิ่มหรือปิดการใช้งานได้ทุกเมื่อ - ความสามารถในการปรับขนาดแนวนอนแบบเดียวกันนั้นใช้งานได้จริง
ในปี 2017 Gartner บริษัทที่ปรึกษาผู้ทรงอิทธิพล Hadoop จะล้าสมัยในไม่ช้า เหตุผลค่อนข้างซ้ำซาก: นักวิเคราะห์เชื่อว่าบริษัทต่างๆ จะย้ายข้อมูลจำนวนมากไปยังระบบคลาวด์ เนื่องจากที่นั่นพวกเขาจะสามารถชำระเงินตามการใช้พลังการประมวลผล ปัจจัยสำคัญประการที่สองที่คาดว่าจะสามารถ "ฝัง" Hadoop ได้คือความเร็วในการทำงาน เนื่องจากตัวเลือกต่างๆ เช่น Apache Spark หรือ Google Cloud DataFlow นั้นเร็วกว่า MapReduce ที่อยู่ภายใต้ Hadoop
Hadoop วางอยู่บนเสาหลักหลายเสา ซึ่งโดดเด่นที่สุดคือเทคโนโลยี MapReduce (ระบบสำหรับกระจายข้อมูลสำหรับการคำนวณระหว่างเซิร์ฟเวอร์) และระบบไฟล์ HDFS หลังได้รับการออกแบบมาเป็นพิเศษสำหรับการจัดเก็บข้อมูลที่กระจายระหว่างโหนดคลัสเตอร์: แต่ละบล็อกที่มีขนาดคงที่สามารถวางบนหลาย ๆ โหนดได้ และด้วยการจำลองแบบ ทำให้ระบบทนทานต่อความล้มเหลวของโหนดแต่ละโหนด แทนที่จะใช้ตารางไฟล์ จะใช้เซิร์ฟเวอร์พิเศษที่เรียกว่า NameNode
ภาพประกอบด้านล่างแสดงวิธีการทำงานของ MapReduce ในขั้นตอนแรก ข้อมูลจะถูกแบ่งตามคุณลักษณะเฉพาะ ในขั้นตอนที่สอง ข้อมูลจะถูกกระจายตามกำลังการประมวลผล ในขั้นตอนที่สามจะมีการคำนวณ
MapReduce ถูกสร้างขึ้นโดย Google เพื่อตอบสนองความต้องการในการค้นหา จากนั้น MapReduce ก็เปลี่ยนเป็นโค้ดฟรี และ Apache ก็เข้ามาควบคุมโปรเจ็กต์นี้ Google ค่อยๆ เปลี่ยนไปใช้โซลูชันอื่น ความแตกต่างที่น่าสนใจ: ในขณะนี้ Google มีโครงการที่ชื่อว่า Google Cloud Dataflow ซึ่งเป็นขั้นตอนต่อไปหลังจาก Hadoop เป็นการแทนที่อย่างรวดเร็ว
มองให้ละเอียดยิ่งขึ้นแสดงว่า Google Cloud Dataflow อิงตามรูปแบบของ Apache Beam ในขณะที่ Apache Beam มีเฟรมเวิร์ก Apache Spark ที่ได้รับการจัดทำเอกสารอย่างดี ซึ่งช่วยให้เราสามารถพูดคุยเกี่ยวกับความเร็วในการดำเนินการโซลูชันได้เกือบเท่าๆ กัน Apache Spark ทำงานได้ดีบนระบบไฟล์ HDFS ซึ่งช่วยให้คุณสามารถปรับใช้บนเซิร์ฟเวอร์ Hadoop
เพิ่มปริมาณเอกสารและโซลูชันสำเร็จรูปสำหรับ Hadoop และ Spark กับ Google Cloud Dataflow ที่นี่ และตัวเลือกของเครื่องมือจะชัดเจน ยิ่งไปกว่านั้น วิศวกรสามารถตัดสินใจได้เองว่าโค้ดใดภายใต้ Hadoop หรือ Spark ที่พวกเขาจะดำเนินการ โดยมุ่งเน้นที่งาน ประสบการณ์ และคุณสมบัติ
คลาวด์หรือเซิร์ฟเวอร์ภายในเครื่อง
แนวโน้มไปสู่การเปลี่ยนแปลงทั่วไปไปสู่ระบบคลาวด์ทำให้เกิดคำที่น่าสนใจเช่น Hadoop-as-a-service ในสถานการณ์ดังกล่าว การดูแลระบบเซิร์ฟเวอร์ที่เชื่อมต่อมีความสำคัญมาก เนื่องจากแม้ว่าจะได้รับความนิยม แต่ Hadoop บริสุทธิ์ก็เป็นเครื่องมือที่ค่อนข้างยากในการกำหนดค่าเนื่องจากคุณต้องทำด้วยมือมากมาย ตัวอย่างเช่น คุณสามารถกำหนดค่าเซิร์ฟเวอร์ทีละรายการ ตรวจสอบประสิทธิภาพ และปรับแต่งพารามิเตอร์จำนวนมาก โดยทั่วไปทำงานให้กับมือสมัครเล่นและมีโอกาสสูงที่จะทำพลาดหรือพลาดบางอย่างไป
ดังนั้นการแจกจ่ายที่หลากหลายจึงได้รับความนิยมอย่างมากซึ่งในขั้นต้นมีเครื่องมือการปรับใช้และการจัดการที่สะดวก หนึ่งในการกระจายยอดนิยมที่รองรับ Spark และทำให้สิ่งต่าง ๆ ง่ายขึ้นคือ Cloudera มีทั้งเวอร์ชันที่ต้องชำระเงินและฟรี - และฟังก์ชันหลักทั้งหมดจะพร้อมใช้งานในภายหลัง และไม่จำกัดจำนวนโหนด
ระหว่างการตั้งค่า Cloudera Manager จะเชื่อมต่อผ่าน SSH ไปยังเซิร์ฟเวอร์ของคุณ จุดที่น่าสนใจ: เมื่อติดตั้งจะเป็นการดีกว่าที่จะระบุว่าจะดำเนินการโดยสิ่งที่เรียกว่า พัสดุ: แพ็คเกจพิเศษ ซึ่งแต่ละแพ็คเกจประกอบด้วยส่วนประกอบที่จำเป็นทั้งหมดที่กำหนดค่าให้ทำงานร่วมกัน ในความเป็นจริงนี่คือตัวจัดการแพ็คเกจรุ่นปรับปรุง
หลังจากการติดตั้ง เราได้รับคอนโซลการจัดการคลัสเตอร์ ซึ่งคุณสามารถดูการวัดและส่งข้อมูลทางไกลสำหรับคลัสเตอร์ บริการที่ติดตั้ง รวมทั้งคุณสามารถเพิ่ม/ลบทรัพยากรและแก้ไขการกำหนดค่าคลัสเตอร์
เป็นผลให้การตัดจรวดนั้นปรากฏขึ้นต่อหน้าคุณ ซึ่งจะนำคุณไปสู่อนาคตที่สดใสของ BigData แต่ก่อนที่เราจะพูดว่า "ไปกันเถอะ" เรามาเร่งเครื่องกันต่อดีกว่า
ข้อกำหนดด้านฮาร์ดแวร์
ในเว็บไซต์ของพวกเขา Cloudera กล่าวถึงการกำหนดค่าต่างๆ ที่เป็นไปได้ หลักการทั่วไปในการสร้างสิ่งเหล่านี้แสดงไว้ในภาพประกอบ:
MapReduce สามารถเบลอภาพที่มองโลกในแง่ดีนี้ได้ เมื่อดูที่ไดอะแกรมในส่วนก่อนหน้าอีกครั้ง จะเห็นได้ชัดว่าในเกือบทุกกรณี งาน MapReduce สามารถประสบปัญหาคอขวดเมื่ออ่านข้อมูลจากดิสก์หรือเครือข่าย สิ่งนี้ถูกบันทึกไว้ในบล็อกของ Cloudera ด้วย ด้วยเหตุนี้ สำหรับการคำนวณที่รวดเร็ว รวมถึงผ่าน Spark ซึ่งมักใช้สำหรับการคำนวณแบบเรียลไทม์ ความเร็ว I/O จึงมีความสำคัญมาก ดังนั้น เมื่อใช้ Hadoop เป็นสิ่งสำคัญมากที่เครื่องที่สมดุลและรวดเร็วจะเข้าสู่คลัสเตอร์ ซึ่งกล่าวง่ายๆ ก็คือไม่ได้จัดเตรียมไว้ในโครงสร้างพื้นฐานระบบคลาวด์เสมอไป
ความสมดุลในการกระจายโหลดทำได้โดยการใช้การจำลองเสมือนของ Openstack บนเซิร์ฟเวอร์ที่มี CPU แบบมัลติคอร์อันทรงพลัง โหนดข้อมูลได้รับการจัดสรรทรัพยากรตัวประมวลผลและดิสก์บางตัว ในการตัดสินใจของเรา เครื่องยนต์ Atos Codex Data Lake บรรลุผลสำเร็จของเวอร์ชวลไลเซชันในวงกว้าง ซึ่งเป็นเหตุผลที่เราชนะทั้งในแง่ของประสิทธิภาพ (ผลกระทบของโครงสร้างพื้นฐานเครือข่ายจะลดลง) และ TCO (เซิร์ฟเวอร์จริงเพิ่มเติมจะถูกกำจัด)
ในกรณีของการใช้เซิร์ฟเวอร์ BullSequana S200 เราได้รับการโหลดที่สม่ำเสมอมาก ปราศจากคอขวดบางส่วน การกำหนดค่าขั้นต่ำประกอบด้วยเซิร์ฟเวอร์ BullSequana S3 200 เครื่อง แต่ละเครื่องมี JBOD สองตัว และ S200 เพิ่มเติมที่มีโหนดข้อมูลสี่โหนดให้เลือกเชื่อมต่อ นี่คือตัวอย่างการโหลดในการทดสอบ TeraGen:
การทดสอบกับปริมาณข้อมูลที่แตกต่างกันและค่าการจำลองแบบจะแสดงผลลัพธ์เดียวกันในแง่ของการกระจายโหลดข้ามโหนดคลัสเตอร์ ด้านล่างนี้เป็นกราฟของการกระจายการเข้าถึงดิสก์โดยการทดสอบประสิทธิภาพ
การคำนวณขึ้นอยู่กับการกำหนดค่าขั้นต่ำของเซิร์ฟเวอร์ BullSequana S3 200 เครื่อง ประกอบด้วยโหนดข้อมูล 9 โหนดและโหนดหลัก 3 โหนด รวมถึงเครื่องเสมือนที่สงวนไว้ในกรณีที่ใช้งานการป้องกันตาม OpenStack Virtualization ผลการทดสอบ TeraSort: ขนาดบล็อก 512 MB ของปัจจัยการจำลองแบบสามตัวพร้อมการเข้ารหัสคือ 23,1 นาที
จะขยายระบบได้อย่างไร? มีส่วนขยายหลายประเภทสำหรับ Data Lake Engine:
- โหนดข้อมูล: สำหรับพื้นที่ใช้งานทุกๆ 40 TB
- โหนดการวิเคราะห์ที่มีความสามารถในการติดตั้ง GPU
- ตัวเลือกอื่นๆ ขึ้นอยู่กับความต้องการทางธุรกิจ (เช่น หากคุณต้องการคาฟคา และอื่นๆ)
คอมเพล็กซ์ Atos Codex Data Lake Engine มีทั้งเซิร์ฟเวอร์เองและซอฟต์แวร์ที่ติดตั้งไว้ล่วงหน้า รวมถึงชุด Cloudera พร้อมใบอนุญาต Hadoop เอง, OpenStack พร้อมเครื่องเสมือนที่ใช้เคอร์เนล RedHat Enterprise Linux, การจำลองข้อมูลและระบบการสำรอง (รวมถึงการใช้โหนดสำรองและ Cloudera BDR - การสำรองข้อมูลและการกู้คืนความเสียหาย) Atos Codex Data Lake Engine เป็นโซลูชันการจำลองเสมือนตัวแรกที่ได้รับการรับรอง .
หากคุณสนใจในรายละเอียด เรายินดีที่จะตอบคำถามของเราในความคิดเห็น
ที่มา: will.com