去Hive的Spark包：Hive on Spark调试利器与配置指南

简介：这份资源是 Spark 2.3.0 面向 Hadoop 2.x 生态的 without-hive 发行包，面向已具备一定大数据基础、希望在不依赖 Hive JAR 包的前提下用 Spark 处理 Hive 数据的开发者与运维人员。其核心价值在于精简依赖：用户可自行补充 Hive 依赖并配置 metastore 地址，实现 Hive on Spark，适合已有独立 Hive 集群或只需借用 Spark 计算能力的场景。压缩包为 tgz 格式，共 867 个文件，约 127.77MB，内含 235 个 py、187 个 scala、125 个 java 源码及 109 个 jar 依赖，另有 sh、cmd 启动脚本与 template、json、parquet、orc 等配置和示例数据，目录结构完整，便于查阅源码、调试运行与二次配置。目前已有 660 人学习下载，可作为搭建 Spark 与 Hive 集成环境的参考包。

1. 一个“去 Hive”的 Spark 包，为什么反而成了 Hive on Spark 的调试利器

手里这个spark-2.3.0-bin-hadoop2-without-hive，名字直白得有点反常：Spark 2.3.0、Hadoop 2.x 预编译、偏偏把 Hive 相关 jar 剥掉了。第一次看到它的人多半会犯嘀咕——做 Hive on Spark 的人不是应该找带 Hive 的包吗？恰恰相反，这个“缺一块”的发行版在排查 Hive on Spark 执行引擎问题时特别好用。原因很实在：Hive on Spark 跑起来时，Hive 自己会往 Spark 的 classpath 里塞它那一套 Hive jar，如果 Spark 发行包再自带一份，版本一冲突，报错信息能绕得你怀疑人生。这个包把 Spark 侧的 Hive 依赖清空，等于把“谁提供 Hive 库”这件事的主动权交回给 Hive 端，冲突面一下子收窄。它适合正在搭 Hive on Spark、被 jar 冲突和类加载顺序折腾过的从业者，也适合想单独验证 Spark 核心引擎、不想被 Hive 元数据服务牵连的场景。下面按“它到底是什么 → 怎么配起来 → 坑在哪 → 怎么验证”走一遍。

2. 拆开这个包：without-hive 到底去掉了什么

2.1 发行包结构与 Hive 依赖的剥离逻辑

拿到压缩包先别急着解压到生产目录，找个临时路径展开看一眼目录骨架。Spark 2.3.0 的二进制发行版结构是固定的：bin/放启动脚本，sbin/放集群管理脚本，jars/是全部运行时依赖，conf/放配置模板，examples/和data/是示例。这个包的特殊之处全在jars/里——正常发行版会带hive-exec、hive-metastore、hive-common这一串，以及spark-hive_2.11这个集成模块；without-hive 版本把这些清掉了，但保留了 Spark SQL 的 catalyst、core、sql 等核心 jar。

# 解压到临时目录，先看结构再决定部署位置 tar -xzf spark-2.3.0-bin-hadoop2-without-hive.tgz -C /opt/tmp/ cd /opt/tmp/spark-2.3.0-bin-hadoop2-without-hive # 统计 jar 数量，和带 hive 的包对比能直观看出差异 ls jars/ | wc -l # 确认 Hive 相关 jar 是否真的不存在 ls jars/ | grep -i hive

最后一条命令如果没有任何输出，说明剥离是干净的；如果还能看到spark-hive之类，那这个包就不是你以为的那个包，得回头核对来源。ls jars/ | wc -l的数值本身没有绝对意义，但和同版本带 Hive 的包一比，差值基本就是被剥掉的那批依赖，心里有个数。

这里要理解一个关键点：Spark 的spark-hive模块提供的是HiveContext以及和 Hive 元数据交互的桥接代码，而hive-exec这些是 Hive 自己的执行库。Hive on Spark 的架构里，Hive 作为客户端提交任务，Spark 作为执行引擎，Hive 端通过hive-exec里的SparkTask等类去驱动 Spark。所以执行引擎侧其实不需要自带 Hive 执行库，它只需要 Spark 核心。这个包正是按这个分工裁的。

2.2 为什么 Hive on Spark 场景反而该选它

