这是我参与「第四届青训营 」笔记创作活动的的第5天
课堂内容
大数据处理链路
数据采集--数据处理--数据应用
开源大数据引擎:batch有Hadoop,Hive,Spark;streaming有Flink;OLAP有Presto,Clickhouse,Impala,DORIS
Spark具体介绍
- 2009年开始,2014年发布1.0版本
- 统一引擎,支持多种分布式场景
- 多语言支持(SQL,R,JAVA,Python,scala)
- 可读取丰富数据源(内置DataSource有Text,parquet/ORC,JSON/CSV,JDBC,还可以自定义DataSource)
- 丰富灵活的API算子(sparkcore里的RDD,sparkSQL的DataFrame)
- 支持K8S/YARN/Mesos资源调度
GraphX:图计算
spark structured streaming:spark中的流处理组件
MLlib:机器学习
spark的运行架构:首先用户会产生一个sparkcontext他是控制任务的生命周期的,他连接到cluster Manager,cluster manager会读取sparkcontext里的数据资源,再向worker node分配计算资源,启动Executor,执行task。同时Driver会将任务资源划分为不同的state,然后不同task负责state的不同分区,task准备完成就可以到worker node执行计算,并且实时返回运行状态,Driver会不断的进行状态更新和调用task直到完成任务。
三种部署方式:Local,standalone,YARN/K8S
Spark下载
spark的搭建
spark一个任务的样子
我们可以在spark UI上看到看到我们的运行内容,在TPC-DS/TPC-H benchmark中看到spark的性能。
sparkcore
sparkcore的核心是RDD,在RDD下去进行一系列的资源调度,内存管理和shuff等等。RDD(Resilient Distributed Dataset):弹性分布式数据集,是一个容错的、并行的数据结构。
- RDD五要素
- RDD的创建
- RDD算子
两类重要的算子:Transform算子和Action算子,前者用来生成新的RDD,后者用来触发JOb提交
- RDD的依赖性
窄依赖:父RDD的每一个partition只对应一个子RDD分区
NarrowDependency
OneToOneDependency
RangeDependency
PruneDependency
宽依赖:父RDD的每一个partition可以对应多个子RDD分区
shuffleDependency
- RDD的执行过程
首先stage的划分是有shuffle就划分一个,narrow就连接。然后由Action触发job,然后进行DAGshceduler的调度分配,这里的调度是按照顺序调度stage为每一个task生成taskset到taskshceduler,然后到taskshceduler里根据调度算法(FIFO/FAIR)对set进行调度,当被调度到,那么这个set所对应的task就到Executor上执行计算任务。
- Executor的内存: 执行内存,存储内存,自定义内存,预留内存。前两者可以相互借用
- shuffle:在map和reduce之间进行数据传输
- sortshuffle:就是这个数据不直接传过去,而是有一个排序的过程和一个加索引的过程,dateFlie是数据,indexFlie是数据索引。
- External shuffle service:是将这个数据和索引存储起来的地方或者说做法。
sparkSQL
组成和执行链路
Catalyst是sparkSQL的核心
Adaptive Query Execution是自身的查询
Runtime Fliter是过滤优化
Codegen是代码生成
SQL Query将代码转化为DAG的语法树,然后analysis进行分析并对节点的数据类型进行绑定,Catalog进行语法树的解析,就可以生成逻辑计划,然后进行RBO,CBO的优化,优化完进行物理转化成物理计划,再CBO的costModel筛选最好的物理计划,最后codeGeneration转化物理计划为RDD代码。
- RBO (规则)
- CBO(代价)
- AQE:自我优化数据运行的功能,通过Driver完成。
- AQE的优化方法:并,拆,改
- RuntimelyFlink:拿小表的特征筛选大表的数据,减少大表的遍历时间。
- Codegen的优化方式
Expression:就是将大量繁琐的重复计算,压缩到一个函数表达式中,减少计算的资源消耗。
WholeStageCodegen:将整火山模型的数据压平,可以理解为上面的解析式再加压。
- 火山模型
业界目前的挑战/难点
- shuffle的稳定性
- SQL的执行性能(目前是CPU的困境)
- 参数推荐(Doctor elephant)
- 作业诊断