这是我参与「第四届青训营 」笔记创作活动的的第5天。
本节课程主要分为 4 个方面：
1.大数据处理引擎Spark介绍
2.SparkCore原理解析
3.SparkSQL原理解析
4.业界挑战与实践
一.大数据引擎Spark介绍
1.1.大数据处理技术
数据—存储—计算—应用
1.4.什么是Spark？
是一个多语言引擎，用于在单节点机器或集群上执行数据工程、数据科学和机器学习。
特点：1).批处理/流数据：使用您的首选语言（Python、SQL、Scala、Java 或 R）以批处理和实时流形式统一数据处理。
2).SQL 分析：执行快速、分布式的 ANSI SQL 查询，以实现仪表板和即席报告。运行速度比大多数数据仓库快。
3).大规模数据科学：对 PB 级数据执行探索性数据分析 （EDA），而无需采用缩减采样。
4).机器学习：在笔记本电脑上训练机器学习算法，并使用相同的代码扩展到数千台计算机的容错群集。
1.4.1.Spark生态 & 特点
生态：
1).Spark Core：Spark核心组件，它实现了Spark的基本功能，包含任务调度、内存管理、错误恢复、与存储系统交互等模块。
2).Spark SQL：用来操作结构化数据的核心组件，通过Spark SQL可以直接查询Hive、HBase等多种外部数据源中的数据。
3).Spark Structured Streaming：Spark提供的流式计算框架，支持高吞吐量、可容错处理的实时流式数据处理。
4).MLlib：Spark提供的关于机器学习功能的算法程序库，包括分类、回归、聚类、协同过滤算法等，还提供了模型评估、数据导入等额外的功能。
5).GraphX：Spark提供的分布式图处理框架，拥有对图计算和图挖掘算法的API接口以及丰富的功能和运算符。
6).独立调度器、Yarn、Mesos、Kubernetes：Spark框架可以高效地在一个到数千个节点之间伸缩计算，集群管理器则主要负责各个节点的资源管理工作，为了实现这样的要求，同时获得最大灵活性，Spark支持在各种集群管理器（Cluster Manager）上运行。
特点：1).统一引擎，支持多种分布式场景
2).多语言支持
3).可读写丰富数据源
4).丰富灵活的API/算子
5).支持K8S/ARN/Mesos资源调度
1.5.Spark-多语言支持
SQL--Java/Scala--R--Python
1.5.1.Spark-丰富数据源：
■ 内置DataSource
■ 自定义DataSource
1.5.2.Spark-丰富灵活的API/算子：
■ SparkCore—>RDD
■ SparkSQL—>DataFrame
1.6.Spark运行架构 & 部署方式
1.11.Spark UI
▢ Job运行中->HTTP://${driver_host}:$port
▢ Job运行完->SparkHistoryServer可查看
二.SparkCore原理解析
2.2.什么是RDD?
RDD(Resilient Distributed Dataset)：弹性分布式数据集，是一个容错的、并行的数据结构。
2.2.1如何创建RDD?
1).内置RDD ShuffleRDD/HadoopRDD/JDBCRDD
2).自定义RDD class CustomRDD(...) extends RDD{}
实现五要素对应的函数
2.2.2.RDD算子
RDD算子：对任何函数进行某一项操作都可以认为是一个算子，RDD算子是RDD的成员函数
两类RDD算子：
✓ Transform(转换)算子: 根据已有RDD创建新的RDD
✓ Action(动作)算子: 将在数据集上运行计算后的数值返回到驱动程序，从而触发真正的计算
2.2.3.RDD依赖
RDD依赖：描述父子RDD之间的依赖关系(lineage)
◆ 窄依赖：父RDD的每个partition至多对应一个子RDD分区。
✓ NarrowDependency
✓ PruneDependency
✓ RangeDependency
✓ OneToOneDependency
◆ 宽依赖：父RDD的每个partition都可能对应多个子RDD分区。
2.2.4.RDD执行流程
Job：RDD action算子触发
Stage：依据宽依赖划分
Task：Stage内执行单个partition任务
2.4.Memory Management
■ Executor内存主要有两类：Storage、Execution
○ UnifiedMemoryManage统一管理Storage/Execution内存；
○ Storage和Execution内存使用是动态调整，可以相互借用；
○ 当Storage空闲，Execution可以借用Storage的内存使用；
○ 可以减少spill等操作，Execution使用的内存不能被Storage驱逐；
○ 当Execution空闲，Storage可以借用Execution的内存使用；
○ 当Execution需要内存时，可以驱逐被Storage借用的内存；
○ spark.memoty.storageFraction边界。
2.5.Shuffle
shuffle write的文件被NodeManager中的Shuffle Service托管，供后续Reduce Task进行shuffle fatch,如果Executor空闲，DRA可以进行回收。
三.SparkSQL原理解析
3.1.SparkSQL
1).SQL Parse： 将SparkSQL字符串或DataFrame解析为一个抽象语法树/AST，即Unresolved Logical Plan
2).Analysis：遍历整个AST，并对AST上的每个节点进行数据类型的绑定以及函数绑定，然后根据元数据信息Catalog对数据表中的字段进行解析。 利用Catalog信息将Unresolved Logical Plan解析成Analyzed Logical plan
3).Logical Optimization：该模块是Catalyst的核心，主要分为RBO和CBO两种优化策略，其中RBO是基于规则优化，CBO是基于代价优化。 利用一些规则将Analyzed Logical plan解析成Optimized Logic plan
4).Physical Planning: Logical plan是不能被spark执行的，这个过程是把Logic plan转换为多个Physical plans
5).CostModel: 主要根据过去的性能统计数据，选择最佳的物理执行计划(Selected Physical Plan)。
6).Code Generation: sql逻辑生成Java字节码.
3.1.Catalyst优化器--RBO
基于规则优化，对语法树进行一次遍历，模式匹配能够满足特定规则的节点，再进行相应的等价转换。
3.1.1.Catalyst优化器--CBO
基于代价优化，根据优化规则对关系表达式进行转换，生成多个执行计划，然后CBO会通过根据统计信息(Statistics)和代价模型(Cost Model)计算各种可能执行计划的代价，从中选用COST最低的执行方案，作为实际运行方案。CBO依赖数据库对象的统计信息，统计信息的准确与否会影响CBO做出最优的选择。
3.2.AQE
AQE框架三种优化场景：
◌ 动态合并shuffle分区（Dynamically coalescing shuffle partitions）
◌ 动态调整Join策略（Dynamically switching join strategies）
◌ 动态优化数据倾斜Join（Dynamically optimizing skew joins）
3.2.1.Coalescing Shuffle Paritions
3.2.1.Switching Join Strategies
3.2.1.Optimizing Skew Joins
3.3.Runtime Flink
实现在Catalyst中。动态获取Filter内容做相关优化，当我们将一张大表和一张小表等值连接时，我们可以从小表侧收集一些统计信息，并在执行join前将其用于大表的扫描，进行分区修剪或数据过滤。可以大大提高性能。
Runtime优化分两类：
● 全局优化：从提升全局资源利用率、消除数据倾斜、降低IO等角度做优化。包括AQE。
● 局部优化：提高某个task的执行效率，主要从提高CPU与内存利用率的角度进行优化。依赖Codegen技术。
3.5.Codegen
1).Expression级别： 表达式常规递归求值语法树。需要做很多类型匹配、虚函数调用、对象创建等额外逻辑，这些overhead远超对表达式求值本身，为了消除这些overhead，Spark Codegen直接拼成求值表达式的java代码并进行即时编译。
2).WholeStage级别： 传统的火山模型：SQL经过解析会生成一颗查询树，查询树的每个节点为Operator，火山模型把operator看成迭代器，每个迭代器提供一个next()接口。通过自顶向下的调用 next 接口，数据则自底向上的被拉取处理，火山模型的这种处理方式也称为拉取执行模型，每个Operator 只要关心自己的处理逻辑即可，耦合性低。
四.业界挑战与实践
4.1.Shuffle稳定性
在大规模需作业下，开源ExtermalShuffleService(ESS)的实现机制容易带来大量随机读导致的磁盘IOPS瓶颈、Fetch请求积压等问题，进而导致运算过程中经常会出现Stage重算甚至作业失败，继而引起资源使用的恶行循环，严重影响SLA。
4.2.SQL执行性能问题
压榨CPU资源
4.3.参数推荐/作业诊断
