Explain the execution flow of a Flink SQL job submitted through StreamPark's SQL editor?

A Flink SQL job takes a different path than an uploaded jar, since there's no pre-built artifact — StreamPark has to turn SQL text into a running Flink job at submission time.

When the job starts, StreamPark first parses and validates the SQL — source DDL, transformation statements, sink DDL — catching obvious syntax problems before anything reaches the cluster. It then resolves the connector dependencies declared for the job (for example a Kafka or JDBC connector jar), pulling them in so the SQL's source and sink connectors actually have implementations available.

With SQL and dependencies in hand, StreamPark constructs the equivalent of a Flink TableEnvironment and statement set internally, and lets Flink's own planner translate that into an executable job graph — StreamPark isn't writing its own SQL engine, it's driving Flink's. That job graph is then handed to the same Flink Submit abstraction used for jar-based jobs, so from the point of submission onward, a Flink SQL job and an Upload Jar job are tracked identically: same Application ID capture, same status polling, same savepoint and stop actions.