Hive on Spark 的官方配置里有一组关键参数，hive.execution.engine=spark，以及spark.master、spark.home、spark.executor.memory这些。Hive 启动 Spark 任务时，会把spark.home指向的目录下的jars/全部加入 classpath，同时 Hive 自己的 lib 目录也在 classpath 上。如果 Spark 发行包自带 Hive jar，就会出现两份hive-exec、两份hive-common，类加载器先加载哪一份取决于顺序，行为不可预测。

常见做法是：执行引擎用 without-hive 的 Spark 包，Hive 端保证hive-exec等库版本一致，让 Hive 成为 Hive 库的唯一提供方。这样版本对齐只需要在一个地方做，出问题也好定位。我一般会在部署前把两边的 Hive 版本号列出来对一遍：

检查项	命令	期望结果
Spark 侧是否残留 Hive jar	ls $SPARK_HOME/jars/ | grep -i hive	无输出
Hive 侧 hive-exec 版本	ls $HIVE_HOME/lib/ | grep hive-exec	单一版本
Spark 版本	cat $SPARK_HOME/RELEASE	2.3.0
Hadoop 依赖版本	ls $SPARK_HOME/jars/ | grep hadoop	2.x 系列

这张表看着简单，但它是后面所有排查的基线。版本对不齐的时候，先别改配置，先把这张表填对。

2.3 解压部署与基础环境变量

确认结构没问题后，把包放到正式路径，配好环境变量。Spark 2.3.0 依赖 JDK 8，JDK 9 及以上会有模块系统相关的兼容问题，这一点在 2.3.x 上尤其明显，别在这上面省事。

# 部署到正式目录 mv /opt/tmp/spark-2.3.0-bin-hadoop2-without-hive /opt/spark # 写入环境变量，注意 SPARK_HOME 要和 Hive 端 spark.home 保持一致 cat >> /etc/profile.d/spark.sh <<'EOF' export SPARK_HOME=/opt/spark export PATH=$SPARK_HOME/bin:$PATH export JAVA_HOME=/usr/lib/jvm/java-8-openjdk EOF source /etc/profile.d/spark.sh # 验证基础可用性，不涉及 Hive $SPARK_HOME/bin/spark-submit --version

spark-submit --version能正常打印版本信息，说明 Spark 核心和 JDK 是通的。这一步不碰 Hive，是故意的——先把执行引擎单独验证通过，再引入 Hive 端，出问题时才能判断是新引入的部分还是原本就有问题。JAVA_HOME指向 JDK 8 的路径按实际机器改，别照抄。

3. 把 Hive on Spark 接起来：配置项与提交链路

3.1 hive-site.xml 里的执行引擎参数

Hive 端要告诉 Hive“用 Spark 跑”，核心就几行配置。这些配置写在$HIVE_HOME/conf/hive-site.xml里，或者通过hive --hiveconf临时传。生产上建议写进配置文件，临时传参只用于验证。

<configuration> <!-- 指定执行引擎为 Spark --> <property> <name>hive.execution.engine</name> <value>spark</value> </property> <!-- 指向 without-hive 的 Spark 安装目录 --> <property> <name>spark.home</name> <value>/opt/spark</value> </property> <!-- 集群模式，按实际资源管理器调整 --> <property> <name>spark.master</name> <value>yarn</value> </property> <!-- 执行器内存，按数据量和队列资源调 --> <property> <name>spark.executor.memory</name> <value>4g</value> </property> <!-- 每个执行器核数，影响并发度 --> <property> <name>spark.executor.cores</name> <value>2</value> </property> </configuration>

spark.home必须指向 without-hive 包的根目录，Hive 会去这个目录下找jars/和bin/。spark.master写yarn表示交给 YARN 调度，如果只是本地验证可以写local[2]，但本地模式测不出资源相关的问题。spark.executor.memory和spark.executor.cores是最容易拍脑袋填的两个参数，填大了队列排不上，填小了任务 OOM 或跑得慢，建议先按队列的常规配额来，跑通再调。

3.2 用 spark-submit 验证执行引擎独立可用

在接 Hive 之前，先用这个包跑一个纯 Spark 任务，确认执行引擎本身没问题。这一步能排除掉“Spark 包损坏”“JDK 不兼容”“YARN 队列权限”这类和 Hive 无关的干扰。

