Hydro : framework de programmation distribuée pour Rust

• Introduction

  • Hydro est un framework de programmation distribuée de haut niveau pour Rust.
  • Hydro aide à écrire rapidement des services distribués extensibles et garantit la sûreté distribuée, tout comme Rust garantit la sûreté mémoire.
  • Il permet d’exécuter facilement des programmes distribués en mode test ou en mode déploiement.

• Caractéristiques de Hydro

  • Hydro est un langage de flux de données distribué, exécuté par le runtime DFIR monothread haute performance.
  • Contrairement aux architectures traditionnelles comme les acteurs ou les RPC, il fournit une API chorégraphique permettant de décrire des calculs répartis sur plusieurs emplacements.
  • Intégré à Hydro Deploy, il permet de déployer et d’exécuter facilement des programmes Hydro distribués en local ou dans le cloud.

• Compilation et déploiement

  • Hydro utilise une approche de compilation en deux étapes.
  • Un programme Hydro est un programme Rust standard qui génère un plan de déploiement depuis l’ordinateur portable du développeur.
  • Ce plan est compilé en DFIR afin de produire des binaires distincts pour chaque machine du système distribué.
  • Le déploiement dans le cloud s’effectue à l’aide du plan généré et des spécifications des ressources cloud.

• Cas d’usage

  • Hydro est utilisé pour implémenter des systèmes distribués haute performance comme le commit en deux phases et Paxos.
  • Une bibliothèque standard pour les systèmes distribués, fournissant ces protocoles sous forme de composants réutilisables, est en cours de développement.

• Remarques

  • La documentation de Hydro est encore en cours de rédaction ; en cas de question ou de bug, il est recommandé d’ouvrir une issue sur le dépôt GitHub de Hydro.

[GN⁺]

Avis sur Hacker News

• Il existe une bonne présentation YouTube qui explique le projet Hydro. Elle se concentre principalement sur DFIR
  https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

• Pour comprendre où l’appliquer concrètement, il faudrait davantage d’exemples d’utilisation réalistes

  • Les exemples de code ne sont pas encore entièrement documentés, mais on peut voir ici une implémentation plus réaliste de Paxos : https://github.com/hydro-project/hydro/blob/main/hydro_test/...
    Ils travaillent aussi à des applications plus complexes, comme un magasin clé-valeur

• Je me demande si, avec un langage intermédiaire doté de son propre runtime au milieu, on ne perd pas les avantages apportés par Rust
  Je pensais que ce serait un langage permettant d’orchestrer des binaires Rust distincts pour les assembler en un système distribué cohérent et fonctionnel, mais cela semble être écrit en DFIR de bout en bout, et pas seulement au niveau de la colle

  • Je suis l’un des doctorants qui dirigent les travaux sur Hydro. DFIR ressemble davantage à un DSL de couche intermédiaire, et permet aux développeurs du langage de haut niveau de restructurer le code Rust pour le rendre plus adapté à des optimisations bas niveau comme la vectorisation
    Les opérateurs DFIR (map, filter, etc.) acceptent des closures Rust, ce qui permet de les transmettre tels quels depuis le langage de haut niveau jusqu’au binaire Rust final. Du point de vue de l’utilisateur, on ne manipule pas directement DFIR
  • Si c’est bien ce que vous demandez, DFIR est implémenté en Rust

