简介这是一份面向大数据学习与毕设演示的基础镜像组件包整合Hadoop、Spark、Hive、Tez、Hue及Kafka等常用组件帮助读者在Docker环境中快速搭建可运行的大数据集群环境。资源共22个文件压缩包仅34KB以10个shell脚本为主覆盖集群初始化、服务启动、MySQL初始化等关键环节另有7个XML配置用于调整Hive/Tez/Spark等组件参数并附带Dockerfile与properties配置便于定制基础镜像。这些脚本与配置可大幅减少手工安装和排查时间整体按hadoop、spark、hive、tez、hue等分目录组织层级清晰作者已测试运行成功适用于计科、人工智能、通信工程等专业学生作为课程设计、毕业设计或项目前期演示的参考模板。目前已有141人学习随包提供README文档说明各组件的启动顺序与验证思路读者可结合自身环境扩展组件或修改配置快速收获一套可落地的大数据环境搭建方案。1. 大数据基础镜像到底解决了什么从零装三天到一条命令拉起来先讲一个大多数人都会撞上的场景你拿到一台新服务器要搭一套能跑 Hive SQL、能提 Spark 作业、能开 Hue 看结果的环境。按各路教程装Hadoop 装好了 HDFS 起来了接着装 Spark提交作业时发现它连不上 Hive 的 metastore再把 Hive 的 hive-site.xml 指过去Hue 又找不到 HiveServer2。来回改配置、重启服务两天就没了。这种翻车几乎都出在同一个地方组件是分别装的配置是各自写的互相之间没有对齐。大数据基础镜像组件就是把 Hadoop、Spark、Hive、Tez、Hue 这几个经常要一起用的东西做进同一个 Docker 镜像里。镜像里不只是装了软件还预先写好了组件之间的连接关系、启动顺序、目录规划拉起来就有一套互相能认的基础环境。你再做项目时不用从零搭直接在这套镜像上扩展省掉的是反复装环境的时间。下面我会把这个镜像怎么设计、怎么构建、每个组件的关键参数怎么配、哪些坑是必踩的完整拆一遍。新手能照着复现熟手可以拿走我踩过的坑当参考。2. 先把组件关系理清Hadoop、Spark、Hive、Tez、Hue 在镜像里各扮演什么角色2.1 五个组件在架构里的位置和依赖边界很多人在搭这套环境时第一个误区是不知道这五个组件不是平级关系。Hadoop 是最底层的存储和资源调度平台HDFS 管存储YARN 管资源Spark 和 Hive 都是跑在 YARN 之上的计算框架Tez 是 Hive 的替代执行引擎Hue 是 Web 可视化层它不直接连 HDFS而是连 HiveServer2 去提交 SQL。按这个依赖关系镜像里的启动顺序必须是 HadoopHDFS YARN先起来然后是 Hive 的 metastore再起 HiveServer2最后才是 Hue。Spark 不需要单独启动常驻服务它是以客户端方式向 YARN 提交作业。这个层次不先理清后面配置全都会乱。组件分工表格如下这个表在你排查问题时会反复用到组件核心职能在镜像中的运行方式关键依赖HadoopHDFS 存储 YARN 资源调度常驻服务NameNode / DataNode / ResourceManager / NodeManagerJDK8SSHSpark内存计算引擎以 YARN 模式运行客户端模式通过 spark-submit 提交Hadoop classpath、配置目录HiveSQL 转 MapReduce/Tez 任务的数仓工具metastore 常驻HiveServer2 常驻MySQL/Derby 存储元数据、HDFSTezHive 的 DAG 执行引擎替代 MR库文件放在 HDFS运行时按需拉起容器HDFS、YARNHueWeb 界面查 HDFS 文件、写 HQL、看任务进度常驻 Web 服务默认端口 8888HiveServer2、HDFS2.2 为什么要做单镜像而不是五套独立镜像很多人会问为什么不把五个组件拆成五个镜像用 Docker Compose 编排起来这个问题的答案取决于你的目标。项目标题叫「大数据基础镜像组件」核心诉求是一套开箱即用的基础环境尤其适合离线交付和学习场景拉一个镜像启动一个容器所有服务齐全。拆开做五套镜像的好处是横向扩展灵活但代价是网络、挂载卷、主机名、共享配置全部要预先规划新手起步门槛很高。做单镜像的好处是配置天然共享hive-site.xml 只要一份网络方面不需要容器间通信构建一次可以多次复用。缺点也比较明显所有服务挤在同一份资源里不适合生产大集群但这个镜像的定位本来就是「基础环境、开发调试、学习复现」。我一般建议的做法是开发调试用单镜像后面你真要上生产集群了再拿这套配置做基底把各组件拆到多台机器上而不是一开始就双机三机编排。2.3 目录规划和版本组合怎么定先定版本才能谈配置做镜像之前最先定的不是配置文件而是版本组合。Hadoop、Spark、Hive、Tez 这几个项目之间有编译兼容性问题乱配版本会在运行时出现各种类冲突和方法找不到。业界最常见、也最稳的组合是Hadoop 3.3.x Spark 3.3.x不带 hadoop 版本的预编译包 Hive 3.1.x Tez 0.10.x JDK 8。这个组合我反复验证过Hive 3.1.3 对 Tez 0.10.0 的兼容性比 Tez 0.9.x 好很多Spark 3.3 用 Scala 2.12 版本即可和 Hadoop 3 的 RPC 机制没有兼容问题。JDK 不要上 11Hive 3.1 对 JDK9 的模块化支持不完整会出现反射访问报错这是很多新手踩的第一个大坑。镜像内的目录规划也建议固定成一套比如路径用途/opt/bigdata所有组件的安装根目录/opt/bigdata/hadoop-3.3.6Hadoop 安装目录/opt/bigdata/spark-3.3.2-bin-hadoop3Spark 安装目录/opt/bigdata/hive-3.1.3Hive 安装目录/opt/bigdata/tez-0.10.0Tez 安装目录/opt/bigdata/hue-4.11.0Hue 安装目录/data/hdfsHDFS 名称目录和数据目录/data/hiveHive 元数据库文件使用 Derby 时这套目录设计的好处是把软件和运行数据分开之后做数据卷挂载时可以只挂 /data软件坏了重建镜像不影响数据。3. 构建大数据基础镜像Dockerfile、SSH 免密与启动脚本怎么写3.1 基础层构建选 Ubuntu 还是 CentOSJDK 怎么装现在做这种基础镜像常见基座是 Ubuntu 20.04 或 CentOS 7/8。我倾向 Ubuntu 20.04原因只有一个软件源稳定装依赖时不容易缺包。CentOS 7 的 glibc 版本老Hue 编译出来的动态库有时候会报 GLIBC 版本不够排查起来很痛苦。Dockerfile 的第一段这样写FROM ubuntu:20.04 ARG DEBIAN_FRONTENDnoninteractive ARG HADOOP_VERSION3.3.6 ARG SPARK_VERSION3.3.2-bin-hadoop3 ARG HIVE_VERSION3.1.3 ARG TEZ_VERSION0.10.0 RUN apt-get update apt-get install -y \ openjdk-8-jdk \ ssh \ rsync \ vim \ curl \ net-tools \ mysql-client \ python3 \ python3-pip \ rm -rf /var/lib/apt/lists/*这个基础层有几处要注意。第一openjdk-8-jdk在 Ubuntu 20.04 的源里已经迁到了openjdk-8-jdk-headless如果apt-get install openjdk-8-jdk报找不到包就两个都写上去。第二SSH 必须装Hadoop 的 start-dfs.sh 脚本靠 SSH 登录本机拉起进程没有 SSH 就不能免密启停。第三mysql-client是为后面初始化 Hive 元数据库准备的如果你用内嵌 Derby 可以不要但生产一点的做法是起一个 MySQL 容器来管 Hive 元数据。装完 JDK 后别急着配 Hadoop先做一件容易被忽略的事把 JAVA_HOME 环境变量和 PATH 写进/etc/profile.d/bigdata.sh然后让 Dockerfile 里所有后续 RUN 指令都 source 它。否则后面启动脚本里找不到 java 命令Log 里全是Cannot find Java。3.2 解压组件并处理 Hadoop 对 SSH 免密的依赖基础层完成后下一步是把四个组件的压缩包复制进镜像并解压。这里有一个构建细节不要在 Dockerfile 里用 RUN wget 从外网下载 Hadoop镜像构建时不方便控制下载速度和失败重试。常见做法是先把 tar.gz 包放到与 Dockerfile 同级的packages/目录然后用 COPY 指令带进镜像。COPY packages/hadoop-${HADOOP_VERSION}.tar.gz /tmp/ COPY packages/spark-${SPARK_VERSION}.tgz /tmp/ COPY packages/hive-${HIVE_VERSION}.tar.gz /tmp/ COPY packages/tez-${TEZ_VERSION}.tar.gz /tmp/ COPY packages/hue-${HUE_VERSION}.tar.gz /tmp/ RUN tar -xzf /tmp/hadoop-${HADOOP_VERSION}.tar.gz -C /opt/bigdata/ \ tar -xzf /tmp/spark-${SPARK_VERSION}.tgz -C /opt/bigdata/ \ tar -xzf /tmp/hive-${HIVE_VERSION}.tar.gz -C /opt/bigdata/ \ tar -xzf /tmp/tez-${TEZ_VERSION}.tar.gz -C /opt/bigdata/ \ tar -xzf /tmp/hue-${HUE_VERSION}.tar.gz -C /opt/bigdata/ \ rm -f /tmp/*.tar.gz /tmp/*.tgz解压之后马上做 SSH 免密配置顺序不能反。Hadoop 的启动脚本会执行ssh localhost如果不先配免密脚本会卡在密码输入上导致整个容器起不来。RUN ssh-keygen -t rsa -P -f /root/.ssh/id_rsa \ cat /root/.ssh/id_rsa.pub /root/.ssh/authorized_keys \ chmod 600 /root/.ssh/authorized_keys \ echo StrictHostKeyChecking no /etc/ssh/ssh_config这里唯一的坑是-P 表示空密码有些版本的 ssh-keygen 会提示你重新输入 passphrase在 Dockerfile 里没法交互所以一定要用这个参数。StrictHostKeyChecking no是为了避免首次 ssh 连接时出现 host key 确认提示不然 startup 脚本会中途挂掉。3.3 Hive 与 Tez 的集成把 Tez 库放到 HDFS 是关键一步Hive 切换到 Tez 引擎不只是改一个参数光改hive.execution.enginetez是不够的Tez 的依赖 jar 必须能让运行时的 YARN 容器获取到。这也是很多人改了配置后 Hive 查询半天没反应、最后报Could not find or load main class org.apache.tez...的原因。正确做法是先把 Tez 的完整目录打包上传到 HDFS然后在 tez-site.xml 里告诉 Hive 去 HDFS 路径下找库。# 进入 Tez 目录把整个目录和依赖一起打成 tar 包 cd /opt/bigdata/tez-0.10.0 tar -czf /tmp/tez.tar.gz ./* # 在 HDFS 上建目录并上传 hdfs dfs -mkdir -p /apps/tez-0.10.0 hdfs dfs -put /tmp/tez.tar.gz /apps/tez-0.10.0/这里要特别提一个参数hive.tez.java.opts和tez.container.max.java.heap.fraction。Tez 的 AppMaster 默认会向 YARN 申请容器资源如果 YARN 的yarn.scheduler.maximum-allocation-mb设小了Tez 申请不到足够内存就会一直处于INFO: Session is not yet open状态。这个现象在测试环境出现频率极高第四部分我会讲具体参数怎么配。3.4 容器启动脚本单镜像如何按顺序拉起所有服务镜像内软件装好、配置写好之后还差最后一块拼图启动脚本。单镜像这种方式下docker run的 CMD 不能只是/bin/bash因为这样不会自动启动任何服务。常见做法是提供一个entrypoint.sh按顺序完成格式化、启动 Hadoop、初始化 Hive、启动 HiveServer2、最后拉起 Hue。#!/bin/bash set -e # 第一次启动时格式化 NameNode注意先判断是否已格式化 if [ ! -d /data/hdfs/name/current ]; then echo 初始化 NameNode... $HADOOP_HOME/bin/hdfs namenode -format -force fi # 启动 Hadoop 集群 $HADOOP_HOME/sbin/start-dfs.sh $HADOOP_HOME/sbin/start-yarn.sh # 初始化 Hive 元数据库幂等处理 $HIVE_HOME/bin/schematool -initSchema -dbType derby || echo 元数据库已初始化跳过 # 启动 HiveServer2 和 Metastore 后台进程 nohup $HIVE_HOME/bin/hive --service metastore /data/logs/metastore.log 21 nohup $HIVE_HOME/bin/hive --service hiveserver2 /data/logs/hiveserver2.log 21 # 启动 Spark 历史服务器方便从 Web 界面看任务状态 nohup $SPARK_HOME/sbin/start-history-server.sh /data/logs/spark-history.log 21 # 最后启动 Hue nohup $HUE_HOME/build/env/bin/supervisor -d -p /data/logs/hue-supervisor.log /data/logs/hue.log 21 echo 所有服务启动完成进入容器保持前台运行 tail -f /dev/null这个脚本里有几个值得注意的设计。namenode -format -force用目录是否存在来判断是否格式化避免每次重启容器都重新格式化导致 HDFS 数据丢失。Metastore 和 HiveServer2 用 nohup 启动是合理的因为它们不是 YARN 管理的组件而 Hadoop 自带的 start-dfs.sh 已经用 SSH 把进程 daemon化了不需要 nohup。tail -f /dev/null是容器保持前台运行的惯用写法没有它容器会因为没有前台进程而直接退出。4. 核心配置文件逐个拆解五个组件怎么靠配置文件互相认4.1 Hadoop 三个配置文件的必调参数与常见错配Hadoop 的配置分散在core-site.xml、hdfs-site.xml、yarn-site.xml和mapred-site.xml四个文件里容器模式下最容易出问题的就是路径和权限。先给一套我在单镜像场景下验证过的核心配置。core-site.xml中最关键的是fs.defaultFS它决定了整个集群的默认 HDFS 地址所有组件都要通过它找到 NameNodeconfiguration property namefs.defaultFS/name valuehdfs://localhost:8020/value /property property namehadoop.proxyuser.root.hosts/name value*/value /property property namehadoop.proxyuser.root.groups/name value*/value /property property namehadoop.http.staticuser.user/name valueroot/value /property /configurationhadoop.proxyuser.root.hosts和groups这两个参数是给 Hue 用的。Hue 在提交 Hive SQL 时会以 root 身份代理用户如果不放开代理权限Hue 里执行任何查询都会报Failed to execute session一类的权限错误。hadoop.http.staticuser.user配成 root是让 Web UI 查看 HDFS 文件时不弹登录纯开发环境适用生产不建议这样开。hdfs-site.xml里重点看两个 block size 和副本数。单镜像测试环境把副本数调成 1 就够能省一半磁盘空间configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name valuefile:///data/hdfs/name/value /property property namedfs.datanode.data.dir/name valuefile:///data/hdfs/data/value /property property namedfs.permissions.enabled/name valuefalse/value /property property namedfs.namenode.datanode.registration.ip-hostname-check/name valuefalse/value /property /configurationdfs.permissions.enabled设成 false 对单镜像开发环境来说能省掉大量权限问题比如 Hive 写 warehouse 目录时不会因为属主不对而报 Permission denied。ip-hostname-check必须设成 false 是个典型的容器坑容器网络下 DataNode 的 hostname 解析偶尔和注册 IP 对不上不关掉这个检查的话 DataNode 会一直注册失败在 50070 页面看到 DataNode 数量为 0。yarn-site.xml是单镜像场景下最需要谨慎调整的文件。容器默认能用的 CPU 和内存都有限YARN 如果不设上限默认会按宿主机全部资源计算容器内直接爆掉configuration property nameyarn.resourcemanager.hostname/name valuelocalhost/value /property property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property property nameyarn.scheduler.maximum-allocation-mb/name value8192/value /property property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property property nameyarn.nodemanager.pmem-check-enabled/name valuefalse/value /property /configurationyarn.nodemanager.resource.memory-mb是给 NodeManager 使用的总内存要根据你docker run时的-m参数适配。如果容器内存限制是 8G这里配 8G 或略小都可以如果配超过容器限制任务一跑就会被 OOM killer 杀掉表现为 Spark 作业Container exited with a non-zero exit code 143。vmem 和 pmem 检查在容器里必须关掉因为容器内存不是按虚拟内存概念走的开着会导致 Container 被误杀。这是 Spark on YARN 场景下的经典玄学问题查了一天最后发现是这两行没关。最后是mapred-site.xml这里有一个很多人漏配的mapreduce.application.classpathHadoop 3.x 不配的话 MapReduce / Tez 作业会报找不到依赖configuration property namemapreduce.framework.name/name valueyarn/value /property property namemapreduce.application.classpath/name value$HADOOP_HOME/share/hadoop/common/*:$HADOOP_HOME/share/hadoop/common/lib/*:$HADOOP_HOME/share/hadoop/hdfs/*:$HADOOP_HOME/share/hadoop/hdfs/lib/*:$HADOOP_HOME/share/hadoop/mapreduce/*:$HADOOP_HOME/share/hadoop/mapreduce/lib/*:$HADOOP_HOME/share/hadoop/yarn/*:$HADOOP_HOME/share/hadoop/yarn/lib/*/value /property /configuration4.2 Hive 切换到 Tez 引擎hive-site.xml 与 tez-site.xml 的呼应关系Hive 的配置核心是hive-site.xml。在这个单镜像里最少需要三个必配项元数据库连接、执行引擎、warehouse 目录。property namejavax.jdo.option.ConnectionURL/name valuejdbc:derby:;databaseName/data/hive/metastore_db;createtrue/value /property property namehive.metastore.warehouse.dir/name valuehdfs://localhost:8020/user/hive/warehouse/value /property property namehive.execution.engine/name valuetez/value /property property namehive.server2.thrift.bind.host/name value0.0.0.0/value /property property namehive.server2.thrift.port/name value10000/value /property元数据库这里用的是 Derby 内嵌模式。生产上把 Derb y 换成 MySQL 是必须的但单镜像测试场景用 Derby 的好处是零外部依赖这也是为什么 Dockerfile 里只装了个 mysql 客户端。 Derby 在单镜像场景有个使用注意不要两个进程同时打开同一个 derby 数据库metastore 和 HiveServer2 如果都走内嵌模式会锁库所以镜像里只让 metastore 进程持有 derby 连接HiveServer2 通过 thrift 协议连 metastore 即可。写法就是上面启动脚本里先单独起 metastore再起 hiveserver2。hive.server2.thrift.bind.host写 0.0.0.0 是为了让 Hue 容器能从外部访问 HiveServer2如果只写 localhost你在宿主机上做端口映射也连不上。Tez 侧的配置不要全丢进 hive-site.xml单独做一个tez-site.xml更清晰Hive 会自动读它configuration property nametez.lib.uris/name valuehdfs://localhost:8020/apps/tez-0.10.0/tez.tar.gz/value /property property nametez.container.max.java.heap.fraction/name value0.4/value /property property nametez.am.resource.memory.mb/name value2048/value /property property nametez.task.resource.memory.mb/name value2048/value /property /configurationtez.lib.uris的值必须和 HDFS 上实际路径保持一致路径写错不会立刻报错而是 Tez 会话创建时卡很久再失败。tez.container.max.java.heap.fraction是容器内 JVM 堆占容器内存的比例默认 0.8调成 0.4 给 native 内存和系统库留出空间不然容器内存容易被打满。tez.am.resource.memory.mb的 2048 要和 YARN 的单容器最大分配值匹配如果 YARN 允许的最大内存是 1024这里申请 2048 会直接失败。4.3 Spark 连 Hive 元数据三个必须对齐的参数Spark 在镜像里不是常驻服务而是靠客户端提交作业。它要访问 Hive 表就必须知道 Hive 的元数据在哪。完全不配置时 Spark 默认用自带的嵌入式元数据会看到你明明在 Hive 里建了表Spark SQL 里查却报 table not found。在$SPARK_HOME/conf/spark-defaults.conf里加三行spark.masteryarn spark.sql.warehouse.dirhdfs://localhost:8020/user/hive/warehouse spark.sql.hive.metastore.version3.1.3 spark.sql.hive.metastore.jarsmavenspark.masteryarn是提交模式这样 Spark 的 executor 会由 YARN 调度。spark.sql.warehouse.dir必须和 Hive 的 warehouse 目录一致否则两边建的表文件落在不同目录互相看不到数据。spark.sql.hive.metastore.version要和镜像内安装的 Hive 版本严格一致如果 Hive 是 3.1.3这里写 3.1.3只写大版本号 3.1Spark 会用错误的连接器启动时直接报 Unsupported Hive version。spark.sql.hive.metastore.jars三选一maven、builtin、路径。离线环境不能选 maven它会去网上下载依赖正确做法是把这个值指向 Hive 安装目录下的 lib 包集合。写成 maven 只适合镜像构建时可以联网的开发环境。所以上面的配置写 maven 是演示默认值离线场景改成spark.sql.hive.metastore.jars$HIVE_HOME/lib/*4.4 Hue 连接 HiveServer2 的配置与端口约定Hue 是所有组件里最容易被配置打倒的。它的配置文件是desktop/conf/hue.ini修改完后必须编译并重启 supervisor。配置核心是两段一段是告诉 Hue 去哪里找 HiveServer2另一段是让 Hue 能访问 HDFS。[hue] secret_keyyour_secret_key_change_me http_port8888 [beeswax] hive_server_hostlocalhost hive_server_port10000 hive_conf_dir/opt/bigdata/hive-3.1.3/conf [hadoop] [[hdfs_clusters]] [[[default]]] fs_defaultfshdfs://localhost:8020 webhdfs_urlhttp://localhost:9870/webhdfs/v1 [[yarn_clusters]] [[[default]]] resourcemanager_hostlocalhost resourcemanager_port8088hive_server_host指向 HiveServer2 所在地址单镜像里就是 localhost。这里有个非常隐蔽的坑Hue 连接 HiveServer2 时会尝试读取hive_conf_dir下的配置文件如果 Hue 运行时用户的权限不够读不了 hive-site.xml就会报Could not connect to HiveServer2。所以镜像里跑 Hue 的进程要么是 root要么把 Hive 的 conf 目录权限放开到 755。Hue 的 Http 端口固定 8888docker run 做端口映射时-p 8888:8888即可。webhdfs_url里的 9870 是 Hadoop 3.x 的 NameNode Web UI 端口注意 Hadoop 2.x 是 50070这个端口写错会导致 Hue 的文件浏览器打不开。5. 必踩的 5 个坑现象、原因和解决办法5.1 容器重启后 HDFS 一直处于 SafeMode上传和查询全部超时构建完镜像第一次启动一切正常结果用docker restart重启容器后执行hdfs dfs -ls /一直卡住日志里反复提示NameNode is in safe mode。原因是 NameNode 启动时先进入安全模式要等 DataNode 上报足够多的数据块才自动退出。容器重启后 DataNode 重新注册需要时间安全模式退出比平时慢。解决方法是先手动看状态再决定是否强制退出hdfs dfsadmin -safemode get hdfs dfsadmin -safemode leave但根本问题是为什么每次都进安全模式还不退。检查发现是 DataNode 的 storage 目录因为容器重启后 hostname 变化和 NameNode 里的记录对不上导致 DataNode 反复连接失败。解决办法是启动脚本里在 DataNode 启动前清理旧的 DataNode 注册信息rm -rf /data/hdfs/data/current这个操作要慎重只适用于测试环境生产环境绝不能删数据目录。5.2 Hue 界面显示无法连接 HiveServer2但 beeline 本地能连上现象是宿主机上用 beeline 连jdbc:hive2://localhost:10000正常但 Hue 页面执行 SQL 时提示Cannot connect to HiveServer2 at localhost:10000。原因有两层。第一层是 HiveServer2 进程确实起来了但只监听了 IPv6 的 localhostHue 用了 IPv4 去连。解决办法是 hive-site.xml 里hive.server2.thrift.bind.host必须写 0.0.0.0 而不是 localhost。第二层是 Hue 启动时使用的是它自己环境里的 Python里面少了 thrift 相关模块报错被吞到日志里。如果你在日志里看到ImportError: No module named thrift就重新编译一次 Hue 的虚拟环境cd /opt/bigdata/hue-4.11.0 make clean make installHue 的 Python 环境是它自己用 build/env 管理的和系统 Python 隔离。很多发行版的 Hue 包依赖系统 python 模块不完整自编译是最稳妥的路。编译时会下载大量依赖确保镜像构建阶段网络通畅否则会把构建时间从 10 分钟拖到 1 小时。5.3 Spark 作业提交到 YARN 后 Container 总是被杀退出码 143spark-submit提交后任务跑起来不到一分钟就失败YARN 日志里能看到Container exited with a non-zero exit code 143。143 这个数字是 SIGTERM 的 shell 码表示容器是被主动终止的不是代码抛异常。原因是 YARN 的虚拟内存检查机制。容器内进程的物理内存不高但 JVM 的虚拟内存映射大NodeManager 检查时发现虚拟内存超出上限就直接杀。解决方式就是在 yarn-site.xml 里关闭 vmem 检查。之前写过的yarn.nodemanager.vmem-check-enabledfalse就是治这个。如果你不想全关可以把yarn.nodemanager.vmem-pmem-ratio从默认 2.1 调高到 4.0但测试环境我更推荐直接关省得排查时还要换算内存比例。5.4 Hive 查询卡在 Session is not yet open等了 10 分钟才报错Tez 模式下执行 Hive SQL 后日志一直停在INFO: Session is not yet open10 分钟后才报超时。很多人以为 Hive 卡死了其实是 Tez 在向 YARN 申请 ApplicationMaster 容器时被拒绝了。原因是tez.am.resource.memory.mb配了 2048但yarn.scheduler.maximum-allocation-mb只给了 1024。YARN 会拒绝所有超过最大分配值的容器请求。排查确认方法是在 YARN ResourceManager 的 8088 页面看 Application 状态通常能看到Application is rejected by queue或诊断里写内存超限。解决办法是把两边对齐# 把 tez-site.xml 里 AM 内存调成最大值以内 sed -i s/tez.am.resource.memory.mb value2048/tez.am.resource.memory.mb value1536/ tez-site.xml另外也可能是yarn.app.mapreduce.am.resource.mb设置了不合理的值牵制了队列。检查 YARN 的 capacity-scheduler 配置的yarn.scheduler.capacity.maximum-am-resource-percent默认 0.5 意味着一半集群资源可以被 AM 占用如果集群总内存只有 2GAM 实际拿不到多少。测试环境把这值调高到 0.8 能减少 AM 被反复拒绝的概率。5.5 Spark SQL 读 Hive 表报 java.lang.NoSuchMethodError 或 Unsupported Hive versionSpark 启动时能正常执行show databases但一旦执行select count(*) from 某张hive表报错java.lang.NoSuchMethodError: org.apache.hadoop.hive.metastore.api.Table.getRequiredParameters。原因非常典型Spark 内部带的 Hive metastore 版本和外部 Hive 版本不一致。Spark 3.3 默认内置 Hive 2.3而你镜像里的 Hive 是 3.1.3两者在 metastore 协议上有方法签名变化。解决办法是前面说的spark.sql.hive.metastore.version和spark.sql.hive.metastore.jars配到一致。如果配了还报错检查spark.sql.hive.metastore.jars是否真正生效了spark-submit --conf spark.sql.hive.metastore.jars$HIVE_HOME/lib/* --conf spark.sql.hive.metastore.version3.1.3 --repositories 你的本地仓库路径还有一类隐蔽情况是你用了spark-shell --packages拉别的依赖时间接把低版本的 hive metastore 包带进了 classpath。这种只能通过spark-submit --verbose看实际加载的 jar 列表确认没有任何 hive-exec-2.x 出现在加载路径里。6. 端到端验证怎么证明这套镜像真的能用6.1 三步健康检查进程、端口、数据写入构建完镜像后不要急着跑业务先花一分钟做健康检查。第一步看进程进入容器执行jps预期能看到这些关键进程rootcontainer:~# jps 1234 NameNode 2345 DataNode 3456 ResourceManager 4567 NodeManager 5678 HiveMetaStore 6789 HiveServer2 789 RunJar第二步看端口重点确认需要对外暴露的端口在监听状态。Hue 8888、HiveServer2 10000、NameNode 9870、YARN 8088。第三步是数据写入验证这个比看进程更可靠hdfs dfs -mkdir -p /tmp/test hdfs dfs -put /etc/hosts /tmp/test/ hdfs dfs -cat /tmp/test/hosts | head -5如果数据能写入能读回HDFS 这一层就是通的。注意观察/tmp/test目录是否产生了_SUCCESS之类的临时文件残留如果有说明写入过程中 Checkpoint 或 OutputCommiter 机制出了问题需要进一步看 DataNode 日志。6.2 端到端跑一遍 HQL 和 Spark SQL验证 Hive Tez Spark 三者连接验证完 HDFS下一步是通过 Hive 建表写入数据再用 Spark SQL 读同一张表。这个流程能证明所有组件的连接关系都正常。先进入 Hive 的 beeline 执行CREATE DATABASE IF NOT EXISTS test_db; USE test_db; CREATE TABLE IF NOT EXISTS user_click ( user_id INT, click_time STRING, page_url STRING ) ROW FORMAT DELIMITED FIELDS TERMINATED BY \t STORED AS TEXTFILE; INSERT INTO user_click VALUES (1, 2025-01-01 10:00:00, /home), (2, 2025-01-01 10:05:00, /search);执行完INSERT后不要立刻退出先确认 Tez 引擎确实被调用了。看 beeline 的执行日志里如果出现DAG相关的任务描述说明走的是 Tez如果显示 MapReduce 字样则说明执行引擎没切过来。这里有个细节SET hive.execution.enginetez;只能在当前会话生效要全局生效必须确保 hive-site.xml 里的配置是对的。然后再用 Spark SQL 从同一张表读数据验证元数据共享正常spark-sql --master yarn --conf spark.sql.hive.metastore.version3.1.3 \ --conf spark.sql.hive.metastore.jars$HIVE_HOME/lib/* \ -e SELECT page_url, COUNT(*) FROM test_db.user_click GROUP BY page_url;如果这步能正常返回聚合结果说明三条链路全部打通HDFS 存储正常、Hive 元数据正常、Spark on YARN 正常。6.3 把这个镜像变成项目基础镜像进阶用法端到端验证通过后镜像就可以作为「基础镜像」使用了。所谓基础镜像就是别人以后做具体项目时FROM 这个镜像在上面继续加自己的业务代码、依赖库、调度脚本而不需要重复面对 Hadoop 生态的配置问题。我自己的习惯是把镜像 tag 成bigdata/base:3.3.6这种带版本号的形式然后在项目的 Dockerfile 里写上FROM bigdata/base:3.3.6 COPY my-job.jar /opt/app/ COPY run.sh /opt/app/run.sh这样的好处是 Hadoop、Spark、Hive 这几个重组件只构建一次后续业务迭代都基于同一个稳定底座。版本升级也很清爽只改镜像 tag 即可。还有一个经验是镜像做好后导出一份保留离线安装包避免团队换台机器就要重新在线拉取基础工具依赖。构建一次基础镜像的时间成本不低离线分发能帮团队省不少时间。这套做下来最后最让我放心的验证方式其实就一句话拉镜像、起容器、跑一遍端到端三分钟内能看到聚合结果这个基础环境就可以交给项目组使用了。环境问题是最不该消耗业务时间的地方把这一步做好后面所有上层项目都会受益。希望帮到你。本文还有配套的精品资源点击获取