Flink Jar 作业

场景　已经有一个写好的 Flink 程序(DataStream/Table API 打成的 fat jar),想直接接入调度、常驻运行,而不是把逻辑翻译成 Flink SQL。

能干什么

你想做的事	配置成 Flink Jar 长这样(示意)
跑一个自带 Main-Class 的 jar	Jar 路径填 s3a://.../app.jar,主类留空或指定
跑镜像内置示例 jar	Jar 路径填 local:///opt/flink/examples/streaming/...
给程序传参数	程序参数按空格分隔填
jar 里要读写湖表	选一个「读写 catalog」,拿到本空间小账号的 S3 凭证

亮点

• Flink 版的 Spark Jar,同样的设计哲学——用户自带 DataStream/Table API 打的 fat jar,不用写 SQL;跟 Flink SQL、Flink CDC 共用同一套「实时集成部署」面板(启动/停止(savepoint)/checkpoint 监控全部通用),因为三者底层都走同一个部署服务,只是编译成 spec 的方式不同。
• 鉴权边界跟 Spark Jar 一致——平台管不到用户 jar 内部逻辑,所以走「本空间小账号 + 存储层 prefix policy 防越权」这条线,不是逐表 SQL 鉴权;能用 SQL 表达的逻辑,优先用 Flink SQL/CDC,受控程度更高。
• native app 模式对"作业该不该结束"很较真——常驻 7×24 是这个类型的默认预期,集群围绕"一直跑"设计(checkpoint、savepoint、重启续跑)。如果 jar 本身的逻辑是有限输入(处理完就退出,不是无界流),Flink 主程序退出后集群会自行销毁,运行期指标（Flink 状态/checkpoint/运行时长）随之清零不可再查,平台会明确提示原因,而不是留一个语义不清的"失败"。

完整操作示例:一次真实测试,验证平台如何处理"跑完就退出"的 jar

用镜像内置的 Flink 官方示例 WordCount.jar(org.apache.flink.streaming.examples.wordcount.WordCount)新建一个 Flink Jar 作业并启动。这个示例读取一段内置文本、统计词频、跑完即退出——是个很好的反例,能验证平台对"非预期退出"的处理是否清楚。

点「启动」后集群很快拉起,但因为 WordCount 处理的是有限数据,主程序几秒内就执行完退出。平台侦测到 native app 集群已消失,把部署状态标为终态,并给出清楚的解释,而不是含糊的"失败":

这个结果连续两次运行完全一致(分别落在“FINISHED”和“已停止”两种终态展示,但提示文案一致):

集群已自行销毁(native app 模式作业结束后自退)，运行期指标不可再查；
结果/日志见对象存储归档；若期望常驻运行，请确认作业逻辑是无界流而非有限输入

这也是这个类型的一个真实使用提醒:跑批处理性质的 Flink 程序应该用别的方式(比如包成 Spark Jar,或者本来就该走批作业),Flink Jar 这条通道是为常驻流处理准备的——jar 里的逻辑得是真正的无界流(读 Kafka/Socket 等持续数据源),平台才会看到预期中的"一直 RUNNING"状态。

想直接写流式 SQL 而不用打 jar 包,看Flink SQL 作业;想跑批处理性质的自带程序,看Spark Jar 作业。

看全部作业类型 →