Hydro: framework de programação distribuída para Rust

• Introdução

  • Hydro é um framework de programação distribuída de alto nível para Rust.
  • Hydro ajuda a escrever rapidamente serviços distribuídos escaláveis e garante segurança distribuída, assim como Rust garante segurança de memória.
  • Ele oferece suporte para executar programas distribuídos com facilidade tanto no modo de teste quanto no modo de implantação.

• Características do Hydro

  • Hydro é uma linguagem de fluxo de dados distribuído executada sobre o runtime DFIR monothread de alto desempenho.
  • Diferentemente de arquiteturas tradicionais como atores ou RPC, ele fornece uma API coreográfica que permite descrever computações distribuídas por vários locais.
  • Integrado ao Hydro Deploy, ele permite implantar e executar facilmente programas distribuídos em Hydro localmente ou na nuvem.

• Compilação e implantação

  • Hydro usa uma abordagem de compilação em duas etapas.
  • Um programa Hydro é um programa Rust padrão que gera um plano de implantação no notebook do desenvolvedor.
  • Esse plano é compilado para DFIR, gerando binários individuais para cada máquina do sistema distribuído.
  • O sistema é implantado na nuvem usando o plano gerado e as especificações dos recursos de nuvem.

• Casos de uso

  • Hydro é usado para implementar sistemas distribuídos de alto desempenho, como commit em duas fases e Paxos.
  • Está em desenvolvimento uma biblioteca padrão de sistemas distribuídos que oferece esses protocolos como componentes reutilizáveis.

• Observações

  • A documentação do Hydro ainda está em desenvolvimento, e recomenda-se abrir uma issue no repositório GitHub do Hydro em caso de dúvidas ou bugs.

[GN⁺]

Opiniões no Hacker News

• Há uma boa apresentação no YouTube explicando o projeto Hydro. Ela se concentra principalmente em DFIR
  https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

• Parece que são necessários mais exemplos de aplicação realistas para entender onde isso seria bom de aplicar na prática

  • Os exemplos de código ainda não estão totalmente documentados, mas uma implementação mais realista de Paxos pode ser vista aqui: https://github.com/hydro-project/hydro/blob/main/hydro_test/...
    Eles também estão desenvolvendo aplicações mais complexas, como um armazenamento chave-valor

• Fico curioso se, ao haver uma linguagem intermediária com runtime próprio no meio, não se perdem as vantagens que o Rust oferece
  Eu imaginava que seria uma linguagem para coordenar binários Rust separados e amarrá-los em um sistema distribuído coerente e funcional, mas parece que não é apenas uma camada de cola: é como se fosse escrito de ponta a ponta em DFIR

  • Sou um dos doutorandos que lideram o trabalho no Hydro. DFIR é mais próximo de uma DSL de camada intermediária e permite que desenvolvedores da linguagem de alto nível reestruturem código Rust para torná-lo mais adequado a otimizações de baixo nível, como vetorização
    Operadores DFIR (map, filter etc.) recebem closures Rust, então eles podem ser repassados diretamente da linguagem de alto nível até o binário Rust final. Do ponto de vista do usuário, ele não terá de lidar diretamente com DFIR
  • Se é isso que você está perguntando, DFIR é implementado em Rust

