Hatchet – fila de tarefas distribuída de código aberto

Fila de tarefas distribuída e tolerante a falhas

• O Hatchet permite projetar cargas de trabalho duráveis que substituem filas ou sistemas pub/sub tradicionais difíceis de gerenciar, recuperam-se de falhas e resolvem problemas como concorrência, justiça e limitação de taxa.
• Em vez de gerenciar sua própria fila de tarefas ou sistema pub/sub, você pode usar o Hatchet para distribuir funções entre uma série de workers com configuração ou infraestrutura mínimas.

Vantagens do Hatchet

• Agendamento de latência ultrabaixa e alto throughput
  • O Hatchet é construído sobre uma fila de baixa latência com tempo médio de início de 25ms, oferecendo um equilíbrio ideal entre capacidade de interação em tempo real e a confiabilidade exigida por cargas de trabalho de missão crítica.
• Concorrência, justiça e limitação de taxa
  • Estratégias como FIFO, LIFO, Round Robin e Priority Queues são implementadas como estratégias nativas do Hatchet, contornando problemas comuns de escalabilidade com configuração mínima.
• Resiliência por design
  • Com políticas de retry personalizadas e tratamento de erros integrado, o Hatchet garante que as tarefas possam se recuperar rapidamente de falhas transitórias.

Visibilidade e controle aprimorados

• Observabilidade
  • Todas as execuções são totalmente pesquisáveis, permitindo identificar problemas rapidamente.
• Execução durável (prática)
  • É possível reproduzir eventos e reiniciar manualmente uma execução a partir de uma etapa específica do workflow.
• Cron
  • É possível agendar execuções de funções de forma recorrente.
• Agendamento único
  • É possível agendar a execução de funções para uma data e hora específicas.
• Proteção contra picos
  • Atenua aumentos repentinos de tráfego e executa apenas o que o sistema consegue processar.
• Streaming progressivo
  • É possível assinar atualizações conforme o progresso dos workers em background.

Casos de uso de exemplo

• Justiça para IA generativa
  • Você pode usar o Hatchet para distribuir solicitações de forma justa entre os workers, evitando que usuários mais ativos sobrecarreguem o sistema.
• Processamento em lote para indexação de documentos
  • O Hatchet lida com processamento em lote em larga escala de documentos, imagens e outros dados, e pode retomar o trabalho a partir do meio em caso de falha.
• Orquestração de workflows para sistemas multimodais
  • O Hatchet pode coordenar entradas e saídas multimodais e lidar com execuções completas no estilo DAG.
• Correção para processamento orientado a eventos
  • Pode reagir a eventos externos ou internos do sistema e reproduzir eventos automaticamente.

Início rápido

• O Hatchet oferece suporte a SDKs open source para Python, Typescript e Go.
• Para começar, consulte a documentação do Hatchet ou veja o repositório de quickstart.

Repositórios de SDK

• O Hatchet fornece nativamente um SDK em Go.
• O SDK de Typescript também está disponível.
• Se houver problemas relacionados aos SDKs, você pode abrir uma issue no repositório correspondente.

Existe uma versão em nuvem gerenciada do Hatchet?

• Sim, durante o período beta eles estão oferecendo uma versão em nuvem para algumas empresas que ajudam a construir e moldar o produto.

Existe uma versão self-hosted do Hatchet?

• Sim, as instruções para os contêineres Docker open source para self-hosting podem ser encontradas na documentação.

Como isso se compara às alternativas? (Celery, BullMQ)

• Por que criar mais uma fila gerenciada?
  • O objetivo era oferecer os benefícios de uma fila transacional completa, especialmente para execuções no estilo DAG, e há uma forte convicção de que o Postgres pode substituir a maioria dos casos de uso de filas.
  • Muitas filas são baseadas em Redis e, se não houver cuidado, pode ocorrer perda de dados por OOM, mas com PG é possível evitar esse tipo de problema.

Problemas

• Você pode enviar bugs encontrados por meio das issues do Github.
• Como o projeto está em estágio inicial, é melhor entrar em contato primeiro pelo Discord antes de solicitar recursos complexos.

Se quiser contribuir

• Consulte a documentação de contribuição e informe no canal #contributing do Discord no que gostaria de trabalhar para ajudar a moldar a direção do projeto e facilitar a colaboração.

Opinião do GN⁺

