Hydro: Rust için dağıtık programlama çatısı

• Giriş

  • Hydro, Rust için yüksek seviyeli bir dağıtık programlama çatısıdır.
  • Hydro, ölçeklenebilir dağıtık servisleri hızlıca yazmaya yardımcı olur ve Rust'ın bellek güvenliğini garanti etmesi gibi dağıtık güvenliğini garanti eder.
  • Dağıtık programların test modunda ya da dağıtım modunda kolayca çalıştırılmasını destekler.

• Hydro'nun özellikleri

  • Hydro, yüksek performanslı tek iş parçacıklı DFIR runtime üzerinde çalışan dağıtık bir veri akışı dilidir.
  • Aktör veya RPC gibi geleneksel mimarilerden farklı olarak, birden fazla konuma yayılmış hesaplamaları tanımlayabilen koreografik bir API sunar.
  • Hydro Deploy ile entegre çalışır; böylece dağıtık Hydro programları yerelde veya bulutta kolayca dağıtılabilir ve çalıştırılabilir.

• Derleme ve dağıtım

  • Hydro, iki aşamalı bir derleme yaklaşımı kullanır.
  • Hydro programları standart Rust programlarıdır ve geliştiricinin dizüstü bilgisayarında bir dağıtım planı oluşturur.
  • Bu plan DFIR'a derlenerek dağıtık sistemdeki her makine için ayrı binary'ler üretir.
  • Oluşturulan plan ve bulut kaynak belirtimleri kullanılarak buluta dağıtılır.

• Kullanım örnekleri

  • Hydro, 2 aşamalı commit ve Paxos gibi yüksek performanslı dağıtık sistemlerin gerçekleştirilmesinde kullanılır.
  • Bu protokolleri yeniden kullanılabilir bileşenler olarak sunan bir dağıtık sistem standart kütüphanesi geliştirilmektedir.

• Dikkat edilmesi gerekenler

  • Hydro'nun dokümantasyonu hâlâ geliştirme aşamasındadır; soru veya hata durumunda Hydro GitHub deposunda issue açılması önerilir.

[GN⁺]

Hacker News yorumları

• Hydro projesini anlatan iyi bir YouTube sunumu var. Ağırlıklı olarak DFIR'a odaklanıyor
  https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

• Gerçekte nerelerde uygulanabileceğini anlamak için daha fazla gerçekçi uygulama örneğine ihtiyaç var gibi görünüyor

  • Kod örnekleri henüz tamamen belgelenmiş değil, ancak Paxos'un daha gerçekçi bir uygulamasını burada görebilirsiniz: https://github.com/hydro-project/hydro/blob/main/hydro_test/...
    Anahtar-değer deposu gibi daha karmaşık uygulamalar da geliştiriliyor

• Arada kendi runtime'ı olan bir ara dil varsa, Rust'ın sağladığı avantajların kaybolup kaybolmadığını merak ediyorum
  Ayrı Rust ikililerini koordine edip tutarlı ve çalışan bir dağıtık sistem hâline getiren bir dil olacağını sanmıştım; ama yapıştırıcı seviyesinde değil, baştan sona DFIR ile yazılıyormuş gibi görünüyor

  • Hydro çalışmasını yöneten doktora öğrencilerinden biriyim. DFIR daha çok ara katman bir DSL'e yakın; üst düzey dil geliştiricilerinin Rust kodunu vektörleştirme gibi düşük seviyeli optimizasyonlara daha uygun olacak şekilde yeniden yapılandırmasını sağlıyor
    DFIR operatörleri (map, filter vb.) Rust closure'ları aldığı için, bunlar üst düzey dilden nihai Rust ikilisine kadar olduğu gibi aktarılabiliyor. Kullanıcı açısından DFIR ile doğrudan uğraşılmıyor
  • Sorduğunuz buysa, DFIR Rust ile uygulanmış durumda

