简介Spark 2.3.0与Hive集成的精简发行版面向需要在不内置Hive依赖包环境下使用Spark处理Hive数据的开发运维人员。该版本兼容Hadoop 2.x解决已有独立Hive集群时引入重复运行环境的资源冗余问题。压缩包共867个文件约127.77MB涵盖多语言源码与脚本、JAR依赖库、启动脚本及配置文件便于修改部署。内含用户表示例数据、元数据文件和命令行工具可验证元数据访问配置。通过指定Hive元数据服务地址即可用Spark SQL查询Hive表避免加载完整Hive运行时。已有659人学习使用适合有一定Hive和Spark基础、追求轻量集成的团队。 搞大数据的人电脑里几乎都躺过这样一个压缩包spark-2.3.0-bin-hadoop2-without-hive.tgz。我当年第一次看到这个文件名第一反应是Hadoop2和without-hive是不是说明这是个残缺版本等真正把这套东西部署进测试环境又把Hive元数据接进来跑通数仓任务之后才算彻底弄明白——这串文件名里每个字段都有讲究选错版本、配错依赖装完跑不起来那都是轻的最坑的是集群CPU资源分配不合理任务卡到天荒地老还找不到原因。这篇内容不打算做成官方文档的复述而是从一个实际跑过Spark 2.3.0 on YARN的老用户视角把文件名拆开揉碎讲清楚再给出可复现的部署步骤、Hive元数据对接方式以及几个社区里反复出现的报错的实际排查过程。适合刚接触Spark的入门者也适合部署完集群但是被各种诡异问题卡住的人。1. 先从文件名的每个字段说起这串字符到底在告诉你什么文件名从来不是随便取的。spark-2.3.0-bin-hadoop2-without-hive这串字符严格来说是在告诉你三件事Spark的版本号、针对哪个Hadoop主版本做的预编译、以及编译时是否捆绑了Hive的依赖模块。1.1 spark-2.3.0版本号的含金量2.3.0是Apache Spark在2018年发布的一个重要版本。相比之前的2.2.x它引入了基于Data Source API V2的重新设计、Structured Streaming的持续处理模式以及GPU调度等特性。如果你工作的公司是从Spark 1.x或者CDH 5.x时代走过来的很多老任务批处理和实时链路到了2024年的今天依然跑在2.3.0上面并不稀奇。从兼容性来讲2.3.0在Scala 2.11环境下运行稳定JDK 8是它的舒适区。相比后续的Spark 3.x2.3.0没有引入太多激进改动对于只使用SQL、DataFrame和普通RDD任务的团队来说它足够成熟。这一点很重要——你下载的2.3.0不是越老越不能用的代名词而是指它在当时代码分支上经过了充分打磨。1.2 bin预编译发行版而不是源码包bin表示这是已经编译好的二进制发行版。别小看这个细节Spark的源码编译是个既耗时又容易踩坑的过程你需要匹配Maven版本、Scala版本、Hadoop版本还要处理网络依赖下载问题。我自己曾经在低网速环境下编译过一次Spark 2.4源码Gradle下载依赖就花了一个多小时中间还因为某个仓库SSL证书报错失败重来。所以对于绝大多数使用场景直接下载bin包是成本最低的选择。你解压以后就能用spark-shell、spark-submit这些命令。需要强调的是bin包虽然叫二进制发行版但它并不包含完整的Java运行环境你依然需要自己装好JDK并配置JAVA_HOME。1.3 hadoop2与without-hive的匹配逻辑这个压缩包针对的是Hadoop 2.x。Hadoop 2.x是目前绝大多数企业部署的主流大版本包括CDH 5.x、HDP 2.x以及开源Apache Hadoop 2.7/2.8/2.9等。Spark与Hadoop之间通过HDFS客户端、YARN客户端相关jar包通信。选错了Hadoop主版本最典型的报错就是NoSuchMethodError或者ClassNotFoundException原因就是Hadoop API在不同主版本之间有少量不兼容调整。“without-hive”字段针对的则是Spark发行版中是否捆绑了Hive支持的模块。Apache Spark官方提供的预编译包一类是with-hive里面包含了Hive的Thrift JDBC驱动和内置的Derby数据库实现可以让Spark SQL直接使用自带的Hive Metastore另一类就是本文标题的without-hive它不包含Hive相关的库启动Spark SQL时默认不会启用Hive支持。我之前在搭建测试环境时选择without-hive的原因很明确生产环境已经有独立的Hive Metastore服务不需要Spark再内置一份Hive依赖避免引入冲突的guava包和Hive jar包版本。这个选择后面会详细展开。2. 不要上来就装先捋清Spark 2.3.0的适用边界与生态匹配不少读者拿到压缩包第一件事就是解压、配环境变量、启动spark-shell看到Scala命令行出来了就认为大功告成。这种装上了其实非常脆弱你一旦提交到YARN或者要读HDFS上的文件各种版本不匹配问题才会陆续暴露。2.1 Spark 2.3.0适合什么场景不适合什么场景先说适合的已有Hadoop 2.x集群Hive数据仓库已经建设完成需要用Spark SQL做即席查询和批处理加速。需要用Structured Streaming做准实时ETL但数据量没有大到必须上Flink的程度。团队主要写PySpark或者Spark SQL不依赖太多Spark 3.x的新特性。不适合的需要使用Delta Lake较新版本的表格式或者要跑依赖Spark 3.x动态分区裁剪的复杂查询。需要使用Kubernetes作为原生调度后端Spark 2.3.0对K8s的支持只是实验性质的坑非常多。需要和JDK 11以上环境共存2.3.0在JDK 11下会有模块访问报错强烈建议使用JDK 8。我在生产环境遇到过最尴尬的一次是业务方拿了一段新写法代码用了Spark 3的from_csv函数的新参数特性跑在2.3.0上直接报AnalysisException。所以选版本前先确认好你们团队的代码基线避免代码写得很超前集群版本拖后腿的窘境。2.2 Spark与Hadoop生态的耦合点就算你下载的是hadoop2版本也并不意味着这个Spark能自动连接任意Hadoop 2.x集群。它的作用只是在字节码层面兼容Hadoop 2.x的API。真正决定能否读写你HDFS数据的是运行时classpath里有没有对应Hadoop发行版的配置和依赖。具体来说你需要把hadoop-client相关的jar包或者HADOOP_CONF_DIR环境变量指到集群的配置文件目录。很多刚接触的人会忽略core-site.xml和hdfs-site.xml的作用结果Spark shell能起来一执行spark.read.parquet(hdfs://...)就报FileSystem closed或者Inconsistent namespace之类的异常。这通常不是Spark的问题而是客户端没有拿到正确的NameNode地址。2.3 内存模型要先搞清楚不然调参全靠猜Spark 2.3.0的内存管理和之前版本一脉相承executor内存分为execution执行和storage缓存两个区域两者之间通过spark.memory.fraction和spark.memory.storageFraction共同决定。2.3.0默认spark.memory.fraction0.6这意味着Executor堆内60%用于管理内存剩下的40%留给用户代码和数据结构。很多性能问题都是内存模型理解偏差导致的。比如有人为了提高缓存能力把spark.memory.storageFraction从默认0.5调到0.8确实能缓存更多RDD但一旦触发Shuffleexecution内存不够用就会频繁spill到磁盘甚至OOM。所以调整内存参数不能只盯着Storage要在spark.ui的Storage和Executors页签一起观察。我再强调一个容易踩的坑2.3.0中spark.executor.memory配置的是Executor的JVM堆内存而spark.executor.memoryOverhead是额外的堆外内存默认是executor.memory * 0.10。如果你的任务涉及大量Shuffle或者UDF里创建了大数组堆外内存不足会引发一个非常隐蔽的问题——进程被YARN直接kill掉而日志里只有Container killed by YARN for exceeding memory limits根本看不到具体StackOverflow或者OOM。遇到这种情况不是代码出错了而是overhead给少了。3. without-hive不代表不能用Hive把Metastore接进来的正确姿势这个可能是最多人误解的点。看到without-hive就以为Spark不能用Hive了其实大错特错。without-hive只是指Spark发行版内部没有内置Hive的jar和Derby数据库但Spark SQL完全可以通过外部配置连接已经部署好的Hive Metastore服务。这也是生产环境最推荐的部署方式。3.1 with-hive与without-hive的本质区别with-hive版本中Spark自带了Hive的Thrift服务支持你可以直接启动spark-sql或者thriftserver它把Hive的元数据信息存放在内置的Derby数据库中。这个数据库是单连接的多个会话同时访问会出现lock timeout问题适合单机体验。without-hive版本则要求你手动提供Hive的依赖和配置。好处是你可以完全控制Hive jar包的版本不会出现Spark自身携带的和Hive服务端不一致的情况。我之前就遇到过使用with-hive版本的Spark去连接CDH环境里的Hive Metastore结果因为Hive版本不统一导致读取表结构时抛异常。后来改成without-hive并指定了CDH自带的hive-exec和hive-metastore jar包问题迎刃而解。3.2 实操配置让Spark 2.3.0连接Hive Metastore假设你的Hive服务端使用的是Hive 2.1.1版本Metastore运行在名为hive-metastore-host的机器上端口是9083。要让Spark 2.3.0也就是我们安装的spark-2.3.0-bin-hadoop2-without-hive连接到它需要做以下几步。进入Spark安装目录的conf文件夹创建或修改hive-site.xmlconfiguration property namehive.metastore.uris/name valuethrift://hive-metastore-host:9083/value /property property namejavax.jdo.option.ConnectionURL/name valuejdbc:mysql://mysql-host:3306/hive_metastore_db?createDatabaseIfNotExisttrue/value /property /configuration注意这个文件的作用不是让Spark自己操作元数据库而是让Spark SQL在解析表结构时去请求远程的Metastore服务。如果你的环境中Hive使用MySQL作为元数据库这一项Spark端一般不需要配置那是Hive服务端负责连的。真正关键的是hive.metastore.uris。接下来需要把Hive的jar包放到Spark的classpath中。最简单的办法是创建$SPARK_HOME/jars/hive目录然后把Hive安装目录下lib里的hive-exec、hive-metastore、hive-common、hive-serde等jar包复制过来。根据Hive版本不同还需要注意guava.jar的冲突。Hive 1.x系列用的guava版本是14.0.1Hive 2.x系列用的是17.0.1而Spark 2.3.0自带的guava是14.0.1。这意味着如果你同时把Spark的jars目录和Hive的jar目录都放在classpath里极大概率会遇到guava冲突。我的做法是在spark-defaults.conf里通过spark.driver.extraClassPath和spark.executor.extraClassPath单独指定Hive jar的路径并且把冲突的guava版本从Hive目录中排除只保留Spark自带的一份。这样即使Hive内部某个功能确实需要更新的guava也能兼容运行因为大多数Metastore访问走的是Thrift协议并不会在Spark端触发Hive内部对guava的深度调用。3.3 验证是否对接成功配置完成后启动spark-sql执行show databases;如果你能看到Hive里已有的数据库列表说明Metastore对接成功。然后再尝试use your_database; show tables;正常情况下Hive服务的所有表都能在Spark SQL里直接查询。有一点要提醒Spark SQL访问Hive表的查询引擎是Spark自己的Catalyst优化器和Hive原生的MapReduce执行引擎走的是完全两条路。所以同一个SQL在Hive里要跑几分钟的在Spark里可能只需十几秒但这不代表Hive本身变快了而是执行框架换了。4. 部署到YARN的必要准备环境变量、目录结构、提交命令当你能正常启动spark-shell之后接下去就是把Spark当作一个YARN客户端应用提交到生产集群。这个过程有几个关键步骤任何一步做错都会导致任务无法正常启动或者资源分配异常。4.1 环境变量配置建议在你需要提交任务的客户端机器也就是部署了Spark的那台机器上编辑/etc/profile或~/.bashrcexport JAVA_HOME/usr/local/jdk1.8.0_202 export HADOOP_HOME/usr/local/hadoop-2.9.2 export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export SPARK_HOME/usr/local/spark-2.3.0-bin-hadoop2-without-hive export PATH$SPARK_HOME/bin:$HADOOP_HOME/bin:$PATHHADOOP_CONF_DIR这个环境变量非常关键。Spark在YARN模式下需要读取yarn-site.xml、core-site.xml和hdfs-site.xml来定位ResourceManager和NameNode。我看到太多人只配了SPARK_HOME结果spark-shell能启动但spark-submit --master yarn模式提交任务时直接在客户端阶段报连接不到YARN集群。4.2 目录结构里容易被忽略的内容解压之后你会在安装目录下看到bin、conf、data、examples、jars、python、R、sbin这本文还有配套的精品资源点击获取 Spark 2.3.0 without-hive深度解析：部署、Hive集成与YARN调优
简介Spark 2.3.0与Hive集成的精简发行版面向需要在不内置Hive依赖包环境下使用Spark处理Hive数据的开发运维人员。该版本兼容Hadoop 2.x解决已有独立Hive集群时引入重复运行环境的资源冗余问题。压缩包共867个文件约127.77MB涵盖多语言源码与脚本、JAR依赖库、启动脚本及配置文件便于修改部署。内含用户表示例数据、元数据文件和命令行工具可验证元数据访问配置。通过指定Hive元数据服务地址即可用Spark SQL查询Hive表避免加载完整Hive运行时。已有659人学习使用适合有一定Hive和Spark基础、追求轻量集成的团队。 搞大数据的人电脑里几乎都躺过这样一个压缩包spark-2.3.0-bin-hadoop2-without-hive.tgz。我当年第一次看到这个文件名第一反应是Hadoop2和without-hive是不是说明这是个残缺版本等真正把这套东西部署进测试环境又把Hive元数据接进来跑通数仓任务之后才算彻底弄明白——这串文件名里每个字段都有讲究选错版本、配错依赖装完跑不起来那都是轻的最坑的是集群CPU资源分配不合理任务卡到天荒地老还找不到原因。这篇内容不打算做成官方文档的复述而是从一个实际跑过Spark 2.3.0 on YARN的老用户视角把文件名拆开揉碎讲清楚再给出可复现的部署步骤、Hive元数据对接方式以及几个社区里反复出现的报错的实际排查过程。适合刚接触Spark的入门者也适合部署完集群但是被各种诡异问题卡住的人。1. 先从文件名的每个字段说起这串字符到底在告诉你什么文件名从来不是随便取的。spark-2.3.0-bin-hadoop2-without-hive这串字符严格来说是在告诉你三件事Spark的版本号、针对哪个Hadoop主版本做的预编译、以及编译时是否捆绑了Hive的依赖模块。1.1 spark-2.3.0版本号的含金量2.3.0是Apache Spark在2018年发布的一个重要版本。相比之前的2.2.x它引入了基于Data Source API V2的重新设计、Structured Streaming的持续处理模式以及GPU调度等特性。如果你工作的公司是从Spark 1.x或者CDH 5.x时代走过来的很多老任务批处理和实时链路到了2024年的今天依然跑在2.3.0上面并不稀奇。从兼容性来讲2.3.0在Scala 2.11环境下运行稳定JDK 8是它的舒适区。相比后续的Spark 3.x2.3.0没有引入太多激进改动对于只使用SQL、DataFrame和普通RDD任务的团队来说它足够成熟。这一点很重要——你下载的2.3.0不是越老越不能用的代名词而是指它在当时代码分支上经过了充分打磨。1.2 bin预编译发行版而不是源码包bin表示这是已经编译好的二进制发行版。别小看这个细节Spark的源码编译是个既耗时又容易踩坑的过程你需要匹配Maven版本、Scala版本、Hadoop版本还要处理网络依赖下载问题。我自己曾经在低网速环境下编译过一次Spark 2.4源码Gradle下载依赖就花了一个多小时中间还因为某个仓库SSL证书报错失败重来。所以对于绝大多数使用场景直接下载bin包是成本最低的选择。你解压以后就能用spark-shell、spark-submit这些命令。需要强调的是bin包虽然叫二进制发行版但它并不包含完整的Java运行环境你依然需要自己装好JDK并配置JAVA_HOME。1.3 hadoop2与without-hive的匹配逻辑这个压缩包针对的是Hadoop 2.x。Hadoop 2.x是目前绝大多数企业部署的主流大版本包括CDH 5.x、HDP 2.x以及开源Apache Hadoop 2.7/2.8/2.9等。Spark与Hadoop之间通过HDFS客户端、YARN客户端相关jar包通信。选错了Hadoop主版本最典型的报错就是NoSuchMethodError或者ClassNotFoundException原因就是Hadoop API在不同主版本之间有少量不兼容调整。“without-hive”字段针对的则是Spark发行版中是否捆绑了Hive支持的模块。Apache Spark官方提供的预编译包一类是with-hive里面包含了Hive的Thrift JDBC驱动和内置的Derby数据库实现可以让Spark SQL直接使用自带的Hive Metastore另一类就是本文标题的without-hive它不包含Hive相关的库启动Spark SQL时默认不会启用Hive支持。我之前在搭建测试环境时选择without-hive的原因很明确生产环境已经有独立的Hive Metastore服务不需要Spark再内置一份Hive依赖避免引入冲突的guava包和Hive jar包版本。这个选择后面会详细展开。2. 不要上来就装先捋清Spark 2.3.0的适用边界与生态匹配不少读者拿到压缩包第一件事就是解压、配环境变量、启动spark-shell看到Scala命令行出来了就认为大功告成。这种装上了其实非常脆弱你一旦提交到YARN或者要读HDFS上的文件各种版本不匹配问题才会陆续暴露。2.1 Spark 2.3.0适合什么场景不适合什么场景先说适合的已有Hadoop 2.x集群Hive数据仓库已经建设完成需要用Spark SQL做即席查询和批处理加速。需要用Structured Streaming做准实时ETL但数据量没有大到必须上Flink的程度。团队主要写PySpark或者Spark SQL不依赖太多Spark 3.x的新特性。不适合的需要使用Delta Lake较新版本的表格式或者要跑依赖Spark 3.x动态分区裁剪的复杂查询。需要使用Kubernetes作为原生调度后端Spark 2.3.0对K8s的支持只是实验性质的坑非常多。需要和JDK 11以上环境共存2.3.0在JDK 11下会有模块访问报错强烈建议使用JDK 8。我在生产环境遇到过最尴尬的一次是业务方拿了一段新写法代码用了Spark 3的from_csv函数的新参数特性跑在2.3.0上直接报AnalysisException。所以选版本前先确认好你们团队的代码基线避免代码写得很超前集群版本拖后腿的窘境。2.2 Spark与Hadoop生态的耦合点就算你下载的是hadoop2版本也并不意味着这个Spark能自动连接任意Hadoop 2.x集群。它的作用只是在字节码层面兼容Hadoop 2.x的API。真正决定能否读写你HDFS数据的是运行时classpath里有没有对应Hadoop发行版的配置和依赖。具体来说你需要把hadoop-client相关的jar包或者HADOOP_CONF_DIR环境变量指到集群的配置文件目录。很多刚接触的人会忽略core-site.xml和hdfs-site.xml的作用结果Spark shell能起来一执行spark.read.parquet(hdfs://...)就报FileSystem closed或者Inconsistent namespace之类的异常。这通常不是Spark的问题而是客户端没有拿到正确的NameNode地址。2.3 内存模型要先搞清楚不然调参全靠猜Spark 2.3.0的内存管理和之前版本一脉相承executor内存分为execution执行和storage缓存两个区域两者之间通过spark.memory.fraction和spark.memory.storageFraction共同决定。2.3.0默认spark.memory.fraction0.6这意味着Executor堆内60%用于管理内存剩下的40%留给用户代码和数据结构。很多性能问题都是内存模型理解偏差导致的。比如有人为了提高缓存能力把spark.memory.storageFraction从默认0.5调到0.8确实能缓存更多RDD但一旦触发Shuffleexecution内存不够用就会频繁spill到磁盘甚至OOM。所以调整内存参数不能只盯着Storage要在spark.ui的Storage和Executors页签一起观察。我再强调一个容易踩的坑2.3.0中spark.executor.memory配置的是Executor的JVM堆内存而spark.executor.memoryOverhead是额外的堆外内存默认是executor.memory * 0.10。如果你的任务涉及大量Shuffle或者UDF里创建了大数组堆外内存不足会引发一个非常隐蔽的问题——进程被YARN直接kill掉而日志里只有Container killed by YARN for exceeding memory limits根本看不到具体StackOverflow或者OOM。遇到这种情况不是代码出错了而是overhead给少了。3. without-hive不代表不能用Hive把Metastore接进来的正确姿势这个可能是最多人误解的点。看到without-hive就以为Spark不能用Hive了其实大错特错。without-hive只是指Spark发行版内部没有内置Hive的jar和Derby数据库但Spark SQL完全可以通过外部配置连接已经部署好的Hive Metastore服务。这也是生产环境最推荐的部署方式。3.1 with-hive与without-hive的本质区别with-hive版本中Spark自带了Hive的Thrift服务支持你可以直接启动spark-sql或者thriftserver它把Hive的元数据信息存放在内置的Derby数据库中。这个数据库是单连接的多个会话同时访问会出现lock timeout问题适合单机体验。without-hive版本则要求你手动提供Hive的依赖和配置。好处是你可以完全控制Hive jar包的版本不会出现Spark自身携带的和Hive服务端不一致的情况。我之前就遇到过使用with-hive版本的Spark去连接CDH环境里的Hive Metastore结果因为Hive版本不统一导致读取表结构时抛异常。后来改成without-hive并指定了CDH自带的hive-exec和hive-metastore jar包问题迎刃而解。3.2 实操配置让Spark 2.3.0连接Hive Metastore假设你的Hive服务端使用的是Hive 2.1.1版本Metastore运行在名为hive-metastore-host的机器上端口是9083。要让Spark 2.3.0也就是我们安装的spark-2.3.0-bin-hadoop2-without-hive连接到它需要做以下几步。进入Spark安装目录的conf文件夹创建或修改hive-site.xmlconfiguration property namehive.metastore.uris/name valuethrift://hive-metastore-host:9083/value /property property namejavax.jdo.option.ConnectionURL/name valuejdbc:mysql://mysql-host:3306/hive_metastore_db?createDatabaseIfNotExisttrue/value /property /configuration注意这个文件的作用不是让Spark自己操作元数据库而是让Spark SQL在解析表结构时去请求远程的Metastore服务。如果你的环境中Hive使用MySQL作为元数据库这一项Spark端一般不需要配置那是Hive服务端负责连的。真正关键的是hive.metastore.uris。接下来需要把Hive的jar包放到Spark的classpath中。最简单的办法是创建$SPARK_HOME/jars/hive目录然后把Hive安装目录下lib里的hive-exec、hive-metastore、hive-common、hive-serde等jar包复制过来。根据Hive版本不同还需要注意guava.jar的冲突。Hive 1.x系列用的guava版本是14.0.1Hive 2.x系列用的是17.0.1而Spark 2.3.0自带的guava是14.0.1。这意味着如果你同时把Spark的jars目录和Hive的jar目录都放在classpath里极大概率会遇到guava冲突。我的做法是在spark-defaults.conf里通过spark.driver.extraClassPath和spark.executor.extraClassPath单独指定Hive jar的路径并且把冲突的guava版本从Hive目录中排除只保留Spark自带的一份。这样即使Hive内部某个功能确实需要更新的guava也能兼容运行因为大多数Metastore访问走的是Thrift协议并不会在Spark端触发Hive内部对guava的深度调用。3.3 验证是否对接成功配置完成后启动spark-sql执行show databases;如果你能看到Hive里已有的数据库列表说明Metastore对接成功。然后再尝试use your_database; show tables;正常情况下Hive服务的所有表都能在Spark SQL里直接查询。有一点要提醒Spark SQL访问Hive表的查询引擎是Spark自己的Catalyst优化器和Hive原生的MapReduce执行引擎走的是完全两条路。所以同一个SQL在Hive里要跑几分钟的在Spark里可能只需十几秒但这不代表Hive本身变快了而是执行框架换了。4. 部署到YARN的必要准备环境变量、目录结构、提交命令当你能正常启动spark-shell之后接下去就是把Spark当作一个YARN客户端应用提交到生产集群。这个过程有几个关键步骤任何一步做错都会导致任务无法正常启动或者资源分配异常。4.1 环境变量配置建议在你需要提交任务的客户端机器也就是部署了Spark的那台机器上编辑/etc/profile或~/.bashrcexport JAVA_HOME/usr/local/jdk1.8.0_202 export HADOOP_HOME/usr/local/hadoop-2.9.2 export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export SPARK_HOME/usr/local/spark-2.3.0-bin-hadoop2-without-hive export PATH$SPARK_HOME/bin:$HADOOP_HOME/bin:$PATHHADOOP_CONF_DIR这个环境变量非常关键。Spark在YARN模式下需要读取yarn-site.xml、core-site.xml和hdfs-site.xml来定位ResourceManager和NameNode。我看到太多人只配了SPARK_HOME结果spark-shell能启动但spark-submit --master yarn模式提交任务时直接在客户端阶段报连接不到YARN集群。4.2 目录结构里容易被忽略的内容解压之后你会在安装目录下看到bin、conf、data、examples、jars、python、R、sbin这本文还有配套的精品资源点击获取