Apache DolphinScheduler 3.x അതിന്റെ ആർക്കിടെക്ചറിൽ വലിയ മാറ്റങ്ങളാണ് വരുത്തിയിരിക്കുന്നത്. 1.3 പതിപ്പിൽ തുടരുന്ന ടീമുകൾക്ക് അപ്ഗ്രേഡ് ചെയ്യുന്നതിന് മുമ്പ് ക്ലസ്റ്റർ ലേഔട്ട് പുനഃക്രമീകരിക്കേണ്ടതും ഡാറ്റാബേസ് സ്കീമ മാറ്റേണ്ടതുമാണ്. പഴയ സിംഗിൾ-നോഡ് മാസ്റ്റർ ഒഴിവാക്കി, പകരം ജോലികൾ ഷെഡ്യൂൾ ചെയ്യാനും സ്റ്റോർ ചെയ്യാനും ലോഗ് ചെയ്യാനും വ്യത്യസ്തമായ രീതി ഉപയോഗിക്കുന്ന പ്ലഗ്-ഇൻ അധിഷ്ഠിതവും വികേന്ദ്രീകൃതവുമായ (decentralized) ഒരു സംവിധാനം കൊണ്ടുവന്നു.
എന്തുകൊണ്ടാണ് ഈ മാറ്റം പ്രധാനമാകുന്നത്
1.3 പതിപ്പ് എല്ലാ ഷെഡ്യൂളിംഗ് തീരുമാനങ്ങളും കൈകാര്യം ചെയ്യുന്ന ഒരു സെൻട്രലൈസ്ഡ് മാസ്റ്ററിനെയാണ് ആശ്രയിച്ചിരുന്നത്, കൂടാതെ പന്ത്രണ്ട് ടാസ്ക് ടൈപ്പുകൾ മാത്രമേ അതിൽ ഉണ്ടായിരുന്നുള്ളൂ. എന്നാൽ 3.x പതിപ്പിൽ ടാസ്ക് ടൈപ്പുകളും സ്റ്റോറേജ് അഡാപ്റ്ററുകളും പ്ലഗ്-ഇനുകളായി ലോഡ് ചെയ്യുന്ന ഒരു മൈക്രോക്കർണൽ (microkernel) ആണ് ഉപയോഗിക്കുന്നത്. കൂടാതെ, മാസ്റ്റർമാരും വർക്കർമാരും ഒരു രജിസ്ട്രി സർവീസ് വഴി ആശയവിനിമയം നടത്തുന്നതിലൂടെ സിംഗിൾ പോയിന്റ് ഓഫ് ഫെയിലർ (single point of failure) ഒഴിവാക്കാനും സാധിക്കുന്നു. ഓപ്പറേറ്റർമാർക്ക് കൂടുതൽ സ്കെയിലബിലിറ്റിയും റെസിലിയൻസും (resilience) ലഭിക്കുന്നു; ഡെവലപ്പർമാർക്ക് കോർ കോഡിൽ മാറ്റം വരുത്താതെ തന്നെ ഒരു JAR ഫയൽ ഉപയോഗിച്ച് ഷെഡ്യൂളർ വികസിപ്പിക്കാൻ സാധിക്കും.
ആർക്കിടെക്ചറിലെ വലിയ മാറ്റങ്ങൾ
- മൈക്രോക്കർണൽ പ്ലഗ്-ഇൻ സിസ്റ്റം – ടാസ്ക് ഡെഫനിഷനുകൾ, റിസോഴ്സ് ഹാൻഡ്ലറുകൾ, കസ്റ്റം ഹെൽത്ത് ചെക്കുകൾ എന്നിവ ഇപ്പോൾ പ്രത്യേക മോഡ്യൂളുകളായി പ്രവർത്തിക്കുന്നു. പുതിയൊരു ടാസ്ക് ടൈപ്പ് ചേർക്കാൻ അതിന്റെ പ്ലഗ്-ഇൻ ക്ലാസ്പാത്തിൽ (classpath) നൽകി ബന്ധപ്പെട്ട നോഡുകൾ റീസ്റ്റാർട്ട് ചെയ്താൽ മതി.
- വികേന്ദ്രീകൃത ഏകോപനം (Decentralized coordination) – മാസ്റ്റർമാരും വർക്കർമാരും ഒരു രജിസ്ട്രി വഴി പരസ്പരം കണ്ടെത്തുന്നു. ഈ രജിസ്ട്രിക്ക് ZooKeeper (പഴയ ഡിഫോൾട്ട്), JDBC അധിഷ്ഠിത റിലേഷണൽ ഡാറ്റാബേസ്, അല്ലെങ്കിൽ ഒരു Etcd ക്ലസ്റ്റർ എന്നിവ ഉപയോഗിക്കാം. നിങ്ങളുടെ നിലവിലുള്ള സാങ്കേതികവിദ്യയ്ക്ക് അനുയോജ്യമായത് തിരഞ്ഞെടുക്കാം.
- വിപുലീകരിച്ച ടാസ്ക് കാറ്റലോഗ് – ഇൻബിൽറ്റ് ടാസ്ക്കുകൾ 12-ൽ നിന്ന് 30-ലധികം ആയി വർദ്ധിച്ചു. ഇവ ക്ലൗഡ്-നേറ്റീവ് വർക്ക്ലോഡുകളെയും മെഷീൻ ലേണിംഗ് പൈപ്പ്ലൈനുകളെയും ഉൾക്കൊള്ളുന്നു.
- MasterServer vs WorkerServer – MasterServer ഇപ്പോൾ DAG പാർട്ടിഷനിംഗ്, സബ്മിഷൻ, ഹെൽത്ത് മോണിറ്ററിംഗ് എന്നിവ കൈകാര്യം ചെയ്യുന്നു. WorkerServer ഒരു എക്സിക്യൂഷൻ എഞ്ചിനായി പ്രവർത്തിക്കുകയും ലോഗുകൾ സ്ട്രീം ചെയ്യുകയും ചെയ്യുന്നു. ഈ വേർതിരിവ് ഉത്തരവാദിത്തങ്ങൾ വ്യക്തമാക്കുകയും ഓരോ ലെയറിനെയും സ്വതന്ത്രമായി ക്രമീകരിക്കാൻ സഹായിക്കുകയും ചെയ്യുന്നു.
- Watcher വഴിയുള്ള ഫോൾട്ട് ടോളറൻസ് – നോഡ് പരാജയങ്ങൾക്കായി Watcher രജിസ്ട്രി നിരീക്ഷിക്കുന്നു. ഒരു മാസ്റ്ററോ വർക്കറോ പ്രവർത്തനരഹിതമായാൽ, രജിസ്ട്രി സ്വയമേവ ഫെയിലോവർ (failover) പ്രക്രിയ ആരംഭിക്കുന്നു.
- gRPC ലോഗ് ട്രാൻസ്പോർട്ട് – റിമോട്ട് ലോഗ് റിട്രീവൽ 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 |
റൺടൈം റെക്കോർഡുകൾക്കും ഇതേ മാറ്റം ബാധകമാണ്. |
പേര് മാറ്റുന്നതിലുപരി, മുമ്പ് JSON ബ്ലോബുകളിൽ സൂക്ഷിച്ചിരുന്ന ടാസ്ക് മെറ്റാഡാറ്റ 3.x പതിപ്പിൽ പ്രത്യേക റിലേഷണൽ ടേബിളുകളിലേക്ക് മാറ്റിയിരിക്കുന്നു. ഇത് ഡാറ്റാ മാനേജ്മെന്റ് കൂടുതൽ ലളിതമാക്കുന്നു.
മൈഗ്രേഷൻ ചെക്ക്ലിസ്റ്റ്
- എല്ലാം ബാക്കപ്പ് ചെയ്യുക – 1.3 ഡാറ്റാബേസ് ഫുൾ ഡമ്പ് എക്സ്പോർട്ട് ചെയ്യുകയും
confഡയറക്ടറി കോപ്പി ചെയ്യുകയും ചെയ്യുക. - പഴയ ടേബിളുകളെ പുതിയ പേരുകളിലേക്ക് മാറ്റുക –
t_ds_process_definitionഎന്നത്t_ds_workflow_definitionഎന്നുംt_ds_process_instanceഎന്നത്t_ds_workflow_instanceഎന്നും മാറ്റുന്നതിനുള്ള സ്ക്രിപ്റ്റ് റൺ ചെയ്യുക. അതിനുശേഷം ഫോറിൻ-കീ (foreign-key) നിയന്ത്രണങ്ങൾ പരിശോധിക്കുക. - JSON ടാസ്ക് ഫീൽഡുകൾ മൈഗ്രേറ്റ് ചെയ്യുക – JSON രൂപത്തിലുള്ള ടാസ്ക് ഡാറ്റ പുതിയ റിലേഷണൽ ടേബിളുകളിലേക്ക് കോപ്പി ചെയ്യുക. ഷെഡ്യൂളർ പുതിയ ലേഔട്ട് ശരിയായി വായിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ കുറച്ച് DAG-കൾ ടെസ്റ്റ് ചെയ്യുക.
- ഒരു രജിസ്ട്രി തിരഞ്ഞെടുക്കുക – നിലവിൽ ZooKeeper ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ അത് തന്നെ തുടരാം; അല്ലെങ്കിൽ ഒരു JDBC അധിഷ്ഠിത രജിസ്ട്രിയോ Etcd ക്ലസ്റ്ററോ സജ്ജീകരിക്കുക, എല്ലാ നോഡുകളെയും പുതിയ അഡ്രസ്സിലേക്ക് പോയിന്റ് ചെയ്യുക.
- പ്ലഗ്-ഇനുകൾ വിന്യസിക്കുക – 1.3-ൽ ഉപയോഗിച്ചിരുന്ന കസ്റ്റം ടാസ്ക് ടൈപ്പുകൾ 3.x-ന് അനുയോജ്യമായ പ്ലഗ്-ഇനുകളായി പാക്കേജ് ചെയ്യുകയും ഓരോ MasterServer-ലും വിന്യസിക്കുകയും ചെയ്യുക.
- ആദ്യം MasterServer വിന്യസിക്കുക – മൈഗ്രേറ്റ് ചെയ്ത ഡാറ്റാബേസുമായി ബന്ധിപ്പിച്ചുകൊണ്ട് ഒരു പുതിയ MasterServer ഇൻസ്റ്റൻസ് ആരംഭിക്കുക. നിലവിലുള്ള വർക്ക്ഫ്ലോകൾ ലിസ്റ്റ് ചെയ്യുന്നുണ്ടെന്നും ഹെൽത്ത് ഡാഷ്ബോർഡിൽ പിശകുകൾ ഇല്ലെന്നും ഉറപ്പുവരുത്തുക.
- WorkerServer-കൾ ചേർക്കുക – ഓരോന്നായി WorkerServer-കൾ പ്രവർത്തനരഹിതമാക്കുക. രജിസ്ട്രിയിൽ അവ വിജയകരമായി രജിസ്റ്റർ ചെയ്തിട്ടുണ്ടെന്നും ലോഗുകൾ gRPC വഴി ലഭിക്കുന്നുണ്ടെന്നും ഉറപ്പാക്കുക.
- സ്മോക്ക് ടെസ്റ്റുകൾ നടത്തുക – സാധാരണയായി ഉപയോഗിക്കുന്ന ടാസ്ക് ടൈപ്പുകൾ ഉൾക്കൊള്ളുന്ന കുറച്ച് DAG-കൾ പ്രവർത്തിപ്പിച്ചു നോക്കുക. ലോഗുകൾ UI-ൽ കാണുന്നുണ്ടെന്നും ടാസ്ക് സ്റ്റാറ്റസ് ശരിയായി അപ്ഡേറ്റ് ആകുന്നുണ്ടെന്നും പരിശോധിക്കുക.
- ഫെയിലോവർ നിരീക്ഷിക്കുക – ഒരു MasterServer ക്രാഷ് ചെയ്യുന്നത് പോലെ സിമുലേറ്റ് ചെയ്യുക, തുടർന്ന് Watcher ഒരു സ്റ്റാൻഡ്ബൈ മാസ്റ്ററിനെ പ്രൊമോട്ട് ചെയ്യുന്നുണ്ടോ എന്ന് നോക്കുക. മാനുവൽ റീസ്റ്റാർട്ട് ഇല്ലാതെ തന്നെ ടാസ്ക്കുകൾ തുടരുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.
ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
പുതിയ പ്ലഗ്-ഇൻ മോഡൽ വളരെ ശക്തമാണ്, എന്നാൽ കസ്റ്റം ഡെവലപ്മെന്റിന് ഇത് കൂടുതൽ വെല്ലുവിളികൾ ഉയർത്തുന്നു.
ചുരുക്കത്തിൽ: 1.3-ൽ നിന്ന് 3.x-ലേക്ക് മാറുന്നത് വെറുമൊരു വേർഷൻ മാറ്റം മാത്രമല്ല; ഇതിനായി ഏകോപിതമായി ഡാറ്റാബേസ് റീനേം ചെയ്യേണ്ടതും, JSON-to-relational migration നടത്തേണ്ടതും, പ്ലഗിൻ-എനേബിൾഡ്, രജിസ്ട്രി-ഡ്രിവൺ മോഡലിന് അനുസൃതമായി നിങ്ങളുടെ ക്ലസ്റ്റർ പുനർനിർമ്മിക്കേണ്ടതും ആവശ്യമാണ്. ചെക്ക്ലിസ്റ്റ് ഘട്ടം ഘട്ടമായി പിന്തുടരുക, നേരത്തെ തന്നെ ടെസ്റ്റ് ചെയ്യുക; അങ്ങനെ നിങ്ങൾക്ക് സ്കെയിൽ ഔട്ട് ചെയ്യാൻ കഴിയുന്നതും, സ്വയം വീണ്ടെടുക്കാൻ (recovers automatically) ശേഷിയുള്ളതും, ആധുനിക ക്ലൗഡ് സേവനങ്ങളുടേതിന് സമാനമായ പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നതുമായ ഒരു ഷെഡ്യൂളർ ലഭിക്കും.