Apache DolphinScheduler 3.x نے اپنے آرکیٹیکچر کو مکمل طور پر بدل دیا ہے۔ جو ٹیمیں اب بھی 1.3 پر ہیں، انہیں اپ گریڈ کرنے سے پہلے اپنے کلسٹر لے آؤٹ کو دوبارہ ترتیب دینا ہوگا اور ڈیٹا بیس اسکیما کو دوبارہ لکھنا ہوگا۔ پرانا سنگل نوڈ ماسٹر ختم ہو گیا ہے، اور اس کی جگہ ایک پلگ ان پر مبنی، غیر مرکزی (decentralized) نظام نے لے لی ہے جو کاموں (jobs) کو مختلف طریقے سے شیڈول، اسٹور اور لاگ کرتا ہے۔

یہ تبدیلی کیوں اہم ہے

ورژن 1.3 ایک مرکزی ماسٹر (centralized master) پر منحصر تھا جو شیڈولنگ کے ہر فیصلے کو سنبھالتا تھا اور صرف بارہ بلٹ ان ٹاسک اقسام پیش کرتا تھا۔ 3.x اسے ایک مائیکرو کرنل (microkernel) سے بدل دیتا ہے جو ٹاسک اقسام اور اسٹوریج ایڈاپٹرز کو پلگ انز کے طور پر لوڈ کرتا ہے، اور یہ ماسٹرز اور ورکرز کو ایک رجسٹری سروس کے ذریعے بات چیت کرنے کی اجازت دے کر 'سنگل پوائنٹ آف فیلر' (single point of failure) کو ختم کر دیتا ہے۔ آپریٹرز کو اس سے پیمائش کے قابل (scalability) اور لچکدار (resilience) نظام ملتا ہے؛ جبکہ ڈویلپرز کور کوڈ میں تبدیلی کرنے کے بجائے محض ایک JAR فائل ڈال کر شیڈولر کو وسعت دے سکتے ہیں۔

آرکیٹیکچرل تبدیلی (Architectural overhaul)

  • Microkernel plug-in system – ٹاسک کی تعریفیں (definitions)، ریسورس ہینڈلرز اور کسٹم ہیلتھ چیک اب الگ الگ ماڈیولز میں موجود ہیں۔ اس کے پلگ ان کو classpath پر رکھ کر اور متاثرہ نوڈز کو ری اسٹارٹ کر کے ایک نئی ٹاسک قسم شامل کریں۔
  • Decentralized coordination – ماسٹرز اور ورکرز ایک رجسٹری کے ذریعے ایک دوسرے کو پہچانتے ہیں۔ رجسٹری ZooKeeper (جو کہ تاریخی طور پر ڈیفالٹ ہے)، ایک JDBC پر مبنی ریلیشنل ڈیٹا بیس، یا ایک Etcd کلسٹر ہو سکتی ہے۔ ایسی ٹیکنالوجی کا انتخاب کریں جو آپ کے موجودہ اسٹیک سے مطابقت رکھتی ہو۔
  • Expanded task catalog – بلٹ ان ٹاسک 12 سے بڑھ کر 30 سے زیادہ ہو گئے ہیں، جو کلاؤڈ نیٹو ورک لوڈز اور مشین لرننگ پائپ لائنز کا احاطہ کرتے ہیں۔
  • MasterServer vs WorkerServer – MasterServer اب DAG پارٹیشننگ، سبمیشن اور ہیلتھ مانیٹرنگ کو سنبھالتا ہے۔ WorkerServer ایک خالص ایگزیکیوشن انجن کے طور پر کام کرتا ہے جو لاگز کو بھی اسٹریم کرتا ہے۔ یہ تقسیم ذمہ داریوں کو واضح کرتی ہے اور آپ کو ہر لیئر کو آزادانہ طور پر ترتیب دینے کی اجازت دیتی ہے۔
  • Fault tolerance via Watcher – Watcher نوڈ کی ناکامیوں کے لیے رجسٹری پر نظر رکھتا ہے۔ جب کوئی Master یا Worker گرتا ہے، تو رجسٹری خودکار طور پر فیل اوور (failover) شروع کر دیتی ہے۔
  • gRPC log transport – ریموٹ لاگ کی واپسی (retrieval) Netty پر مبنی پروٹوکول سے gRPC پر منتقل ہو گئی ہے، جس کے بارے میں ذرائع کا کہنا ہے کہ یہ بہتر کارکردگی فراہم کرتا ہے۔

ڈیٹا بیس ری فیکٹرنگ جسے آپ نظر انداز نہیں کر سکتے

اسکیما کی تبدیلی کسی بھی اپ گریڈ کے لیے سب سے بڑی رکاوٹ ہے:

