Hatchet – Postgres-आधारित job orchestration प्लेटफ़ॉर्म

 (github.com/hatchet-dev)
11 पॉइंट द्वारा GN⁺ 2025-04-07 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Postgres-आधारित बड़े पैमाने के background job processing प्लेटफ़ॉर्म का open source संस्करण
  • Distributed Task Queue और workflow orchestration प्लेटफ़ॉर्म
  • जटिल job workflow, failure recovery, scheduling, event-based trigger, और real-time monitoring तक का समर्थन
  • Python, Go, TypeScript SDK उपलब्ध
  • MIT लाइसेंस, self-hosting और cloud version उपलब्ध

मुख्य फीचर्स का सारांश

  • queue management

    • Postgres-आधारित durable queue system
      • key-based queuing (fair job distribution लागू करने के लिए)
      • rate limiting
      • Sticky Assignment और Worker Affinity
    • job distribution, retry, और failure notification का स्वतः प्रबंधन
    • Python / TypeScript / Go उदाहरण उपलब्ध

  • job orchestration

    • DAG-आधारित workflow configuration
      • condition-based execution (उदा: sleep, event-based trigger, parent job के output value के आधार पर conditional execution आदि)
      • जटिल branching logic को संभाल सकता है
    • jobs के बीच dependency definition, कई jobs का parallel execution
    • durable task के रूप में intermediate result storage और recovery का समर्थन
      • durable function execution: failure होने पर intermediate state को cache करके rerun से restore करता है
      • Durable Sleep और Durable Events का भी समर्थन

  • flow control

    • user-level concurrency limits
    • global और dynamic rate limiting
    • रणनीतिक job distribution के ज़रिए system stability सुनिश्चित

  • job scheduling

    • Cron jobs, scheduled execution, durable sleep का समर्थन
    • उदाहरण: रोज़ आधी रात को execution, किसी विशेष समय पर schedule, तय समय तक wait आदि

  • job routing

    • Sticky Assignment: job को उसी worker पर स्थिर रखना
    • Worker Affinity: optimal worker selection logic लागू

  • event-based triggers

    • external event प्राप्त होने के बाद job execute किया जा सकता है
    • event/sleep conditions को combine किया जा सकता है

  • real-time web UI

    • real-time dashboard और monitoring
    • job logs देखना, notification settings (Slack/email)

Hatchet का उपयोग कब करना चाहिए?

  • ✅ जब DAG-आधारित workflow configuration की ज़रूरत हो
  • ✅ जब job failure पर retry और state preservation महत्वपूर्ण हो
  • ✅ बहुत-से users वाले application में distributed job processing की ज़रूरत हो
  • ❌ जब केवल तेज़ी से setup होने वाली simple queue चाहिए (Celery/BullMQ आदि सुझाए जाते हैं)
  • ❌ जब विभिन्न data connectors के साथ integration महत्वपूर्ण हो (Airflow/Prefect आदि सुझाए जाते हैं)

तुलना: Hatchet vs अन्य solutions

  • Hatchet vs Temporal

    • Hatchet में queue + DAG + Durable Execution तीनों का समर्थन है
    • Temporal, Durable Execution के लिए अधिक optimize है
    • Hatchet को self-host करना आसान है (सिर्फ Postgres चाहिए)

  • Hatchet vs BullMQ / Celery

    • Hatchet में job history storage + UI visualization + built-in orchestration शामिल है
    • BullMQ/Celery हल्के queue libraries हैं, लेकिन monitoring features सीमित हैं

  • Hatchet vs Airflow / Prefect

    • Hatchet में high-speed execution, low latency, self-managed workers हैं
    • Airflow/Prefect data pipeline-केंद्रित हैं और integration connectors में मजबूत हैं

सारांश

  • Hatchet केवल Postgres पर चलने वाला आधुनिक distributed job processing प्लेटफ़ॉर्म है
  • Durable, Observable, Composable job system को एक ही tool से लागू किया जा सकता है
  • cloud/self-hosting दोनों का समर्थन करता है, और Python/Go/TypeScript के साथ आसानी से integrate किया जा सकता है

संबंधित पढ़ाई

2 टिप्पणियां

 
halfenif 2025-04-08

2 घंटे टेस्ट करने के बाद लिखा है.

  • मैं MQ बना रहा हूँ, इसलिए सोचा कि शायद यह Postgres-आधारित कुछ नया होगा, इसलिए टेस्ट किया, लेकिन rabbit की ज़रूरत देखकर थोड़ा निराश हुआ
  • यह k8s दृष्टिकोण वाला नहीं है, इसलिए docker-compose.yaml को podman(+Arch) पर चलाया
  • मैं Postgres को अलग से इस्तेमाल करना चाहता था, इसलिए थोड़ी और सेटिंग करनी पड़ी, लेकिन आखिर में "SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER: Invalid certificate verification context" मिलने पर रुक गया
  • बीच में कुछ गलत हो जाए तो Postgres database को drop करके फिर से शुरू करना पड़ता था
  • हर बार API Key बनानी पड़ती है, लेकिन Web स्क्रीन पर Key पूरा दिखाई नहीं देता, इसलिए developer tools का इस्तेमाल करके उसे निकालना पड़ा.
 
