Hatchet – Open-Source-Queue für verteilte Jobs

Verteilte, fehlertolerante Job-Queue

• Hatchet ersetzt bestehende, schwer zu verwaltende Queue- oder Pub/Sub-Systeme und ermöglicht die Gestaltung dauerhafter Workloads, die sich von Ausfällen erholen und Probleme wie Konkurrenz, Fairness und Rate Limiting lösen können.
• Anstatt eine eigene Job-Queue oder ein eigenes Pub/Sub-System zu verwalten, kann man mit Hatchet Funktionen mit minimaler Konfiguration oder Infrastruktur auf eine Reihe von Workern verteilen.

Vorteile von Hatchet

• Scheduling mit extrem niedriger Latenz und hohem Durchsatz
  • Hatchet basiert auf einer Low-Latency-Queue mit einer durchschnittlichen Startzeit von 25ms und bietet damit eine ausgewogene Kombination aus Echtzeit-Interaktionsfähigkeit und der für unternehmenskritische Jobs nötigen Zuverlässigkeit.
• Konkurrenz, Fairness, Rate Limiting
  • Strategien wie FIFO, LIFO, Round Robin und Priority Queues sind als integrierte Strategien in Hatchet umgesetzt, sodass sich gängige Skalierungsprobleme mit minimaler Konfiguration umgehen lassen.
• Resilienz by Design
  • Mit benutzerdefinierten Retry-Richtlinien und integrierter Fehlerbehandlung stellt Hatchet sicher, dass Jobs sich schnell von temporären Fehlern erholen können.

Verbesserte Sichtbarkeit und Kontrolle

• Observability
  • Alle Ausführungen sind vollständig durchsuchbar, sodass sich Probleme schnell identifizieren lassen.
• (Praktisch) durable execution
  • Ereignisse lassen sich erneut abspielen, und Ausführungen können an bestimmten Schritten eines Workflows manuell neu gestartet werden.
• Cron
  • Funktionsausführungen lassen sich wiederkehrend planen.
• Einmaliges Scheduling
  • Funktionsausführungen lassen sich zu einer bestimmten Uhrzeit und an einem bestimmten Datum planen.
• Spike-Schutz
  • Dämpft plötzliche Traffic-Spitzen und führt nur das aus, was das System verarbeiten kann.
• Progressives Streaming
  • Updates können entsprechend dem Fortschritt von Hintergrund-Workern abonniert werden.

Beispielhafte Einsatzfälle

• Fairness für Generative AI
  • Mit Hatchet lassen sich Anfragen fair auf Worker verteilen, damit stark ausgelastete Nutzer das System nicht überlasten.
• Batch-Verarbeitung für die Dokumentenindizierung
  • Hatchet kann große Batch-Verarbeitungen von Dokumenten, Bildern und anderen Daten übernehmen und bei Fehlern mittendrin wieder ansetzen.
• Workflow-Orchestrierung für multimodale Systeme
  • Hatchet kann multimodale Ein- und Ausgaben koordinieren und komplette Ausführungen im DAG-Stil verarbeiten.
• Korrektheit für ereignisgesteuerte Verarbeitung
  • Es kann auf externe oder interne Systemereignisse reagieren und Ereignisse automatisch erneut abspielen.

Schnellstart

• Hatchet unterstützt Open-Source-SDKs für Python, Typescript und Go.
• Zum Einstieg kann man die Hatchet-Dokumentation lesen oder das Quickstart-Repository ansehen.

SDK-Repositories

• Hatchet bietet standardmäßig ein Go-SDK an.
• Ein Typescript-SDK ist ebenfalls verfügbar.
• Wenn Probleme im Zusammenhang mit den SDKs auftreten, können im jeweiligen Repository Issues eingereicht werden.

Gibt es eine gemanagte Cloud-Version von Hatchet?

• Ja, während der Beta-Phase wird einigen Unternehmen eine Cloud-Version angeboten, die beim Aufbau und der Weiterentwicklung des Produkts helfen.

Gibt es eine Self-Hosted-Version von Hatchet?

• Ja, Anleitungen für Open-Source-Docker-Container zur Selbst-Hosting-Nutzung finden sich in der Dokumentation.

Wie schneidet das im Vergleich zu Alternativen ab? (Celery, BullMQ)

• Warum wurde noch eine weitere gemanagte Queue entwickelt?
  • Ziel war es insbesondere, die Vorteile eines vollständigen transaktionalen Queueings zu bieten, das sich auf Ausführungen im DAG-Stil stützt, und es besteht die starke Überzeugung, dass Postgres die meisten Queueing-Anwendungsfälle ersetzen kann.
  • Viele Queues basieren auf Redis, was bei Unachtsamkeit zu Datenverlust durch OOM führen kann, während sich solche Probleme mit PG vermeiden lassen.

Probleme

• Über Github-Issues können gefundene Bugs gemeldet werden.
• Da sich das Projekt noch in einer frühen Phase befindet, ist es besser, vor komplexen Feature-Requests zunächst über Discord Kontakt aufzunehmen.

Wenn du beitragen möchtest

• Sieh dir die Beitragsdokumentation an und teile im Discord-Kanal #contributing mit, woran du arbeiten möchtest; das hilft, die Projektrichtung mitzugestalten und die Zusammenarbeit zu erleichtern.

Meinung von GN⁺

