Background To use SeaTunnel, the current user first needs to create and write a configuration file that specifies the engine to run the job and the parameters associated with the engine. Then define the "source," "transform," and "sink" of the job. We want to provide a client that allows the user to define the engine, source, and transformation, and receive information for a job directly from the code in the client, rather than starting with a configuration file. Users can then submit job definition information through the client, and SeaTunnel will run these jobs. After a job is submitted, the user can obtain the running status of the job through the client. Users can use this client to manage jobs that are already running, such as stop jobs, temporary jobs, and so on.
Motivation The solution we adopted is to design Seatunnel Http Client instead of Seatnnel CLI. Compared with Seatunnel CLI, Seatunnel Http Client has the following advantages: - The REST API is more lightweight than the Seatnnel CLI - Unified model guided implementation of multi-language support The REST API runs as part of JobMaster on the computing engine (Seatunnel Zeta) and is supported by the server. If we use Zeta as the computing engine, Seatunnel Http Client will communicate with the Zeta engine, which is Responsible for Zeta cluster-level operations such as submitting jobs, listing jobs, requesting cluster status, etc. More design please reference https://docs.google.com/document/d/1GYSyV6NY6DwLTWisy7VFSxFaocJgR3BFDn3v9imuWwg/edit#heading=h.fct1e0kpr5g9 -- Best Regards ------------ EricJoy2048 [email protected]
