Hatchet – แพลตฟอร์มออร์เคสตรางานที่ทำงานบน Postgres

 (github.com/hatchet-dev)
11 คะแนน โดย GN⁺ 2025-04-07 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • โอเพนซอร์ส แพลตฟอร์มประมวลงานเบื้องหลังขนาดใหญ่ ที่ทำงานบน Postgres
  • Distributed Task Queue และ แพลตฟอร์ม Workflow Orchestration
  • รองรับตั้งแต่เวิร์กโฟลว์งานที่ซับซ้อน การกู้คืนจากความล้มเหลว การตั้งเวลา ทริกเกอร์แบบอิงเหตุการณ์ ไปจนถึงการมอนิเตอร์แบบเรียลไทม์
  • มี SDK สำหรับ Python, Go, TypeScript
  • ใบอนุญาต MIT มีทั้งเวอร์ชัน self-hosting และคลาวด์

สรุปความสามารถหลัก

  • การจัดการคิว

    • ระบบคิวที่ทนทานบน Postgres
      • การเข้าคิวแบบอิงคีย์ (ทำให้การกระจายงานเป็นธรรม)
      • Rate limiting
      • Sticky Assignment และ Worker Affinity
    • จัดการการกระจายงาน การลองใหม่ และการแจ้งเตือนเมื่อเกิดความล้มเหลวโดยอัตโนมัติ
    • มีตัวอย่างสำหรับ Python / TypeScript / Go

  • การออร์เคสตรางาน

    • สร้างเวิร์กโฟลว์แบบอิง DAG
      • การทำงานตามเงื่อนไข (เช่น sleep, ทริกเกอร์แบบอิงเหตุการณ์, การทำงานตามเงื่อนไขจากค่าผลลัพธ์ของงานแม่ เป็นต้น)
      • รองรับลอจิกการแตกแขนงที่ซับซ้อน
    • กำหนด dependency ระหว่างงาน และรันหลายงานแบบขนานได้
    • รองรับการบันทึกและกู้คืนผลลัพธ์ระหว่างทางด้วย durable task
      • การรันฟังก์ชันแบบคงทน: เมื่อเกิดความล้มเหลวจะ cache สถานะระหว่างทางและกู้คืนด้วยการรันใหม่
      • รองรับ Durable Sleep และ Durable Events ด้วย

  • การควบคุมโฟลว์ (Flow Control)

    • จำกัด concurrency ระดับผู้ใช้
    • Rate Limiting แบบ global และแบบไดนามิก
    • เพิ่มเสถียรภาพของระบบผ่านการกระจายงานเชิงกลยุทธ์

  • การตั้งเวลางาน

    • รองรับ Cron jobs, การรันตามเวลาที่กำหนด, durable sleep
    • ตัวอย่าง: รันทุกวันตอนเที่ยงคืน, จองรันตามเวลาที่กำหนด, รอตามเวลาที่ระบุ เป็นต้น

  • การกำหนดเส้นทางงาน

    • Sticky Assignment: ตรึงงานไว้กับ worker เดิม
    • Worker Affinity: ใช้ลอจิกเลือก worker ที่เหมาะสมที่สุด

  • ทริกเกอร์แบบอิงเหตุการณ์

    • สามารถรันงานหลังรับเหตุการณ์จากภายนอกได้
    • รวมเงื่อนไขแบบ event/sleep ได้

  • เว็บ UI แบบเรียลไทม์

    • แดชบอร์ดและการมอนิเตอร์แบบเรียลไทม์
    • ดูล็อกงานและตั้งค่าการแจ้งเตือน (Slack/อีเมล)

Hatchet เหมาะใช้เมื่อไร?

  • ✅ เมื่อต้องการสร้างเวิร์กโฟลว์แบบอิง DAG
  • ✅ เมื่อต้องให้ความสำคัญกับการลองใหม่และการคงสถานะเมื่อเกิดความล้มเหลว
  • ✅ การกระจายประมวลงานสำหรับแอปพลิเคชันที่มีผู้ใช้จำนวนมาก
  • ❌ เมื่อต้องการเพียงคิวแบบง่ายที่ตั้งค่าได้รวดเร็ว (แนะนำ Celery/BullMQ เป็นต้น)
  • ❌ เมื่อต้องให้ความสำคัญกับการเชื่อมต่อกับ data connector ที่หลากหลาย (แนะนำ Airflow/Prefect เป็นต้น)

