Apache DolphinScheduler 3.x พลิกโฉมสถาปัตยกรรมใหม่ทั้งหมด ทีมที่ยังใช้งานเวอร์ชัน 1.3 จะต้องปรับเปลี่ยนโครงสร้างคลัสเตอร์และเขียน schema ของฐานข้อมูลใหม่ก่อนที่จะสามารถอัปเกรดได้ ระบบ Master แบบ single-node เดิมจะหายไป และถูกแทนที่ด้วยระบบแบบกระจายศูนย์ (decentralized) ที่ขับเคลื่อนด้วยปลั๊กอิน ซึ่งมีการจัดตารางเวลา (schedule) การจัดเก็บ และการบันทึก log งานที่แตกต่างออกไป

ทำไมการก้าวกระโดดครั้งนี้ถึงสำคัญ

เวอร์ชัน 1.3 ยึดติดกับ Master แบบรวมศูนย์ที่จัดการการตัดสินใจในการจัดตารางเวลาทั้งหมด และมีประเภท Task ในตัวเพียง 12 ประเภท ในขณะที่ 3.x เปลี่ยนมาใช้ microkernel ที่โหลดประเภท Task และ storage adapters ในรูปแบบปลั๊กอิน และช่วยกำจัดจุดอ่อนที่ทำให้ระบบล่มได้ทั้งระบบ (single point of failure) โดยการให้ Master และ Worker สื่อสารกันผ่านบริการ Registry ผู้ดูแลระบบจะได้รับความสามารถในการขยายตัว (scalability) และความยืดหยุ่น (resilience) ที่มากขึ้น ส่วนนักพัฒนาสามารถขยายความสามารถของ scheduler ได้ง่ายๆ เพียงแค่เพิ่มไฟล์ JAR แทนที่จะต้องเข้าไปแก้ไขโค้ดหลัก

การยกเครื่องสถาปัตยกรรม

  • ระบบปลั๊กอินแบบ Microkernel – การกำหนดค่า Task, ตัวจัดการทรัพยากร (resource handlers) และการตรวจสอบสถานะ (health checks) แบบกำหนดเอง จะถูกแยกออกเป็นโมดูลต่างๆ คุณสามารถเพิ่มประเภท Task ใหม่ได้โดยการวางปลั๊กอินลงใน classpath และรีสตาร์ทโหนดที่เกี่ยวข้อง
  • การประสานงานแบบกระจายศูนย์ (Decentralized coordination) – Master และ Worker จะค้นหากันและกันผ่าน Registry โดย Registry สามารถเป็น ZooKeeper (ค่าเริ่มต้นเดิม), ฐานข้อมูลเชิงสัมพันธ์ที่ใช้ JDBC หรือคลัสเตอร์ Etcd ก็ได้ เลือกเทคโนโลยีที่เหมาะสมกับ stack เดิมของคุณ
  • รายการ Task ที่เพิ่มมากขึ้น – Task ในตัวเพิ่มขึ้นจาก 12 เป็นมากกว่า 30 ประเภท ครอบคลุมทั้ง cloud-native workloads และ machine-learning pipelines
  • MasterServer vs WorkerServer – MasterServer จะทำหน้าที่จัดการการแบ่งส่วน DAG, การส่งงาน (submission) และการตรวจสอบสถานะ (health monitoring) ส่วน WorkerServer จะทำหน้าที่เป็นเอนจินสำหรับการประมวลผล (execution engine) และการสตรีม log การแยกส่วนนี้ช่วยให้ขอบเขตความรับผิดชอบชัดเจนขึ้น และช่วยให้คุณสามารถกำหนดขนาด (size) ของแต่ละเลเยอร์ได้อย่างอิสระ
  • ความทนทานต่อความผิดพลาดผ่าน Watcher – Watcher จะคอยเฝ้าดู Registry เพื่อตรวจหาความล้มเหลวของโหนด เมื่อ Master หรือ Worker หลุดจากการเชื่อมต่อ Registry จะสั่งการให้เกิดการทำ failover โดยอัตโนมัติ
  • การรับส่ง Log ผ่าน gRPC – การดึง Log จากระยะไกลเปลี่ยนจากโปรโตคอลที่ใช้ Netty มาเป็น gRPC ซึ่งข้อมูลระบุว่าให้ประสิทธิภาพที่ดีกว่า

การปรับโครงสร้างฐานข้อมูลที่คุณไม่สามารถมองข้ามได้

การยกเครื่อง schema คืออุปสรรคที่ชัดเจนที่สุดสำหรับการอัปเกรดใดๆ:

