SparkShuffer机制(三)

Spark在DAG调度阶段会将一个Job划分为多个Stage，上游Stage做map工作，下游Stage做reduce工作，其本质上还是MapReduce计算框架。Shuffle是连接map和reduce之间的桥梁，它将map的输出对应到reduce输入中，这期间涉及到序列化反序列化、跨节点网络IO以及磁盘读写IO等，所以说Shuffle是整个应用程序运行过程中非常昂贵的一个阶段，理解Spark Shuffle原理有助于优化Spark应用程序。

-上面是使用哪种 writer 的判断依据， 是否开启 mapSideCombine 这个判断，是因为有些算子会在 map 端先进行一次 combine， 减少传输数据。

-因为 BypassMergeSortShuffleWriter 会临时输出Reducer个（分区数目）小文件，所以分区数必须要小于一个阀值，默认是小于200。

-UnsafeShuffleWriter需要Serializer支持relocation，Serializer支持relocation：原始数据首先被序列化处理，并且再也不需要反序列，在其对应的元数据被排序后，需要Serializer支持relocation，在指定位置读取对应数据。

我们可以先考虑一个问题，假如我有 100亿条数据，但是我们的内存只有1M，但是我们磁盘很大， 我们现在要对这100亿条数据进行排序，是没法把所有的数据一次性的load进行内存进行排序的，这就涉及到一个外部排序的问题，我们的1M内存只能装进1亿条数据，每次都只能对这 1亿条数据进行排序，排好序后输出到磁盘，总共输出100个文件，最后怎么把这100个文件进行merge成一个全局有序的大文件。我们可以每个文件（有序的）都取一部分头部数据最为一个 buffer， 并且把这 100个 buffer放在一个堆里面，进行堆排序，比较方式就是对所有堆元素（buffer）的head元素进行比较大小， 然后不断的把每个堆顶的 buffer 的head 元素 pop 出来输出到最终文件中， 然后继续堆排序，继续输出。如果哪个buffer 空了，就去对应的文件中继续补充一部分数据。最终就得到一个全局有序的大文件。

如果你能想通我上面举的例子，就差不多搞清楚sortshufflewirter的实现原理了，因为解决的是同一个问题。

SortShuffleWriter 中的处理步骤就是

使用 PartitionedAppendOnlyMap 或者 PartitionedPairBuffer 在内存中进行排序， 排序的 K 是（partitionId， hash（key）） 这样一个元组。

如果超过内存 limit， 我 spill 到一个文件中，这个文件中元素也是有序的，首先是按照 partitionId的排序，如果 partitionId 相同， 再根据 hash（key）进行比较排序

如果需要输出全局有序的文件的时候，就需要对之前所有的输出文件 和 当前内存中的数据结构中的数据进行 merge sort， 进行全局排序

和我们开始提的那个问题基本类似，不同的地方在于，需要对 Key 相同的元素进行 aggregation， 就是使用定义的 func 进行聚合， 比如你的算子是 reduceByKey（+）, 这个func 就是加法运算， 如果两个key 相同， 就会先找到所有相同的key 进行 reduce(+) *** 作，算出一个总结果 Result，然后输出数据（K，Result）元素。

SortShuffleWriter 中使用 ExternalSorter 来对内存中的数据进行排序，ExternalSorter内部维护了两个集合PartitionedAppendOnlyMap、PartitionedPairBuffer， 两者都是使用了 hash table 数据结构， 如果需要进行 aggregation， 就使用 PartitionedAppendOnlyMap（支持 lookup 某个Key，如果之前存储过相同key的K-V 元素，就需要进行 aggregation，然后再存入aggregation后的 K-V）， 否则使用 PartitionedPairBuffer（只进行添K-V 元素），

触发条件:

版本： 233

Hive on Spark为Hive提供了 Apache Spark 作为执行引擎。

set hiveexecutionengine=spark;

Hive 11+以上版本提供Hive on Spark 。它在“ spark ”和“spark2”分支中仍处于发展阶段，并且定期合并到Hive的“主”分支中。

参见 HIVE-7292 及其子任务和相关问题。

Hive on Spark仅用特定版本的Spark进行测试，因此给定版本的Hive只能保证与Spark的特定版本兼容。Spark的其他版本可能与给定版本的Hive一起使用，但不能保证。以下是Hive版本及其相应兼容Spark版本的列表。

按照说明安装Spark：

YARN模式： >

下面对集中部署模式进行详细介绍

该模式运行任务不会提交在集群中，只在本节点执行，有两种情况

运行该模式非常简单，只需要把Spark的安装包解压后，改一些常用的配置即可使用，而不用启动Spark的Master、Worker守护进程( 只有集群的Standalone方式时，才需要这两个角色)，也不用启动Hadoop的各服务（除非你要用到HDFS）。

Spark不一定非要跑在hadoop集群，可以在本地，起多个线程的方式来指定。将Spark应用以多线程的方式直接运行在本地，一般都是为了方便调试，本地单机模式分三类：

搭建步骤：

（中间有报错：raise IllegalArgumentException(ssplit(': ', 1)[1], stackTrace)

pysparksqlutilsIllegalArgumentException: u'Unable to locate hive jars to connect to metastore Please set sparksqlhivemetastorejars'，网上提示查看jdk版本，发现ubuntu 1804默认是openjdk-11-jdk包(java -version提示1001)。重新安装openjdk-8-jdk版本不报错）

运行：

使用spark-shell、spark-submit、pyspark

例如使用spark-shell：

local：单机、单核运行

local[k]:启动k个executor

local[ ]：启动跟cpu数目相同的 executor

上述情况中，local[N]与local[]相当于用单机的多个线程来模拟spark分布式计算，通常用来检验开发出来的程序逻辑上有没有问题。

其中N代表可以使用N个线程，每个线程拥有一个core。

这些任务的线程，共享在一个进程中，可以开到，在程序的执行过程中只会产生一个进程，这个进程揽下了所有的任务，既是客户提交任务的client进程，又是spark的driver程序，还是spark执行task的executor

这种运行模式，和Local[N]很像，不同的是，它会在单机启动多个进程来模拟集群下的分布式场景，而不像Local[N]这种多个线程只能在一个进程下委屈求全的共享资源。通常也是用来验证开发出来的应用程序逻辑上有没有问题，或者想使用Spark的计算框架而没有太多资源。

用法：提交应用程序时使用local-cluster[x,y,z]参数：x代表要生成的executor数，y和z分别代表每个executor所拥有的core和memory数。

上面这条命令代表会使用2个executor进程，每个进程分配3个core和1G的内存，来运行应用程序。可以看到，在程序执行过程中，会生成如下几个进程：

以上就是关于SparkShuffer机制(三)全部的内容，包括:SparkShuffer机制(三)、Hive on Spark、spark几种部署模式，每种模式特点及搭建等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！