เปรียบเทียบ: Hatchet vs โซลูชันอื่น

  • Hatchet vs Temporal

    • Hatchet รองรับทั้ง คิว + DAG + Durable Execution
    • Temporal เหมาะที่สุดสำหรับ Durable Execution
    • Hatchet ทำ self-hosting ได้ง่ายกว่า (ต้องใช้แค่ Postgres)

  • Hatchet vs BullMQ / Celery

    • Hatchet มี การเก็บประวัติงาน + การแสดงผลผ่าน UI + orchestration ในตัว
    • BullMQ/Celery เป็นไลบรารีคิวแบบน้ำหนักเบา แต่มีความสามารถด้านมอนิเตอร์ค่อนข้างจำกัด

  • Hatchet vs Airflow / Prefect

    • Hatchet มีจุดเด่นที่ การทำงานความเร็วสูง, latency ต่ำ, และการจัดการ worker ในตัวเอง
    • Airflow/Prefect เน้น data pipeline และเด่นด้าน connector สำหรับการเชื่อมต่อ

สรุป

  • Hatchet คือ แพลตฟอร์มประมวลงานแบบกระจายสมัยใหม่ ที่ทำงานได้ด้วย Postgres เพียงอย่างเดียว
  • สามารถสร้างระบบงานที่ Durable, Observable และ Composable ได้ด้วยเครื่องมือเดียว
  • รองรับทั้งคลาวด์และ self-hosting และเชื่อมต่อได้ง่ายด้วย Python/Go/TypeScript

บทความที่เกี่ยวข้อง

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
  • ถ้ามีอะไรผิดพลาดขึ้นมาระหว่างทาง ต้อง drop ฐานข้อมูล postgres แล้วเริ่มใหม่
  • ต้องสร้าง API Key ใหม่ทุกครั้ง แต่บนหน้าเว็บ Key แสดงไม่ครบทั้งหมด จึงต้องใช้เครื่องมือนักพัฒนาเพื่อดึงออกมา
 
