Hatchet – file de travaux distribuée open source

File de travaux distribuée et tolérante aux pannes

• Hatchet remplace les files d’attente ou systèmes pub/sub existants, difficiles à gérer, afin de concevoir des charges de travail durables capables de se remettre des échecs et de résoudre des problèmes tels que la concurrence, l’équité et la limitation de débit.
• Au lieu de gérer votre propre file de travaux ou système pub/sub, vous pouvez utiliser Hatchet pour répartir des fonctions entre une série de workers avec un minimum de configuration ou d’infrastructure.

Avantages de Hatchet

• Planification à très faible latence et haut débit
  • Hatchet est construit sur une file à faible latence avec un temps de démarrage moyen de 25ms, offrant un équilibre optimal entre capacité d’interaction en temps réel et fiabilité nécessaire aux tâches critiques.
• Concurrence, équité et limitation de débit
  • Des stratégies comme FIFO, LIFO, Round Robin et les Priority Queues sont implémentées comme stratégies intégrées de Hatchet, ce qui permet de contourner les problèmes classiques de montée en charge avec une configuration minimale.
• Résilience dès la conception
  • Grâce à des politiques de retry personnalisées et à une gestion des erreurs intégrée, Hatchet garantit une reprise rapide des tâches après des échecs temporaires.

Visibilité et contrôle renforcés

• Observabilité
  • Toutes les exécutions sont entièrement interrogeables, ce qui permet d’identifier rapidement les problèmes.
• Exécution durable (pratique)
  • Vous pouvez rejouer les événements et redémarrer manuellement une exécution à une étape précise d’un workflow.
• Cron
  • Vous pouvez planifier l’exécution répétée de fonctions.
• Planification ponctuelle
  • Vous pouvez planifier l’exécution d’une fonction à une heure et une date spécifiques.
• Protection contre les pics
  • Atténue les pics de trafic et n’exécute que ce que le système peut supporter.
• Streaming progressif
  • Vous pouvez vous abonner aux mises à jour selon l’avancement des workers d’arrière-plan.

Exemples de cas d’usage

• Équité pour l’IA générative
  • Hatchet permet de répartir équitablement les requêtes entre les workers afin d’éviter qu’un utilisateur très actif ne surcharge le système.
• Traitement par lots pour l’indexation de documents
  • Hatchet peut gérer le traitement par lots à grande échelle de documents, d’images et d’autres données, et reprendre le travail en cours en cas d’échec.
• Orchestration de workflows pour les systèmes multimodaux
  • Hatchet peut coordonner des entrées et sorties multimodales et prendre en charge des exécutions complètes de type DAG.
• Exactitude pour le traitement piloté par événements
  • Il peut réagir à des événements externes ou internes au système et rejouer automatiquement les événements.

Démarrage rapide

• Hatchet prend en charge des SDK open source pour Python, Typescript et Go.
• Pour commencer, vous pouvez consulter la documentation Hatchet ou le dépôt de démarrage rapide.

Dépôts SDK

• Hatchet fournit par défaut un SDK Go.
• Un SDK Typescript est également disponible.
• En cas de problème lié à un SDK, vous pouvez soumettre une issue dans le dépôt concerné.

Existe-t-il une version cloud managée de Hatchet ?

• Oui, une version cloud est proposée à certaines entreprises qui aident à construire et façonner le produit pendant la période bêta.

Existe-t-il une version auto-hébergée de Hatchet ?

• Oui, la documentation contient les instructions pour les conteneurs Docker open source destinés à l’auto-hébergement.

Comment cela se compare-t-il aux alternatives ? (Celery, BullMQ)

• Pourquoi avoir créé une autre file managée ?
  • L’objectif était notamment de bénéficier des avantages d’une file transactionnelle complète, en particulier pour les exécutions de type DAG, avec la conviction forte que Postgres peut remplacer la plupart des cas d’usage de file.
  • Beaucoup de files reposent sur Redis, et si l’on n’y prend pas garde, des pertes de données dues à un OOM peuvent survenir ; avec PG, ces problèmes peuvent être évités.

Problèmes

• Vous pouvez signaler les bugs découverts via les issues GitHub.
• Comme le projet en est à ses débuts, il est préférable de prendre d’abord contact sur Discord avant de demander des fonctionnalités complexes.

Si vous souhaitez contribuer

• Consultez la documentation de contribution et indiquez sur le canal Discord #contributing sur quoi vous souhaitez travailler afin d’aider à orienter le projet et de faciliter la collaboration.

Avis de GN⁺

