Java与大数据学习路线：四阶段能力组装施工图-育师

1. 这不是一张“万能地图”，而是一份踩过坑后画出的施工图

“Java及大数据学习路线”——这七个字在招聘网站、技术社区、自学论坛里高频出现，但凡想转行进开发、想从传统后端往数据方向拓展、或者刚毕业不知该往哪扎的新人，几乎都会搜它。可搜完之后呢？90%的人点开一堆图文、视频、PDF，最后卡在“学完Java基础该干啥”“Hadoop和Spark到底先碰哪个”“为什么写完MapReduce跑不通集群”这种具体问题上，不是资料太散，就是步骤断层，再或者干脆是路线本身脱离真实工作流。我带过几十个从零起步的学员，也帮某高校实验室设计过三届本科生的数据工程实训路径，最深的体会是：所谓“学习路线”，本质不是知识罗列，而是能力组装的工序表。你得知道每一步组装什么模块、用什么工具、装歪了会卡在哪、拧紧螺丝的力道怎么控制。比如Java部分，很多人死磕《Effective Java》却连Tomcat怎么热部署都搞不定；大数据部分，背熟YARN调度原理，结果连一个能读取HDFS文件的Spark Shell命令都敲错两次。这篇内容不讲“应该学什么”，只讲“实际怎么搭”。我会把整条路径拆成四个可触摸的阶段：语言筑基→工程落地→数据管道成型→生产环境穿透，每个阶段明确交付物（比如“能独立写出带事务回滚的Spring Boot接口”）、避坑红线（比如“别在Windows上直接装Hadoop伪分布式”）、以及最关键的——为什么这个顺序不能调换。适合两类人：一类是每天挤地铁时刷两小时网课却总感觉“学了又忘”的自学者；另一类是已经写过Java Web项目，但面对Flink实时计算任务时手足无措的在职开发者。如果你正卡在某个具体环节，比如“学完Java集合框架后不知道下一步该啃JVM还是直接上Spring”，或者“Hive建表成功但SELECT *返回空结果查了一下午”，后面的内容会直接给你解法。

2. 路线设计逻辑：为什么必须分四步走，而不是“Java+Hadoop+Spark”三连击

2.1 核心矛盾：技术栈的“深度依赖链”被严重低估

很多学习路线图把Java、Hadoop、Spark、Flink并列成四个平行模块，像超市货架一样任选。这是最大的认知偏差。真实的技术栈是嵌套式洋葱结构：外层能力完全依赖内层稳定。举个最典型的例子：你在Spark中调用spark.read.parquet("hdfs://...")，表面看是Spark语法，背后至少涉及三层依赖：

最内层（Java层）：JVM必须正确加载Hadoop Client的jar包（如hadoop-client-3.3.6.jar），且版本与集群匹配；否则抛NoClassDefFoundError；
中间层（Hadoop层）：HDFS的core-site.xml和hdfs-site.xml必须正确配置到Spark的conf/目录下，否则连接超时；
最外层（Spark层）：spark.sql.adaptive.enabled等参数若开启，需YARN ResourceManager有对应资源队列权限，否则任务卡在ACCEPTED状态。

如果跳过Java工程化能力直接冲大数据，就像没学过砌墙就去盖摩天楼——砖（Java语法）你认识，但水泥配比（Maven依赖管理）、钢筋绑扎（Spring事务传播）、承重计算（JVM内存模型）全靠猜。我见过太多人卡在“Spark读HDFS报错”，花三天查Spark日志，最后发现是pom.xml里Hadoop版本写成了3.2.0，而集群是3.3.6，导致org.apache.hadoop.fs.FileSystem类签名不兼容。这种问题根本不在Spark文档里，只在Maven依赖树里。

2.2 阶段划分依据：以“最小可交付功能”为里程碑

我们不用“学完XX天”“掌握XX概念”这种虚指标，而是用能跑通的真实功能定义阶段终点：

