Apache DolphinScheduler 3.x wywraca architekturę do góry nogami. Zespoły korzystające z wersji 1.3 muszą przebudować układ klastra i przepisać schemat bazy danych przed aktualizacją. Stary, jednonodowy master znika, a jego miejsce zajmuje zdecentralizowany system oparty na wtyczkach, który inaczej planuje, przechowuje i loguje zadania.

Dlaczego ta zmiana jest istotna

Wersja 1.3 polegała na scentralizowanym masterze, który obsługiwał każdą decyzję dotyczącą harmonogramowania i oferował tylko dwanaście wbudowanych typów zadań. 3.x zastępuje go mikrojądrem (microkernel), które ładuje typy zadań i adaptery pamięci masowej jako wtyczki, eliminując przy tym pojedynczy punkt awarii (single point of failure) dzięki komunikacji masterów i workerów poprzez usługę rejestracji (registry service). Operatorzy zyskują skalowalność i odporność; deweloperzy mogą rozszerzać scheduler, po prostu wrzucając plik JAR, zamiast modyfikować kod rdzenia.

Przełom architektoniczny

  • System wtyczek oparty na mikrojądrze – Definicje zadań, obsługa zasobów i niestandardowe sprawdzanie stanu (health checks) znajdują się teraz w oddzielnych modułach. Aby dodać nowy typ zadania, wystarczy umieścić jego wtyczkę w classpath i zrestartować odpowiednie węzły.
  • Zdecentralizowana koordynacja – Masterzy i workerzy odkrywają się nawzajem za pomocą rejestru. Rejestrem może być ZooKeeper (historyczny standard), relacyjna baza danych oparta na JDBC lub klaster Etcd. Wybierz technologię pasującą do Twojego stosu technologicznego.
  • Rozszerzony katalog zadań – Liczba wbudowanych zadań wzrosła z 12 do ponad 30, obejmując obciążenia cloud-native oraz potoki uczenia maszynowego (machine-learning pipelines).
  • MasterServer vs WorkerServer – MasterServer zajmuje się teraz partycjonowaniem DAG, przesyłaniem zadań i monitorowaniem stanu. WorkerServer działa jako czysty silnik wykonawczy, który dodatkowo przesyła logi w strumieniu. Ten podział klaruje odpowiedzialności i pozwala na niezależne skalowanie każdej warstwy.
  • Odporność na awarie dzięki Watcherowi – Watcher monitoruje rejestr pod kątem awarii węzłów. Gdy Master lub Worker ulegnie awarii, rejestr wyzwala automatyczne przełączenie awaryjne (failover).
  • Transport logów przez gRPC – Zdalne pobieranie logów zostało przeniesione z protokołu opartego na Netty na gRPC, co według źródeł zapewnia lepszą wydajność.

Refaktoryzacja bazy danych, której nie można zignorować

Przebudowa schematu jest najbardziej konkretną przeszkodą przy jakiejkolwiek aktualizacji:

Tabela 1.3 Tabela 3.x Co się zmieniło
t_ds_process_definition t_ds_workflow_definition Termin „process” został zmieniony na „workflow”, aby dopasować się do terminologii interfejsu użytkownika i API.
t_ds_process_instance t_ds_workflow_instance Ta sama zmiana semantyczna dla rekordów czasu wykonania (runtime).

Poza zmianą nazw, wersja 3.x wyodrębnia metadane zadań, które wcześniej znajdowały się wewnątrz obiektów JSON, do dedykowanych tabel relacyjnych, co sprawia, że zarządzanie danymi jest czystsze.

Lista kontrolna migracji

  1. Zrób kopię zapasową wszystkiego – Wyeksportuj pełny zrzut bazy danych 1.3 i skopiuj katalog conf.
  2. Zmapuj stare tabele na nowe nazwy – Uruchom skrypt zmieniający nazwę t_ds_process_definition na t_ds_workflow_definition oraz t_ds_process_instance na t_ds_workflow_instance. Następnie zweryfikuj więzy kluczy obcych (foreign-key constraints).
  3. Zmigruj pola zadań JSON – Skopiuj dane zadań zakodowane w formacie JSON do nowych tabel relacyjnych. Przetestuj kilka DAG-ów, aby potwierdzić, że scheduler poprawnie odczytuje nowy układ.
  4. Wybierz rejestr – Zachowaj ZooKeeper, jeśli już go używasz; w przeciwnym razie skonfiguruj rejestr oparty na JDBC lub klaster Etcd i skieruj wszystkie węzły na nowy adres.
  5. Wdróż wtyczki – Spakuj wszelkie niestandardowe typy zadań używane w wersji 1.3 jako wtyczki kompatybilne z 3.x i wdróż je na każdym MasterServerze.
  6. Najpierw wdróż MasterServer – Uruchom nową instancję MasterServer wskazującą na zmigrowaną bazę danych. Sprawdź, czy wyświetla ona istniejące workflowy i czy panel stanu (health dashboard) nie pokazuje błędów.
  7. Dodaj WorkerServery – Uruchamiaj WorkerServery jeden po drugim. Monitoruj rejestr pod kątem udanej rejestracji i potwierdź, że logi płyną przez gRPC.
  8. Przeprowadź testy dymne (smoke tests) – Uruchom kilka niskoryzykownych DAG-ów obejmujących najczęstsze typy zadań. Sprawdź, czy logi pojawiają się w UI i czy aktualizacje statusu zadań rozchodzą się poprawnie.
  9. Monitoruj przełączanie awaryjne – Zasymuluj awarię MasterServera i obserwuj, jak Watcher promuje węzeł zapasowy (standby). Potwierdź, że zadania w toku (in-flight tasks) kontynuują działanie bez konieczności ręcznego restartu.

Co może sprawić Ci problemy

Nowy model wtyczek jest potężny, ale podnosi poprzeczkę dla niestandardowego rozwoju.

Podsumowując: Przejście z wersji 1.3 do 3.x to nie jest zwykłe podniesienie wersji; wymaga ono skoordynowanej zmiany nazw w bazie danych, migracji z formatu JSON do modelu relacyjnego oraz przebudowy architektury klastra w oparciu o model oparty na rejestrze i obsługujący wtyczki. Postępuj zgodnie z listą kontrolną krok po kroku, wykonuj testy na wczesnym etapie, a zyskasz scheduler, który skaluje się horyzontalnie, automatycznie odzyskuje sprawność i używa tego samego protokołu co nowoczesne usługi chmurowe.