这是我参与「第四届青训营 」笔记创作活动的第5天
大数据处理引擎Spark介绍
1.大数据处理技术栈
- 数据-Volume Variety Velocity
- 存储-HDFS Kafka HBase
- 计算-Spqrk Flink ClickHouse
- 应用-BI报表 实时大盘 广告推荐
2.常见大数据处理链路
3.开源大数据处理引擎
Batch批式处理 hadoop Hive Strem流式处理 Spark 流批一体处理 Flink OLAP presto ClickHouse DORIS Impala
4. Spark
Unified engine for large-scale data analysis
Apache Spark is multi-language engine for executing data engineering,data science,and machine learning on single-mode machines or clusters.
版本演进
生态
特点
- 统一引擎,支持多种分布式场景
- 多语言支持
- 可读写丰富数据源
- 丰富灵活的API/算子
- 支持K8S/YARN/Mesos资源调度
SparkCore原理解析
1.SparkCore
2.RDD
RDD(Resilient Distributed Datasets) ,弹性分布式数据集, 是分布式内存的一个抽象概念,RDD提供了一种高度受限的共享内存模型,即RDD是只读的记录分区的集合,只能通过在其他RDD执行确定的转换操作(如map、join和group by)而创建,然而这些限制使得实现容错的开销很低。对开发者而言,RDD可以看作是Spark的一个对象,它本身运行于内存中,如读文件是一个RDD,对文件计算是一个RDD,结果集也是一个RDD ,不同的分片、 数据之间的依赖 、key-value类型的map数据都可以看做RDD。
RDD依赖
描述父子RDD直接的依赖关系
窄依赖-父RDD的每个partition至多对应一个子RDD分区
宽依赖-父RDD的每个partition可能对应多个子RDD分区
RDD执行流程
3.Scheduler
- 根据 ShuffleDependency切分Stage,并按照依赖顺序调度Stage,为每个Stage生成并提交TaskSet到TaskScheduler
- 根据调度算法(FIFO/FAIR)对多个TaskSet进行调度,对于调度到的 TaskSet,会将Task调度(locality)到相关Executor上面执行,Executor SchedulerBackend提供
4.Memory Management
- Executor内存主要有两类:Storage、Execution
- UnifiedMemoryManager统一管理Storage/Execution内存
- Storage 和Execution内存使用是动态调整,可以相互借用
- 当Storage空闲,Execution可以借用 Storage的内存使用,
- 可以减少spill等操作,Execution使用的内存不能被Storage 驱逐
- 当Execution空闲,Storage可以借用Execution的内存使用
- 当Execution需要内存时,可以驱逐被Storage借用的内存,直到spark.memory.storageFraction边界
UnifiedMemoryManager 统—管理多个并发Task的内存分配
每个Task获取的内存区间为1/(2*N)~1/N, N为当前Executor中正在并发运行的task数量
5.Shuffle
- 每个MapTask生成一个Shuffle数据文件和一个index文件dataFile 中的数据按照partitionld进行排序,
- 同一个partitionld的数据聚集在一起indexFile保存了所有paritionld在dataFlle中的位置信息,
- 方便后续ReduceTask 能 Fetch 到对应 partitionld 的数据
SparkSQL原理解析
1.Catalyst优化器-RBO
Batch执行策略:
- Once ->只执行—次
- FixedPoint ->重复执行,直到plan不再改变,或者执行达到固定次数(默认100次)
2.Adaptive Query Execution(AQE)
- 每个Task结束会发送MapStatus信息给Driver
- Task的MapStatus中包含当前Task Shuffle产生的每个Partition的size统计信息
- Driver获取到执行完的Stages的MapStatus信息之后,
- 按照MapStatus中partition大小信息识别匹配一些优化场景,然后对后续未执行的Plan进行优化
目前支持的优化场景:
- Partiton合并,优化shuffle读取,减少reduce task个数-SMJ -> BHJ
- Skew Join优化
业界挑战与实践
1.Shuffle稳定性问题
在大规模作业下,开源ExternalShuffleService(ESS)的实现机制容易带来大量随机读导致的磁盘IOPS瓶颈、Fetch 请求积压等问题,进而导致运算过程中经常会出现 Stage重算甚至作业失败,继而引起资源使用的恶性循环,严重 影响SLA.