阶段一（Java筑基）终点：能独立完成一个带用户注册、登录、订单提交的Spring Boot单体应用，数据库用MySQL，接口用Postman验证，关键要求是所有异常必须有try-catch+日志记录，且能通过日志定位到具体行号。达不到这点，说明连Java最基本的错误处理链路都没打通，后续大数据的复杂异常（如SerializationException）只会更崩溃。
阶段二（工程落地）终点：将上述Spring Boot应用改造成微服务架构，用Nacos做服务发现，Sentinel限流，关键要求是在本地启动两个服务实例，用curl调用时能观察到负载均衡轮询效果，并手动停掉一个实例后调用不中断。这逼你直面网络通信、服务注册、故障转移这些大数据组件天天打交道的基础能力。
阶段三（数据管道成型）终点：用Flume采集Nginx访问日志，存入Kafka，再用Spark Streaming消费Kafka数据，实时统计每分钟IP访问量，结果写入Redis。关键要求是能修改Spark Streaming的batchDuration参数（如从30秒调到10秒），并观察到Redis中计数器更新频率同步变化。这验证你真正理解了“实时”背后的批处理本质。
阶段四（生产环境穿透）终点：将阶段三的Spark Streaming作业打包成jar，提交到某公司测试集群（非本地伪分布），使用YARN client模式运行，关键要求是在YARN Web UI（http://yarn-master:8088）中能清晰看到Application ID、Running Containers数量、以及每个Container的Stderr日志中无ClassNotFoundException。这才是离生产最近的一公里。

提示：所有阶段终点都强调“可观测性”。大数据工程师的核心能力不是写代码，而是让系统状态可看见、可推断、可干预。你看不懂YARN UI里的AM Container内存占用，就永远搞不清为什么Spark Driver OOM。

2.3 为什么拒绝“速成班式”路线：时间成本藏在隐性依赖里

某在线教育平台曾推过“7天搞定Java+Spark”课程，大纲看着很美：Day1 Java基础，Day2 Hadoop，Day3 Spark Core… 结果学员反馈：“Day3写的WordCount在本地IDEA跑通了，但Day4教集群提交时，光配置spark-defaults.conf就花了4小时，最后还是报错”。问题出在哪？隐性依赖没暴露。比如Spark集群提交，至少要提前搞定三件事：

SSH免密登录：Master节点必须能无密码ssh到所有Worker节点，否则spark-submit --master yarn直接失败；
Hadoop环境变量：$HADOOP_CONF_DIR必须指向包含core-site.xml的目录，且该目录权限不能是777（Hadoop会拒绝加载）；
JDK版本一致性：集群所有节点JDK必须同为1.8.0_292（举例），差一个小版本都可能触发Unsupported major.minor version。

这些事不会出现在“Spark API详解”PPT里，但占新手实操时间的60%以上。我们的路线把这类隐性依赖显性化：阶段一就强制要求用Linux虚拟机（推荐Ubuntu 20.04）而非Windows，因为所有大数据组件原生适配Linux；阶段二要求用Docker Compose启动Nacos，而不是下载zip包解压，因为后者会遇到nacos.log权限问题；阶段三的Flume配置，直接提供flume-conf.properties完整模板，连agent.sinks.k1.type = hdfs这种易错拼写都加注释。省下的不是时间，而是挫败感。

3. 四阶段核心细节与实操要点：从代码行到服务器日志的全链路

3.1 阶段一：Java筑基——用“可调试性”倒逼工程规范

这不是Java语法复习，而是用调试能力反向构建工程肌肉记忆。重点不是“你会不会写HashMap”，而是“当HashMap在高并发下扩容失败时，你怎么从线程dump里定位到问题”。

