Apache DolphinScheduler 3.x mengubah arsitekturnya secara total. Tim yang masih menggunakan versi 1.3 harus mengatur ulang tata letak klaster dan menulis ulang skema database sebelum dapat melakukan upgrade. Master node tunggal yang lama kini hilang, digantikan oleh sistem terdesentralisasi berbasis plug-in yang menjadwalkan, menyimpan, dan mencatat log pekerjaan dengan cara yang berbeda.

Mengapa lompatan ini penting

Versi 1.3 bergantung pada master terpusat yang menangani setiap keputusan penjadwalan dan hanya menawarkan dua belas tipe tugas bawaan. Versi 3.x menggantinya dengan microkernel yang memuat tipe tugas dan adapter penyimpanan sebagai plugin, serta menghilangkan single point of failure dengan membiarkan master dan worker berkomunikasi melalui layanan registry. Operator mendapatkan skalabilitas dan ketahanan; pengembang dapat memperluas scheduler cukup dengan memasukkan file JAR alih-alih mengubah kode inti.

Perombakan arsitektur

  • Sistem plug-in microkernel – Definisi tugas, handler sumber daya, dan pemeriksaan kesehatan (health check) kustom kini berada di modul yang terpisah. Tambahkan tipe tugas baru dengan menempatkan plug-in-nya pada classpath dan memulai ulang node yang terdampak.
  • Koordinasi terdesentralisasi – Master dan worker saling menemukan melalui registry. Registry dapat berupa ZooKeeper (default historis), database relasional berbasis JDBC, atau klaster Etcd. Pilih teknologi yang sesuai dengan stack Anda saat ini.
  • Katalog tugas yang diperluas – Tugas bawaan telah berkembang dari 12 menjadi lebih dari 30, mencakup beban kerja cloud-native dan pipeline machine learning.
  • MasterServer vs WorkerServer – MasterServer kini menangani partisi DAG, pengiriman (submission), dan pemantauan kesehatan. WorkerServer bertindak sebagai mesin eksekusi murni yang juga melakukan streaming log. Pemisahan ini memperjelas tanggung jawab dan memungkinkan Anda menentukan ukuran setiap lapisan secara independen.
  • Toleransi kesalahan via Watcher – Watcher memantau registry untuk kegagalan node. Saat Master atau Worker mati, registry akan memicu failover otomatis.
  • Transportasi log gRPC – Pengambilan log jarak jauh berpindah dari protokol berbasis Netty ke gRPC, yang menurut sumbernya memberikan performa yang lebih baik.

Refaktorisasi database yang tidak bisa Anda abaikan

Perombakan skema adalah penghambat paling nyata untuk setiap upgrade:

Tabel 1.3 Tabel 3.x Apa yang berubah
t_ds_process_definition t_ds_workflow_definition Istilah “process” diubah namanya menjadi “workflow” agar sesuai dengan kosakata UI dan API.
t_ds_process_instance t_ds_workflow_instance Pergeseran semantik yang sama untuk catatan runtime.

Selain penggantian nama, versi 3.x mengekstrak metadata tugas yang sebelumnya berada di dalam blob JSON ke dalam tabel relasional khusus, membuat manajemen data menjadi lebih bersih.

Daftar periksa migrasi

  1. Cadangkan semuanya – Ekspor dump database 1.3 secara lengkap dan salin direktori conf.
  2. Petakan tabel lama ke nama baru – Jalankan skrip yang mengubah nama t_ds_process_definition menjadi t_ds_workflow_definition dan t_ds_process_instance menjadi t_ds_workflow_instance. Verifikasi batasan foreign-key setelahnya.
  3. Migrasikan field tugas JSON – Salin data tugas yang dienkode JSON ke dalam tabel relasional baru. Uji beberapa DAG untuk memastikan scheduler membaca tata letak yang baru.
  4. Pilih registry – Tetap gunakan ZooKeeper jika Anda sudah menjalankannya; jika tidak, siapkan registry berbasis JDBC atau klaster Etcd dan arahkan semua node ke alamat baru tersebut.
  5. Deploy plug-in – Kemas tipe tugas kustom apa pun yang Anda gunakan di 1.3 sebagai plug-in yang kompatibel dengan 3.x dan deploy ke setiap MasterServer.
  6. Deploy MasterServer terlebih dahulu – Mulai instance MasterServer baru yang mengarah ke database yang telah dimigrasi. Verifikasi bahwa ia mencantumkan workflow yang ada dan dashboard kesehatan tidak menunjukkan kesalahan.
  7. Tambahkan WorkerServer – Jalankan WorkerServer satu per satu. Pantau registry untuk registrasi yang berhasil dan konfirmasikan bahwa log mengalir melalui gRPC.
  8. Jalankan smoke test – Picu beberapa DAG berisiko rendah yang mencakup tipe tugas paling umum. Periksa apakah log muncul di UI dan apakah pembaruan status tugas menyebar dengan benar.
  9. Pantau failover – Simulasikan crash pada MasterServer dan pantau Watcher saat mempromosikan node standby. Konfirmasikan bahwa tugas yang sedang berjalan (in-flight) berlanjut tanpa restart manual.

Apa yang bisa menjadi kendala bagi Anda

Model plug-in yang baru sangat kuat, tetapi ia meningkatkan standar untuk pengembangan kustom.

Intinya: Beralih dari 1.3 ke 3.x bukan sekadar peningkatan versi biasa; ini memerlukan penggantian nama database yang terkoordinasi, migrasi JSON-ke-relasional, dan arsitektur ulang klaster Anda di sekitar model berbasis registri yang mendukung plugin. Ikuti daftar periksa langkah demi langkah, lakukan pengujian lebih awal, dan Anda akan mendapatkan scheduler yang dapat melakukan scale out, pulih secara otomatis, dan menggunakan protokol yang sama dengan layanan cloud modern.