GN⁺ 2025-04-07
ความคิดเห็นบน Hacker News

  • อยากรู้ว่ามันแตกต่างจากตัวรันงาน Python ที่อิงกับ pg ตัวอื่นอย่าง Procrastinate หรือ Chancy อย่างไร

  • น่าสนใจมาก

    • เมื่อบอกว่า FOR UPDATE SKIP LOCKED ขยายไปไม่ถึง 25k queries/sec ก็อยากรู้ว่าไปชนเพดานที่จุดไหน
    • อยากรู้เรื่องการอ่านและเขียนแบบบัฟเฟอร์ รวมถึงการเปลี่ยนตารางขนาดใหญ่ทั้งหมดให้ใช้คอลัมน์ ID
    • อยากรู้ว่าสิ่งเหล่านี้เป็นส่วนหนึ่งของวิธีแก้เพื่อทำให้ FOR UPDATE SKIP LOCKED ขยายได้ตามความต้องการหรือไม่

  • อยากรู้ว่างานในคิว (การใส่งานเข้าคิวและทำเครื่องหมายว่าเสร็จสิ้น) เกิดขึ้นในทรานแซกชันเดียวกับ business logic ของผมหรือไม่

    • คิดว่านี่เป็นความสามารถหลักของคิวที่อิงฐานข้อมูล
    • ทำให้ตรรกะเกี่ยวกับการ retry ง่ายขึ้น
    • ปัญหาเดียวกันนี้อาจเกิดขึ้นตอนรันงานได้เช่นกัน
    • ณ จุดนี้ การใช้ SQS อาจจะดีกว่าก็ได้

  • กำลังออกแบบแอปพลิเคชันที่ขับเคลื่อนด้วย event/workflow และโซลูชันนี้ดูมีอนาคตมาก

    • เคยพิจารณา Temporal ด้วย แต่รู้สึกว่ายังไม่ใช่ตัวที่เหมาะพอดี
    • ไลเซนส์โอเพนซอร์สช่วยให้มั่นใจในการออกแบบแอปพลิเคชันมากขึ้น
    • กำลังมองหาเงื่อนไขแบบเดียวกับ CEL อยู่

  • การปรับปรุงสถาปัตยกรรมของ Hatchet ทั้งหกข้อทำให้ประสิทธิภาพดีขึ้นในทุกมิติ

    • การแบ่งพาร์ทิชันตามช่วงสำหรับตาราง time series
    • การแบ่งพาร์ทิชันตามแฮชสำหรับ event ของงาน
    • การแยกตาราง monitoring ออกจากคิว
    • การอ่านและเขียนแบบบัฟเฟอร์
    • การเปลี่ยนตารางขนาดใหญ่ทั้งหมดให้ใช้คอลัมน์ ID
    • การใช้ Postgres trigger อย่างจริงจัง
    • ถ้าอ่านคู่มือดี ๆ ก็ทำอะไรน่าทึ่งได้

  • README เหมือนตั้งสมมติฐานว่าผู้ใช้ส่วนใหญ่ใช้ dark mode

    • โลโก้เป็นสีขาว เลยจะมองไม่เห็นถ้าไม่มี dark mode
    • ถ้าได้ดูสถิติของ GitHub ก็น่าจะน่าสนใจ

  • ตอนใช้ Postgres เป็น message queue เคยเจอปัญหาในการจัดการ payload ขนาดใหญ่ (มากกว่า 50MB)

    • วิธีแก้คือใช้ตาราง unlogged และทำ full vacuum เป็นระยะ
    • ไม่ได้เป็นผู้เชี่ยวชาญ Postgres แต่ก็อยากรู้ว่าจัดการปัญหานี้ไปแล้วหรือยัง

  • หลังจากดูเอกสารอยู่ 15 นาที ก็ขอให้ฟีดแบ็กไว้

    • ชอบ light mode, ความเป็นโอเพนซอร์ส, logging และอินเทอร์เฟซด้าน DX
    • น่าจะดีกว่าถ้าแทนที่ตัวอย่าง Hello World ด้วยสถานการณ์จริง
    • โค้ดของ workflow ที่มีงานหลายขั้นยังไม่ค่อยตรงไปตรงมา
    • ต้องทำความคุ้นเคยกับแนวคิด แพตเทิร์น และศัพท์เฉพาะของ Hatchet
    • ดูเหมือนยังพยายามไม่มากพอที่จะทำให้มันง่ายสำหรับลูกค้า
    • โพสต์เชิงวิศวกรรมมีความหมายก็จริง แต่ลูกค้าไม่ได้สนใจคลาวด์อินฟราสตรักเจอร์
    • เพราะในตลาด workflow มีตัวเลือกมากมาย จึงมีโอกาสสูงที่จะเขียนใหม่อีกครั้งหรือ pivot ในตอนท้าย
    • ควรโฟกัสเส้นทางการทำ automation และทำให้คนหยิบไปใช้กับตั้งค่าได้ง่าย
    • การ serialize workflow เป็น JSON ทำได้ยาก
    • ควรทำให้ย้าย workflow ของ Hatchet ไปบริษัทอื่นได้ง่าย

  • ขอแสดงความยินดีกับการเปิดตัว v1

    • ใช้ Hatchet มาเกือบ 1 ปีแล้ว และนำขึ้นโปรดักชันเมื่อ 6 เดือนก่อน
    • การซัพพอร์ตโอเพนซอร์สและการเริ่มต้นใช้งานที่รวดเร็วนั้นยอดเยี่ยมมาก
    • งานวิศวกรรมที่ใส่เข้ามาในระบบเห็นได้ชัดเจน

  • ความประทับใจแรกดีมาก ยินดีกับการเปิดตัว

    • มีคำถามอยู่เล็กน้อย
    • อยากรู้ว่ารองรับงานแบบถาวรหรือไม่
    • อยากรู้ว่าข้อมูลนำเข้าและผลลัพธ์ของงานถูกเก็บไว้ที่ไหน
    • อยากรู้ว่าสามารถประเมินจำนวนงานต่อวินาทีที่ระบบประมวลผลได้จากขนาดของอินสแตนซ์ PostgreSQL และเมตริก I/O หรือไม่
    • กำลังประเมินเครื่องมือหลายตัวอยู่ และอยากรู้ว่า Hatchet ให้ความรู้สึกอย่างไร
    • กำลังมองหาเครื่องมือที่ใช้งานได้ด้วย boilerplate น้อยที่สุด