关键动作1：强制使用Lombok + SLF4J
新建Spring Boot项目时，在pom.xml中必须引入：
```
<dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> </dependency>
```
理由：Lombok的@Slf4j注解让日志声明变成一行private static final Logger log = LoggerFactory.getLogger(XXX.class);，避免手写错误；SLF4J而非System.out.println，是因为生产环境日志必须可分级（DEBUG/INFO/WARN）、可重定向（输出到文件而非控制台）。我试过让学员禁用Lombok，结果30%的人在log.info()前忘了初始化Logger对象，报NullPointerException。
关键动作2：异常处理必须带上下文
拒绝这种写法：
```
try { userService.save(user); } catch (Exception e) { log.error("保存失败"); // ❌ 无堆栈、无参数、无法复现 }
```
必须写成：
```
try { userService.save(user); } catch (DataAccessException e) { // ❌ 具体异常类型 log.error("用户保存失败，ID={}, 姓名={}, 原因={}", user.getId(), user.getName(), e.getMessage(), e); // ✅ 参数+堆栈 }
```
实测下来，带参数的日志能让问题定位速度提升5倍。某次线上订单重复创建，就靠log.error("订单创建失败，订单号={}, 用户ID={}, 原因={}", orderNo, userId, e.getMessage())这一行，3分钟锁定是Redis分布式锁超时导致。
关键动作3：用JUnit5写“破坏性测试”
不只测正常流程，更要故意制造失败：
```
@Test void testOrderSubmitWithNullUser() { // 故意传null，验证是否抛IllegalArgumentException assertThrows(IllegalArgumentException.class, () -> orderService.submit(null)); }
```
这逼你思考边界条件。大数据场景中，Kafka消息体为null、HDFS路径不存在、Parquet文件Schema变更——全是常态。习惯写破坏性测试，等于提前给未来的大数据异常打疫苗。

注意：此阶段严禁使用IDEA自动补全的try-catch快捷键！必须手动敲try{...}catch(Exception e){...}，并逐字输入log.error。肌肉记忆比快捷键重要100倍。

3.2 阶段二：工程落地——用容器化绕过90%的环境冲突

为什么不用“直接下载Nacos安装包”？因为你会遇到：

Windows路径分隔符\vs Linux/导致nacos/conf/application.properties读取失败；
JDK版本不一致引发UnsupportedClassVersionError；
nacos.log文件权限不足（Windows无chmod概念）。

Docker Compose方案直接规避：

# docker-compose.yml version: '3.8' services: nacos: image: nacos/nacos-server:v2.2.3 container_name: nacos-standalone environment: - MODE=standalone - JVM_XMS=512m - JVM_XMX=512m volumes: - ./nacos-logs:/home/nacos/logs ports: - "8848:8848"

执行docker-compose up -d，5秒启动。关键技巧：volumes映射日志目录，这样你能在宿主机直接tail -f ./nacos-logs/nacos.log看启动过程，比进容器docker exec -it nacos-standalone bash高效得多。

服务发现实操要点：
Spring Boot服务注册到Nacos，application.yml必须写：
```
spring: cloud: nacos: discovery: server-addr: host.docker.internal:8848 # ⚠️ 关键！Mac/Win用host.docker.internal，Linux用宿主机IP
```
host.docker.internal是Docker Desktop提供的特殊DNS，指向宿主机。如果写成localhost，服务会注册到容器自己的localhost（即Nacos容器内部），其他服务发现不了。这个坑95%的教程不提。
Sentinel限流验证方法：
启动Sentinel Dashboard后，在application.yml中加：
```
spring: cloud: sentinel: transport: dashboard: host.docker.internal:8080 # 同样用host.docker.internal
```
然后用JMeter发100并发请求，打开Sentinel控制台，你会看到：
- “簇点链路”页显示你的Controller方法；
- 点击“流控规则”→新增，QPS阈值设为10；
- 再次压测，观察返回码：超过10的请求返回Blocked by Sentinel（默认行为），证明限流生效。

实操心得：阶段二所有操作必须在Linux虚拟机中完成。Windows用户请用WSL2或VirtualBox装Ubuntu。理由：大数据集群100%是Linux，提前适应vim编辑配置、journalctl -u docker查日志、netstat -tuln | grep 8848查端口占用——这些技能在阶段三会救命。