• Vraiment intéressant. Si quelqu’un connaît ce domaine, j’aimerais savoir s’il existe des travaux antérieurs ou des frameworks similaires dans d’autres langages
  Beaucoup de gens ont travaillé sur le dataflow ; j’ai trouvé Materialize assez impressionnant et j’ai aussi utilisé Kafka Streams au travail. Je pense qu’un framework qui relie tout cela aurait du sens

  • Au premier abord, cela semble assez proche conceptuellement de travaux côté data science. Cela fait penser à Spark ou Dask, mentionnés dans la documentation
    Le fait que ce soit basé sur Rust, et donc potentiellement bien intégrable avec d’autres langages, pourrait être un vrai point fort. Pour Spark, la JVM est un bon choix en termes de portabilité, mais elle apporte beaucoup de complexité ; Dask tourne en Python, ce qui en fait une dépendance assez lourde si l’on n’utilise pas déjà Python
    Côté Rust distribué, j’ai aussi regardé Lunatic, qui avait l’air intéressant, mais il semblait plus bas niveau que ce que vise Hydro
  • Cela ressemble à un mélange entre Akka (https://getakka.net/, avec un côté moins enterprise que la version Java), fondé sur le modèle d’acteurs et axé sur les systèmes distribués, et des bibliothèques réactives comme rx (https://reactivex.io/)
    Donc https://doc.akka.io/libraries/akka-core/current/stream/index... pourrait être la comparaison la plus proche
  • Ce projet vient de RISELab
    https://rise.cs.berkeley.edu/projects/
    La plupart des systèmes de traitement de données et des systèmes distribués ont, d’une manière ou d’une autre, un lien avec les recherches menées par ce labo

• J’apprécie l’effort, mais j’aimerais qu’un jour quelque chose comme akka.rs arrive dans l’écosystème Rust

• Je me demande comment cela se compare à timely [0] du point de vue du dataflow. Je me demande aussi si la représentation intermédiaire permet d’exprimer le flux de contrôle, comme les boucles
  [0] https://github.com/TimelyDataflow/timely-dataflow

  • J’ai parcouru l’article Flo : il décrit des graphes de dataflow comme Timely, mais semble venir de la tradition du dataflow sémantique, contrairement à l’historique plus orienté exécution de Timely
    On est davantage du côté de la programmation réactive fonctionnelle, de la composition, des flux de flux, des opérateurs algébriques et d’une approche orientée preuve. La notion de « progrès » y est très différente de celle de Timely, avec l’objectif de garantir que la composition reste productive même avec des entrées de streaming potentiellement infinies
    En fait, Flo n’a presque pas de notion de « timelyness » et pas de timestamps. Il prend en charge les itérations imbriquées comme Timely, mais avec des mécanismes très différents. L’algèbre de base est extrêmement acyclique, mais la formalisation en flux/graphes imbriqués permet l’itération
    L’article le compare aussi directement à DBSP ; d’après ce que j’ai compris, DBSP appartient également à la lignée Timely/Naiad. Les auteurs voient Flo comme un possible cadre sémantique unificateur pour plusieurs systèmes similaires comme Flink, LVars et DBSP
    Donc les auteurs de Flo connaissent bien Naiad/Timely et se sont inspirés des graphes d’itération imbriqués, mais à part cela, je dirais que c’est très différent
  • Le dernier article [0] mentionne plusieurs fois Naiad (timely dataflow). Par exemple : « Inspirés par les nœuds ingress/egress de Naiad [34], les flux imbriqués peuvent être traités comme des graphes de dataflow imbriqués qui traitent de manière répétée des fragments de données issus d’un flux plus large et prennent en charge le passage d’état entre les itérations »
    [0] https://hydro.run/papers/flo.pdf

• Si chaque « processus » est déployé comme un binaire distinct, cela signifie sans doute qu’il s’exécute comme un processus séparé ; dans ce cas, il semble y avoir un problème du point de vue de l’augmentation de l’overhead
  Je me demande comment les communications rapides sont obtenues. Utilise-t-il un mécanisme comme de l’IPC rapide via mémoire partagée ?
  Je ne vois pas non plus d’information sur l’intégration avec async. Qu’on le veuille ou non, l’écrasante majorité du code qui gère le réseau est passée à async, et dans de nombreux domaines qui nécessitent du réseau, il est difficile de trouver de bonnes bibliothèques non asynchrones

  • J’avais compris « distribué » comme signifiant réparti sur des machines complètement distinctes. Dans ce cas, il est nécessaire que chaque composant s’exécute comme un processus indépendant
  • Pour l’instant, Hydro se concentre sur les applications réseau, et l’essentiel du parallélisme vient du parallélisme entre machines, pas de l’intérieur d’une seule machine
    Donc si l’on veut du parallélisme sur une seule machine, il y a un certain overhead supplémentaire. Comme mentionné, c’est un point que nous voulons absolument résoudre à l’avenir via la mémoire partagée
    La semaine dernière, à POPL 2025, un étudiant de premier cycle ayant contribué à Hydro a présenté un compilateur qui compile automatiquement des blocs de code async-await en flux de données Hydro. C’est encore en cours de travail et non documenté, mais c’est visible ici : https://github.com/hydro-project/HydraulicLift

• Ça a vraiment l’air excellent, et quelques cas d’usage me viennent en tête. En particulier, la partie déploiement semble originale
  J’ai hâte que la documentation soit davantage étoffée, et je suis particulièrement curieux des parties Streams, Singletons et Optionals, qui semblent centrales

  • Ça tombe justement pendant notre semaine de rédaction de documentation :) En attendant, la Rustdoc sur les streams est déjà assez complète : https://hydro.run/rustdoc/hydro_lang/stream/struct.Stream

• J’aime bien le modèle de programmation. Je me demande s’il effectue aussi de l’optimisation réseau lors de la réécriture de l’application
  J’aimerais savoir s’il traite les goulets d’étranglement réseau ou la gestion de la congestion

• Je me demande comment cela se compare à l’utilisation de quelque chose comme Ballista pour les pipelines de données
  Ballista bénéficie beaucoup du fait d’être construit au-dessus d’Apache Arrow et d’Apache Datafusion

  • Je suis l’une des personnes qui ont créé Hydro. L’écosystème autour de Ballista, Arrow et Parquet est beaucoup plus axé sur le traitement de requêtes analytiques, tandis qu’Hydro vise à apporter les concepts du monde du traitement de requêtes à l’implémentation de systèmes distribués
    L’objectif n’est pas d’exécuter des requêtes SQL, mais de traiter le code de systèmes distribués — par exemple l’implémentation de microservices — comme des requêtes SQL. L’intégration avec Arrow et Parquet figure aussi dans la roadmap