1.3 Table 3.x Table สิ่งที่เปลี่ยนแปลง
t_ds_process_definition t_ds_workflow_definition เปลี่ยนคำว่า “process” เป็น “workflow” เพื่อให้สอดคล้องกับคำศัพท์ใน UI และ API
t_ds_process_instance t_ds_workflow_instance เปลี่ยนคำศัพท์ในลักษณะเดียวกันสำหรับข้อมูลการทำงาน (runtime records)

นอกเหนือจากการเปลี่ยนชื่อแล้ว 3.x ยังดึง metadata ของ task ที่เดิมเคยอยู่ในรูปแบบ JSON blobs ออกมาไว้ในตารางเชิงสัมพันธ์ (relational tables) โดยเฉพาะ ทำให้การจัดการข้อมูลสะอาดและเป็นระเบียบมากขึ้น

รายการตรวจสอบการย้ายระบบ

  1. สำรองข้อมูลทั้งหมด – ส่งออกฐานข้อมูล 1.3 แบบเต็มรูปแบบ (full dump) และคัดลอกไดเรกทอรี conf ไว้
  2. จับคู่ตารางเก่ากับชื่อใหม่ – รันสคริปต์เพื่อเปลี่ยนชื่อ t_ds_process_definition เป็น t_ds_workflow_definition และ t_ds_process_instance เป็น t_ds_workflow_instance จากนั้นตรวจสอบข้อกำหนด foreign-key (foreign-key constraints) อีกครั้ง
  3. ย้ายฟิลด์ Task ที่เป็น JSON – คัดลอกข้อมูล Task ที่เข้ารหัสแบบ JSON ลงในตารางเชิงสัมพันธ์ใหม่ ทดสอบ DAG จำนวนหนึ่งเพื่อยืนยันว่า scheduler สามารถอ่านโครงสร้างใหม่ได้ถูกต้อง
  4. เลือก Registry – ใช้ ZooKeeper ต่อไปหากคุณใช้งานอยู่แล้ว มิฉะนั้นให้ตั้งค่า registry ที่ใช้ JDBC หรือคลัสเตอร์ Etcd และชี้โหนดทั้งหมดไปยังที่อยู่ใหม่
  5. ติดตั้งปลั๊กอิน – แพ็กประเภท Task แบบกำหนดเองที่คุณเคยใช้ใน 1.3 ให้เป็นปลั๊กอินที่รองรับ 3.x และติดตั้งลงในแต่ละ MasterServer
  6. เริ่มใช้งาน MasterServer ก่อน – เริ่มต้น instance ของ MasterServer ใหม่ที่ชี้ไปยังฐานข้อมูลที่ย้ายมาแล้ว ตรวจสอบว่ามีการแสดงรายการ workflow ที่มีอยู่ และแดชบอร์ดสถานะ (health dashboard) ไม่แสดงข้อผิดพลาด
  7. เพิ่ม WorkerServers – เริ่มใช้งาน WorkerServers ทีละตัว คอยดูใน Registry ว่ามีการลงทะเบียนสำเร็จหรือไม่ และยืนยันว่า log ไหลผ่าน gRPC ได้ปกติ
  8. ทำการทดสอบเบื้องต้น (Smoke tests) – รัน DAG ที่มีความเสี่ยงต่ำจำนวนหนึ่งซึ่งครอบคลุมประเภท Task ที่ใช้บ่อยที่สุด ตรวจสอบว่า log ปรากฏใน UI และสถานะของ Task อัปเดตได้อย่างถูกต้อง
  9. เฝ้าระวังการทำ Failover – จำลองสถานการณ์ MasterServer ล่ม และดูว่า Watcher ทำการเลื่อนสถานะเครื่องสำรอง (standby) ขึ้นมาแทนหรือไม่ ยืนยันว่า Task ที่กำลังทำงานอยู่สามารถดำเนินต่อไปได้โดยไม่ต้องเริ่มใหม่ด้วยตนเอง

สิ่งที่คุณอาจต้องระวัง

โมเดลปลั๊กอินแบบใหม่นั้นทรงพลัง แต่ก็ทำให้มาตรฐานการพัฒนาแบบกำหนดเอง (custom development) สูงขึ้นตามไปด้วย

Bottom line: Moving from 1.3 to 3.x is not a simple version bump; it requires a coordinated database rename, JSON-to-relational migration, and a re-architecture of your cluster around a plug-in-enabled, registry-driven model. Follow the checklist step-by-step, test early, and you’ll gain a scheduler that scales out, recovers automatically, and speaks the same protocol as modern cloud services.