3.3 阶段三：数据管道成型——用“日志驱动”替代“概念驱动”

别急着背Flink状态后端原理。先搞定一件事：让每条数据流经的每个环节，都能在日志里留下指纹。

Flume采集Nginx日志实操：
flume-conf.properties核心配置：

# agent名必须唯一 a1.sources = r1 a1.sinks = k1 a1.channels = c1 # source：监控Nginx日志文件 a1.sources.r1.type = exec a1.sources.r1.command = tail -F /var/log/nginx/access.log a1.sources.r1.shell = /bin/bash -c # sink：输出到Kafka a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink a1.sinks.k1.kafka.topic = nginx-log a1.sinks.k1.kafka.bootstrap.servers = host.docker.internal:9092 a1.sinks.k1.kafka.producer.acks = 1 # channel：内存channel足够教学用 a1.channels.c1.type = memory a1.channels.c1.capacity = 1000 a1.channels.c1.transactionCapacity = 100 # 绑定source/sink/channel a1.sources.r1.channels = c1 a1.sinks.k1.channel = c1

关键点：kafka.bootstrap.servers用host.docker.internal:9092，因为Flume容器需要访问宿主机上的Kafka（我们用Docker启动Kafka）。启动命令：

flume-ng agent --conf ./conf/ --conf-file ./conf/flume-conf.properties --name a1 -Dflume.root.logger=INFO,console

--Dflume.root.logger=INFO,console确保日志输出到控制台，方便你第一眼看到Successfully started。

Spark Streaming消费Kafka实操：
用Scala写（Java太啰嗦，Scala是Spark官方推荐）：

val spark = SparkSession.builder() .appName("NginxLogAnalysis") .master("local[*]") // 本地模式，无需集群 .config("spark.sql.adaptive.enabled", "false") // 教学阶段关掉自适应查询优化，避免干扰 .getOrCreate() val kafkaParams = Map[String, Object]( "bootstrap.servers" -> "host.docker.internal:9092", "key.deserializer" -> classOf[StringDeserializer], "value.deserializer" -> classOf[StringDeserializer], "group.id" -> "nginx-log-group", "auto.offset.reset" -> "latest", "enable.auto.commit" -> "false" ) val topics = Array("nginx-log") val stream = KafkaUtils.createDirectStream[String, String]( ssc, LocationStrategies.PreferConsistent, ConsumerStrategies.Subscribe[String, String](topics, kafkaParams) ) // 解析Nginx日志（简化版：提取IP和时间） stream.map(record => { val logLine = record.value() val ip = logLine.split(" ")(0) // 第一个空格前是IP val time = logLine.split(" ")(3).drop(1) // [10/Jan/2023:12:34:56 (ip, time) }).map(x => (x._1, 1)) // 转成(IP, 1) .reduceByKey(_ + _) // 按IP聚合 .foreachRDD(rdd => { rdd.foreachPartition(partition => { partition.foreach { case (ip, count) => println(s"IP $ip 访问 $count 次") // 控制台输出，教学用 // 生产环境这里写入Redis：JedisPool.getResource.setex(s"ip:$ip", 3600, count.toString) } }) })

关键技巧：println必须放在foreachPartition内，而不是foreachRDD外，否则只打印一次。这是Spark分区机制的硬知识——新手常在这里卡住，以为代码没跑。

实时性验证方法：
在Nginx日志中手动追加一行：
```
echo '192.168.1.100 - - [10/Jan/2023:12:34:56 +0000] "GET / HTTP/1.1" 200 612' >> /var/log/nginx/access.log
```
3秒内，Spark Streaming控制台应打印IP 192.168.1.100 访问 1 次。如果延迟超过10秒，检查batchDuration参数（默认2000毫秒），调小即可。实时性不是玄学，是可调的数字。

3.4 阶段四：生产环境穿透——用YARN Web UI代替IDEA Debugger

本地跑通≠生产可用。阶段四的目标：让你第一次提交Spark作业到YARN时，不慌。