# 用自带的示例 jar 跑 Pi 估算，纯计算，不碰 Hive $SPARK_HOME/bin/spark-submit \ --class org.apache.spark.examples.SparkPi \ --master yarn \ --deploy-mode client \ --executor-memory 2g \ --num-executors 2 \ $SPARK_HOME/examples/jars/spark-examples_2.11-2.3.0.jar \ 10

--master yarn和 Hive 配置里的spark.master保持一致，避免两边行为不同。--deploy-mode client在验证阶段方便看日志，生产上按需改 cluster。10是 Pi 估算的切片数，只是示例参数。跑通会看到Pi is roughly 3.14...，跑不通就看 YARN 的 application 日志，错误信息通常在stderr里。

这一步过了，说明 without-hive 包作为执行引擎是健康的，接下来接 Hive 才有意义。

3.3 从 Hive CLI 提交第一个 Spark 任务

执行引擎验证通过后，进 Hive 提交一个简单查询，观察它是否真的走了 Spark。最直接的办法是看 Hive 日志里有没有 Spark 相关的提交信息，以及 YARN 上有没有对应的 application。

-- 在 hive CLI 里执行，先建个测试表 CREATE TABLE IF NOT EXISTS test_spark_engine (id INT, name STRING) STORED AS ORC; INSERT INTO test_spark_engine VALUES (1, 'a'), (2, 'b'), (3, 'c'); -- 这个查询会触发 Spark 执行引擎 SELECT count(*) FROM test_spark_engine;

执行SELECT时，Hive 会通过spark.home找到 Spark，提交一个 Spark 任务。如果配置正确，YARN 上能看到新 application，Hive 日志里会有SparkTask相关的记录。如果查询秒回且没有 YARN application，那多半是走了本地模式或者根本没切到 Spark 引擎，回头检查hive.execution.engine是否生效——用set hive.execution.engine;在 CLI 里确认当前值。

INSERT INTO在 Hive on Spark 下也会走 Spark 执行，所以这一步同时验证了读写两条链路。ORC 格式是 Hive 场景的常规选择，换成 TEXTFILE 也能测，但 ORC 更接近真实使用。

4. 踩坑记录：jar 冲突、类加载与资源参数

4.1 现象：启动即报 NoClassDefFoundError

现象是 Hive 提交 Spark 任务时直接抛NoClassDefFoundError，类名指向某个 Hive 内部类，比如org.apache.hadoop.hive.ql.exec.Utilities。原因通常是 Hive 端的hive-exec没有正确进入 Spark 执行器的 classpath，或者版本和 Hive 客户端不一致。without-hive 包本身不提供这些类，全靠 Hive 端注入，注入链路一断就报这个。

解决分两步：先确认$HIVE_HOME/lib/hive-exec-*.jar存在且只有一个版本；再确认 Hive 提交时确实把这个 jar 分发到了执行器。可以在hive-site.xml里显式加spark.yarn.jar或通过spark.executor.extraClassPath指定，但更稳妥的做法是保证 Hive 端 lib 目录干净、版本单一，让 Hive 自己的分发机制生效。多个hive-exec版本共存时，先删掉旧的再试。

4.2 现象：类冲突报错，两个同名类来自不同 jar

现象是运行时报IllegalAccessError或LinkageError，提示某个类在两个 jar 里都有。原因就是 classpath 上出现了重复的 Hive 库——可能是 Spark 包没剥干净，也可能是 Hive 端 lib 里混进了别的发行版带的 jar。without-hive 包的价值就在这里：它保证 Spark 侧不贡献重复项，问题只可能出在 Hive 侧。

解决方法是回到 2.2 那张检查表，把$SPARK_HOME/jars/和$HIVE_HOME/lib/两边的 Hive 相关 jar 列出来比对，重复的删掉。注意别误删 Hive 端唯一的hive-exec，删之前先确认另一个来源是否真的需要。

4.3 现象：任务卡在 ACCEPTED 不动

