Hydro: Ein Framework für verteilte Programmierung in Rust

• Einführung

  • Hydro ist ein High-Level-Framework für verteilte Programmierung in Rust.
  • Hydro hilft dabei, skalierbare verteilte Services schnell zu schreiben, und garantiert verteilte Sicherheit, so wie Rust Speichersicherheit garantiert.
  • Es unterstützt die einfache Ausführung verteilter Programme im Testmodus oder im Deployment-Modus.

• Eigenschaften von Hydro

  • Hydro ist eine verteilte Dataflow-Sprache, die von einer performanten Single-Thread-DFIR-Runtime angetrieben wird.
  • Anders als traditionelle Architekturen wie Actor oder RPC bietet es eine choreografische API, mit der sich Berechnungen über mehrere Orte hinweg beschreiben lassen.
  • Durch die Integration mit Hydro Deploy lassen sich verteilte Hydro-Programme lokal oder in der Cloud einfach bereitstellen und ausführen.

• Kompilierung und Deployment

  • Hydro verwendet einen zweistufigen Kompilierungsansatz.
  • Hydro-Programme sind Standard-Rust-Programme, die auf dem Laptop des Entwicklers einen Deployment-Plan erzeugen.
  • Dieser Plan wird zu DFIR kompiliert und erzeugt einzelne Binärdateien für jede Maschine im verteilten System.
  • Mit dem erzeugten Plan und den Spezifikationen der Cloud-Ressourcen wird anschließend in die Cloud deployt.

• Anwendungsfälle

  • Hydro wird zur Implementierung hochperformanter verteilter Systeme wie Two-Phase Commit und Paxos verwendet.
  • Derzeit wird an einer Standardbibliothek für verteilte Systeme gearbeitet, die diese Protokolle als wiederverwendbare Komponenten bereitstellt.

• Hinweise

  • Die Dokumentation von Hydro ist noch in Arbeit; bei Fragen oder Bugs wird empfohlen, im Hydro-GitHub-Repository ein Issue zu eröffnen.

[GN⁺]

Meinungen auf Hacker News

• Es gibt einen guten YouTube-Vortrag, der das Hydro-Projekt erklärt. Der Fokus liegt vor allem auf DFIR
  https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

• Um zu verstehen, wo man es in der Praxis sinnvoll einsetzen könnte, bräuchte es wohl mehr realistische Anwendungsbeispiele

  • Die Codebeispiele sind zwar noch nicht vollständig dokumentiert, aber eine realistischere Paxos-Implementierung findet sich hier: https://github.com/hydro-project/hydro/blob/main/hydro_test/...
    An komplexeren Anwendungen wie einem Key-Value-Store wird ebenfalls gearbeitet

• Wenn es dazwischen eine Zwischensprache mit eigener Runtime gibt, frage ich mich, ob man damit die Vorteile von Rust verliert
  Ich hatte erwartet, dass es eine Sprache ist, die separate Rust-Binaries koordiniert und zu einem konsistenten, funktionierenden verteilten System verbindet. Es sieht aber so aus, als würde man nicht nur auf Glue-Ebene arbeiten, sondern von Anfang bis Ende in DFIR schreiben

  • Ich bin einer der Doktoranden, die die Arbeit an Hydro leiten. DFIR ist eher eine DSL auf einer Zwischenschicht und ermöglicht es Entwicklern der Hochsprache, Rust-Code so umzustrukturieren, dass er besser für Low-Level-Optimierungen wie Vektorisierung geeignet ist
    DFIR-Operatoren (map, filter usw.) nehmen Rust-Closures entgegen, sodass sie aus der Hochsprache bis zum finalen Rust-Binary unverändert durchgereicht werden können. Als Nutzer muss man sich nicht direkt mit DFIR befassen
  • Falls das die Frage war: DFIR ist in Rust implementiert