• Hatchet semble être une solution qui réduit la complexité de la gestion des files de travaux dans les systèmes distribués tout en offrant haute disponibilité et tolérance aux pannes, particulièrement utile pour le traitement de données à grande échelle et les services en temps réel.
• Par rapport aux autres systèmes de file utilisés sur le marché, la stabilité et la scalabilité obtenues grâce à l’usage de Postgres constituent un avantage notable.
• Parmi les points à considérer lors de l’adoption de Hatchet figurent la compatibilité avec l’infrastructure existante, la migration des données et le niveau de compétence technique de l’équipe.
• Les fonctions avancées de visibilité et de contrôle offertes par Hatchet peuvent faciliter la surveillance des performances du système et la résolution des problèmes, réduisant ainsi la charge de travail des équipes de développement et d’exploitation.
• Hatchet étant encore en phase bêta, une validation suffisante est nécessaire en matière de stabilité et de fonctionnalités, ainsi que des tests approfondis avant une application à grande échelle.

[GN⁺]

Commentaires sur Hacker News

• Un utilisateur explique qu’il cherchait depuis 3 ans un produit avec une file de tâches basée sur Postgres, des workers opérant dans plusieurs langages, et des capacités d’observabilité intégrées correctes. Il dit avoir vérifié le marché tous les 6 mois et évalué des alternatives, mais avoir toujours été déçu. Il précise toutefois préférer une file basée sur Postgres afin d’éviter des dépendances supplémentaires comme RabbitMQ. Il utilise actuellement graphile-worker, mais indique avoir encore des besoins non couverts.
• Un autre utilisateur souligne que ce produit est financé par Y Combinator et se demande si l’entreprise suivra un modèle « open core » ou cherchera un autre mode de monétisation.
• Un autre utilisateur mentionne apprécier la fonctionnalité de push subscription des systèmes pub/sub et explique que, par exemple, dans GCP pub/sub, on peut avoir des abonnés qui poussent vers un endpoint HTTP au lieu de tirer les événements depuis la file. Cette approche présente l’avantage de pouvoir scaler à partir de requêtes HTTP et jusqu’à zéro en utilisant des runtimes comme Cloud Run ou Lambda. Il ajoute que configurer l’auto-scaling des workers peut être plus complexe, et qu’il est possible de mettre en place l’auto-scaling KEDA sur RabbitMQ à partir des métriques de profondeur de file, mais que cela ajoute de la complexité. Il demande s’il est prévu de prendre en charge un modèle dans lequel un démon maintenant une connexion HTTP peut pousser les tâches.
• Un utilisateur demande d’expliquer pourquoi toutes les fonctions reçoivent un contexte en argument. Il dit avoir l’impression que cela oblige à écrire beaucoup de code boilerplate lors de la rédaction des fonctions.
• Un autre utilisateur dit qu’il aurait aimé connaître cette idée lorsqu’il a implémenté un système distribué de traitement de DAG, et qu’il a envie de l’essayer.
• Un utilisateur demande si les tarifs de l’offre cloud managée sont publics et s’il est prévu de créer un opérateur Kubernetes pour l’option self-hosted. Il exprime aussi son inquiétude quant au fait que l’utilisation de la licence MIT pourrait permettre à Amazon de lancer à l’avenir un service Amazon Hatchet.
• Un autre utilisateur indique qu’il est en train d’écrire une file de tâches pour un exécuteur de jobs basé sur des DAG, et qu’il souhaite que le graphe de tâches puisse s’exécuter avec PostgreSQL, SQLite, en mémoire, etc., sans prendre en compte les retries, les timeouts, les ressources sérialisées, et ainsi de suite. Cette approche l’intéresse.
• Un utilisateur dit avoir besoin d’une file de tâches dans laquelle le client (navigateur web) peut écouter la progression d’un job jusqu’à son achèvement. Il apprécie la simplicité et l’accessibilité de Deno Queue, mais dit devoir implémenter lui-même côté client la souscription à l’état des jobs. Il se demande si cela est possible sur une base Postgres et dit avoir confirmé que c’était faisable via un lien vers la documentation.
• Un autre utilisateur mentionne avoir rencontré, dans un ancien emploi, un problème nécessitant de planifier un nombre illimité de tâches. Par exemple, si un patient prend rendez-vous dans 6 mois, il faut programmer une série de notifications pour lui rappeler son rendez-vous pendant cette période. Il dit avoir commencé par insérer des enregistrements dans une file en base de données et à les scruter toutes les quelques secondes, mais que le coût d’IO lié au polling n’était pas idéal et qu’il voulait résoudre cela sans utiliser de système distribué. Il est ensuite passé à Redis, mais a rencontré des problèmes comme la complexité liée à la gestion de plusieurs dispatchers, des problèmes d’OOM, et la nécessité d’exécuter des jobs auxiliaires pour déplacer les tâches vers une file immédiate. Il avait envisagé de passer à PG avec SKIP LOCKED, entre autres, mais a changé d’entreprise. Il se demande si Hatchet convient à ce type de cas d’usage.
• Enfin, un utilisateur demande comment Hatchet se compare à Temporal/Cadence/Conductor, et si Hatchet prend lui aussi en charge l’exécution durable.