spark join的几种方式

sort merge join

broadcast join

hash join

note

spark sql不需要关注哪个是左表哪个是右表，spark sql会自动将大表判断为左表

sort merge join实现

适用场景

适合两张大表的join，将相同key放在相同的分区，提升join性能

要让两条记录能join到一起，首先需要将具有相同key的记录在同一个分区，所以通常来说，需要做一次shuffle，map阶段根据join条件确定每条记录的key，基于该key做shuffle write，将可能join到一起的记录分到同一个分区中，这样在shuffle read阶段就可以将两个表中具有相同key的记录拉到同一个分区处理。前面我们也提到，对于buildIter一定要是查找性能较优的数据结构，通常我们能想到hash表，但是对于一张较大的表来说，不可能将所有记录全部放到hash表中，另外也可以对buildIter先排序，查找时按顺序查找，查找代价也是可以接受的，我们知道，spark shuffle阶段天然就支持排序，这个是非常好实现的，下面是sort merge join示意图。

在shuffle read阶段，分别对streamIter和buildIter进行merge sort，在遍历streamIter时，对于每条记录，都采用顺序查找的方式从buildIter查找对应的记录，由于两个表都是排序的，每次处理完streamIter的一条记录后，对于streamIter的下一条记录，只需从buildIter中上一次查找结束的位置开始查找，所以说每次在buildIter中查找不必重头开始，整体上来说，查找性能还是较优的。

broadcast join实现（又称map join）

适用场景

适用于其中一张表是小表broadcast到所有分区，就避免了shuffle;被广播的表首先被collect（转成数组）到driver端，然后被冗余分发到每个executor上，所以当表比较大时，采用broadcast join会对driver端和executor端造成较大的压力

spark sql会自动判断将小表broadcast

为了能具有相同key的记录分到同一个分区，我们通常是做shuffle，那么如果buildIter是一个非常小的表，那么其实就没有必要大动干戈做shuffle了，直接将buildIter广播到每个计算节点，然后将buildIter放到hash表中，如下图所示。

从上图可以看到，不用做shuffle，可以直接在一个map中完成，通常这种join也称之为map join。那么问题来了，什么时候会用broadcast join实现呢？这个不用我们担心，spark sql自动帮我们完成，当buildIter的估计大小不超过参数spark.sql.autoBroadcastJoinThreshold设定的值(默认10M)，那么就会自动采用broadcast join，否则采用sort merge join

hash join实现

适用场景

shuffle hash join:适合一张较小表（不适合广播）和一张大表进行join，或者是两张小表之间的join

除了上面两种join实现方式外，spark还提供了hash join实现方式，在shuffle read阶段不对记录排序，反正来自两格表的具有相同key的记录会在同一个分区，只是在分区内不排序，将来自buildIter的记录放到hash表中，以便查找，如下图所示。

不难发现，要将来自buildIter的记录放到hash表中，那么每个分区来自buildIter的记录不能太大，否则就存不下，默认情况下hash join的实现是关闭状态，如果要使用hash join，必须满足以下四个条件：

buildIter总体估计大小超过spark.sql.autoBroadcastJoinThreshold设定的值，即不满足broadcast join条件

开启尝试使用hash join的开关，spark.sql.join.preferSortMergeJoin=false

每个分区的平均大小不超过spark.sql.autoBroadcastJoinThreshold设定的值，即shuffle read阶段每个分区来自buildIter的记录要能放到内存中

streamIter的大小是buildIter三倍以上

所以说，使用hash join的条件其实是很苛刻的，在大多数实际场景中，即使能使用hash join，但是使用sort merge join也不会比hash join差很多，所以尽量使用hash

spark提交作业的方式

参考

https://ld246.com/article/1500366757237

https://stackoverflow.com/questions/41124428/spark-yarn-cluster-vs-client-how-to-choose-which-one-to-use

通过yarn提交作业
Yarn 集群的 Cluster Manager 是 RecourxeManager 简称 RM，类似于 Master,其 NodeManager 相当于 Worker 简称 NM

yarn cluster

YarnCluster 与 Client 不同的是在提交之后请求 RM 启动 ApplicationMaster，RM 分配 Container 在 NM 启动一个 AM，AM 启动之后注册到 RM 中并连接其他的 NM 启动 Executor。

In yarn-cluster mode, the driver runs in the Application Master. This means that the same process is responsible for both driving the application and requesting resources from YARN, and this process runs inside a YARN container. The client that starts the app doesn’t need to stick around for its entire lifetime.

通过spark-submit提交作业到yarn集群

yarn client

任务提交会在本机上启动 Driver，然后请求 RM 启动 SparkApplicationMaster(Driver),Driver 启动之后请求 RM 分配 Container,启动 Executor,Executor 启动之后会注册到 Driver 中，Driver 中的 SparkConetxt 会发送 task 给 Executor 执行。

The yarn-cluster mode is not well suited to using Spark interactively, but the yarn-client mode is. Spark applications that require user input, like spark-shell and PySpark, need the Spark driver to run inside the client process that initiates the Spark application. In yarn-client mode, the Application Master is merely present to request executor containers from YARN. The client communicates with those containers to schedule work after they start:

转载地址：http://djwmf.baihongyu.com/

你可能感兴趣的文章

【UML】《Theach yourself uml in 24hours》——hour2&hour3