• Hatchet scheint eine Lösung zu sein, die die Komplexität der Verwaltung von Job-Queues in verteilten Systemen reduziert und hohe Verfügbarkeit sowie Fehlertoleranz bietet, was besonders für groß angelegte Datenverarbeitung und Echtzeitdienste nützlich sein dürfte.
• Im Vergleich zu anderen derzeit am Markt verwendeten Queue-Systemen ist die durch den Einsatz von Postgres gewonnene Stabilität und Skalierbarkeit ein bemerkenswerter Vorteil.
• Bei der Einführung von Hatchet sollten die Kompatibilität mit der bestehenden Infrastruktur, die Datenmigration und die technischen Fähigkeiten des Teams berücksichtigt werden.
• Die erweiterten Funktionen für Sichtbarkeit und Kontrolle, die Hatchet bietet, können Performance-Monitoring und Fehlerbehebung erleichtern und so die Arbeitslast von Entwicklern und Betriebsteams verringern.
• Da Hatchet sich noch in der Beta-Phase befindet, ist eine ausreichende Validierung hinsichtlich Stabilität und Funktionalität erforderlich, und vor dem Einsatz in großen Systemen sind umfassende Tests nötig.

[GN⁺]

Hacker-News-Kommentare

• Ein Nutzer sagte, er habe drei Jahre lang nach einem Produkt gesucht, das eine auf Postgres basierende Job-Queue, Worker für verschiedene Sprachen und angemessene integrierte Observability bietet. Er habe alle sechs Monate den Markt geprüft und Alternativen bewertet, sei aber immer enttäuscht gewesen. Er erwähnte jedoch, dass er zusätzliche Abhängigkeiten wie RabbitMQ vermeiden wolle und deshalb Postgres-basierte Queues bevorzuge. Derzeit nutze er graphile-worker, habe aber weiterhin Anforderungen, die nicht erfüllt würden.
• Ein anderer Nutzer wies darauf hin, dass dieses Produkt von Y Combinator gefördert wird, und fragte sich, ob das Unternehmen einem „Open-Core“-Modell folgen oder andere Wege der Monetarisierung suchen werde.
• Ein weiterer Nutzer erwähnte, dass ihm die Push-Subscription-Funktion von Pub/Sub-Systemen gefalle, und erklärte, dass man etwa bei GCP pub/sub Subscriber haben könne, die statt Events aus der Queue zu ziehen an einen HTTP-Endpunkt gepusht würden. Das habe den Vorteil, dass man mit Laufzeitumgebungen wie Cloud Run oder Lambda anhand von HTTP-Anfragen skalieren und bis auf null herunterskalieren könne. Das Einrichten von Auto-Scaling für Worker könne komplizierter sein; man könne etwa in RabbitMQ KEDA-Auto-Scaling auf Basis von Queue-Depth-Metriken konfigurieren, was jedoch zusätzliche Komplexität mit sich bringe. Der Nutzer fragte, ob geplant sei, ein Modell zu unterstützen, bei dem ein Daemon mit offener HTTP-Verbindung Jobs pushen könne.
• Ein Nutzer bat um eine Erklärung, warum alle Funktionen context als Argument annehmen. Er sagte, das fühle sich so an, als müsse man beim Schreiben von Funktionen viel Boilerplate-Code verfassen.
• Ein anderer Nutzer sagte, er hätte sich gewünscht, diese Idee schon gekannt zu haben, als er ein verteiltes DAG-Verarbeitungssystem implementierte, und würde es gern ausprobieren.
• Ein Nutzer fragte, ob Preise für den Cloud-Service veröffentlicht werden, und ob geplant sei, für Self-Hosting-Optionen einen Kubernetes Operator zu bauen. Außerdem äußerte er die Sorge, dass Amazon durch die MIT-Lizenz künftig vielleicht einen Amazon-Hatchet-Service bauen könnte.
• Ein weiterer Nutzer schrieb, dass er an einer Job-Queue für einen DAG-basierten Task-Runner arbeite und erreichen wolle, dass der Task-Graph mit PostgreSQL, SQLite, In-Memory usw. laufe, ohne dass bei der Ausführung Retries, Timeouts, serialisierte Ressourcen und Ähnliches berücksichtigt werden müssten. Dieser Nutzer zeigte Interesse an dem Ansatz.
• Ein Nutzer sagte, er brauche eine Job-Queue, bei der der Client (Webbrowser) den Fortschritt eines Jobs bis zum Abschluss mitverfolgen könne. Ihm gefielen die Einfachheit und Zugänglichkeit von Deno Queues, aber man müsse selbst implementieren, wie der Client den Job-Status abonniert. Er fragte sich, ob das auf Postgres-Basis möglich sei, und bestätigte über einen Dokumentationslink, dass es möglich ist.
• Ein anderer Nutzer erwähnte, dass er in einem früheren Job vor dem Problem stand, eine unbegrenzte Anzahl von Jobs terminieren zu müssen. Wenn etwa ein Patient einen Termin in sechs Monaten vereinbart, müsse man eine Reihe von Erinnerungen für diesen Termin über diesen Zeitraum hinweg einplanen. Dieser Nutzer begann damit, Records in eine Datenbank-Queue zu schreiben und alle paar Sekunden zu pollen, aber die IO-Kosten des Pollings seien nicht ideal gewesen, weshalb er das Problem ohne ein verteiltes System lösen wollte. Er wechselte zu Redis, stieß aber auf Probleme wie die Komplexität im Umgang mit mehreren Dispatchern, OOM-Probleme und die Notwendigkeit, Hilfsjobs auszuführen, um Tasks in eine Sofort-Queue zu verschieben. Er habe auch überlegt, zu PG zu wechseln und Methoden wie SKIP LOCKED zu verwenden, habe dann aber den Job gewechselt. Er fragte, ob Hatchet für einen solchen Use Case geeignet sei.
• Schließlich fragte ein Nutzer, wie sich Hatchet im Vergleich zu Temporal/Cadence/Conductor schlägt und ob Hatchet ebenfalls Durable Execution unterstützt.