• Wirklich interessant. Wenn sich jemand in diesem Bereich auskennt, wäre es spannend zu hören, welche Vorarbeiten es gab oder ob es ähnliche Frameworks in anderen Sprachen gab
  Im Dataflow-Bereich haben viele Leute gearbeitet, Materialize fand ich ziemlich cool, und beruflich habe ich auch Kafka Streams verwendet. Ich denke, ein Framework, das all das zusammenführt, könnte sinnvoll sein

  • Auf den ersten Blick wirkt es konzeptionell recht ähnlich zu Arbeiten aus dem Data-Science-Bereich. Man denkt an Spark oder Dask, die auch in der Dokumentation erwähnt werden
    Gerade weil es Rust-basiert ist und sich gut mit anderen Sprachen verzahnen lässt, könnte das eine Stärke werden. Für Spark ist die JVM aus Portabilitätssicht eine gute Wahl, bringt aber viel Komplexität mit sich; Dask läuft in Python und ist daher eine ziemlich schwere Abhängigkeit, wenn man nicht ohnehin schon Python verwendet
    Im Bereich verteiltes Rust habe ich mir auch Lunatic angesehen, das recht ordentlich wirkte, aber im Vergleich zu dem, worauf Hydro abzielt, eher Low-Level aussah
  • Es wirkt wie eine Mischung aus Akka (https://getakka.net/, weniger Enterprise-mäßig als die Java-Version), das auf dem Actor Model basiert und auf verteilte Systeme fokussiert ist, und reaktiven Bibliotheken wie rx (https://reactivex.io/)
    Daher könnte https://doc.akka.io/libraries/akka-core/current/stream/index... der naheliegendste Vergleich sein
  • Dieses Projekt stammt aus dem RISELab
    https://rise.cs.berkeley.edu/projects/
    Ein Großteil der Datenverarbeitung und der verteilten Systeme hat in gewisser Weise Anknüpfungspunkte an die Forschung dieses Labs

• Ich schätze den Aufwand, aber ich hoffe, dass irgendwann etwas wie akka.rs ins Rust-Ökosystem kommt

• Aus Dataflow-Perspektive frage ich mich, wie es sich mit timely [0] vergleicht. Außerdem würde mich interessieren, ob sich in der Zwischendarstellung Kontrollfluss wie Schleifen ausdrücken lässt
  [0] https://github.com/TimelyDataflow/timely-dataflow

  • Ich habe das Flo-Paper kurz angelesen: Es beschreibt wie Timely Dataflow-Graphen, scheint aber im Gegensatz zu Timelys stärker ausführungsorientiertem Hintergrund eher aus der Tradition des semantischen Dataflow zu kommen
    Es ist näher an funktionaler reaktiver Programmierung, Komposition, Flows von Flows, algebraischen Operatoren und beweisorientierten Ansätzen. Es hat einen ganz anderen Begriff von „Fortschritt“ als Timely und konzentriert sich darauf, sicherzustellen, dass Komposition auch bei potenziell unendlichen Streaming-Eingaben produktiv bleibt
    Tatsächlich gibt es in Flo kaum ein Konzept von „Timeliness“ und auch keine Timestamps. Es unterstützt wie Timely verschachtelte Iteration, aber der Mechanismus ist sehr anders. Die grundlegende Algebra ist extrem azyklisch, doch die Formalisierung verschachtelter Streams/Graphen ermöglicht Iteration
    Das Paper vergleicht auch direkt mit DBSP; so wie ich es verstehe, gehört DBSP ebenfalls zur Timely/Naiad-Familie. Die Autoren sehen Flo als möglichen einheitlichen semantischen Rahmen für mehrere ähnliche Systeme wie Flink, LVars und DBSP
    Daher kennen die Flo-Autoren Naiad/Timely gut und wurden von verschachtelten Iterationsgraphen inspiriert, aber ansonsten scheint es ziemlich anders zu sein
  • Im neuesten Paper [0] wird Naiad (timely dataflow) mehrfach erwähnt. Zum Beispiel heißt es: „Inspiriert von den Ingress-/Egress-Knoten in Naiad [34] können verschachtelte Streams als verschachtelter Dataflow-Graph verarbeitet werden, der Datenstücke aus einem größeren Stream iterativ verarbeitet und die Weitergabe von Zustand zwischen Iterationen unterstützt“
    [0] https://hydro.run/papers/flo.pdf

• Wenn jeder „Prozess“ als separates Binary ausgeliefert wird, bedeutet das vermutlich, dass er auch als separater Prozess läuft. Dann wirkt das im Hinblick auf zusätzlichen Overhead problematisch.
  Ich frage mich, wie schnelle Kommunikation erreicht wird. Wird ein Mechanismus wie schnelles Shared-Memory-IPC verwendet?
  Außerdem sehe ich nichts zur Integration mit async. Ob man es mag oder nicht: Der überwältigende Großteil des Codes, der Networking behandelt, ist zu async gewechselt, und in vielen Bereichen, die Networking brauchen, ist es schwer, gute nicht-asynchrone Bibliotheken zu finden.

  • Unter „verteilt“ habe ich verstanden, dass die Teile vollständig auf separate Maschinen aufgeteilt sind. Dann ist es erforderlich, dass jede Komponente als unabhängiger Prozess läuft.
  • Derzeit konzentriert sich Hydro auf Netzwerk-Anwendungen, und der Großteil der Parallelität entsteht nicht innerhalb einer einzelnen Maschine, sondern durch Parallelität zwischen Maschinen.
    Wenn man also Parallelität auf einer einzelnen Maschine möchte, gibt es etwas zusätzlichen Overhead. Wie erwähnt, ist das ein Punkt, den wir künftig unbedingt über Shared Memory angehen möchten.
    Letzte Woche hat ein an Hydro beteiligter Student auf der POPL 2025 einen Compiler vorgestellt, der async-await-Codeblöcke automatisch in Hydro-Datenflüsse kompiliert. Das ist noch in Arbeit und nicht dokumentiert, aber hier zu sehen: https://github.com/hydro-project/HydraulicLift

• Sieht wirklich großartig aus, und mir fallen einige Einsatzmöglichkeiten ein. Besonders der Deployment-Teil wirkt ungewöhnlich.
  Ich freue mich darauf, dass die Dokumentation weiter ausgebaut wird; besonders neugierig bin ich auf die offenbar zentralen Teile Streams, Singletons und Optionals.

  • Das fällt gerade in unsere Dokumentationswoche :) In der Zwischenzeit ist das Rustdoc zu Streams schon ziemlich vollständig: https://hydro.run/rustdoc/hydro_lang/stream/struct.Stream

• Das Programmiermodell gefällt mir. Ich frage mich, ob beim Umschreiben der Anwendung auch Netzwerkoptimierung durchgeführt wird.
  Ich würde gern wissen, ob Netzwerkengpässe oder Congestion Handling behandelt werden.

• Ich frage mich, wie sich das mit dem Einsatz von etwas wie Ballista für Daten-Pipelines vergleichen lässt.
  Ballista profitiert stark davon, dass es auf Apache Arrow und Apache Datafusion aufbaut.

  • Ich bin einer der Entwickler von Hydro. Das Ökosystem rund um Ballista, Arrow und Parquet ist deutlich stärker auf analytische Query-Verarbeitung ausgerichtet, während Hydro versucht, Konzepte aus der Welt der Query-Verarbeitung in die Implementierung verteilter Systeme zu übertragen.
    Ziel ist nicht, SQL-Queries auszuführen, sondern Code für verteilte Systeme (z. B. die Implementierung von Microservices) so zu behandeln wie SQL-Queries. Die Integration von Arrow und Parquet steht ebenfalls auf der Roadmap.