• Muito interessante. Se alguém conhecer essa área, seria bom saber se houve trabalhos anteriores ou frameworks semelhantes em outras linguagens
  Várias pessoas trabalharam com fluxo de dados, achei o Materialize bem legal, e também já usei Kafka Streams no trabalho. Acho que um framework que reúna isso tudo faria sentido

  • À primeira vista, parece conceitualmente bem parecido com trabalhos da área de ciência de dados. Lembra Spark ou Dask, que a documentação também menciona
    O fato de ser baseado em Rust e, por isso, poder se integrar bem com outras linguagens, parece ter potencial para ser um ponto forte. No caso do Spark, a JVM é uma boa escolha em termos de portabilidade, mas traz bastante complexidade; já o Dask roda em Python, então é uma dependência bem pesada se você já não estiver usando Python
    Também vi o Lunatic para Rust distribuído, e ele parecia bom, mas parecia um pouco mais baixo nível do que aquilo que o Hydro busca
  • Parece uma mistura de Akka(https://getakka.net/, menos “enterprise” que a versão em Java), que é baseado no modelo de atores e focado em sistemas distribuídos, com bibliotecas reativas como rx(https://reactivex.io/)
    Por isso, https://doc.akka.io/libraries/akka-core/current/stream/index... talvez seja o comparativo mais próximo
  • Este projeto veio do RISELab
    https://rise.cs.berkeley.edu/projects/
    A maior parte do processamento de dados e dos sistemas distribuídos tem algum ponto de conexão com pesquisas feitas por esse laboratório

• Gosto do esforço, mas espero que algum dia algo como akka.rs entre no ecossistema Rust

• Do ponto de vista de fluxo de dados, fico curioso sobre como ele se compara ao timely [0]. Também fico curioso se é possível expressar fluxo de controle, como loops, na representação intermediária
  [0] https://github.com/TimelyDataflow/timely-dataflow

  • Li um pouco o artigo sobre Flo e, embora ele descreva grafos de fluxo de dados como o Timely, parece vir da tradição de fluxo de dados semântico, ao contrário da base mais voltada à execução do Timely
    É mais próximo de programação reativa funcional, composição, fluxos de fluxos, operadores algébricos e orientação a provas. Ele tem uma noção de “progresso” muito diferente da do Timely e se concentra em garantir que a composição seja produtiva mesmo com entradas de streaming potencialmente infinitas
    Na verdade, o Flo quase não tem conceito de “pontualidade” e não tem timestamps. Ele dá suporte a iteração aninhada como o Timely, mas o mecanismo é muito diferente. A álgebra básica é extremamente acíclica, mas a formalização de streams/grafos aninhados possibilita a iteração
    O artigo também o compara diretamente ao DBSP; pelo que entendi, o DBSP também pertence à linhagem Timely/Naiad. Os autores veem o Flo como um possível framework semântico unificador para vários sistemas semelhantes, como Flink, LVars e DBSP
    Portanto, acho que os autores do Flo conhecem bem Naiad/Timely e se inspiraram em grafos de iteração aninhados, mas, fora isso, é bastante diferente
  • O artigo mais recente [0] menciona Naiad (timely dataflow) algumas vezes. Por exemplo, diz: “Inspirados pelos nós de ingress/egress do Naiad [34], streams aninhados podem ser processados como grafos de fluxo de dados aninhados que iteram sobre fragmentos de dados vindos de um stream maior e dão suporte à passagem de estado entre iterações”
    [0] https://hydro.run/papers/flo.pdf

• Se cada “processo” for distribuído como um binário separado, isso provavelmente significa que ele roda como um processo separado; então parece haver um problema em termos de aumento de overhead
  Fico curioso sobre como a comunicação rápida é alcançada. Usa algum mecanismo como IPC rápido via memória compartilhada?
  Também não vejo nada sobre integração com async. Gostando ou não, a esmagadora maioria do código que lida com networking migrou para async, e em muitas áreas que precisam de networking é difícil encontrar boas bibliotecas não assíncronas

  • Entendi “distribuído” como algo dividido entre máquinas completamente separadas. Nesse caso, é necessário que cada componente rode como um processo independente
  • Atualmente, o Hydro é focado em aplicações de rede, e a maior parte do paralelismo vem de paralelismo entre máquinas, não dentro de uma única máquina
    Então, se você quiser paralelismo em uma única máquina, há algum overhead adicional. Como mencionado, isso é algo que queremos muito resolver no futuro por meio de memória compartilhada
    Na semana passada, na POPL 2025, um aluno de graduação envolvido no Hydro apresentou um compilador que compila automaticamente blocos de código async-await para fluxos de dados do Hydro. Ainda está em andamento e não está documentado, mas pode ser visto aqui: https://github.com/hydro-project/HydraulicLift

• Parece realmente muito bacana, e consigo imaginar algumas formas de uso. Especialmente a parte de implantação parece única
  Estou ansioso para que a documentação fique mais completa, e tenho curiosidade especialmente sobre Streams, Singletons e Optionals, que parecem ser centrais

  • Por acaso estamos na semana de escrever documentação :) Enquanto isso, o Rustdoc sobre streams já está bastante completo: https://hydro.run/rustdoc/hydro_lang/stream/struct.Stream

• Gosto do modelo de programação. Fico curioso se, ao reescrever a aplicação, ele também realiza otimização de rede
  Quero saber se ele lida com gargalos de rede ou tratamento de congestionamento

• Fico curioso sobre como isso se compara ao uso de algo como Ballista em pipelines de dados
  O Ballista se beneficia muito por ser construído sobre Apache Arrow e Apache Datafusion

  • Sou uma das pessoas que criou o Hydro. O ecossistema em torno de Ballista, Arrow e Parquet é muito mais focado no processamento de consultas analíticas, enquanto o Hydro tenta trazer conceitos do mundo de processamento de consultas para a implementação de sistemas distribuídos
    O objetivo não é executar consultas SQL, mas tratar código de sistemas distribuídos (por exemplo, implementação de microsserviços) como se fosse uma consulta SQL. A integração com Arrow e Parquet também está no roadmap