Spark Streaming 这玩意儿搞大数据的都不陌生接 Kafka、做准实时计算确实好用。但如果你用的是 qData 平台会发现它跟裸 Spark 提交方式不太一样——控制台、API、后台命令各有各的坑。而且流任务要常驻、要断点续跑、要优雅停止这些规范流程没搞清楚分分钟丢数据、任务秒退。我在这上面栽过好几次今天把从开发、提交、运维到排查的全流程整理出来都是亲测可用的经验直接照着做就行。一、qData 跑 Spark Streaming 的原理一句话把常驻任务管起来qData 对 Spark Streaming 做了专门的封装跟普通离线 Spark 任务的核心区别就两点离线任务跑完自动退出完事释放资源。Streaming 任务常驻启动后一直监听数据流除非你手动停否则它不会自己退出。另外qData 会自动帮你管理资源队列和心跳监控日志采集失败自动重启基于 Checkpoint 的断点续跑挂了再起来不丢数据所以你不用操心 YARN 层面的琐事但前提是你的代码要符合平台的规范。二、开始之前这些条件是硬性要求集群环境qData 上 Spark 组件正常2.x/3.x 都行YARN 有资源Kafka 能通qData-api 服务没挂。数据源本文以 Kafka 为例Socket/MQ 类似。你的代码必须遵守三条铁律必须设 Checkpoint 目录否则故障重启会丢偏移量或重复消费。代码末尾必须有 ssc.awaitTermination()否则任务启动后秒退。不要在代码里写死 CPU、内存这些全交给 qData 平台配置。三、一个可以直接拿来用的 PySpark 模板这个模板我在 qData 上跑通过Kafka 直连你改改参数就能用from pyspark import SparkContext from pyspark.streaming import StreamingContext from pyspark.streaming.kafka import KafkaUtils import os sc SparkContext(appNameQData-SparkStreaming-Demo) sc.setLogLevel(WARN) # 批次间隔 3 秒自己按业务调 ssc StreamingContext(sc, 3) # Checkpoint 目录 —— 断点续跑的核心必须配 checkpoint_path /qdata/spark/checkpoint/stream-demo ssc.checkpoint(checkpoint_path) # Kafka 参数 kafka_params { bootstrap.servers: 你的Kafka地址:9092, group.id: qdata-stream-group, auto.offset.reset: latest } topic test_topic stream KafkaUtils.createDirectStream(ssc, [topic], kafkaParamskafka_params) # 业务逻辑打印每条消息内容 stream.map(lambda x: x[1]).pprint() # 关键少了这一行任务绝对秒退 ssc.start() ssc.awaitTermination()四、三种提交方式控制台、后台命令、API方式一qData 控制台提交最推荐日常用这是最省事的全程页面点一点登录 qData 平台 → 进入 任务调度 / Spark任务管理 → 新建任务类型选 流式任务Spark Streaming。填任务名称上传你的 py 或 jar 包指定主文件路径。资源配置避坑重点Driver 内存2~4GExecutor 内存4~8G核心数2~4 核重启策略开启自动重启平台自带超时时间一定要设成“永久”否则任务跑一阵自己就停了保存点 手动运行。任务就会提交到 YARN 常驻运行持续消费。方式二后台命令行适合调试、临时测登录 qData 所在的服务器用平台封装的 qdata-spark-submit 命令不用自己配环境变量qdata-spark-submit \ --master yarn \ --deploy-mode cluster \ --driver-memory 2G \ --executor-memory 4G \ --executor-cores 2 \ /opt/qdata/spark/job/stream-demo.py提交后去 qData 控制台的任务列表就能看到运行状态和日志。方式三API 提交适合自动化、对接第三方如果你的流水线要自动启停流任务或者对接其他系统可以调 qData 的 API。核心就是调用 qdata-api 的提交接口把任务配置、脚本路径传进去实现一键启动。具体 API 文档平台里有这里不贴代码了但思路就是 POST 请求提交任务定义。五、怎么看任务状态和日志页面监控qData 任务管理页面会显示运行状态是否活着批次执行情况消费速度和堆积量资源使用率失败次数基本上够日常看了。日志排查实时运行日志控制台直接看 stdout/stderr大部分报错这里都有。底层 YARN 日志如果页面看不清楚登录服务器看 YARN 的 Spark Executor 日志。Checkpoint 日志检查快照目录是否有读写权限很多重启问题都是因为权限不对导致写不进去。六、启停规范优雅停止最重要正常启动优先用 qData 控制台启动。任务会自动注册到平台享受心跳监控和异常重启。优雅停止千万注意别直接杀进程绝对不要直接 kill 进程否则偏移量没提交重启后必然丢数据或重复消费。正确做法方法一在 qData 控制台点 停止任务平台会自动执行优雅停机——等当前批次处理完再终止。方法二后台执行 yarn application -kill app-id 也能优雅停前提是信号能传到 StreamingContext。重启 / 更新任务如果你改了代码或调整了资源务必清空旧的 Checkpoint 目录否则任务会加载旧状态你的修改可能不生效。删目录命令hdfs dfs -rm -r /qdata/spark/checkpoint/stream-demo七、常见翻车现场及解决方法问题1任务启动后几秒就退根本待不住原因代码里没有 ssc.awaitTermination()或者平台任务超时设成了“自动终止”或者 Checkpoint 目录没权限写。解决补上那行代码、改超时为永久、授权目录。问题2重启后疯狂重复消费原因没有配置 Checkpoint或者 Kafka 消费组的偏移量没持久化。解决强制开启 Checkpoint规范配置 group.id 和 auto.offset.reset。问题3任务越跑越慢数据堆积严重原因批次间隔太短但处理不过来Executor 资源太少业务逻辑里有慢操作比如频繁写外部存储。解决调大内存和核数、增加批次间隔、开启背压spark.streaming.backpressure.enabledtrue。问题4控制台提交一直失败原因qData-api 服务挂了YARN 队列没资源了脚本路径写错。解决重启 qData-api 服务参考前面部署的 v1.1.1、清理闲置任务释放资源、核对路径。八、我总结的几个最佳实践Checkpoint 必配不要偷懒否则断点续跑就是空话。awaitTermination() 必写否则任务铁定秒退。生产环境统一用控制台提交别在后台瞎 kill统一运维方便很多。按需配资源别动不动给 10 核 20G浪费资源还容易被 DBA 找。改任务时记得删旧 Checkpoint这个坑我踩了不下三次。九、最后说两句qData 跑 Spark Streaming 其实不算复杂就是平台规则 代码规范 资源合理 启停标准。跟裸 Spark 相比它帮你省了管理 YARN 和监控的麻烦但你要适应它的约束。如果你照着上面的步骤还遇到奇怪报错欢迎在评论区贴日志我看到了会帮你看看。毕竟都是趟过坑的兄弟。