Apache DolphinScheduler 3.x ਇਸਦੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜੋ ਟੀਮਾਂ ਅਜੇ ਵੀ 1.3 'ਤੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਕਲੱਸਟਰ ਲੇਆਉਟ ਨੂੰ ਮੁੜ-ਵਿਵਸਥਿਤ ਕਰਨਾ ਹੋਵੇਗਾ ਅਤੇ ਡੇਟਾਬੇਸ ਸਕੀਮਾ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਹੋਵੇਗਾ। ਪੁਰਾਣਾ ਸਿੰਗਲ-ਨੋਡ ਮਾਸਟਰ (single-node master) ਖਤਮ ਹੋ ਗਿਆ ਹੈ, ਅਤੇ ਇਸਦੀ ਜਗ੍ਹਾ ਇੱਕ ਪਲੱਗ-ਇਨ-ਡ੍ਰਿਵਨ (plug-in-driven), ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ (decentralized) ਪ੍ਰਣਾਲੀ ਨੇ ਲੈ ਲਈ ਹੈ ਜੋ ਜੌਬਸ ਨੂੰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਸ਼ਡਿਊਲ, ਸਟੋਰ ਅਤੇ ਲੌਗ ਕਰਦੀ ਹੈ।
ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਵਰਜ਼ਨ 1.3 ਇੱਕ ਕੇਂਦਰੀਕ੍ਰਿਤ ਮਾਸਟਰ (centralized master) 'ਤੇ ਨਿਰਭਰ ਸੀ ਜੋ ਹਰ ਸ਼ਡਿਊਲਿੰਗ ਫੈਸਲੇ ਨੂੰ ਸੰਭਾਲਦਾ ਸੀ ਅਤੇ ਸਿਰਫ਼ ਬਾਰਾਂ ਬਿਲਟ-ਇਨ ਟਾਸਕ ਕਿਸਮਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਸੀ। 3.x ਇਸਦੀ ਜਗ੍ਹਾ ਇੱਕ ਮਾਈਕਰੋਕਰਨਲ (microkernel) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਟਾਸਕ ਕਿਸਮਾਂ ਅਤੇ ਸਟੋਰੇਜ ਅਡੈਪਟਰਾਂ ਨੂੰ ਪਲੱਗਇਨਾਂ ਵਜੋਂ ਲੋਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਮਾਸਟਰਾਂ ਅਤੇ ਵਰਕਰਾਂ ਨੂੰ ਰਜਿਸਟਰੀ ਸਰਵਿਸ ਰਾਹੀਂ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ ਸਿੰਗਲ ਪੁਆਇੰਟ ਆਫ ਫੇਲ੍ਹਅਰ (single point of failure) ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ। ਆਪਰੇਟਰਾਂ ਨੂੰ ਸਕੇਲੇਬਿਲਟੀ (scalability) ਅਤੇ ਰੈਜ਼ੀਲੀਅੰਸ (resilience) ਮਿਲਦੀ ਹੈ; ਡਿਵੈਲਪਰ ਕੋਰ ਕੋਡ ਨੂੰ ਬਦਲਣ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਇੱਕ JAR ਫਾਈਲ ਪਾ ਕੇ ਸ਼ਡਿਊਲਰ ਦਾ ਵਿਸਤਾਰ ਕਰ ਸਕਦੇ ਹਨ।
ਆਰਕੀਟੈਕਚਰਲ ਓਵਰਹੌਲ
- Microkernel plug-in system – ਟਾਸਕ ਡੈਫੀਨੇਸ਼ਨ, ਰਿਸੋਰਸ ਹੈਂਡਲਰ ਅਤੇ ਕਸਟਮ ਹੈਲਥ ਚੈੱਕ ਹੁਣ ਵੱਖਰੇ ਮੋਡਿਊਲ ਵਿੱਚ ਹੁੰਦੇ ਹਨ। ਇਸਦੇ ਪਲੱਗ-ਇਨ ਨੂੰ ਕਲਾਸਪਾਥ (classpath) 'ਤੇ ਰੱਖ ਕੇ ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਨੋਡਾਂ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਕੇ ਇੱਕ ਨਵਾਂ ਟਾਸਕ ਟਾਈਪ ਜੋੜੋ।
- Decentralized coordination – ਮਾਸਟਰ ਅਤੇ ਵਰਕਰ ਇੱਕ ਰਜਿਸਟਰੀ ਰਾਹੀਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਲੱਭਦੇ ਹਨ। ਰਜਿਸਟਰੀ ZooKeeper (ਪੁਰਾਣਾ ਡਿਫੌਲਟ), ਇੱਕ JDBC-ਬੈਕਡ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ, ਜਾਂ Etcd ਕਲੱਸਟਰ ਹੋ ਸਕਦੀ ਹੈ। ਉਹ ਤਕਨਾਲੋਜੀ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਸਟੈਕ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋਵੇ।
- Expanded task catalog – ਬਿਲਟ-ਇਨ ਟਾਸਕ 12 ਤੋਂ ਵਧ ਕੇ 30 ਤੋਂ ਵੱਧ ਹੋ ਗਏ ਹਨ, ਜੋ ਕਲਾਊਡ-ਨੇਟਿਵ ਵਰਕਲੋਡਸ ਅਤੇ ਮਸ਼ੀਨ-ਲਰਨਿੰਗ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ।
- MasterServer vs WorkerServer – MasterServer ਹੁਣ DAG ਪਾਰਟੀਸ਼ਨਿੰਗ, ਸਬਮਿਸ਼ਨ ਅਤੇ ਹੈਲਥ ਮਾਨੀਟਰਿੰਗ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। WorkerServer ਇੱਕ ਸ਼ੁੱਧ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਇੰਜਣ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਲੌਗਸ ਨੂੰ ਵੀ ਸਟ੍ਰੀਮ ਕਰਦਾ ਹੈ। ਇਹ ਵੰਡ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਹਰੇਕ ਲੇਅਰ ਨੂੰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਸਾਈਜ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।
- Fault tolerance via Watcher – Watcher ਨੋਡ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਰਜਿਸਟਰੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਮਾਸਟਰ ਜਾਂ ਵਰਕਰ ਡਿੱਗਦਾ ਹੈ, ਤਾਂ ਰਜਿਸਟਰੀ ਇੱਕ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ (failover) ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੀ ਹੈ।
- gRPC log transport – ਰਿਮੋਟ ਲੌਗ ਰਿਟ੍ਰੀਵਲ ਨੂੰ 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.3 ਡੇਟਾਬੇਸ ਡੰਪ ਐਕਸਪੋਰਟ ਕਰੋ ਅਤੇ
confਡਾਇਰੈਕਟਰੀ ਦੀ ਕਾਪੀ ਬਣਾਓ। - ਪੁਰਾਣੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਨਵੇਂ ਨਾਮਾਂ ਨਾਲ ਮੈਪ ਕਰੋ – ਇੱਕ ਸਕ੍ਰਿਪਟ ਚਲਾਓ ਜੋ
t_ds_process_definitionਨੂੰt_ds_workflow_definitionਵਿੱਚ ਅਤੇt_ds_process_instanceਨੂੰt_ds_workflow_instanceਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਫੋਰਨ-ਕੀ (foreign-key) ਦੀਆਂ ਪਾਬੰਦੀਆਂ ਦੀ ਜਾਂਚ ਕਰੋ। - JSON ਟਾਸਕ ਫੀਲਡਾਂ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕਰੋ – JSON-ਐਨਕੋਡਡ ਟਾਸਕ ਡੇਟਾ ਨੂੰ ਨਵੇਂ ਰਿਲੇਸ਼ਨਲ ਟੇਬਲਾਂ
ਮੁੱਖ ਗੱਲ: 1.3 ਤੋਂ 3.x 'ਤੇ ਜਾਣਾ ਸਿਰਫ਼ ਇੱਕ ਸਧਾਰਨ ਵਰਜ਼ਨ ਅਪਡੇਟ ਨਹੀਂ ਹੈ; ਇਸ ਲਈ ਡੇਟਾਬੇਸ ਦੇ ਨਾਮ ਨੂੰ ਤਾਲਮੇਲ ਨਾਲ ਬਦਲਣ, JSON-to-relational ਮਾਈਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਇੱਕ ਪਲੱਗ-ਇਨ-ਇਨੇਬਲਡ, ਰਜਿਸਟਰੀ-ਡਰਿਵਨ ਮਾਡਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਦੀ ਮੁੜ-ਰਚਨਾ ਦੀ ਲੋੜ ਹੈ। ਚੈੱਕਲਿਸਟ ਦੀ ਕਦਮ-ਦਰ-ਕਦਮ ਪਾਲਣਾ ਕਰੋ, ਜਲਦੀ ਟੈਸਟ ਕਰੋ, ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਅਜਿਹਾ ਸ਼ੈਡਿਊਲਰ ਮਿਲੇਗਾ ਜੋ ਸਕੇਲ ਆਊਟ ਹੁੰਦਾ ਹੈ, ਆਪਣੇ ਆਪ ਰਿਕਵਰ ਕਰ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਆਧੁਨਿਕ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਵਾਂਗ ਹੀ ਇੱਕੋ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।