把DolphinScheduler用Standalone模式部署起来，再让Flink去消费Kafka里的消息，看起来是两件独立的事，实际趟完一遍你会发现，真正花时间的不是启动脚本，而是把"消息推送—流式计算—工作流调度"这三层串成一条可控的链路。这篇内容就围绕这个目标展开：DolphinScheduler单机部署、Flink客户端安装、Kafka消息推送、Flink消费，最后统一编排进同一个工作流，让定时调度、手动补跑、日志查看都落在一个平台里。
文章适合这几类人：第一次接触DolphinScheduler、想快速在本地验证功能的；手头有Flink作业需要纳入统一调度体系、但暂时不想直接上集群的；以及被"Flink任务为什么一直运行中"这类问题折磨过的人。整个过程我尽量按实际操作的顺序写，命令和配置都是可直接复制的，版本以DolphinScheduler 3.2.x和Flink 1.17/1.18为参照。
1. 为什么先跑通Standalone模式：价值与边界
1.1 Standalone模式到底给了你什么
DolphinScheduler的部署模式里，Standalone是启动成本最低的一种。它把这套调度平台的核心组件——Master、Worker、API服务、UI界面、内置注册中心和H2数据库——全部塞进一个Java进程里。你下载解压后执行一个启动脚本，就能得到一个完整可用的调度平台。
这种设计的价值在于：它保留了完整的工作流定义、任务编排、依赖关系、定时调度、日志查看和告警能力。也就是说，你在生产集群上能用到的功能，Standalone模式基本都有。对个人学习、功能验证、小规模数据管道搭建来说，它足够撑起整个业务场景，而且省去了部署MySQL、ZooKeeper、Redis这些外部依赖的时间。我见过不少小团队用Standalone模式稳定跑了很长时间，管理几十个离线任务完全没问题。
1.2 什么情况下别用Standalone
Standalone的边界也很清楚。它不是一个高可用架构，Master或Worker挂了不会自动故障转移；它默认用内置H2数据库，不方便横向扩展，不适合多人同时大规模开发和密集调度；它也不自带YARN、K8s这类资源管理能力，虽然可以提交到外部集群，但调度平台本身没有集群容错。
如果你们的生产环境有这些诉求，还是直接上伪集群或真正的集群部署更合适。下表是我个人做选型时的判断依据：
| 对比维度 | Standalone单机 | 集群部署 |
|---|---|---|
| 外部依赖 | H2数据库+内置注册中心，零外部依赖 | MySQL/PostgreSQL + ZooKeeper/注册中心 |
| 高可用 | 无故障转移能力 | 支持Master/Worker多节点 |
| 适用场景 | 学习验证、小团队、预发环境 | 生产环境、大规模任务编排 |
| 资源成本 | 一台机器2-4GB内存足够 | 至少三台以上机器起步 |
| 与YARN/K8s集成 | 可作为提交客户端 | 深度集成资源管理 |
我这次的目标很明确：先把整条数据链路跑通，用DolphinScheduler的工作流把模拟消息推送到Kafka，再由Flink任务消费Kafka里的消息并打印落库。这个目标Standalone完全能覆盖。
1.3 完整链路的目标拓扑
部署完成后，机器上会同时存在这几个角色：
- DolphinScheduler Standalone服务，负责工作流编排和定时调度；
- Kafka Broker（单节点即可），负责承接消息的推送与消费；
- Flink客户端及本地Standalone Session集群，负责执行流式计算作业。
DolphinScheduler工作流里会有两个节点：第一个是Shell节点，模拟业务系统向Kafka topic推送一批消息；第二个是Flink节点，提交一个消费Kafka的作业，作业启动后持续从topic里拉取消息，打印到控制台或写入外部存储。工作流可以被手动触发，也可以配置cron定时触发。这就是"Kafka消息推送 + Flink消费"被调度化的完整形态。
2. 部署前的环境自查清单
2.1 JDK与内存：最容易忽略的运行条件
DolphinScheduler和Flink都是Java系应用，JDK版本直接影响启动结果。DolphinScheduler 3.x要求JDK8以上，Flink 1.17/1.18推荐JDK11或17。我实际用的是OpenJDK 11，两边都没遇到兼容问题。先执行java -version确认，如果没有或版本过低，装好并配置JAVA_HOME再继续。
内存方面，Standalone模式虽然只开一个进程，但它内部同时跑Master、Worker、API等多个角色，再加上Flink本地集群和Kafka Broker，一台2GB内存的机器会非常吃力。我给的建议是至少4GB，最好8GB。云主机的话，4C8G的配置跑这套链路会比较舒服。上生产前还可以调整bin/start-dolphinscheduler-standalone.sh里的JVM参数，默认值偏向通用场景，任务量大时Worker的堆内存要单独调。
2.2 端口规划与访问入口
Standalone模式启动后会占用几个默认端口，如果机器上已经跑了其他服务，需要提前确认不冲突。我整理了一份常用的端口清单：
| 服务 | 默认端口 | 说明 |
|---|---|---|
| DolphinScheduler UI/API | 12345 | 浏览器访问控制台入口 |
| DolphinScheduler内部通信 | 25333、25551等 | Master与Worker通信，一般无需外部访问 |
| Flink WebUI | 8081 | 查看作业状态和日志 |
| Kafka Broker | 9092 | Producer和Flink消费连接的入口 |
检查端口可以用ss -lntp或netstat -lntp。防火墙如果是开启状态，至少放行12345和9092，否则你本地浏览器能打开控制台，但Kafka消息会一直发不出去。这些细节在测试环境容易忽视，等排查问题时会浪费很多时间。
2.3 下载、解压与目录约定
DolphinScheduler官方发行包命名为apache-dolphinscheduler-3.2.1-bin.tar.gz，下载后建议放到/opt目录下统一管理。Flink的发行包是flink-1.18.0-bin-scala_2.12.tgz，Kafka用kafka_2.13-3.6.0.tgz这样带Scala版本号的二进制包。
我习惯的目录结构是这样：
/opt/ ├── dolphinscheduler/ # DolphinScheduler解压目录 ├── flink/ # Flink解压目录 ├── kafka/ # Kafka解压目录 └── data/ ├── kafka-logs/ # Kafka消息数据目录 └── h2/ # DolphinScheduler内置H2数据库目录提前把三条路径想清楚很有用，后续配置环境变量、写Shell脚本、找日志都不用临时猜。下载时记得校验一下SHA512，开源软件从镜像站下载后校验是基本习惯，避免拿到损坏的包。
3. 动手部署DolphinScheduler Standalone服务端
3.1 一条命令启动，然后确认进程与日志
解压完成后，进入bin目录执行：
cd /opt/dolphinscheduler/bin bash start-dolphinscheduler-standalone.sh正常情况下，脚本会启动一个名为DolphinSchedulerStandaloneServer的Java进程。用jps命令看一下，如果能看到这个进程，说明核心服务已经起来了。第一次启动可能需要几十秒，因为要初始化内置的H2数据库、创建元数据表、启动内部注册中心。启动慢不代表卡死，观察日志文件比干等更有意义：
tail -100f /opt/dolphinscheduler/logs/dolphinscheduler-standalone.log日志里出现DolphinSchedulerStandaloneServer started successfully这类信息，就说明服务端就绪了。如果启动失败，绝大多数情况是端口被占用或者JDK版本不匹配，看异常堆栈基本能定位。这一步我的经验是：不要急着改配置，先把默认状态跑起来，再逐项调整，排错难度会低很多。
3.2 首次登录与初始配置
打开浏览器访问http://<服务器IP>:12345/dolphinscheduler/ui，看到登录页后使用默认账号admin登录，初始密码以官方文档为准（常见是dolphinscheduler123）。首次登录后建议立刻修改密码，这个习惯在测试环境也同样重要，因为Standalone模式的API端口默认对网络开放，如果你所在的网络环境不安全，默认口令很容易被扫描器利用。
登录后进入控制台，左侧菜单能看到项目、工作流、数据源、安全中心等功能区域。此时先不用急着建工作流，需要去"安全中心"做一些基础配置：队列管理里确认有default队列；租户管理里创建租户；Worker分组里确认default分组存在。这些概念后面章节会展开，先把位置记住就行。
3.3 内置H2数据库的工作机制与备份注意
Standalone模式默认使用内嵌H2数据库，所有工作流定义、调度记录、租户信息都存在H2文件里。H2数据库文件默认生成在用户主目录下的.dolphinscheduler目录中，或者由DOLPHINSCHEDULER_HOME指向的路径控制。
这意味着：只要不删除数据文件，DolphinScheduler重启后工作流定义和定时任务都还在。但H2毕竟不适合高并发多写，如果你后面要频繁做大量实验，建议尽早切到MySQL模式，避免导入导出数据时踩到数据库瓶颈。做备份也很简单，直接停掉服务后把整个数据目录压缩归档即可，恢复时解压回原路径再启动。
4. Flink客户端部署与自检
4.1 版本选择与目录释放
Flink的版本选择主要看两件事：你依赖的Kafka connector版本，以及运行方式。我这次选Flink 1.18，Kafka connector使用对应的flink-connector-kafka-3.1.0版本。如果不小心把1.17的connector放到1.18的环境里，通常会报方法签名错误或NoSuchMethodError。
解压后把FLINK_HOME和PATH写进/etc/profile，然后source一下，方便后续直接用flink命令：
export FLINK_HOME=/opt/flink export PATH=$FLINK_HOME/bin:$PATH注意/opt/flink目录下会有lib与plugins目录。DolphinScheduler的Flink任务节点在执行时会读取FLINK_HOME环境变量，所以这里配置的路径后面要给DolphinScheduler的"环境管理"也配置一份，两处要保持一致，否则任务提交时会提示找不到Flink命令。
4.2 快速验证：跑通自带示例
Flink解压后自带一个本地Standalone集群脚本，先启动它：
bash /opt/flink/bin/start-cluster.sh启动后访问http://<服务器IP>:8081，可以看到Flink WebUI，确认只有一个TaskManager且内存正常。接着用自带的WordCount示例验证提交链路：
flink run -m localhost:8081 /opt/flink/examples/streaming/WordCount.jar提交后去WebUI的Completed Jobs里查看，能看到作业执行记录。这个验证很关键，它说明Flink客户端、本地集群、Jar包提交这条链路都是通的。后续DolphinScheduler提交Flink作业，本质上也是走这条链路，只是把"手动执行命令"换成了"调度平台触发命令"。
4.3 部署模式的取舍思路
Flink作业的部署方式直接决定了DolphinScheduler里任务节点的配置，常见的几种模式如下：
| 部署方式 | 提交命令 | 特点 | 适合场景 |
|---|---|---|---|
| Local Standalone Session | flink run -m localhost:8081 | 本地共享集群，提交立即运行 | 本地验证、开发调试 |
| YARN Application | flink run -t yarn-application | 作业粒度独立，资源隔离好 | 生产Flink作业 |
| YARN Session | flink run -t yarn-session -Dyarn.application.id=... | 共享会话，启动快 | 多个小作业复用集群 |
| Kubernetes Application | flink run -t kubernetes-application | 容器化隔离 | 云原生环境 |
这篇文章的演示环境用Local模式最直接，DolphinScheduler提交Flink任务时部署方式选择LOCAL，运行模式选择"运行（detached）"，这样调度任务只负责提交作业并返回成功，而不是傻等作业完成。这个思路非常重要，下一章Kafka接入后我还会重点提。
5. Kafka消息推送与Flink消费：先让数据转起来
5.1 Kafka准备：Topic、分区与序列化
先启动Kafka。我用的是Kafka自带的ZooKeeper模式，执行下面两条命令分别启动ZooKeeper和Kafka Broker：
bash /opt/kafka/bin/zookeeper-server-start.sh /opt/kafka/config/zookeeper.properties bash /opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.propertiesBroker起来后创建本链路的核心Topic：
/opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:9092 \ --create --topic user_behavior \ --partitions 3 --replication-factor 1分区数我设为3，这是为了模拟真实场景下的并行消费能力。Flink的KafkaSource会自动根据分区数决定并行度，如果你只有一个分区，Flink端并行度设再高也没用，这是新手特别容易忽略的点。消息格式直接用JSON字符串，消费端用SimpleStringSchema先拿到原始文本，需要结构化处理时再反序列化成Java对象。
5.2 推送端模拟：Shell命令代表业务消息
在真实业务里，消息推送方是埋点系统或业务服务，但在这里我们只需要一个能稳定产生可控消息的脚本，方便在DolphinScheduler工作流里反复执行。我用一段Shell脚本来做Kafka消息推送：
#!/bin/bash { for i in $(seq 1 50); do echo "{\"userId\":\"u${i}\",\"action\":\"click\",\"page\":\"/product/${i}\",\"ts\":\"$(date +%s)\"}" done } | /opt/kafka/bin/kafka-console-producer.sh \ --broker-list localhost:9092 \ --topic user_behavior echo "push 50 messages to topic user_behavior done"这里有个细节：kafka-console-producer会逐行读取标准输入，所以我把多条消息一次性管道进去，而不是循环50次启动50个Producer进程。每个Producer进程的初始化都要创建连接、拉取元数据，如果循环调用，脚本执行时间会从几秒变成几分钟，工作流里这种低效写法会直接拉长整个链路的执行时间。
验证推送是否成功，可以在另一个终端启动控制台消费者：
/opt/kafka/bin/kafka-console-consumer.sh \ --bootstrap-server localhost:9092 \ --topic user_behavior \ --from-beginning \ --max-messages 50能看到50条JSON消息刷出来，说明Kafka收发链路是通的。
5.3 消费端：一个标准的KafkaSource作业
推送端验证完毕后，写一个最简Flink消费作业。我习惯先写一个可以打印到控制台的版本，确认链路通了再加业务逻辑。代码大致如下：
import org.apache.flink.api.common.eventtime.WatermarkStrategy; import org.apache.flink.api.common.serialization.SimpleStringSchema; import org.apache.flink.connector.kafka.source.KafkaSource; import org.apache.flink.connector.kafka.source.enumerator.initializer.OffsetsInitializer; import org.apache.flink.streaming.api.datastream.DataStream; import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment; public class KafkaFlinkSinkJob { public static void main(String[] args) throws Exception { String bootstrapServers = "localhost:9092"; String topic = "user_behavior"; StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); KafkaSource<String> source = KafkaSource.<String>builder() .setBootstrapServers(bootstrapServers) .setTopics(topic) .setGroupId("flink-scheduler-demo") .setStartingOffsets(OffsetsInitializer.latest()) .setValueOnlyDeserializer(new SimpleStringSchema()) .build(); DataStream<String> stream = env.fromSource( source, WatermarkStrategy.noWatermarks(), "kafka-source" ); stream.map(value -> { System.out.println("[kafka-message] " + value); return value; }).name("print-message"); env.execute("KafkaFlinkSinkJob"); } }这段代码注意几个配置点：setGroupId定义了消费组，DolphinScheduler每次调度提交新作业时，如果groupId不变，Flink会从上次提交的位点继续消费；setStartingOffsets(OffsetsInitializer.latest())表示作业第一次启动时从最新消息开始，不消费历史积压。实际项目中这两个参数要根据语义仔细设计，我在第7章还会专门讲这个坑。
写好后用mvn package打包，确保用maven-shade-plugin打成一个包含所有依赖的fat jar。Kafka connector的依赖如果只以provided方式引入，提交到Flink集群时会报ClassNotFoundException，这一步几乎每个人都会踩一次。
6. 把整条链路编排进DolphinScheduler
6.1 前置条件：租户、环境、Worker分组
在DolphinScheduler控制台里创建任务之前，有几项安全中心配置必须处理，否则任务会直接失败。
第一项是队列。队列对应底层调度资源组，Standalone模式没有真正接入YARN，但DolphinScheduler要求任务必须指定队列。在"安全中心-队列管理"里确认存在default队列即可。
第二项是租户。DolphinScheduler的任务最终要落到Linux系统用户去执行，所以要创建一个操作系统用户，再在租户管理里创建同名租户。例如创建系统用户：
useradd -m -s /bin/bash dolphinscheduler然后在"安全中心-租户管理"里新建租户名dolphinscheduler，关联这个系统用户。租户权限决定了任务能读写哪些文件，很多莫名其妙的任务失败都来自租户对应的系统用户没有日志目录或资源目录的写权限。
第三项是环境。在"安全中心-环境管理"里创建名为flink-env的环境，配置项要包含Flink的环境变量：
FLINK_HOME=/opt/flink PATH=$FLINK_HOME/bin:$PATH创建完成后，在Flink任务节点里指定该环境。DolphinScheduler执行Flink任务时会把这份环境变量注入到任务进程，和你在/etc/profile里配置的效果一样。
6.2 上传Flink作业Jar到资源中心
之前手工flink run提交时，Jar包直接放在本地文件系统。现在要让DolphinScheduler提交，需要把Jar上传到它的资源中心，这样多个租户可以复用，版本也比较可控。
在控制台"资源中心-文件管理"里新建目录，例如/user/dolphinscheduler，然后上传KafkaFlinkSinkJob.jar。上传成功后，它会生成一个资源路径，类似/user/dolphinscheduler/KafkaFlinkSinkJob.jar，后面配置任务节点时直接用这个路径，不用关心服务器物理路径。
资源中心的权限和租户是关联的。如果任务执行失败且日志显示找不到Jar，八成是当前租户没有该资源目录的权限，去资源管理里把资源指定给对应租户即可。
6.3 创建工作流：推送Kafka + 消费Flink
现在进入"项目-工作流定义"，新建一个项目，然后创建两个任务节点。
第一个节点是Shell任务，用于Kafka消息推送。配置内容就是把之前写好的推送脚本填进去。脚本里注意使用绝对路径，因为DolphinScheduler执行Shell任务的工作目录不固定，依赖相对路径会翻车。节点名称写成push_kafka_messages。
第二个节点是Flink任务，用于提交Flink消费作业。关键配置项我整理成下表：
| 配置项 | 示例值 | 说明 |
|---|---|---|
| 程序类型 | JAVA | 对应Java Jar任务 |
| 部署方式 | LOCAL | 提交到本机Flink Standalone Session |
| 运行模式 | 运行（detached） | 提交完成后立即返回成功 |
| Main Jar | /user/dolphinscheduler/KafkaFlinkSinkJob.jar | 选择资源中心里上传的Jar |
| Main Class | com.example.KafkaFlinkSinkJob | 带包名的全类名 |
| 环境名称 | flink-env | 选择第6.1节创建的环境 |
在Flink节点上我还习惯加几个自定义参数，把broker地址和topic名都作为运行时参数传进去，避免改代码重新打包。Main类里需要相应解析这些参数，本文示例代码为了简洁直接把值写死在常量里，实操时改成从args读取更规范。
两个节点都创建好后，用连线把push_kafka_messages指向flink_kafka_consumer，形成上下游依赖。保存后点击"上线"，工作流就可以被触发了。
6.4 手动执行与定时调度
重头戏在于验证两种运行方式。第一种是手动执行：点击工作流定义里的"运行"按钮，设置运行参数后触发，然后到"工作流实例"页面观察状态。Shell节点执行完成后，Flink节点会开始提交作业，最终两个节点都显示成功。
第二种是定时调度：在工作流定义里设置cron表达式。DolphinScheduler的定时配置和Linux crontab略有区别，它使用自己的规则，但常见表达式基本一致。例如每天凌晨2点执行一次：
0 0 2 * * ? *配置定时后记得点击"上线"，并且确保调度开关是打开状态。这个场景的实际含义是：每天定时向Kafka推送一批模拟数据，并启动Flink作业消费处理。如果处理的是真实业务管道，推送节点可以替换为Kafka连通性检查或者上游任务告警，核心编排逻辑完全一致。
7. 实战中的故障与收尾：每次部署都会踩的坑
7.1 Flink任务节点为什么一直显示"运行中"
这是我在这个链路里遇到最多的问题。很多人的直觉是：DolphinScheduler里的Flink任务任务节点执行后，应该等当前Flink作业跑完才显示成功。但Flink消费Kafka的作业是持续运行的流作业，它根本没有"跑完"这个概念，所以任务节点会一直挂在RUNNING状态，工作流永远不会结束。
解决办法不是去配置超时时间，而是理解部署方式与运行模式组合的含义。Flink任务节点提交作业时选择"运行（detached）"模式，DolphinScheduler只负责把作业提交到Flink集群，拿到作业ID后立即返回成功。真正的Flink作业生命周期交由Flink集群管理，DolphinScheduler这边的工作流可以继续走后续节点。换句话说，DolphinScheduler管理的是"提交动作"和"作业状态归集"，不是"等待作业自然结束"。理解这一点后，就不会再去纠结为什么流任务不结束了。
如果业务上确实需要等到作业跑完再走下一步，那就应该设计成有界数据流，比如消费一个固定范围的Kafka消息后让作业退出，但生产上的流作业很少这么用，多数人最后都选择了detached提交加外部监控的组合。
7.2 资源中心Jar找不到或提交报ClassNotFound
任务节点如果配置了资源中心的Jar路径，DolphinScheduler执行时会把资源文件同步到本地临时目录再提交。这个过程中有一层租户和资源权限的映射关系。错误日志里出现"resource does not exist"或"no permission"时，优先去资源中心确认Jar是否上传成功、租户是否授权。
如果日志报的是NoClassDefFoundError: org/apache/flink/connector/kafka/...，问题不在DolphinScheduler，而在Flink作业的Jar包没有做依赖合并。Kafka connector和Flink核心依赖的关系比较复杂，尤其涉及flink-shaded重定位类时，直接打普通Jar提交几乎必炸。解决方式是用maven-shade-plugin在打包阶段把org.apache.flink.connector.kafka相关的依赖打进同一个Jar，并且排除掉Flink自带的核心类，避免版本冲突。这个经验可以提前记住，等出了问题再查会浪费一个下午。
7.3 消费组位点问题：重复消费还是漏消费
Flink作业的group.id和auto.offset.reset直接决定了消费起点。因为我代码里用的latest，所以每次DolphinScheduler重新提交作业时，如果消费组还在且已有位点，Flink会从上次提交的位置继续，而不会从头消费新推送的50条消息。这会导致一个现象：工作流明明显示成功，但控制台没有打印任何新消息。
排查这类问题的方法是看Flink WebUI中的作业日志，以及Kafka的消费组命令：
/opt/kafka/bin/kafka-consumer-groups.sh \ --bootstrap-server localhost:9092 \ --group flink-scheduler-demo \ --describe这个命令会输出当前消费组的位点信息。如果出现current-offset和log-end-offset不一致，说明消息被消费过或还没被消费。实际生产里，流作业一旦启动就是长驻的，很少反复重提，所以位点问题往往出在测试和补跑场景。建议在验证数据时使用独立的topic或独立的group，避免和正式作业互相污染。
7.4 任务失败的日志去哪个页面看
DolphinScheduler的日志路径很容易让新手迷茫。先说结论：排错顺序是先看"任务实例"页面里该节点的日志，再看Flink WebUI的作业日志，最后查Kafka的消费情况。
DolphinScheduler任务实例的日志入口在"工作流实例-任务节点-查看日志"。这里的日志包含完整的环境变量、提交命令和退出码。Flink作业提交成功后，运行期间的输出在Flink WebUI的TaskManager日志里。Kafka侧的异常则在/opt/kafka/logs/下，比如server.log里如果有连接拒绝或认证失败会直接体现。
我整理了一个基于实际经验的问题对照表：
| 常见现象 | 可能原因 | 排查方向 |
|---|---|---|
| Shell推送节点失败 | producer脚本找不到Kafka路径 | 检查shell脚本绝对路径 |
| Flink节点失败提示找不到Main Jar | 资源中心权限未授权 | 给租户授权资源路径 |
| Flink节点一直运行中 | 未使用detached提交模式 | 修改运行模式配置 |
| 控制台无消费日志 | group.id位点已过latest | 换组或使用独立topic验证 |
| 提交时报HADOOP_CLASSPATH缺失 | 本地无Hadoop环境 | 部署方式选择LOCAL，避免依赖YARN |
这里单独说一下HADOOP_CLASSPATH这个报错。如果你在DolphinScheduler里配置Flink任务时选择了YARN相关部署模式，而机器上又没有安装Hadoop客户端，Flink提交时会要求设置HADOOP_CLASSPATH。本地验证阶段没必要现在搭Hadoop，部署方式直接用LOCAL就能绕开。
7.5 关于任务超时与失败重试的补充
DolphinScheduler里每个任务节点可以配置超时时间和失败重试次数。对于Flink流任务，超时时间要谨慎设置。如果采用detached提交，任务节点本身几十秒内就返回了，超时时间设短一些问题不大。但如果你某些节点还是要等待作业完成，超时阈值就需要比实际最长运行时间大很多，否则作业还在跑，工作流已经把它标记为超时失败。
重试次数我通常设为1到2次。这里有个隐患：Flink作业如果是detached提交但实际提交后立刻失败，DolphinScheduler重试时会再提交一次前一个作业，导致重复资源申请。所以对于常驻流作业，重试策略建议关闭或只在"提交失败"这个层面重试。这是我被生产环境教训过一次才注意到的细节。
最后再分享一点个人体会
这个链路整体跑通之后，我最深的感受是：调度平台对流计算作业的管理形态和离线任务完全不同。离线任务等它跑完即可，流计算作业则是"常驻、持续消费、生命周期由集群管理"。DolphinScheduler在这里扮演的角色更像是一个"作业提交和服务编排入口"，而不是"作业运行终态控制器"。
另外一件事值得多说一句：Kafka消息推送与Flink消费的链路验证，不要一开始就接入调度平台。先手动推送、手动提交、手动看日志，把每个环节都确认一遍，再接入DolphinScheduler，这样即使出问题，你也知道该去哪个环节找原因。我们经常看到排错排到最后发现是脚本里少了一个空格导致JSON格式错乱，这种问题放在调度平台里排查反而更费劲，因为它会包装成"任务失败"的通用表象。
如果你按这篇文章的思路把环境搭起来，建议下一步做两件事：一是把Shell推送节点换成真实的业务数据源或上游数据检查任务；二是把Flink作业改成从args读取topic和broker地址，让作业和具体topic解耦。这样整个调度系统的扩展性和可维护性会好很多，后续接更多实时任务时也只需要复制工作流再改参数而已。