YARN集群准备（伪分布式，单节点）：
下载Hadoop 3.3.6，解压后配置etc/hadoop/core-site.xml：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> <!-- 必须用localhost，不用127.0.0.1 --> </property> </configuration>

etc/hadoop/hdfs-site.xml：

<configuration> <property> <name>dfs.replication</name> <value>1</value> <!-- 单节点设为1 --> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:/usr/local/hadoop/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:/usr/local/hadoop/data/datanode</value> </property> </configuration>

启动命令：

./bin/hdfs namenode -format # 格式化 ./sbin/start-dfs.sh # 启动HDFS ./sbin/start-yarn.sh # 启动YARN

验证：浏览器打开http://localhost:9870（HDFS UI）和http://localhost:8088（YARN UI），看到Live Nodes为1，说明成功。

Spark on YARN提交实操：
将阶段三的Spark Streaming代码打包成nginx-log-analysis-1.0.jar，上传到Linux服务器。提交命令：
```
spark-submit \ --master yarn \ --deploy-mode client \ --class "com.example.StreamingApp" \ --conf spark.yarn.maxAppAttempts=1 \ --conf spark.sql.adaptive.enabled=false \ nginx-log-analysis-1.0.jar
```
关键参数解释：
- --master yarn：指定YARN为集群管理器；
- --deploy-mode client：Driver在客户端（你当前终端）运行，便于看日志；
- --conf spark.yarn.maxAppAttempts=1：失败不重试，避免YARN UI里堆积多个失败Application；
- --conf spark.sql.adaptive.enabled=false：关掉自适应优化，教学阶段减少干扰。
YARN Web UI诊断三板斧：
提交后，立刻打开http://localhost:8088，找到你的Application，点击进入：
1. 看ApplicationMaster日志：左侧菜单“Logs”→“All Logs”，找stdout和stderr。stderr里若有ClassNotFoundException，说明jar包缺依赖；stdout里若有Starting streaming job，说明Spark Streaming已启动。
2. 看Containers列表：右上角“Containers”标签页，正常应有2个Container：1个AM（ApplicationMaster），1个Executor。如果只有AM，说明Executor启动失败，查AM日志。
3. 看Timeline：底部“Timeline”图表，横轴是时间，纵轴是Container数量。一条水平线代表稳定运行，波浪线代表Container频繁重启。

注意：阶段四所有操作必须在纯Linux环境（无Docker）下进行。因为生产集群就是裸金属服务器，Docker只是阶段二的“学习加速器”，不是生产真相。

4. 常见问题与排查技巧实录：那些文档里找不到的“血泪经验”

4.1 Java阶段高频问题：不是语法错，是环境错

问题现象	排查路径	根本原因	解决方案
`mvn clean install`报`Could not resolve dependencies for project`	`mvn dependency:tree -Dverbose \| grep -i hadoop`	Maven本地仓库中Hadoop相关jar损坏，或镜像源（如阿里云）未同步最新版本	删除`~/.m2/repository/org/apache/hadoop/`目录，换用中央仓库：`mvn clean install -Dmaven.repo.local=/tmp/m2`
Spring Boot启动报`java.lang.IllegalStateException: Failed to load property source from location 'classpath:/application.yml'`	`ls -l src/main/resources/`→`file encoding`	`application.yml`用Windows记事本保存，BOM头导致UTF-8解析失败	用VS Code打开，右下角点击“UTF-8”→“Save with Encoding”→选“UTF-8 without BOM”
JUnit5测试报`org.junit.jupiter.api.extension.ParameterResolutionException: No ParameterResolver registered for parameter`	`mvn test -Dtest=MyTest#myMethod -X`（启用debug）	测试类未加`@ExtendWith(MockitoExtension.class)`，且Mockito版本与JUnit5不兼容	`pom.xml`中统一用`mockito-junit-jupiter:5.5.0`，删掉`mockito-core`