• Gerçekten ilginç. Bu alanı bilen biri varsa, önceki çalışmaları ya da başka dillerde benzer framework'ler olup olmadığını anlatırsa iyi olur
  Veri akışı tarafında pek çok kişi çalıştı; Materialize'ı oldukça havalı bulmuştum, işte Kafka Streams de kullandım. Bunları bir araya getiren bir framework mantıklı olabilir diye düşünüyorum

  • İlk bakışta veri bilimi tarafındaki çalışmalarla kavramsal olarak oldukça benzer görünüyor. Belgelerde de adı geçen Spark veya Dask akla geliyor
    Özellikle Rust tabanlı olduğu için başka dillerle iyi bütünleşebilmesi güçlü bir yön olabilir. Spark için taşınabilirlik açısından JVM iyi bir tercih, ama beraberinde çok karmaşıklık getiriyor; Dask ise Python üzerinde çalıştığından, zaten Python kullanılan bir ortamda değilseniz oldukça ağır bir bağımlılık
    Dağıtık Rust tarafında Lunatic'e de bakmıştım; fena görünmüyordu ama Hydro'nun hedeflediğinden biraz daha düşük seviyeli görünmüştü
  • Aktör modeli tabanlı ve dağıtık sistemlere odaklanan Akka (https://getakka.net/, Java sürümüne göre daha az kurumsal hissediyor) ile rx (https://reactivex.io/) gibi reaktif kütüphanelerin bir karışımı gibi görünüyor
    Bu yüzden https://doc.akka.io/libraries/akka-core/current/stream/index... en yakın karşılaştırma adayı olabilir
  • Bu proje RISELab'den çıkmış
    https://rise.cs.berkeley.edu/projects/
    Veri işleme ve dağıtık sistemlerin çoğu, bu laboratuvarın yaptığı araştırmalarla bir ölçüde bağlantılı

• Gösterilen çabayı beğeniyorum ama bir gün Rust ekosistemine akka.rs gibi bir şeyin girmesini isterim

• Veri akışı açısından timely [0] ile nasıl karşılaştırıldığını merak ediyorum. Ara temsilde döngüler gibi kontrol akışının ifade edilip edilemediğini de merak ediyorum
  [0] https://github.com/TimelyDataflow/timely-dataflow

  • Flo makalesini biraz okudum; Timely gibi bir veri akışı grafiğini tarif ediyor, ancak Timely'nin daha yürütme odaklı arka planının aksine anlamsal veri akışı geleneğinden geliyor gibi görünüyor
    Fonksiyonel reaktif programlama, bileşim, akışların akışı, cebirsel operatörler ve ispat odaklı yaklaşıma daha yakın. Timely'den çok farklı bir “ilerleme” kavramına sahip ve potansiyel olarak sonsuz akış girdilerinde bile bileşimin üretken olmasını garanti etmeye odaklanıyor
    Aslında Flo'da “timeliness” kavramı neredeyse yok ve zaman damgaları da yok. Timely gibi iç içe yinelemeleri destekliyor, ancak mekanizma çok farklı. Temel cebir son derece döngüsüz, fakat iç içe akış/graf biçimselleştirmesi yinelemeyi mümkün kılıyor
    Makale DBSP ile de doğrudan karşılaştırma yapıyor; anladığım kadarıyla DBSP de Timely/Naiad çizgisinde. Yazarlar Flo'nun Flink, LVars, DBSP gibi çeşitli benzer sistemler için birleştirici bir anlamsal framework olabileceğini düşünüyor
    Bu yüzden Flo yazarları Naiad/Timely'yi iyi biliyor ve iç içe yinelemeli grafiklerden ilham almışlar, ama bunun dışında oldukça farklı olduğunu düşünüyorum
  • En yeni makalede [0] Naiad'den (timely dataflow) birkaç kez söz ediliyor. Örneğin şöyle deniyor: “Naiad [34]'ün ingress/egress düğümlerinden ilhamla, iç içe akışlar daha büyük bir akıştan gelen veri parçalarını yinelemeli olarak işleyen ve yinelemeler arasında durum aktarımını destekleyen iç içe veri akışı grafikleri olarak ele alınabilir”
    [0] https://hydro.run/papers/flo.pdf

• Her “process” ayrı bir ikili dosya olarak dağıtılıyorsa muhtemelen ayrı bir süreç olarak çalıştırıldığı anlamına gelir; bu durumda ek yük artışı açısından sorunlu görünüyor.
  Hızlı iletişimin nasıl sağlandığını merak ediyorum. Hızlı paylaşımlı bellek IPC gibi bir mekanizma mı kullanılıyor?
  Ayrıca async ile entegrasyona dair bir şey de görünmüyor. İyi ya da kötü, ağ iletişimiyle uğraşan kodların ezici çoğunluğu async’e geçti ve ağ gerektiren pek çok alanda iyi bir asenkron olmayan kütüphane bulmak zor.

  • “Dağıtık” dendiğinde bunun tamamen ayrı makinelere bölünmüş olduğu anlamına geldiğini düşünmüştüm. Öyleyse her bileşenin bağımsız bir süreç olarak çalışması gerekir.
  • Hydro şu anda ağ uygulamalarına odaklanıyor ve paralelliğin büyük kısmı tek bir makinenin içinden değil, makineler arası paralellikten geliyor.
    Bu yüzden tek makine paralelliği istiyorsanız bir miktar ek yük var. Belirttiğiniz gibi, paylaşımlı bellek üzerinden ileride mutlaka çözmek istediğimiz bir konu.
    Geçen hafta POPL 2025’te Hydro’da çalışan bir lisans öğrencisi, async-await kod bloklarını otomatik olarak Hydro veri akışlarına derleyen bir derleyici sundu. Hâlâ üzerinde çalışılıyor ve belgelenmiş değil, ancak buradan görülebilir: https://github.com/hydro-project/HydraulicLift

• Gerçekten harika görünüyor ve aklıma birkaç kullanım biçimi geliyor. Özellikle dağıtım kısmı özgün görünüyor.
  Belgelerin daha da tamamlanmasını bekliyorum; özellikle de temel gibi görünen Streams, Singletons ve Optionals bölümlerini merak ediyorum.

  • Tam da dokümantasyon haftasına denk geldi :) Bu arada stream’ler için Rustdoc oldukça tamamlanmış durumda: https://hydro.run/rustdoc/hydro_lang/stream/struct.Stream

• Programlama modelini beğendim. Uygulamayı yeniden yazarken ağ optimizasyonu da yapıp yapmadığını merak ediyorum.
  Ağ darboğazlarını veya tıkanıklık yönetimini ele alıp almadığını bilmek isterim.

• Veri pipeline’ları için Ballista gibi bir şey kullanmaya kıyasla nasıl olduğunu merak ediyorum.
  Ballista, Apache Arrow ve Apache Datafusion üzerine kurulu olmasından çok fayda sağlıyor.

  • Hydro’yu yapanlardan biriyim. Ballista ile Arrow ve Parquet çevresindeki ekosistem, analitik sorgu işlemeye çok daha fazla odaklanmış durumda; Hydro ise sorgu işleme dünyasındaki kavramları dağıtık sistem uygulamasına taşımaya çalışıyor.
    Amaç SQL sorguları çalıştırmak değil, dağıtık sistem kodunu (ör. mikroservis uygulamalarını) SQL sorguları gibi ele almak. Arrow ve Parquet entegrasyonu da yol haritasında yer alıyor.