Hydro: Framework lập trình phân tán cho Rust

 (hydro.run)
1 điểm bởi GN⁺ 2025-02-02 | 1 bình luận | Chia sẻ qua WhatsApp

  • Giới thiệu

    • Hydro là một framework lập trình phân tán cấp cao dành cho Rust.
    • Hydro giúp viết nhanh các dịch vụ phân tán có khả năng mở rộng, đồng thời đảm bảo tính an toàn phân tán giống như cách Rust đảm bảo an toàn bộ nhớ.
    • Hỗ trợ chạy chương trình phân tán dễ dàng trong chế độ kiểm thử hoặc chế độ triển khai.

  • Các đặc điểm của Hydro

    • Hydro là một ngôn ngữ luồng dữ liệu phân tán được vận hành bởi runtime DFIR đơn luồng hiệu năng cao.
    • Khác với các kiến trúc truyền thống như actor hay RPC, Hydro cung cấp API choreographic cho phép mô tả việc tính toán trải dài trên nhiều vị trí.
    • Tích hợp với Hydro Deploy để có thể dễ dàng triển khai và chạy các chương trình Hydro phân tán trên máy cục bộ hoặc trên đám mây.

  • Biên dịch và triển khai

    • Hydro sử dụng cách tiếp cận biên dịch hai giai đoạn.
    • Chương trình Hydro là chương trình Rust tiêu chuẩn, tạo ra kế hoạch triển khai trên laptop của nhà phát triển.
    • Kế hoạch này được biên dịch sang DFIR để tạo các binary riêng cho từng máy trong hệ thống phân tán.
    • Kế hoạch được tạo ra cùng với đặc tả tài nguyên đám mây sẽ được dùng để triển khai lên đám mây.

  • Trường hợp sử dụng

    • Hydro được dùng để triển khai các hệ thống phân tán hiệu năng cao như two-phase commit và Paxos.
    • Dự án đang phát triển một thư viện chuẩn cho hệ thống phân tán, cung cấp các giao thức này dưới dạng thành phần có thể tái sử dụng.

  • Lưu ý

    • Tài liệu của Hydro hiện vẫn đang được hoàn thiện; nếu có câu hỏi hoặc phát hiện lỗi, bạn nên tạo issue trên kho GitHub của Hydro.

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-02-02
Ý kiến trên Hacker News

  • Có một bài thuyết trình YouTube hay giải thích dự án Hydro. Chủ yếu tập trung vào DFIR
    https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

  • Có vẻ cần thêm ví dụ ứng dụng thực tế để hiểu nên áp dụng nó vào đâu trong thực tế

  • Tôi thắc mắc liệu có đánh mất các lợi thế mà Rust mang lại không nếu ở giữa có một ngôn ngữ trung gian với runtime riêng
    Tôi cứ nghĩ đây sẽ là một ngôn ngữ điều phối các binary Rust riêng biệt để ghép chúng thành một hệ thống phân tán nhất quán và hoạt động được, nhưng có vẻ như không chỉ ở mức keo dán mà là viết từ đầu đến cuối bằng DFIR

    • Tôi là một trong các nghiên cứu sinh tiến sĩ dẫn dắt công việc về Hydro. DFIR gần giống một DSL tầng trung gian hơn, cho phép các nhà phát triển ngôn ngữ cấp cao tái cấu trúc mã Rust để phù hợp hơn với các tối ưu hóa cấp thấp như vector hóa
      Các toán tử DFIR (map, filter, v.v.) nhận Rust closure, nên chúng có thể được truyền nguyên vẹn từ ngôn ngữ cấp cao đến binary Rust cuối cùng. Từ góc nhìn người dùng, họ sẽ không phải trực tiếp làm việc với DFIR
    • Nếu đó là điều bạn hỏi, thì DFIR được triển khai bằng Rust

  • Thật sự thú vị. Nếu có ai rành lĩnh vực này, tôi muốn biết có nghiên cứu trước đó hoặc framework tương tự nào trong các ngôn ngữ khác không
    Mảng dataflow đã có nhiều người làm, tôi từng nghĩ Materialize khá hay, và cũng đã dùng Kafka Streams trong công việc. Tôi cho rằng một framework kết nối những thứ này lại với nhau sẽ có ý nghĩa

    • Nhìn qua thì về mặt khái niệm nó khá giống các công việc trong mảng khoa học dữ liệu. Tôi nghĩ đến Spark hoặc Dask, vốn cũng được nhắc trong tài liệu
      Đặc biệt vì dựa trên Rust nên khả năng phối hợp tốt với các ngôn ngữ khác có thể trở thành điểm mạnh. Với Spark, JVM là lựa chọn tốt về tính khả chuyển nhưng đem theo nhiều độ phức tạp; còn Dask chạy trên Python nên là một phụ thuộc khá nặng nếu bạn không vốn đã dùng Python
      Về Rust phân tán, tôi cũng từng xem Lunatic và thấy có vẻ ổn, nhưng nó có vẻ thấp tầng hơn một chút so với hướng mà Hydro nhắm tới
    • Trông như một sự pha trộn giữa Akka(https://getakka.net/, phiên bản ít mang cảm giác enterprise hơn so với bản Java), vốn dựa trên actor model và tập trung vào hệ thống phân tán, với các thư viện phản ứng như rx(https://reactivex.io/)
      Vì vậy https://doc.akka.io/libraries/akka-core/current/stream/index... có thể là đối tượng so sánh gần nhất
    • Dự án này xuất phát từ RISELab
      https://rise.cs.berkeley.edu/projects/
      Hầu hết xử lý dữ liệu và hệ thống phân tán đều có một mức độ liên hệ nào đó với các nghiên cứu mà phòng lab này đã làm

  • Tôi thích nỗ lực này, nhưng hy vọng một ngày nào đó hệ sinh thái Rust sẽ có thứ gì đó như akka.rs

  • Tôi tò mò nó so với timely [0] như thế nào từ góc nhìn dataflow. Cũng muốn biết liệu biểu diễn trung gian có thể diễn đạt control flow như vòng lặp hay không
    [0] https://github.com/TimelyDataflow/timely-dataflow

    • Tôi đọc qua bài báo Flo một chút thì thấy nó mô tả đồ thị dataflow như Timely, nhưng khác với nền tảng thiên về thực thi hơn của Timely, nó dường như đến từ truyền thống dataflow ngữ nghĩa
      Nó gần với lập trình phản ứng hàm, hợp thành, luồng của luồng, toán tử đại số và hướng chứng minh hơn. Nó có một khái niệm “tiến triển” rất khác Timely, và tập trung vào việc đảm bảo rằng phép hợp thành vẫn có tính sinh ngay cả với đầu vào streaming có khả năng vô hạn
      Thực ra trong Flo gần như không có khái niệm “tính đúng lúc” và cũng không có timestamp. Nó hỗ trợ lặp lồng nhau như Timely nhưng cơ chế rất khác. Đại số cơ sở cực kỳ phi chu trình, nhưng việc hình thức hóa stream/đồ thị lồng nhau cho phép biểu diễn lặp
      Bài báo cũng so sánh trực tiếp với DBSP; theo cách tôi hiểu thì DBSP cũng thuộc dòng Timely/Naiad. Các tác giả xem Flo là một framework ngữ nghĩa thống nhất tiềm năng cho nhiều hệ thống tương tự như Flink, LVars, DBSP
      Vì vậy tôi nghĩ các tác giả Flo hiểu rõ Naiad/Timely và được truyền cảm hứng từ đồ thị lặp lồng nhau, nhưng ngoài điểm đó thì khá khác biệt
    • Bài báo mới nhất [0] có nhắc đến Naiad(timely dataflow) vài lần. Chẳng hạn: “Lấy cảm hứng từ các nút ingress/egress của Naiad [34], stream lồng nhau có thể được xử lý bằng các đồ thị dataflow lồng nhau, xử lý lặp các mảnh dữ liệu đến từ một stream lớn hơn và hỗ trợ truyền trạng thái giữa các lần lặp”
      [0] https://hydro.run/papers/flo.pdf

  • Nếu mỗi “process” được triển khai dưới dạng một binary riêng, có lẽ điều đó nghĩa là nó được chạy như một process riêng; khi đó nhìn từ góc độ tăng overhead thì có vẻ có vấn đề
    Tôi tò mò họ đạt được giao tiếp nhanh bằng cách nào. Có dùng cơ chế kiểu IPC qua shared memory tốc độ cao không?
    Ngoài ra cũng không thấy nội dung nào về việc tích hợp với async. Dù thích hay không, phần lớn áp đảo code xử lý networking đã chuyển sang async, và trong nhiều lĩnh vực cần networking, rất khó tìm được thư viện tốt mà không bất đồng bộ

    • Tôi hiểu “phân tán” nghĩa là các phần được tách ra trên những máy hoàn toàn riêng biệt. Nếu vậy thì việc mỗi thành phần chạy như một process độc lập là cần thiết
    • Hiện tại Hydro tập trung vào các ứng dụng mạng, và phần lớn tính song song đến từ song song giữa các máy, chứ không phải bên trong một máy duy nhất
      Vì vậy nếu muốn song song trên một máy đơn thì sẽ có thêm chút overhead. Như đã nhắc, đây là phần chúng tôi nhất định muốn giải quyết trong tương lai thông qua shared memory
      Tuần trước tại POPL 2025, một sinh viên đại học tham gia Hydro đã trình bày một compiler tự động biên dịch các khối code async-await thành data flow của Hydro. Vẫn đang trong quá trình phát triển và chưa được tài liệu hóa, nhưng có thể xem tại đây: https://github.com/hydro-project/HydraulicLift

  • Trông thật sự rất hay và tôi nghĩ ra vài cách sử dụng. Đặc biệt phần triển khai trông khá độc đáo
    Tôi mong tài liệu sẽ được bổ sung thêm, và đặc biệt tò mò về các phần có vẻ là cốt lõi như Streams, Singletons, Optionals

  • Tôi thích programming model này. Tôi tò mò liệu khi viết lại ứng dụng, nó có thực hiện cả tối ưu hóa mạng không
    Tôi muốn biết nó có xử lý các bottleneck mạng hay congestion không

  • Tôi tò mò nó so với trường hợp dùng thứ như Ballista cho data pipeline thì thế nào
    Ballista hưởng lợi rất nhiều từ việc được xây dựng trên Apache Arrow và Apache Datafusion

    • Tôi là một trong những người tạo ra Hydro. Hệ sinh thái quanh Ballista, Arrow và Parquet tập trung nhiều hơn vào xử lý truy vấn phân tích, còn Hydro là nỗ lực đưa các khái niệm từ thế giới xử lý truy vấn sang triển khai hệ thống phân tán
      Mục tiêu không phải là chạy truy vấn SQL, mà là xử lý code hệ thống phân tán (ví dụ: triển khai microservice) như một truy vấn SQL. Tích hợp Arrow và Parquet cũng nằm trong roadmap