实操心得：Java阶段所有问题，80%出在文件编码、路径分隔符、Maven仓库污染。养成习惯：新建项目后第一件事，用file src/main/resources/application.yml确认编码为UTF-8；第二件事，echo $PATH确认Maven路径在JDK之前；第三件事，mvn clean后立即ls -la ~/.m2/repository/看是否有乱码目录。

4.2 大数据阶段致命陷阱：配置项的“隐形依赖”

问题现象	排查路径	根本原因	解决方案
Flume启动后无日志输出，`ps aux \| grep flume`显示进程存在但`netstat -tuln \| grep 41414`无端口	`jps -l`→ 找到Flume进程PID →`jstack PID > flume.stack`	Flume的`-Dflume.root.logger`参数被IDEA的VM Options覆盖，导致日志输出被重定向到IDEA控制台	启动Flume时用纯命令行，禁用IDEA集成；或在`flume-env.sh`中加`export JAVA_OPTS="-Dflume.root.logger=INFO,console"`
Spark Streaming消费Kafka，控制台一直打印`No new offsets`，无数据处理	`kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic nginx-log --from-beginning`	Kafka Topic无数据，或Producer未正确发送（如Flume未启动，或Nginx日志路径配置错误）	用`kafka-topics.sh --list --bootstrap-server localhost:9092`确认Topic存在；用`kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic nginx-log --time -1`查最新offset
YARN上Spark作业卡在`ACCEPTED`状态，YARN UI显示`AM Container is launched, waiting for AM Container to Register with RM`	`yarn logs -applicationId application_1234567890_0001`	Spark Driver尝试连接YARN ResourceManager，但`yarn.resourcemanager.hostname`配置为`localhost`，而YARN实际监听在`0.0.0.0`	修改`etc/hadoop/yarn-site.xml`： `<property><name>yarn.resourcemanager.hostname</name><value>0.0.0.0</value></property>` 重启YARN

血泪教训：大数据组件的配置项不是孤立的，而是环环相扣的链条。比如YARN的yarn.resourcemanager.hostname，不仅影响Spark，还影响MapReduce、Hive。每次改一个配置，必须用yarn rmadmin -getServiceState rm1验证ResourceManager状态，再用yarn node -list确认NodeManager注册成功，最后才提交作业。跳过验证步骤，90%的问题会放大。

4.3 跨阶段连环故障：当Java的坑遇上大数据的坑

典型场景：Spark读HDFS报java.io.IOException: Failed on local exception: java.io.IOException: Response too long

表象：Spark代码spark.read.text("hdfs://localhost:9000/user/test.txt")报错；
初级排查：hadoop fs -ls hdfs://localhost:9000/能列出文件，说明HDFS正常；
中级排查：spark-shell --master local[*]中执行相同命令，成功！说明Spark本地模式OK；
终极排查：spark-shell --master yarn中执行，失败。此时看YARN UI的AM日志，发现Caused by: java.net.ConnectException: Connection refused (Connection refused)；
根因：Spark on YARN时，Driver运行在YARN Container中，其localhost指向Container内部，而非宿主机。HDFS NameNode监听在宿主机0.0.0.0:9000，但Spark Driver尝试连localhost:9000（即Container的127.0.0.1:9000），当然拒绝；

解法：修改HDFS配置，让NameNode绑定到0.0.0.0（已在hdfs-site.xml中配置），并在Spark代码中用宿主机IP：

// 不用 hdfs://localhost:9000 // 改用 hdfs://192.168.1.100:9000 （你的Linux宿主机IP） spark.read.text("hdfs://192.168.1.100:9000/user/test.txt")

这个案例说明：阶段一的Java网络编程知识（localhost vs 0.0.0.0），在阶段四会以“跨容器网络”形式重现。所以阶段一学的每一个知识点，都不是孤立的，而是未来排障的“弹药”。

5. 工具链与版本选择：为什么这些组合能少踩80%的坑

5.1 Java生态工具链：用“保守版本”换稳定性