• O Hatchet parece ser uma solução que reduz a complexidade do gerenciamento de filas de tarefas em sistemas distribuídos e oferece alta disponibilidade e tolerância a falhas, sendo especialmente útil para processamento de dados em larga escala e serviços em tempo real.
• Em comparação com outros sistemas de filas usados atualmente no mercado, a estabilidade e a escalabilidade obtidas com o uso de Postgres são vantagens dignas de nota.
• Ao adotar o Hatchet, é preciso considerar a compatibilidade com a infraestrutura existente, a migração de dados e a capacidade técnica da equipe.
• Os recursos avançados de visibilidade e controle oferecidos pelo Hatchet podem facilitar o monitoramento de desempenho e a resolução de problemas, reduzindo a carga de trabalho de desenvolvedores e equipes de operações.
• Como o Hatchet ainda está em fase beta, é necessária validação suficiente em termos de estabilidade e funcionalidade, além de testes adequados antes de aplicá-lo em sistemas de grande porte.

[GN⁺]

Comentários no Hacker News

• Um usuário disse que vinha procurando há 3 anos um produto com fila de tarefas baseada em Postgres, workers que operassem em várias linguagens e bons recursos de observabilidade embutidos. Ele comentou que verificava o mercado e avaliava alternativas a cada 6 meses, mas sempre se decepcionava. No entanto, mencionou que queria evitar dependências extras como RabbitMQ, então preferia filas baseadas em Postgres. Atualmente usa graphile-worker, mas disse que ainda há requisitos não atendidos.
• Outro usuário apontou que esse produto está sendo apoiado pela Y Combinator e ficou curioso para saber se a empresa seguirá um modelo de "open core" ou buscará outra forma de monetização.
• Outro usuário mencionou que gosta do recurso de push subscriptions em sistemas pub/sub e explicou que, por exemplo, no GCP pub/sub é possível ter assinantes que fazem push para um endpoint HTTP em vez de puxar eventos da fila. Disse que essa abordagem tem a vantagem de usar runtimes como Cloud Run ou Lambda para escalar com base em requisições HTTP e escalar até zero. Comentou que configurar auto scaling para workers pode ser mais complexo, e que também seria possível configurar auto scaling com KEDA no RabbitMQ com base na métrica de profundidade da fila, mas isso adiciona complexidade. O usuário perguntou se há planos para dar suporte a um modelo em que um daemon que mantém uma conexão HTTP possa receber tarefas por push.
• Um usuário pediu que explicassem por que todas as funções recebem context como argumento. Disse que isso parece exigir bastante código boilerplate ao escrever funções.
• Outro usuário disse que gostaria de ter tido essa ideia ao implementar um sistema distribuído de processamento de DAG e quer experimentar.
• Um usuário perguntou se os preços do serviço gerenciado em nuvem são públicos e se há planos para criar um operador de Kubernetes para a opção self-hosted. Também demonstrou preocupação de que, ao usar a licença MIT, a Amazon possa no futuro criar um Amazon Hatchet Service.
• Outro usuário disse que está escrevendo uma fila de tarefas para um runner de jobs baseado em DAG e quer que o grafo de tarefas seja executado usando PostgreSQL, SQLite, memória interna etc., sem precisar se preocupar com retries, timeouts, recursos serializados e afins. Esse usuário demonstrou interesse nessa abordagem.
• Um usuário disse que precisa de uma fila de tarefas em que o cliente (navegador web) possa acompanhar o progresso do job até a conclusão. Ele gosta da simplicidade e acessibilidade do Deno Queues, mas comentou que precisaria implementar por conta própria uma forma de o cliente assinar o estado do job. Perguntou se isso seria possível com base em Postgres e confirmou, por meio de um link na documentação, que sim.
• Outro usuário mencionou que, em um emprego anterior, enfrentou o problema de precisar agendar uma quantidade ilimitada de tarefas. Por exemplo, se um paciente marca uma consulta para daqui a 6 meses, é preciso programar uma série de notificações de lembrete ao longo desse período. Esse usuário disse que começou inserindo registros em uma fila no banco de dados e fazendo polling a cada poucos segundos, mas o custo de IO causado pelo polling não era ideal e ele queria resolver isso sem usar um sistema distribuído. Mudou para Redis, mas encontrou problemas como a complexidade de lidar com vários dispatchers, problemas de OOM e a necessidade de executar jobs auxiliares para mover tarefas para a fila imediata. Considerou migrar para PG e usar SKIP LOCKED etc., mas acabou trocando de emprego. Perguntou se o Hatchet seria adequado para esse caso de uso.
• Por fim, um usuário perguntou como o Hatchet se compara a Temporal/Cadence/Conductor e se o Hatchet também oferece suporte a durable execution.