Spark面试题2

Spark join的分类
当前SparkSQL支持三种Join算法：shuffle hash join、broadcast hash join以及sort merge join。

Hash Join
  采用hash join算法，整个过程会经历三步：

确定Build Table以及Probe Table：Build Table使用join key构建Hash Table，而Probe Table使用join key进行探测，探测成功就可以join在一起。通常情况下，小表会作为Build Table，大表作为Probe Table。

构建Hash Table：依次读取Build Table的数据，对于每一行数据根据join key进行hash，hash到对应的Bucket，生成hash table中的一条记录。数据缓存在内存中，如果内存放不下需要dump到外存。

探测：再依次扫描Probe Table的数据，使用相同的hash函数映射Hash Table中的记录，映射成功之后再检查join条件，如果匹配成功就可以将两者join在一起。

Broadcast Hash Join
  将其中一张小表广播分发到另一张大表所在的分区节点上，分别并发地与其上的分区记录进行hash join。broadcast适用于小表很小，可以直接广播的场景。broadcast hash join可以分为两步：

broadcast阶段：将小表广播分发到大表所在的所有主机
hash join阶段：在每个executor上执行hash join，小表映射，大表试探

Shuffle Hash Join
  在大数据条件下如果一张表很小，执行join操作最优的选择无疑是broadcast hash join，效率最高。一旦小表数据量较大，此时就不再适合进行广播分发。这种情况下，可以根据join key相同必然分区相同的原理，将两张表分别按照join key进行重新组织分区，这样就可以将join分而治之，划分为很多小join，充分利用集群资源并行化。默认设置的shuffle partition的个数是200，然后两张表的key值分别去基于200做hash取余散布在每个分区中，这样就避免了大范围的遍历比较，节省了时间和内存。如下图所示，shuffle hash join也可以分为两步：

shuffle阶段：分别将两个表按照join key进行分区，将相同join key的记录重分布到同一分区
hash join阶段：每个分区上的数据单独执行hash join算法

Sort-Merge Join
  SparkSQL对两张大表join采用sort-merge join。在Shuffle Hash Join方法的基础上，hash取余之后要分别对两张表的key值进行排序，这样去做等值比较的时候就不需要将某一方的全部数据都加载到内存进行计算了，而是即用即取即丢，从而大大提升了大数据量下sql join的稳定性。因为两个序列都是有序的，从头遍历，碰到key相同的就输出；如果不同，左边小就继续取左边，反之取右边。如下图所示，整个过程分为三个步骤：

shuffle阶段：将两张大表根据join key进行重新分区，两张表数据会分布到整个集群，以便分布式并行处理
sort阶段：对单个分区节点的两表数据，分别进行排序
merge阶段：对排好序的两张分区表数据执行join操作。join操作很简单，分别遍历两个有序序列，碰到相同join key就merge输出，否则取更小一边，见下图示意：

sort-merge join的代价并不比shuffle hash join小，那为什么SparkSQL还会在两张大表的场景下选择使用sort-merge join算法呢？
这和Spark的shuffle实现有关，目前Spark的shuffle实现都适用sort-based shuffle算法，因此在经过shuffle之后partition数据都是按照key排序的。因此理论上可以认为数据经过shuffle之后是不需要sort的，可以直接merge。

Spark join在什么情况下会变成窄依赖?
join 操作何时是宽依赖，何时是窄依赖:

如果join操作的两个RDD有分区器，且两个分区器的分区数相同，则满足条件if (rdd.partitioner == Some(part))，此时join操作是窄依赖。

如果join操作的两个RDD没有分区器或分区数量不同，那么则不满足上面的判断语句，会执行shuffle操作

由上述分析可以知道，如果需要join的两个表，本身已经有分区器，且分区的数目相同，此时，相同的key在同一个分区内。就是窄依赖。反之，如果两个需要join的表中没有分区器或者分区数量不同，在join的时候需要shuffle，那么就是宽依赖 ! 注意在创建RDD的时候没有指定分区器,在后面调用join的时候会调用默认的分区器,所以这个时候需要数据的shuffle ,是宽依赖!

Spark编程:RDD、DataFrame、DataSet三者的关系

1. RDD:

=> RDD 一般和spark mllib同时使用

=> RDD不支持sparksql操作

2. DataFrame：

=> 与RDD 和 DataSet不同，DataFrame每一行的类型固定为Row, 每一列的值没法直接访问，只有通过解析才能获取各个字段的值。

=> DataFrame 与 DataSet 一般不与spark mllib同时使用。

=> DataFrame 与 DataSet 均支持SparkSQL的操作，比如select，groupby 之类，还能注册临时表/视窗，进行sql语句操作。

2. DataSet：

=> DataSet 和 DataFrame拥有完全相同的成员函数，区别只是每一行的数据类型不同。

DataFrame其实就是DataSet的一个特例。 type DataFrame = DataSet[Row]

=> DataFrame也可以叫DataSet[Row]，每一行类型是Row,不解析，每一行究竟有哪些字段，各个字段又是什么类型都无从得知，只能用上面的getAs方法或者共性中的第七条提到的模式匹配拿出特定字段，而DataSet中，每一行是什么类型是不一定的，在自定义case class之后可以很自由的获取每一行的信息

Spark的batchsize，怎么解决小文件合并问题?
spark合并小文件有两种办法,分别针对spark core和spark sql
一、设置spark配置文件的属性(spark sql)

spark.sql.shuffle.partitions
example:

SparkSession.builder().enableHiveSupport().config(conf).
config(“spark.sql.shuffle.partitions”,5).
getOrCreate()
这里表示shuffle时自动分区为5个分区

二、对DataFrame或者RDD之后调用如下方法重新分区(spark core)

调用coalesce(num) 或者 repartition(num)方法，其中num为分区数量，可简单的理解成文件数量,可以通过修改分区数来控制文件数，通过控制文件数量可以达到控制小文件的数量来解决此问题，对于DataFrame和RDD，这里推荐使用coalesce(num)来解决小文件问题

使用INSERT OVERWRITE bi.dwd_tbl_conf_info SELECT * FROM bi.dwd_tbl_conf_info合并下历史的数据。