工具	推荐版本	选择理由	替代方案风险
JDK	OpenJDK 8u292	Spark 3.x、Hadoop 3.x官方认证最稳版本；JDK11+的`--add-opens`参数在大数据组件中支持不一	JDK17：Flink 1.16需额外配置`--add-opens java.base/java.lang=ALL-UNNAMED`，新手易漏
Maven	3.8.6	兼容所有主流插件；3.9.x对某些老插件（如maven-shade-plugin）有兼容问题	Maven 4.0：尚无稳定大数据生态支持
Spring Boot	2.7.18	Spring Cloud Alibaba 2021.0.5.0的黄金搭档；3.x需升级到Spring Cloud 2022+，Nacos SDK不兼容	Spring Boot 3.2：要求JDK17，与Hadoop 3.3.6冲突

提示：所有工具版本必须从官网下载，禁用Homebrew/MacPorts一键安装。因为这些包管理器常修改默认配置（如Homebrew的Maven会覆盖settings.xml），导致mvn命令行为异常。

5.2 大数据组件版本矩阵：抄作业式选型

组件	推荐版本	关键依赖	版本锁死原因
Hadoop	3.3.6	JDK8, protoc 2.5.0	3.3.x系列对Kerberos支持最完善；3.2.x的YARN Timeline Server有内存泄漏Bug
Kafka	3.4.0	Scala 2.13, ZooKeeper 3.6+	3.4.0修复了KRaft模式下Controller选举失败问题；3.3.x在单节点易假死
Spark	3.3.2	Scala 2.12, Hadoop 3.3.6	Spark 3.3.x与Hadoop 3.3.x的Shaded Hadoop Client完全匹配；3.4.x需Hadoop 3.4+
Flink	1.16.3	Scala 2.12, JDK8	1.16是最后一个支持JDK8的Flink大版本；1.17+强制JDK11

实操原则：所有组件版本号必须精确到小版本（x.y.z），不能写“3.x”或“最新版”。因为Hadoop 3.3.0和3.3.6的RPC协议有细微差异，Spark 3.3.0编译的jar在3.3.6集群上可能ClassNotFoundException。我建议建一个versions.md文件，记录：
- Hadoop: 3.3.6 (sha256: a1b2c3...) - Spark: 3.3.2 (sha256: d4e5f6...) - Kafka: 3.4.0 (sha256: g7h8i9...)

5.3 开发环境配置：让“环境”成为你的队友

Linux发行版选择：Ubuntu 20.04 LTS（非22.04）。理由：Hadoop 3.3.6的官方文档明确标注“Tested on Ubuntu 20.04”，22.04的glibc版本更高，某些C++编译的Hadoop Native Lib会报GLIBC_2.34 not found。

Shell配置：在~/.bashrc中加：

# 快速切换Java版本 export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 alias jdk8='export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64' alias jdk11='export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64' # Maven国内镜像 export MAVEN_OPTS="-Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true"

VS Code必备插件：
- Remote-SSH：直接连Linux服务器写代码，避免Windows/Linux换行符问题；
- Language Support for Java：微软官方，比Eclipse JDT LS更轻量；
- ShellCheck：写Shell脚本时实时提示$?未检查、cd失败未处理等。

最后分享一个技巧：在Linux服务器上，用tmux分屏工作。左屏tail -f /usr/local/hadoop/logs/hadoop-xxx-namenode-xxx.log，右屏vim flume-conf.properties。改完配置，Ctrl+B然后D分离会话，tmux attach回来继续。这种“日志+编辑”双视图，是大数据工程师的日常姿势。

我在某公司带团队时，新入职的工程师前三天任务就是：在Ubuntu 20.04上，用OpenJDK 8u292、Maven 3.8.6、Hadoop 3.3.6、Spark 3.3.2，从零搭建一套能跑通WordCount的YARN集群。不许查文档，只许看日志。三天后，90%的人能独立解决80%的线上问题。因为真正的学习，从来不是记住多少概念，而是亲手把一堆报错日志，翻译成可执行的操作。