这是我参与「第四届青训营 」笔记创作活动的第4天。
今日内容：#Spark原理与实战
学习目标：了解spark。
一、课前预习
二、课中笔记
1.Spark简介
Spark运行架构和工作原理
Spark应用包括多个独立进程，进程之间通过驱动程序（Driver Program）中的SparkContext对象进行协调。SparkContext对象能够与多种集群资源管理器（Cluster Manager）通信，并连接，Spark会为该应用在各个集群节点上申请执行器（Executor），用于执行计算任务和存储数据。Spark将应用程序代码发送给所申请到的执行器，SparkContext对象将分割出的任务（Task）发送给各个执行器去运行。
每个Spark application都有其对应的多个executor进程，且进程在整个应用程序生命周期内，都保持运行状态、多线程方式执行。
好处：Executor进程可以隔离每个Spark应用。（调度角度，每个driver可以独立调度本应用程序的内部任务/executor角度，不同Spark应用对应的任务将会在不同的JVM中运行。）
缺点：多个Spark应用程序之间无法共享数据，除非把数据写到外部存储结构中。
Driver Program在整个生命周期内必须监听并接受其对应的各个executor的连接请求，因此driver program必须能被所有worker节点访问到。
driver要调度任务，driver应该和worker节点距离近一些。
2.SparkCore：
RDD执行过程
划分Stage的整体思路：
从后往前推。
遇到宽依赖就断开，划分为一个Stage。
遇到窄依赖，就将这个RDD加入该Stage中，DAG最后一个阶段会为每个结果的Partition生成一个ResultTask。
每个Stage里面的Task数量由最后一个RDD的Partition数量决定，其余的阶段会生成ShuffleMapTask。
当RDD对象创建后，SparkContext会根据RDD对象构建DAG有向无环图，然后将Task提交给DAGScheduler。
DAGScheduler根据ShuffleDependency将DAG划分为不同的Stage，为每个Stage生成TaskSet任务集合，并以TaskSet为单位提交给TaskScheduler。
TaskScheduler根据调度算法(FIFO/FAIR)对多个TaskSet进行调度，并通过集群中的资源管理器(Standalone模式下是Master，Yarn模式下是ResourceManager)把Task调度(locality) 到集群中Worker的Executor，Executor由SchedulerBackend提供。
内存管理
Spark 是基于内存的分布式计算引擎，采用统一内存管理机制，动态占用机制。
设定基本的存储内存(Storage)和执行内存(Execution) 区域，该设定确定了双方各自拥有的空间的范围，UnifiedMemoryManager统一管理Storage/Execution内存
双方的空间都不足时，则存储到硬盘；若己方空间不足而对方空余时，可借用对方的空间
当Storage空闲，Execution可以借用Storage的内存使用，可以减少spill等操作， Execution内存不能被Storage驱逐。Execution内存的空间被Storage内存占用后，可让对方将占用的部分转存到硬盘，然后"归还"借用的空间。
当Execution空闲，Storage可以借用Execution内存使用，当Execution需要内存时，可以驱逐被Storage借用的内存，可让对方将占用的部分转存到硬盘，然后"归还"借用的空间
user memory存储用户自定义的数据结构或者spark内部元数据 Reserverd memory：预留内存，防止OOM，
堆内(On-Heap)内存/堆外(Off-Heap)内存：Executor 内运行的并发任务共享 JVM 堆内内存。为了进一步优化内存的使用以及提高 Shuffle 时排序的效率，Spark 可以直接操作系统堆外内存，存储经过序列化的二进制数据。减少不必要的内存开销，以及频繁的 GC 扫描和回收，提升了处理性能。
3.SparkSQL：
SparkSQL执行过程
SQL Parse： 将SparkSQL字符串或DataFrame解析为一个抽象语法树/AST，即Unresolved Logical Plan
Analysis：遍历整个AST，并对AST上的每个节点进行数据类型的绑定以及函数绑定，然后根据元数据信息Catalog对数据表中的字段进行解析。 利用Catalog信息将Unresolved Logical Plan解析成Analyzed Logical plan
Logical Optimization：Catalyst的核心，主要分为RBO和CBO，基于规则优化/基于代价优化。 利用规则将Analyzed Logical plan解析成Optimized Logic plan
Physical Planning: Logical plan是不能被spark执行的，这个过程是把Logic plan转换为多个Physical plans
CostModel: 主要根据过去的性能统计数据，选择最佳的物理执行计划(Selected Physical Plan)。
Code Generation: sql逻辑生成Java字节码
影响SparkSQL性能两大技术：
Optimizer：执行计划的优化，目标是找出最优的执行计划
Runtime：运行时优化，目标是在既定的执行计划下尽可能快的执行完毕。
AQE
AQE对于整体的Spark SQL的执行过程做了相应的调整和优化，它最大的亮点是可以根据已经完成的计划结点真实且精确的执行统计结果来不停的反馈并重新优化剩下的执行计划。
AQE框架三种优化场景：
动态合并shuffle分区（Dynamically coalescing shuffle partitions）
动态调整Join策略（Dynamically switching join strategies）
动态优化数据倾斜Join（Dynamically optimizing skew joins）
RuntimeFilter
实现在Catalyst中。动态获取Filter内容做相关优化，当我们将一张大表和一张小表等值连接时，我们可以从小表侧收集一些统计信息，并在执行join前将其用于大表的扫描，进行分区修剪或数据过滤。可以大大提高性能。
Runtime优化：
全局优化：从提升全局资源利用率、消除数据倾斜、降低IO等角度做优化。包括AQE。
局部优化：提高某个task的执行效率，主要从提高CPU与内存利用率的角度进行优化。依赖Codegen技术。
Codegen
提高cpu的利用率的角度来进行runtime优化。
Expression级别
表达式常规递归求值语法树。需要做很多类型匹配、虚函数调用、对象创建等额外逻辑，这些overhead远超对表达式求值本身，为了消除这些overhead，Spark Codegen直接拼成求值表达式的java代码并进行即时编译
WholeStage级别
传统火山模型：
SQL经过解析会生成一颗查询树，查询树的每个节点为Operator，火山模型把operator看成迭代器，每个迭代器提供一个next()接口。通过自顶向下的调用 next 接口，数据则自底向上的被拉取处理，(也称为拉取执行模型，每个Operator 只要关心自己的处理逻辑即可，耦合性低。)
火山模型问题：
数据以行为单位进行处理，每处理一行需要调用多次next() 函数，而next()为虚函数调用。会有大量类型转换和虚函数调用。虚函数调用会导致CPU分支预测失败，从而导致严重的性能回退
Spark WholestageCodegen：
为了消除这些overhead，会为物理计划生成类型确定的java代码。并进行即时编译和执行。 Codegen打破了Stage内部算子间的界限，拼出来跟原来的逻辑保持一致的裸的代码（通常是一个大循环）然后把拼成的代码编译成可执行文件。