现象是 YARN 上 application 状态长时间停在 ACCEPTED，日志没有进展。原因多半是资源参数和队列配额不匹配，spark.executor.memory加spark.executor.cores的组合超过了队列单容器上限，或者队列本身资源紧张。这跟 without-hive 包没关系，但 Hive on Spark 场景下特别容易撞上，因为 Hive 的默认参数往往偏大。

解决是先查队列的资源上限，把spark.executor.memory降到上限以内，spark.executor.cores也按队列允许的核数来。可以在hive-site.xml里临时调小验证，跑通后再逐步加。别一上来就按“越大越快”的思路填，排队时间比执行时间还长是常事。

4.4 现象：本地能跑，集群上执行器找不到 Spark 目录

现象是 client 模式提交正常，cluster 模式或分布式执行器上报找不到spark.home指向的路径。原因是spark.home是本地路径，执行器在别的节点上，那个节点没有同样的目录。without-hive 包如果只装在一台机器上，分布式场景就会翻车。

解决是把 Spark 包分发到所有可能跑执行器的节点，路径保持一致；或者用spark.yarn.archive/spark.yarn.jars把 jar 打包上传到 HDFS，让执行器从 HDFS 拉取。后者更适合节点多、不想逐台部署的场景。这一步不做，前面配得再对也白搭。

4.5 现象：查询结果对但极慢，怀疑没走 Spark

现象是任务能出结果，但耗时和预期差很远，怀疑执行引擎没切过去。原因是hive.execution.engine被别处的配置覆盖了，比如会话级set或者更高优先级的配置文件。Hive 的配置优先级是会话 > 命令行 > hive-site.xml > 默认值，任何一层覆盖都会生效。

解决是在 CLI 里执行set hive.execution.engine;看实际值，再逐层排查覆盖来源。同时看 YARN 上有没有对应的 Spark application，没有就说明确实没走 Spark。这个坑不涉及 jar，但排查顺序上应该放在 jar 问题之前——先确认引擎切没切，再查引擎为什么报错。

5. 验证与调优：确认它真的在跑 Spark

5.1 用执行计划和日志双重确认

光看结果对不对不够，得确认执行路径。Hive on Spark 下，EXPLAIN的输出里能看到 Spark 相关的算子信息，配合 YARN application 的日志，两条线对上了才算真跑通。

-- 看执行计划，确认走的是 Spark 引擎 EXPLAIN SELECT count(*) FROM test_spark_engine; -- 会话内确认引擎参数 set hive.execution.engine; set spark.home; set spark.master;

EXPLAIN输出里如果出现 Spark 的 stage 划分信息，说明引擎切换生效。三个set命令把关键参数的实际值打出来，和配置文件对一遍，能发现被覆盖的情况。我习惯在每次改完配置后都跑一遍这三条，比翻日志快。

5.2 参数调优的边界与验证方法

调优别凭感觉，用对照实验。固定数据量和查询，只改一个参数，看耗时和资源占用的变化。下面这张表是我一般会先摸的几个参数和它们的边界：

参数	作用	调大风险	建议起点
spark.executor.memory	单执行器堆内存	超队列上限排队	队列单容器上限的 70%
spark.executor.cores	单执行器并发核数	核多内存摊薄易 OOM	2～4
spark.executor.instances	执行器数量	占满队列影响他人	按队列配额
spark.sql.shuffle.partitions	shuffle 分区数	分区过多小文件多	执行器核数总数的 2～3 倍

spark.sql.shuffle.partitions在 Hive on Spark 下容易被忽略，默认值 200 在小数据量时会产生大量小任务，调度开销盖过计算本身。按执行器总核数的 2～3 倍起步，再根据 shuffle 数据量微调。每次只动一个参数，记录前后耗时，别一次改一堆然后说不清是谁的功劳。

5.3 一个收尾习惯

从那以后我每次部署 without-hive 这类“裁剪版”发行包，都强制先走一遍“空跑验证”：先spark-submit --version，再跑一个纯 Spark 示例，最后才接 Hive。这三步任何一步不过，都不往下走。血泪经验是，跳过空跑直接上 Hive，出了问题你根本分不清是包的问题、Hive 配置的问题还是资源的问题，排查成本翻几倍。这个包本身不复杂，复杂的是它所在的那条链路，把链路分段验证，比事后对着报错猜要省事得多。希望帮到你。

本文还有配套的精品资源，点击获取