GN⁺ 2025-04-07
Hacker News टिप्पणियाँ

  • जानना चाहता हूँ कि यह Procrastinate या Chancy जैसे दूसरे pg-आधारित Python job runners से कैसे अलग है

  • यह काफ़ी दिलचस्प है

    • जब कहा गया कि FOR UPDATE SKIP LOCKED 25k queries/sec तक scale नहीं करता, तो जानना चाहता हूँ कि यह किस बिंदु पर सीमा तक पहुँचा
    • buffered reads और writes, और सभी high-volume tables को ID column पर बदलने के बारे में जानना चाहता हूँ
    • जानना चाहता हूँ कि क्या ये बातें FOR UPDATE SKIP LOCKED को ज़रूरत के हिसाब से scale करने वाले समाधान का हिस्सा थीं

  • जानना चाहता हूँ कि queue operations (jobs को queue में डालना और complete के रूप में mark करना) क्या मेरे business logic के साथ उसी transaction में होती हैं

    • मुझे लगता है कि यही database-based queue की मुख्य विशेषता है
    • यह retries के लिए logic को सरल बनाता है
    • job execution के समय भी वही समस्या हो सकती है
    • इस बिंदु पर शायद SQS का इस्तेमाल करना बेहतर हो

  • मैं एक event/workflow-आधारित application डिज़ाइन कर रहा हूँ, और यह solution बहुत promising लग रहा है

    • मैंने Temporal पर भी विचार किया, लेकिन यह बिल्कुल सही fit नहीं लगा
    • open source license application design को लेकर भरोसा देता है
    • मैं CEL जैसे condition expressions ढूँढ रहा था

  • Hatchet architecture में छह सुधारों की वजह से हर dimension में performance बेहतर हुई

    • time series tables की range-based partitioning
    • task events की hash-based partitioning
    • monitoring tables और queue का अलगाव
    • buffered reads और writes
    • सभी high-volume tables को ID column पर बदलना
    • Postgres triggers का आक्रामक उपयोग
    • manual पढ़ें तो हैरान कर देने वाली चीज़ें की जा सकती हैं

  • README मानकर चलता है कि dark mode इस्तेमाल करने वाले users ज़्यादा हैं

    • logo सफ़ेद है, इसलिए dark mode न हो तो दिखाई नहीं देता
    • GitHub के आँकड़े देखना दिलचस्प होगा

  • Postgres को message queue की तरह इस्तेमाल करते समय मुझे बड़े payloads (50MB+) को संभालने की समस्या का सामना करना पड़ा

    • समाधान unlogged tables और नियमित full vacuum का उपयोग था
    • मैं Postgres expert नहीं हूँ, लेकिन जानना चाहता हूँ कि क्या इस समस्या का समाधान किया गया है

  • docs को 15 मिनट देखने के बाद मैं यह feedback दे रहा हूँ

    • light mode, open source, logging, और DX interface अच्छे हैं
    • Hello World example को किसी वास्तविक scenario से बदलना बेहतर होगा
    • multi-step jobs वाले workflow का code intuitive नहीं है
    • Hatchet की सोच, patterns, और terminology की आदत डालनी पड़ती है
    • users के लिए इसे आसान बनाने की कोशिश कम लगती है
    • engineering posts का मतलब है, लेकिन customers को cloud infrastructure में दिलचस्पी नहीं होती
    • workflow बाज़ार में बहुत सारे options हैं, इसलिए अंत में फिर से rewrite या pivot करने की संभावना ज़्यादा है
    • automation journey पर फ़ोकस करना चाहिए, ताकि लोग इसे आसानी से अपनाकर configure कर सकें
    • workflow को JSON में serialize करना मुश्किल है
    • Hatchet workflows को दूसरी कंपनी में आसानी से ले जाया जा सके, ऐसा होना चाहिए

  • v1 release के लिए बधाई

    • मैं लगभग 1 साल से Hatchet का उपयोग कर रहा हूँ, और 6 महीने पहले इसे production में deploy किया था
    • open source support और quick start शानदार हैं
    • system में डाला गया engineering effort साफ़ दिखता है

  • पहली छाप अच्छी है, release के लिए बधाई

    • मेरे कुछ सवाल हैं
    • जानना चाहता हूँ कि क्या यह durable jobs को support करता है
    • जानना चाहता हूँ कि job inputs और outputs कहाँ store होते हैं
    • जानना चाहता हूँ कि PostgreSQL instance के size और I/O metrics के आधार पर यह अनुमान लगाया जा सकता है या नहीं कि system प्रति सेकंड कितने jobs process कर सकता है
    • मैं अलग-अलग tools का मूल्यांकन कर रहा हूँ, और जानना चाहता हूँ कि Hatchet का अनुभव कैसा है
    • मैं ऐसा tool ढूँढ रहा हूँ जिसमें न्यूनतम boilerplate के साथ काम किया जा सके