JDK 17 + Hadoop 3.3.5 + Spark 3.3.2 集群搭建:从虚拟机克隆到圆周率计算的保姆级避坑实录
JDK 17 + Hadoop 3.3.5 + Spark 3.3.2 集群搭建实战:从虚拟机克隆到圆周率计算的深度避坑指南
当你第一次尝试在CentOS 8.5上搭建基于JDK 17的大数据环境时,可能会被各种报错信息淹没。本文将带你完整走一遍从虚拟机准备到成功运行Spark圆周率计算的实战过程,重点不是简单的步骤罗列,而是那些教科书上不会告诉你的"坑"和解决方案。无论你是想学习大数据技术栈的开发者,还是需要快速搭建测试环境的技术人员,这份指南都能帮你节省大量排查问题的时间。
1. 环境准备:虚拟机与JDK 17的配置陷阱
1.1 虚拟机初始化的隐藏问题
选择CentOS 8.5作为基础系统时,有几个关键点需要注意:
磁盘空间分配:官方建议20GB,但实际使用中,特别是需要运行多个服务时,至少需要40GB空间。否则在后续Hadoop运行中可能遇到
No space left on device错误。内存配置:4GB内存是最低要求,如果计划同时运行多个节点服务,建议调整为8GB。可以通过以下命令检查内存使用情况:
free -h- 网络模式:使用桥接模式而非NAT,确保各节点间能够互相访问。错误的网络配置会导致后续节点通信失败。
1.2 JDK 17安装的特殊注意事项
在Hadoop 3.3.5和Spark 3.3.2环境中使用JDK 17需要特别注意兼容性问题:
# 安装后验证Java版本 java -version常见问题及解决方案:
- 模块系统访问警告:JDK 9+引入了模块系统,可能导致Hadoop报错。解决方法是在
/etc/profile中添加:
export HADOOP_OPTS="--add-opens java.base/java.lang=ALL-UNNAMED"- 环境变量配置:确保
JAVA_HOME指向正确的JDK 17路径。一个验证方法是:
echo $JAVA_HOME提示:如果遇到
Permission denied错误,检查是否使用了root用户或适当权限。
2. 集群基础配置:SSH互信与网络设置
2.1 虚拟机克隆后的必要调整
克隆虚拟机后,必须修改以下配置以避免冲突:
主机名修改:
hostnamectl set-hostname master # 主节点 hostnamectl set-hostname vice1 # 从节点1网络配置重置:
rm -f /etc/udev/rules.d/70-persistent-net.rules systemctl restart NetworkManager
2.2 SSH免密登录的完整流程
实现节点间无密码访问是集群工作的基础,以下是详细步骤:
生成密钥对:
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa合并公钥到授权文件:
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys测试连接:
ssh master date # 从任意节点测试
常见问题排查表:
| 错误现象 | 可能原因 | 解决方案 |
|---|---|---|
| 仍需输入密码 | authorized_keys权限错误 | chmod 600 ~/.ssh/authorized_keys |
| Connection refused | SSH服务未启动 | systemctl start sshd |
| Host key verification failed | 已知主机记录冲突 | 删除~/.ssh/known_hosts中对应条目 |
3. Hadoop 3.3.5集群部署实战
3.1 关键配置文件解析
Hadoop的配置文件位于$HADOOP_HOME/etc/hadoop/目录下,以下是核心配置项:
core-site.xml:
<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://master:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/hadoop-3.3.5/tmp</value> </property> </configuration>hdfs-site.xml需要特别注意:
<property> <name>dfs.namenode.http-address</name> <value>master:9870</value> <!-- 注意端口变化 --> </property>3.2 启动过程中的典型错误
错误1:start-all.sh报权限相关错误
解决方案:在每台节点的/etc/profile中添加:
export HDFS_NAMENODE_USER=root export HDFS_DATANODE_USER=root export YARN_RESOURCEMANAGER_USER=root错误2:NameNode无法启动
排查步骤:
- 检查日志文件:
tail -n 100 $HADOOP_HOME/logs/hadoop-*-namenode-*.log - 确保已经格式化NameNode:
hdfs namenode -format
注意:格式化操作会清除所有HDFS数据,仅应在首次启动或需要重置时执行。
4. Spark on YARN集成配置
4.1 Spark与Hadoop的版本匹配
必须使用与Hadoop兼容的Spark版本。对于Hadoop 3.3.5,应选择"without Hadoop"的Spark包,然后手动配置类路径:
export SPARK_DIST_CLASSPATH=$(/opt/hadoop-3.3.5/bin/hadoop classpath)4.2 spark-defaults.conf关键配置
spark.master yarn spark.eventLog.enabled true spark.eventLog.dir hdfs://master:9000/spark-eventlog spark.serializer org.apache.spark.serializer.KryoSerializer常见配置错误:
- 端口不一致(如HDFS使用9000而Spark配置8020)
- 路径权限问题(确保HDFS中存在
/spark-eventlog目录)
4.3 圆周率计算任务排错
运行测试任务:
spark-submit --master yarn --class org.apache.spark.examples.SparkPi \ $SPARK_HOME/examples/jars/spark-examples_2.12-3.3.2.jar 100可能遇到的问题及解决:
ClassNotFound异常:
- 检查
SPARK_DIST_CLASSPATH配置 - 确认Hadoop类路径包含所有必要jar包
- 检查
连接拒绝:
- 验证YARN ResourceManager是否正常运行
- 检查防火墙状态和端口访问
日志查看技巧:
yarn logs -applicationId <app_id> | less
5. 性能调优与监控
5.1 内存配置优化
Hadoop和Spark都是内存密集型框架,合理的内存分配至关重要:
| 组件 | 配置参数 | 建议值 (8GB内存节点) |
|---|---|---|
| YARN | yarn.nodemanager.resource.memory-mb | 6144 (6GB) |
| Spark | spark.executor.memory | 2g |
| Spark | spark.driver.memory | 1g |
5.2 监控工具使用
HDFS Web UI:
http://master:9870- 检查DataNode存活状态
- 监控存储空间使用情况
YARN ResourceManager:
http://master:8088- 查看任务执行情况
- 分析资源利用率
Spark History Server:
$SPARK_HOME/sbin/start-history-server.sh访问地址:
http://master:18080
6. 日常维护与问题快速定位
6.1 常用诊断命令
检查HDFS健康状态:
hdfs dfsadmin -report查看YARN节点:
yarn node -listSpark应用列表:
yarn application -list
6.2 日志分析技巧
所有组件的日志文件位置:
| 组件 | 日志路径 |
|---|---|
| Hadoop | $HADOOP_HOME/logs/ |
| YARN | $HADOOP_HOME/logs/ |
| Spark | $SPARK_HOME/logs/ |
关键日志文件命名模式:
hadoop-<user>-<daemon>-<hostname>.logspark-<user>-org.apache.spark.deploy.<role>-<appid>-<hostname>.log
在集群运行过程中,最耗时的往往不是配置本身,而是各种环境差异导致的问题排查。建议每次修改配置后记录变更,并使用版本控制系统管理配置文件。当遇到难以解决的问题时,先检查基础环境(网络、权限、资源),再分析组件日志,这种自底向上的排查方法通常最有效。
