Data science

Tuplex ให้ Python UDF เพิ่มประสิทธิภาพ

วิทยาศาสตร์ข้อมูลมีการใช้งาน Python เพิ่มขึ้น เนื่องจากมีความเก่งกาจและใช้งานง่าย แต่ในฐานะที่เป็นภาษาที่แปลแล้ว โค้ด Python อาจค่อนข้างช้า โดยเฉพาะอย่างยิ่งเมื่อเทียบกับ C++ ที่เขียนด้วยมือ นั่นคือสิ่งที่ผลักดันกลุ่มนักวิจัยมหาวิทยาลัยจาก Brown University และ MIT ให้สร้าง Tuplex ซึ่งเป็นเฟรมเวิร์กใหม่ที่เร่งความเร็วในการดำเนินการ Python ที่ผู้ใช้กำหนดฟังก์ชัน (UDFs) โดยปัจจัย 3 เป็น 38x เทียบกับ Spark และ Dask เป็นการยากที่จะพูดเกินจริงถึงความนิยมของ Python ในปัจจุบัน ในเวลาเพียงไม่กี่ปี Python ก็ได้แซงหน้า R, Java, Scala และภาษาอื่นๆ ทั้งหมดให้กลายเป็นภาษาที่ใช้กันอย่างแพร่หลายที่สุดสำหรับปริมาณงานด้านวิทยาศาสตร์ข้อมูล เมื่อแรงโน้มถ่วงเพิ่มขึ้น จำนวนไลบรารีและแพ็คเกจ Python จะเพิ่มขึ้นเรื่อยๆ ซึ่งเพิ่งจะขยายความเป็นผู้นำ Leonhard Spiegelberg นักศึกษาระดับปริญญาเอกที่ Brown University และหัวหน้านักพัฒนาของ Tuplex กล่าวว่าแม้จะได้รับความนิยม แต่ Python ก็ไม่เร็วนัก โดยเฉพาะอย่างยิ่งสำหรับปริมาณงาน Big Data “การใช้ Python UDF นั้นไม่มีประสิทธิภาพอย่างเหลือเชื่อ” Spiegelberg กล่าวในวิดีโอเกี่ยวกับ Tuplex ที่โพสต์บน YouTube มีเหตุผลหลายประการที่ทำให้ Python UDF ทำงานช้า เขากล่าว เหตุผลอันดับหนึ่งคือโค้ด Python UDF ต้องรันผ่านตัวแปลไบต์โค้ดแบบสแต็กก่อนดำเนินการ การพิมพ์และการจัดส่งแบบไดนามิก โอเวอร์เฮดการทำให้เป็นอนุกรม การรวบรวมขยะ และการล็อคล่ามล้วนมีส่วนทำให้การเรียกใช้ Python UDF ช้าลง Spiegelberg กล่าวในการนำเสนอของเขา นักวิทยาศาสตร์คอมพิวเตอร์บางคนพยายามที่จะแก้ไขปัญหาด้านประสิทธิภาพนี้ด้วยการสร้างคอมไพเลอร์ ตัวอย่างเช่น PyPy, Pyston, Glow, Nuitka, Weld และ MLIR เป็นคอมไพเลอร์ Python ที่เห็นการใช้งานในภาคสนาม “แต่เมื่อเราใช้คอมไพเลอร์เหล่านั้นกับไปป์ไลน์วิทยาศาสตร์ข้อมูล เราไม่เห็นประโยชน์หรือเพียงเท่านั้น การปรับปรุง” สปีเกลเบิร์กกล่าว Tuplex สร้างโค้ดที่คอมไพล์แล้วสำหรับ Python UDF (ที่มา: Leonhard Spiegelberg, Brown University) Tuplex แสดงถึง “แนวทางที่แตกต่างอย่างสิ้นเชิง” ต่อปัญหาด้านประสิทธิภาพ แทนที่จะสร้างระบบเอนกประสงค์ Spiegelberg มุ่งสร้างแนวทางเฉพาะโดเมนที่สามารถเพิ่มความเร็วของ Python UDF บางประเภทได้ Tuplex ซึ่งเป็นกระเป๋าหิ้วของทูเพิลและข้อยกเว้น เป็นคอมไพเลอร์แบบทันเวลาที่จะเปลี่ยน Python UDF เป็นโค้ดเนทีฟ ใช้งานได้กับ Python UDF ที่มีลักษณะเหมือนกัน สำหรับทุกสิ่งทุกอย่างที่ไม่เข้ากับกรณีการใช้งานที่แคบของ Tuplex หรือที่ส่งคืนข้อผิดพลาด Tuplex จะทำงานผ่านล่ามมาตรฐาน หลังจากที่ทั้งสองระบบทำงานพร้อมกัน ผลลัพธ์จะถูกรวมเข้าด้วยกันเพื่อผลลัพธ์สุดท้าย “เราใช้คุณสมบัติของ UDF อย่างชัดเจน ซึ่งฝังอยู่ในไปป์ไลน์วิทยาศาสตร์ข้อมูล” สปีเกลเบิร์กกล่าว “เนื่องจากพวกมันมีขนาดเล็ก ไร้สัญชาติ และถูกเรียกว่าเป็นส่วนหนึ่งของไปป์ไลน์ของสคีมาที่คนส่วนใหญ่รู้จัก เราสามารถจับคู่ความหมายของ Pyton กับโมเดลการดำเนินการที่ง่ายกว่ามาก” ผู้ใช้โต้ตอบกับ Tuplex เหมือนกับที่พวกเขาโต้ตอบกับคอมไพเลอร์ Python อื่น ๆ หลังจากนำเข้า Python UDF ไปยัง Tuplex เฟรมเวิร์กจะสุ่มตัวอย่างข้อมูล และสร้างอ็อบเจ็กต์บริบทตามโค้ดนั้น จากนั้นผู้ใช้จะเขียนโอเปอเรเตอร์แบบ LINQ ระดับสูงและส่งผ่าน UDF เป็นพารามิเตอร์ไปยังโอเปอเรเตอร์เหล่านั้น Spiegelberg และเพื่อนร่วมงานของเขาเขียนในรายงานการวิจัย “Tuplex: Data Science in Python at Native Code Speed” ซึ่งเผยแพร่เมื่อเดือนที่แล้ว ในการดำเนินการของ SIGMOD 2021 “เทคนิคหลักของเราในการบรรลุเป้าหมายนี้คือการรวบรวมสำหรับพื้นที่ส่วนกลาง ซึ่งช่วยให้ Tuplex หลีกเลี่ยงการพิมพ์แบบไดนามิกและแจกจ่ายโค้ดที่คอมไพล์แล้ว” Spiegelberg กล่าว “การฝัง UDF ที่คอมไพล์แล้วภายใน…แผนการสืบค้นที่คอมไพล์แล้ว Tuplex สามารถหลีกเลี่ยงค่าใช้จ่ายในการทำให้เป็นอนุกรมส่วนใหญ่ได้ และสำหรับการรวบรวมขยะ Tuplex ใช้การจัดการหน่วยความจำตามภูมิภาค ยิ่งไปกว่านั้น เนื่องจาก UDF นั้นไร้สัญชาติ Tuplex จึงไม่ต้องการโกลบอลล็อกสำหรับการขนานกันอีกต่อไป แต่ก็ยังตรงกับความหมายของ Python” Tuplex รัน Python UDF สูงสุด 38 x เร็วกว่า Spark (ที่มา: Leonhard Spiegelberg, Brown University) Python UDF บางตัวไม่เหมาะกับ Tuplex กรอบงานซึ่งเขียนเป็นหลักใน C ++ และวัดเกี่ยวกับ 40,000 บรรทัดของรหัส ต้องการระดับของความเป็นเนื้อเดียวกันในรหัส สิ่งที่สปีเกลเบิร์กเรียกว่า “พื้นที่ส่วนกลาง” และกรอบงานยังคงสามารถส่งคืนข้อผิดพลาดได้ แม้ว่าพื้นที่ส่วนกลางจะเอื้ออำนวยต่อการดำเนินการก็ตาม นั่นเป็นสาเหตุที่เฟรมเวิร์กใช้แชนเนลการประมวลผลแบบคู่ ซึ่งช่วยให้ UDF ที่ไม่เหมาะสมทำงานผ่านล่ามมาตรฐานได้ นี่คือกุญแจสำคัญสู่ธรรมชาติ “ตั้งแต่ต้นจนจบ” ของ Tuplex: แม้ว่าจะมีข้อผิดพลาด กระบวนการจะทำงานจนจบเสมอ การทดสอบเกณฑ์มาตรฐานดำเนินการโดย Spiegelberg และเพื่อนร่วมงานของเขาแสดงให้เห็นว่า Tuplex สามารถเพิ่มประสิทธิภาพได้อย่างมาก นักวิจัยได้สร้างไปป์ไลน์วิทยาศาสตร์ข้อมูลมาตรฐานห้ารายการ ซึ่งรวมถึงการดำเนินการแผนที่ เข้าร่วม และกรอง และดำเนินการกับ Python UDF มาตรฐานโดยใช้กรอบงาน Spark และ Dask นักวิจัยพยายามใช้เทคนิคล่าสุดและยิ่งใหญ่ที่สุดในทุกที่ที่ทำได้ ซึ่งรวมถึงการใช้ฟังก์ชัน Spark SQL พวกเขายังสร้างโปรแกรม C ++ ที่สร้างขึ้นด้วยมือเพื่อประโยชน์ในการเปรียบเทียบ Tuplex ส่งคืนการค้นหาที่ใดก็ได้จากเร็วกว่า 3 เท่าเป็น 38 เท่า เร็วกว่าเมื่อเทียบกับโปรแกรม Spark และ Dask ที่ปรับแต่งด้วยมือ Spiegelberg กล่าวในขณะที่ช้ากว่าเล็กน้อย โปรแกรม C++ ซึ่งถูกเข้ารหัสด้วยมือ “ต้องขอบคุณ UDF แบบ end-to-end และการรวบรวมคิวรี Tuplex มีประสิทธิภาพเหนือกว่า Dask และ Spark ในทุกสถานการณ์” เขากล่าว “Tuplex มีประสิทธิภาพเหนือกว่าบรรทัดฐาน Python แบบเธรดเดียวโดยหนึ่งลำดับความสำคัญและอยู่ภายใน 25% ของพื้นฐาน C ++” การทดสอบอื่นเปรียบเทียบประสิทธิภาพของกรอบงานกับชุดข้อมูลขนาดใหญ่ที่ทำงานในลักษณะกระจาย A 87 -core Tuplex setup สามารถประมวลผลชุดข้อมูลได้ในเวลาประมาณ 2.5 วินาที ในขณะที่การตั้งค่า Spark ดำเนินการ 87 วินาที “เกือบเสร็จแล้ว” ก่อนที่ Spark จะโหลดข้อมูลเสร็จ ยิ่งไปกว่านั้น Spark cluster ต้องการ 40GB ของหน่วยความจำ ในขณะที่คลัสเตอร์ Tuplex ต้องการเพียง 412MB ของหน่วยความจำ Tuplex พร้อมใช้งานสำหรับ Linux และ MacOS ซอฟต์แวร์บรรลุความขนานกันในฐานะแอปพลิเคชันแบบมัลติเธรดที่ทำงานบนเซิร์ฟเวอร์เครื่องเดียว หรือเป็นฟังก์ชัน Lamba แบบไร้เซิร์ฟเวอร์ที่ทำงานในระบบคลาวด์ รหัสนี้เป็นโอเพ่นซอร์สและสามารถดาวน์โหลดได้ที่ tuplex.cs.brown.edu/gettingstarted.html

วิทยาศาสตร์ข้อมูล

  • การตลาด
  • Leave a Reply

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

    Back to top button