简介一份面向高校大数据课程学习者与Flink初学者的实验报告主题为Flink初级编程实践围绕WordCount程序开发和数据流词频统计两项核心任务。报告基于Windows 10专业版主机与VirtualBox Ubuntu虚拟机构建实验环境完整记录了Apache Flink的安装启动、Maven项目配置、IntelliJ IDEA中编写Java代码、打包JAR并提交到Flink集群运行的过程第二个任务则使用Linux自带的nc命令模拟持续产生单词的数据流编写Flink程序进行实时词频计算并通过Flink Web控制台查看输出结果帮助理解DataStream API的基本用法。报告还专门总结了开发调试中遇到的IDEA引用Flink报错、Maven打包速度慢、nc运行后无输出等常见问题给出了使用阿里云镜像加速依赖下载、nc需手动输入数据后再到控制台检查输出等实践性解决思路。资源为单个docx文档大小2.46MB已有5100余人学习下载适合正在完成同类实验作业、需要参考Flink入门实操细节的读者借鉴。1. Flink 初级编程实践一份实验报告里的完整链路与三个必踩的坑大数据入门有个很现实的坎课程资料讲概念讲得头头是道但真到自己动手光是把「本机写代码 → Maven 打包 → 提交 Flink 集群 → 观察作业输出」这条链路跑通就能耗掉一个下午。这份实验 8 Flink 初级编程实践报告恰好把这套流程完整走了一遍在 Windows 本机用 VirtualBox 跑 Ubuntu 虚拟机装 IntelliJ IDEA 写 WordCount打包 JAR 提交到 Flink再用 NC 程序模拟实时数据流做流式词频统计。它最值钱的部分不是 FLink 的 API 怎么调而是把环境搭建、依赖配置、Web UI 观察输出这些环节的真实操作记录了下来——包括三个典型坑的解决方案。适合正在做大据课程的本科生也适合想快速复现 Flink 入门流程但不想从官方文档逐页猜参数的工程师。2. 环境准备为什么用虚拟机 IDEA Maven 这套组合2.1 虚拟机的选型逻辑Windows 本机跑 Linux隔离的是依赖不是麻烦实验报告里的环境是 Windows 10 本机 Oracle VM VirtualBox 跑 Ubuntu 64-bit虚拟机给了 2048MB 内存、4 个处理器、64MB 显存。这套配置放到今天看偏紧但结构上没问题Flink 是 JVM 应用跑在 Linux 上最省心而 Windows 用户装双系统成本太高虚拟机是性价比最高的中间方案。常见的做法是虚拟机网络用桥接模式这样虚拟机里的 Flink Web UI 可以通过http://虚拟机IP:8081从宿主机浏览器直接访问不用折腾端口转发。如果 NAT 模式下 8081 端口访问不通优先检查 VirtualBox 的端口转发规则是否配置正确。处理器给 4 个是因为 Flink 本地模式会按 CPU 核数创建 TaskManager 的 slot给太少并行度上不去给太多宿主机扛不住4 个在 i7-4790 上是个稳定值。2.2 IDEA 与 Maven 的职责边界一个管理源码一个管理依赖实验要求在 Linux 里先装 IntelliJ IDEA再由 Maven 管理 Flink 依赖并打包。这个分工值得新手注意IDEA 只负责写 Java 和调试真正决定「能不能跑到 Flink 上」的是 Maven 的 pom.xml。IDEA 里引用 Flink 报错绝大多数情况下是 pom.xml 里的依赖声明不对不是 IDE 的问题。Maven 安装后第一件事是配阿里云镜像这是从实验报告「Maven 打包太慢」这个坑里提炼出来的标准解法。打开~/.m2/settings.xml没有就新建在mirrors节点下加镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror逻辑说明mirrorOf写central表示只拦截 Maven 中央仓库的请求不影响其他仓库url指向阿里云公共仓库它同时代理了 central 和 jcenter对 Flink 相关依赖的覆盖率足够。注意这个配置是给 Maven 3.x 用的新版 Maven 如果还慢检查一下是不是 IDEA 内置的 Maven 而不是命令行 Maven 在跑打包。参数说明如果你用的是 Maven 3.8 以上版本有时需要额外配置idaliyunmaven/id的blocked标签但阿里云源一般不需要。打包慢除了网络还可能是每次都在重新下载依赖——确认本地仓库~/.m2/repository里是否已经有flink-streaming-java的 jar 包有的话说明依赖分析环节有冗余可以用mvn dependency:analyze查是不是引了没用的包。2.3 Flink 集群启动的验证手段日志、进程、Web UI 三层确认安装 Flink 后启动的正确姿势是先解压再进bin目录执行启动脚本。注意 Flink 需要 JDK 8 或 11实验环境用的 Ubuntu 自带的 OpenJDK 一般没问题但如果你在本地复现且装了 JDK 17启动时会直接报UnsupportedClassVersionError这是新手最容易忽略的一点。启动命令cd flink-1.13.6 ./bin/start-cluster.sh逻辑说明start-cluster.sh会同时启动 JobManager 和 TaskManager两个进程都在后台运行。启动完不要急着提交作业先确认三个信号一是终端没有报错二是日志目录log/下生成了flink-*-standalonesession-*.log三是浏览器能打开http://localhost:8081出现 Flink Web Dashboard 才算真正起来了。参数说明默认配置下 Flink 本地集群的 JobManager 占用 6144MB 堆内存虚拟机只有 2048MB RAM大概率会内存不足。所以在启动前要改conf/flink-conf.yaml里的jobmanager.memory.process.size和taskmanager.memory.process.size各调到 1024m 或 512m否则 JVM 可能直接起不来。这个细节实验报告没写但实际操作中你大概率会遇上。验证集群状态还可以用命令行./bin/flink list逻辑说明flink list连的是 JobManager 的 REST 接口输出当前集群里所有作业的 ID 和状态。如果这里报连接失败说明集群没启动成功回去看日志比盲改配置有效。3. WordCount 离线批处理打包 JAR 提交 Flink 的完整链路3.1 项目骨架与 pom.xmlFlink 依赖的版本管理是第一个黑匣子实验的第一个任务是用 IntelliJ IDEA 写 WordCountMaven 打包成 JAR 提交到 Flink。走通这一步的关键不是 WordCount 业务逻辑而是 pom.xml 的写法。Flink 项目天生是 Maven 多模块结构但单模块也能跑关键是把依赖声明对properties maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target flink.version1.13.6/flink.version /properties dependencies dependency groupIdorg.apache.flink/groupId artifactIdflink-java/artifactId version${flink.version}/version scopeprovided/scope /dependency dependency groupIdorg.apache.flink/groupId artifactIdflink-streaming-java_2.12/artifactId version${flink.version}/version scopeprovided/scope /dependency /dependencies逻辑说明flink-java提供批处理 DataSet APIflink-streaming-java_2.12提供流处理 DataStream API两个都声明是因为实验里两类程序都会写。_2.12后缀是 Scala 版本号Flink 内部有一部分实现基于 Scala选 2.12 是生态兼容性最好的选择。关键点在于scopeprovided/scope——这告诉 Maven 打包时不要把这些 jar 打进 JAR 里因为 Flink 集群本身已经带了这些库。如果你把 scope 改成compile打出来的 JAR 会非常大并且提交时可能与集群自带的 Flink 库版本冲突报NoClassDefFoundError这类玄学错误。参数说明flink.version用属性变量统一管理方便后续切换版本。1.13.6 是实验环境的时间点常用的稳定版到 2024 年 Flink 已经发展到 1.17、1.18API 有变化特别是 DataSet API 在 1.18 里标记为废弃。如果你在较新版本的 Flink 上复现建议用 1.13.6 保持与实验一致或直接改用 DataStream API 统一处理批流。3.2 WordCount 主类DataSet API 还是 DataStream API实验环境优先选前者实验报告在 IDEA 里写的 WordCount核心逻辑是标准的 MapReduce 思路。关键代码结构如下import org.apache.flink.api.common.functions.FlatMapFunction; import org.apache.flink.api.java.DataSet; import org.apache.flink.api.java.ExecutionEnvironment; import org.apache.flink.api.java.tuple.Tuple2; import org.apache.flink.util.Collector; public class WordCount { public static void main(String[] args) throws Exception { ExecutionEnvironment env ExecutionEnvironment.getExecutionEnvironment(); DataSetString text env.fromElements( hello flink, hello world, flink streaming ); DataSetTuple2String, Integer counts text .flatMap(new Tokenizer()) .groupBy(0) .sum(1); counts.print(); } public static class Tokenizer implements FlatMapFunctionString, Tuple2String, Integer { Override public void flatMap(String value, CollectorTuple2String, Integer out) { for (String word : value.toLowerCase().split(\\W)) { if (word.length() 0) { out.collect(new Tuple2(word, 1)); } } } } }逻辑说明fromElements直接构造内存数据集适合本地验证。flatMap是做分词和打平的算子每条输入行可以输出 0 到多个(word, 1)键值对。groupBy(0)按 Tuple2 的第一个字段单词分组sum(1)对第二个字段计数求和。这是批处理模式下的标准词频统计链路。参数说明\\W正则表示按非单词字符切分会把标点和空格都过滤掉。如果你的数据里有中文这个正则就失效了——中文字符会被当成分隔符整条输出就是空这是不少同学在实验报告里写出「程序跑了但输出为空」的原因之一。如果要处理中文换成split( )并按需清洗。3.3 Maven 打包与提交命令JAR 包提交时的 class 路径参数写完代码后在 IDEA 里直接mvn package就能出 JAR但提交到 Flink 时有个参数容易忽略——主类名不写全的话Flink 会报找不到 main 方法mvn clean package -DskipTests ./bin/flink run -c com.example.WordCount /path/to/wordcount-1.0.jar逻辑说明-c参数指定全类名含包名Flink 提交 JAR 时根据这个入口类反射调用 main 方法。如果省略Flink 会尝试从 MANIFEST.MF 里读Main-Class而 Maven 默认打包是不写这个属性的所以大概率报ClassNotFoundException。实验报告里「运行 JAR 包结果」这张图如果没有在 IDEA 里配置过mainClass实际执行时必然需要在flink run命令里带上-c。参数说明-DskipTests跳过测试编译阶段的测试执行但不影响测试代码编译能省一点打包时间。flink run后面跟的路径既支持绝对路径也支持相对路径但注意如果你在集群模式下提交JAR 路径需要所有节点都能访问到——本地集群无所谓真实多节点集群要放到 HDFS 或共享存储上。提交后的输出验证可以在命令端窗口直接看到完整结果。批处理任务跑完就退出不会挂在集群里这和后面的流式任务有本质区别。WordCount 批处理的输出数据量通常不大直接在终端看即可不需要非得去 Web UI 翻 TaskManager 日志。4. 实时数据流词频统计NC 模拟数据源与流式处理的两处关键差异4.1 NC 程序模拟数据流nc -lk的参数含义和实际用法实验的第二个任务是用 Linux 自带的 NC 程序模拟数据源再写 Flink 程序实时接收并统计词频。NCnetcat的作用相当于一个原始版 TCP 服务器监听指定端口把你从键盘输入的内容发给连上来的客户端。启动 NC 的命令nc -lk 8888逻辑说明-l表示监听模式listen-k表示接受多个连接后继续监听keep listening8888是端口号。NC 启动后会阻塞在终端等你在键盘上敲单词按回车发出去所有连接了这个端口的客户端都会收到这行数据。这里的关键理解是NC 本身不是实时生成数据而是「你手动敲一行它转发一行」所以实验报告里「NC 程序需要手动输入一些数据」这个描述是正确的——数据源是人类不是机器。参数说明-k参数在 macOS 和 Linux 上的行为不完全一样有些版本不支持-k需要用nc -l -p 8888替代。另外如果你在虚拟机的 Ubuntu 里跑 NC而 Flink 作业在同一个虚拟机里跑使用localhost即可连接跨主机就要填虚拟机的 IP。4.2 流式词频统计代码Source 换成 Socket 后一切逻辑都变了流式版本和批处理版本看着像但核心编程模型完全不同。批处理是「先拿全量数据再算」流处理是「来一条算一条的状态计算」。对应到代码上最大的变化是 DataStream API 替代了 DataSet APIimport org.apache.flink.streaming.api.datastream.DataStream; import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment; import org.apache.flink.api.common.functions.FlatMapFunction; import org.apache.flink.api.java.tuple.Tuple2; import org.apache.flink.util.Collector; public class StreamWordCount { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env StreamExecutionEnvironment.getExecutionEnvironment(); DataStreamString text env.socketTextStream(localhost, 8888); DataStreamTuple2String, Integer counts text .flatMap(new Tokenizer()) .keyBy(0) .sum(1); counts.print(); env.execute(Stream WordCount); } public static class Tokenizer implements FlatMapFunctionString, Tuple2String, Integer { Override public void flatMap(String value, CollectorTuple2String, Integer out) { for (String word : value.toLowerCase().split(\\W)) { if (word.length() 0) { out.collect(new Tuple2(word, 1)); } } } } }逻辑说明socketTextStream(localhost, 8888)创建了一个从 TCP Socket 持续读取数据的 Source每收到一行文本就发射一条数据。批处理里的groupBy(0)在这里变成了keyBy(0)这是批流 API 的重大分界keyBy是按 key 做逻辑分区而不是物理分组后续的sum(1)会维护每个 key 的累加状态实现增量统计。最后的env.execute()是流式作业必须调用的方法否则程序只是定义了数据流图不会真正启动任务。参数说明print()在流处理里是把每条计算结果输出到 TaskManager 的标准输出不是直接打在提交作业的终端上。你会在 Flink Web UI 的 TaskManager 日志里看到输出而不是在flink run的窗口里——这对第一次做流式实验的人来说是个容易困惑的点。这里有个核心区别值得强调批处理任务提交后跑完自动退出流式任务会永远挂在那里等数据。所以提交流式 JAR 包的终端会一直占用不要以为是卡死了。如果任务不想要了要么在 Web UI 里 Cancel要么直接上flink cancel jobId。4.3 从提交到观察Web UI 是流式任务真正的「黑匣子」窗口实验报告提到「在 flink 控制台查看输出情况地址为 http://自己的 ip 地址:8081」这一步是流式实验和批处理实验最大的体验差异。批处理直接在终端看结果流式作业因为跑在后台必须靠 Web UI 来观察。提交流式作业前建议先把 Web UI 打开看清楚两个东西一是 Jobs 列表里新作业是否处于 RUNNING 状态二是 TaskManager 的日志输出位置。流程是NC 终端输入单词 → Flink 作业消费并计算 → 输出打到 TaskManager 的 stdout 日志里。在 Web UI 上点进正在运行的作业 → 左侧 TaskManagers → 点开对应 TaskManager → 选 Stdout 标签页就能看到实时打印的词频结果。这个链路里有一个常见误区在 Web UI 的 Job 详情页找「输出」是找不到的因为 Flink 的 Web UI 默认不展示作业的标准输出只展示 metrics 和累加器。要看到print()的输出只能进 TaskManager 的 Stdout 日志。如果你按实验报告的指引打不开 Web UI优先检查虚拟机 IP 是否正确、8081 端口是否被占用以及 flink-conf.yaml 里的rest.bind-address是否绑定了正确的网卡地址。5. 常见问题与排查这份实验报告里的三个高频翻车点5.1 IDEA 引用 Flink 报错先看依赖坐标再看模块 JDK现象在 IntelliJ IDEA 里写 Flink 程序import 语句报红代码里所有 Flink 类都找不到Maven 面板显示依赖缺失或冲突。原因这个问题的根源通常不是 IDEA 本身而是 pom.xml 里的依赖坐标不对。最常见的三种情况一是flink-streaming-java的 artifactId 漏了_2.12后缀二是scopeprovided/scope在 IDEA 里虽然能让编译通过但如果 IDEA 的 Maven 设置里勾选了「使用本地仓库」提供的依赖可能没有被正确解析到三是 Flink 版本与 JDK 版本不兼容比如 JDK 17 跑 Flink 1.13 的老项目。解决先在 Maven 面板执行reload让 IDEA 重新解析依赖确认~/.m2/repository里有对应的 jar。仍然报红就把 pom.xml 里的 Flink 依赖全部显式写全并确认三个坐标都对齐groupId、artifactId、version。实验报告给了一个更实在的解法——「用 IDEA 写代码用 Maven 打包」意思是 IDEA 的报错可以不理会只要命令行mvn package能过就不影响实验推进。这个思路对初学者是友好的先把链路跑通再回头解决 IDE 的显示问题。5.2 Maven 打包太慢换源是第一步跳过测试是第二步现象执行mvn package时进度条卡住不动日志显示在下载依赖整个过程耗时 5 到 15 分钟甚至出现下载失败。原因默认 Maven 中央仓库在国外下载速度受网络环境影响极大。实验报告提到「在 Maven 的 config 里部署阿里云的镜像」这个路径是对的——直接在~/.m2/settings.xml里配mirror比在 IDEA 里设置更快因为命令行 Maven 和 IDEA 内置 Maven 读的是同一份 settings.xml。解决配完镜像后如果还慢加-DskipTests跳过测试阶段不是关键关键是确认依赖下载是增量不是全量。观察日志里是「Downloading」还是「Resolving」——如果是前者说明本地仓库没有缓存需要耐心等待如果是后者说明依赖分析耗时可以加-o离线模式跑一次验证本地仓库是否完整。另外有一个实战技巧把 IDEA 的 Maven 设置里的「Work offline」勾上如果本地仓库已经有 Flink 相关 jar打包速度会快很多。但从那以后我每次搭 Flink 环境都强制走一遍先配镜像再验证下载的策略省下的时间足够再跑一遍实验。5.3 NC 程序没有输出分清「没收到数据」和「没显示结果」现象NC 终端输入了单词Flink 作业显示 RUNNING但怎么都看不到词频统计结果。原因这一条在实验报告里写得最简短「NC 程序需要手动输入一些数据」但背后的坑不止一层。第一层是 NC 的输入和 Flink 的输出不在同一个窗口print()的结果打到了 TaskManager 日志在提交作业的终端看不到。第二层是nc -lk 8888启动后如果 Flink 作业先启动NC 后启动Socket 连接可能没有建立成功——TCP 连接是作业启动时主动发起的NC 后启动只是开始监听但 Flink 那一次的 connect 已经失败并重试有时间差问题。第三层是输入了中文或特殊字符被\\W正则全部分割掉输出了大量空串。解决先把两个程序的启动顺序固定先启动 NC 监听确认端口处于 LISTEN 状态ss -lntp | grep 8888再提交 Flink 作业。然后确认输出位置到 Web UI 里找 TaskManager 的 Stdout 页签或者用./bin/flink log查看运行日志。最后验证输入内容只敲英文单词和空格回车发送观察 Flink 是否有反应。如果print()还是没有输出用./bin/flink list确认作业没有处于 FAILED 状态——常见的失败原因包括 socket 连接被拒、端口占用、序列化异常。检查 TaskManager 日志里的 Exception 堆栈是第一优先级不要盲猜。这三条踩坑记录里前两条是环境与配置问题第三条是操作顺序问题在真实的 Flink 入门场景里出现频率最高。实验报告给出的解决方案偏向「能跑就行」但作为有经验的工程师我更建议在入门阶段就把这三个检查项变成操作习惯代码能用但 IDE 报红时先确认命令行能不能完成编译打包慢时先换源再查依赖流式作业看不到输出时先分清三种可能再动手。6. 把这套实验跑成自己的流程用 Web UI 和日志做最后的验证闭环实验报告的内容到这里已经完整覆盖了 Flink 入门的两条主线——批处理 WordCount 和流式词频统计。但如果你只是为了交实验报告照着做完就结束那这份资源的价值就只用到了一半。最后这一个章节我想把自己反复调试 Flink 实验后沉淀下来的验证流程写出来让这套实验真正变成你自己的东西。先说日志分级的应对。日常工作里排查 Flink 问题90% 的情况都靠三类日志JobManager 日志解决「作业能不能提交」的问题TaskManager 日志解决「作业为什么不输出」的问题Flink Web UI 上的异常堆栈解决「运行时报错」的问题。实验报告的「NC 程序没有输出」看似是功能问题实际是日志定位问题。我的习惯是提交作业后先不急着在 NC 里输入数据先去 Web UI 看作业是否进入 RUNNING 且没有重启记录再输入数据然后立刻切到 TaskManager 的 Stdout 页签。如果两分钟内没有输出再看 TaskManager 的日志文件通常能看到 Socket 连接异常或正则切分异常的明确堆栈。再说一个进阶验证技巧流式任务跑起来后用 Flink Web UI 的「Metrics」面板看numRecordsIn和numRecordsOut这两个计数器。数值在涨说明数据在流动问题出在输出侧数值不动说明数据源没接上问题出在 NC 或 Socket 连接。这个技巧不需要任何额外工具但对定位「作业明明 RUNNING 却没有输出」这类问题特别有效。实验报告的 Web UI 只用来观察输出但你把它当监控工具用能省下大量靠猜的时间。最后提一个虚拟机上跑 Flink 容易忽略的事情Flink 集群默认的系统并行度等于 TaskManager 的 CPU 核数如果虚拟机给了 4 个处理器默认就是 4 个并行实例。流式作业里print()的输出会分散到多个 TaskManager 的日志里你在 Web UI 里翻到的可能只是其中一部分。要看到完整顺序可以在env.execute()前加env.setParallelism(1)强制单并行度这个调整对实验场景完全够用也更能直观理解数据流被并行分片后输出混乱的现象。从那以后我每次搭 Flink 实验环境都强制走一遍「先确认集群状态 → 再提交作业 → 最后用计数器验证数据流」的流程翻车的概率比一开始盲跑低了不少。希望这份实验报告的拆解能帮到你把这仨坑记住你的 Flink 入门会顺畅得多。本文还有配套的精品资源点击获取