Hydro: เฟรมเวิร์กการเขียนโปรแกรมแบบกระจายสำหรับ Rust

 (hydro.run)
1 คะแนน โดย GN⁺ 2025-02-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • แนะนำ

    • Hydro เป็นเฟรมเวิร์กการเขียนโปรแกรมแบบกระจายระดับสูงสำหรับ Rust
    • Hydro ช่วยให้เขียนบริการแบบกระจายที่ขยายขนาดได้อย่างรวดเร็ว และรับประกันความปลอดภัยของระบบแบบกระจาย เช่นเดียวกับที่ Rust รับประกันความปลอดภัยของหน่วยความจำ
    • รองรับการรันโปรแกรมแบบกระจายได้อย่างง่ายดายในโหมดทดสอบหรือโหมดดีพลอย

  • คุณสมบัติของ Hydro

    • Hydro เป็นภาษาการไหลของข้อมูลแบบกระจายที่ขับเคลื่อนด้วยรันไทม์ DFIR แบบเธรดเดี่ยวประสิทธิภาพสูง
    • ต่างจากสถาปัตยกรรมดั้งเดิมอย่าง actor หรือ RPC โดยมี API แบบ choreographic ที่สามารถอธิบายการคำนวณข้ามหลายตำแหน่งได้
    • ทำงานร่วมกับ Hydro Deploy เพื่อให้สามารถดีพลอยและรันโปรแกรม Hydro แบบกระจายได้อย่างง่ายดายทั้งบนเครื่องโลคัลหรือบนคลาวด์

  • การคอมไพล์และการดีพลอย

    • Hydro ใช้แนวทางการคอมไพล์แบบสองขั้นตอน
    • โปรแกรม Hydro เป็นโปรแกรม Rust มาตรฐานที่สร้าง แผนการดีพลอย บนแล็ปท็อปของนักพัฒนา
    • แผนนี้จะถูกคอมไพล์เป็น DFIR เพื่อสร้างไบนารีแยกสำหรับแต่ละเครื่องในระบบแบบกระจาย
    • จากนั้นจึงดีพลอยขึ้นคลาวด์โดยใช้แผนที่สร้างขึ้นและสเปกทรัพยากรคลาวด์

  • กรณีการใช้งาน

    • Hydro ถูกใช้ในการพัฒนาระบบแบบกระจายประสิทธิภาพสูง เช่น 2-phase commit และ Paxos
    • กำลังพัฒนาไลบรารีมาตรฐานสำหรับระบบแบบกระจายที่ให้โปรโตคอลเหล่านี้เป็นคอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้

  • ข้อควรทราบ

    • เอกสารของ Hydro ยังอยู่ระหว่างการจัดทำ และหากมีคำถามหรือพบบั๊ก แนะนำให้เปิด issue ใน GitHub repository ของ Hydro

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-02-02
ความคิดเห็นจาก Hacker News

  • มีการนำเสนอใน YouTube ที่อธิบายโปรเจกต์ Hydro ได้ดี โดยเน้นไปที่ DFIR เป็นหลัก
    https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

  • ดูเหมือนว่ายังต้องมี ตัวอย่างการใช้งานจริง เพิ่มเติม เพื่อให้เข้าใจว่าควรนำไปใช้กับอะไรจึงจะเหมาะ

    • แม้ตัวอย่างโค้ดยังไม่ได้จัดทำเป็นเอกสารครบถ้วน แต่สามารถดูการใช้งาน Paxos ที่สมจริงกว่านี้ได้ที่นี่: https://github.com/hydro-project/hydro/blob/main/hydro_test/...
      ตอนนี้กำลังสร้างแอปพลิเคชันที่ซับซ้อนขึ้นอย่างที่เก็บคีย์-ค่าอยู่ด้วย

  • ถ้ามีภาษากลางพร้อม runtime ของตัวเองอยู่ตรงกลาง ก็สงสัยว่าจะเสียข้อดีที่ Rust ให้มาหรือไม่
    ตอนแรกคิดว่าจะเป็นภาษาที่คอยประสานไบนารี Rust แยกหลายตัวให้รวมกันเป็นระบบกระจายที่สอดคล้องและทำงานได้ แต่ดูเหมือนว่าจะเขียนด้วย DFIR ตั้งแต่ต้นจนจบ ไม่ใช่แค่ระดับกาวเชื่อม

    • ผมเป็นหนึ่งในนักศึกษาปริญญาเอกที่นำงาน Hydro อยู่ DFIR ใกล้เคียงกับ DSL ชั้นกลางมากกว่า และช่วยให้นักพัฒนาภาษาระดับสูงสามารถจัดโครงสร้างโค้ด Rust ใหม่ให้เหมาะกับการปรับแต่งระดับต่ำอย่าง vectorization ได้มากขึ้น
      ตัวดำเนินการของ DFIR (map, filter ฯลฯ) รับ Rust closure ดังนั้นจึงสามารถส่งต่อจากภาษาระดับสูงไปจนถึงไบนารี Rust ขั้นสุดท้ายได้ตามเดิม จากมุมมองผู้ใช้ จึงไม่ต้องจัดการ DFIR โดยตรง
    • ถ้านี่คือสิ่งที่ถามอยู่ละก็ DFIR ถูก implement ด้วย Rust

  • น่าสนใจมาก ถ้ามีใครรู้จักสาขานี้ อยากให้ช่วยบอกงานวิจัยก่อนหน้าหรือเฟรมเวิร์กคล้าย ๆ กันที่เคยมีในภาษาอื่นด้วย
    ฝั่ง dataflow มีหลายคนทำงานกันมา และผมคิดว่า Materialize ค่อนข้างเจ๋ง อีกทั้งเคยใช้ Kafka Streams ในงานด้วย ผมมองว่าเฟรมเวิร์กที่รวมสิ่งเหล่านี้เข้าด้วยกันน่าจะมีความหมาย

    • ดูครั้งแรกแล้วในเชิงแนวคิดค่อนข้างคล้ายกับงานฝั่ง data science หลายอย่าง ทำให้นึกถึง Spark หรือ Dask ที่เอกสารก็กล่าวถึงด้วย
      โดยเฉพาะการที่มีพื้นฐานเป็น Rust จึงอาจมีพลังตรงที่เข้ากับภาษาอื่นได้ดี Spark เลือก JVM ได้ดีในแง่ portability แต่ก็พาความซับซ้อนเข้ามามาก ส่วน Dask รันบน Python จึงเป็น dependency ที่ค่อนข้างหนักถ้าไม่ได้อยู่ในบริบทที่ใช้ Python อยู่แล้ว
      ฝั่ง distributed Rust ผมเคยดู Lunatic ด้วย และก็ดูใช้ได้ แต่ดูเหมือนจะอยู่ในระดับต่ำกว่าที่ Hydro มุ่งไปเล็กน้อย
    • ดูเหมือนเป็นการผสมระหว่าง Akka(https://getakka.net/, ให้ความรู้สึก enterprise น้อยกว่าเวอร์ชัน Java) ที่อิง actor model และโฟกัสระบบกระจาย กับไลบรารี reactive อย่าง rx(https://reactivex.io/)
      ดังนั้น https://doc.akka.io/libraries/akka-core/current/stream/index... อาจเป็นตัวเปรียบเทียบที่ใกล้เคียงที่สุด
    • โปรเจกต์นี้มาจาก RISELab
      https://rise.cs.berkeley.edu/projects/
      การประมวลผลข้อมูลและระบบกระจายส่วนใหญ่มีจุดเชื่อมโยงกับงานวิจัยที่แล็บนี้ทำมาในระดับหนึ่ง

  • ชอบความพยายามนี้นะ แต่หวังว่าสักวันระบบนิเวศ Rust จะมีอะไรอย่าง akka.rs เข้ามา

  • สงสัยว่าเมื่อมองจากมุม dataflow แล้วเทียบกับ timely [0] อย่างไร และสงสัยด้วยว่าสามารถแสดง control flow อย่าง loop ใน intermediate representation ได้หรือไม่
    [0] https://github.com/TimelyDataflow/timely-dataflow

    • ผมอ่านเปเปอร์ Flo ไปนิดหน่อย ดูเหมือนว่าจะบรรยายกราฟ dataflow แบบเดียวกับ Timely แต่ต่างจากพื้นฐานของ Timely ที่เน้นการรันมากกว่า ตรงที่ Flo ดูมาจากสายประเพณีของ semantic dataflow
      ใกล้เคียงกับ functional reactive programming, composition, flow of flows, ตัวดำเนินการเชิงพีชคณิต และแนวทางที่เน้นการพิสูจน์ มีแนวคิดเรื่อง “progress” ที่ต่างจาก Timely มาก และเน้นการรับประกันว่า composition จะเป็นแบบ productive แม้กับอินพุต streaming ที่อาจไม่มีที่สิ้นสุด
      จริง ๆ แล้ว Flo แทบไม่มีแนวคิดเรื่อง “timeliness” และไม่มี timestamp ด้วย รองรับ nested iteration เหมือน Timely แต่กลไกต่างกันมาก พีชคณิตพื้นฐานมีลักษณะ acyclic อย่างยิ่ง แต่การทำให้ nested stream/graph เป็นรูปแบบทางการทำให้รองรับ iteration ได้
      เปเปอร์ยังเปรียบเทียบโดยตรงกับ DBSP ด้วย ซึ่งเท่าที่ผมเข้าใจ DBSP ก็อยู่ในสาย Timely/Naiad เช่นกัน ผู้เขียนมองว่า Flo อาจเป็นกรอบความหมายรวมสำหรับระบบคล้ายกันหลายตัว เช่น Flink, LVars, DBSP
      ดังนั้นผู้เขียน Flo จึงรู้จัก Naiad/Timely ดีและได้รับแรงบันดาลใจจากกราฟ nested iteration แต่ในด้านอื่น ๆ ผมมองว่าต่างกันมาก
    • ในเปเปอร์ล่าสุด [0] มีการกล่าวถึง Naiad(timely dataflow) อยู่หลายครั้ง เช่น “ได้รับแรงบันดาลใจจากโหนด ingress/egress ของ Naiad [34] ทำให้ nested stream สามารถถูกประมวลผลเป็นกราฟ nested dataflow ที่วนประมวลผลชิ้นข้อมูลจาก stream ที่ใหญ่กว่า และรองรับการส่งต่อสถานะระหว่างรอบการวนซ้ำได้”
      [0] https://hydro.run/papers/flo.pdf

  • ถ้าแต่ละ “โปรเซส” ถูกดีพลอยเป็นไบนารีแยกกัน ก็น่าจะหมายความว่ามันรันเป็นโปรเซสแยกกันด้วย ซึ่งดูเหมือนจะมีปัญหาในแง่ โอเวอร์เฮดที่เพิ่มขึ้น
    อยากรู้ว่าทำให้สื่อสารได้เร็วได้อย่างไร ใช้กลไกอย่าง shared memory IPC ที่เร็ว ๆ หรือเปล่า?
    อีกอย่างก็ไม่เห็นเนื้อหาเกี่ยวกับการผสานกับ async ด้วย ไม่ว่าจะชอบหรือไม่ โค้ดส่วนใหญ่ท่วมท้นที่จัดการ networking ก็ย้ายไปใช้ async แล้ว และในหลายพื้นที่ที่ต้องใช้ networking ก็หาไลบรารีที่ไม่ใช่ asynchronous ดี ๆ ได้ยาก

    • ถ้าเป็น “distributed” ผมเข้าใจว่าหมายถึงถูกแบ่งอยู่คนละเครื่องโดยสิ้นเชิง ถ้าอย่างนั้นก็จำเป็นที่แต่ละคอมโพเนนต์จะรันเป็นโปรเซสอิสระ
    • ตอนนี้ Hydro โฟกัสที่แอปพลิเคชันเครือข่าย และ parallelism ส่วนใหญ่ไม่ได้มาจากภายในเครื่องเดียว แต่มาจาก parallelism ระหว่างเครื่อง
      ดังนั้นถ้าต้องการ parallelism บนเครื่องเดียว ก็จะมีโอเวอร์เฮดเพิ่มเติมอยู่บ้าง อย่างที่คุณพูดไว้ นี่เป็นส่วนที่เราอยากแก้ให้ได้ในอนาคตผ่าน shared memory
      เมื่อสัปดาห์ที่แล้วที่ POPL 2025 นักศึกษาปริญญาตรีที่ร่วมทำ Hydro ได้นำเสนอคอมไพเลอร์ที่คอมไพล์บล็อกโค้ด async-await เป็น data flow ของ Hydro โดยอัตโนมัติ ยังอยู่ระหว่างพัฒนาและยังไม่มีเอกสาร แต่ดูได้ที่นี่: https://github.com/hydro-project/HydraulicLift

  • ดูเจ๋งมาก และนึกวิธีใช้งานได้หลายแบบ โดยเฉพาะ ส่วนการดีพลอย ที่ดูไม่เหมือนใคร
    รอให้เอกสารสมบูรณ์ขึ้น และอยากรู้เป็นพิเศษเกี่ยวกับ Streams, Singletons, Optionals ซึ่งดูเหมือนจะเป็นส่วนหลัก

  • ชอบโมเดลการเขียนโปรแกรมนี้ อยากรู้ว่าตอน rewrite แอปพลิเคชัน มีการทำ การปรับแต่งเครือข่ายให้เหมาะสม ด้วยหรือไม่
    อยากรู้ว่ารองรับการจัดการคอขวดของเครือข่ายหรือ congestion หรือเปล่า

  • อยากรู้ว่าเทียบกับกรณีที่ใช้ของอย่าง Ballista สำหรับ data pipeline แล้วเป็นอย่างไร
    Ballista ได้ประโยชน์มากจากการสร้างอยู่บน Apache Arrow และ Apache Datafusion

    • ผมเป็นหนึ่งในคนที่สร้าง Hydro ระบบนิเวศรอบ ๆ Ballista, Arrow และ Parquet โฟกัสไปที่การประมวลผลคิวรีเชิงวิเคราะห์มากกว่ามาก ส่วน Hydro คือความพยายามนำแนวคิดจากโลกของการประมวลผลคิวรีมาใช้กับ การสร้างระบบแบบกระจาย
      เป้าหมายไม่ใช่การรันคิวรี SQL แต่เป็นการปฏิบัติกับโค้ดระบบแบบกระจาย (เช่น การสร้างไมโครเซอร์วิส) ให้เหมือนคิวรี SQL การผสานกับ Arrow และ Parquet ก็อยู่ในโรดแมปด้วย