1.3 Table 3.x Table کیا تبدیل ہوا
t_ds_process_definition t_ds_workflow_definition UI اور API کی اصطلاحات سے مطابقت رکھنے کے لیے "process" کا نام بدل کر "workflow" رکھ دیا گیا ہے۔
t_ds_process_instance t_ds_workflow_instance رن ٹائم ریکارڈز کے لیے بھی یہی مفہومی تبدیلی کی گئی ہے۔

نام بدلنے کے علاوہ، 3.x ٹاسک میٹا ڈیٹا (metadata) کو جو پہلے JSON بلاگز کے اندر ہوتا تھا، اب مخصوص ریلیشنل ٹیبلز میں نکال لیتا ہے، جس سے ڈیٹا مینجمنٹ زیادہ منظم ہو جاتی ہے۔

مائیگریشن چیک لسٹ

  1. Back up everything – مکمل 1.3 ڈیٹا بیس ڈمپ ایکسپورٹ کریں اور conf ڈائریکٹری کاپی کریں۔
  2. Map old tables to new names – ایک اسکرپٹ چلائیں جو t_ds_process_definition کو t_ds_workflow_definition میں اور t_ds_process_instance کو t_ds_workflow_instance میں تبدیل کر دے۔ اس کے بعد فارن کی (foreign-key) کنسٹرینٹس کی تصدیق کریں۔
  3. Migrate JSON task fields – JSON-انکوڈڈ ٹاسک ڈیٹا کو نئے ریلیشنل ٹیبلز میں کاپی کریں۔ چند DAGs کا ٹیسٹ کریں تاکہ تصدیق ہو سکے کہ شیڈولر نئے لے آؤٹ کو پڑھ رہا ہے۔
  4. Choose a registry – اگر آپ پہلے سے ZooKeeper استعمال کر رہے ہیں تو اسے برقرار رکھیں؛ ورنہ ایک JDBC پر مبنی رجسٹری یا Etcd کلسٹر سیٹ اپ کریں اور تمام نوڈز کو نئے ایڈریس پر پوائنٹ کریں۔
  5. Deploy plug-ins – 1.3 میں استعمال ہونے والی کسی بھی کسٹم ٹاسک قسم کو 3.x کے موافق پلگ انز کے طور پر پیک کریں اور انہیں ہر MasterServer پر ڈیپلائے کریں۔
  6. Roll out MasterServer first – مائیگریٹ شدہ ڈیٹا بیس کی طرف اشارہ کرنے والا ایک نیا MasterServer انسٹنس شروع کریں۔ تصدیق کریں کہ یہ موجودہ ورک فلو (workflows) کی فہرست دکھاتا ہے اور ہیلتھ ڈیش بورڈ میں کوئی غلطی نہیں ہے۔
  7. Add WorkerServers – WorkerServers کو ایک ایک کر کے شروع کریں۔ کامیاب رجسٹریشن کے لیے رجسٹری پر نظر رکھیں اور تصدیق کریں کہ لاگز gRPC کے ذریعے بہہ رہے ہیں۔
  8. Run smoke tests – چند کم خطرے والے DAGs چلائیں جو عام ترین ٹاسک اقسام کا احاطہ کرتے ہوں۔ چیک کریں کہ لاگز UI میں نظر آ رہے ہیں اور ٹاسک اسٹیٹس کی اپ ڈیٹس درست طریقے سے پھیل رہی ہیں۔
  9. Monitor for failover – MasterServer کے کریش ہونے کی نقل (simulate) کریں اور دیکھیں کہ Watcher کس طرح ایک اسٹینڈ بائی (standby) کو پروموٹ کرتا ہے۔ تصدیق کریں کہ جاری کام (in-flight tasks) دستی ری اسٹارٹ کے بغیر جاری رہتے ہیں۔

کیا مشکلات پیش آ سکتی ہیں

نیا پلگ ان ماڈل طاقتور ہے، لیکن یہ کسٹم ڈویلپمنٹ کے معیار کو مزید مشکل بنا دیتا ہے۔

خلاصہ: 1.3 سے 3.x پر منتقل ہونا محض ورژن میں تبدیلی نہیں ہے؛ اس کے لیے ڈیٹا بیس کے نام میں مربوط تبدیلی، JSON-to-relational مائیگریشن، اور اپنے کلسٹر کی پلگ ان سے لیس (plug-in-enabled) اور رجسٹری پر مبنی (registry-driven) ماڈل کے گرد دوبارہ تشکیل (re-architecture) درکار ہے۔ چیک لسٹ پر مرحلہ وار عمل کریں، جلد از جلد ٹیسٹنگ کریں، اور آپ کو ایک ایسا شیڈیولر ملے گا جو اسکیل آؤٹ (scales out) ہو سکتا ہے، خودکار طریقے سے ریکور (recovers) ہوتا ہے، اور جدید کلاؤڈ سروسز کے یکساں پروٹوکول پر کام کرتا ہے۔