Spark的复习
- Spark的运行流程
在说这个问题之前，我们可以看下Spark的主键
可以分为master，负责管理整个集群，worker，负责节点的计算
这是物理层面的
而在逻辑层面上呢，则是Driver，负责运行程序的main的方法，
以及提交jar包之后会生成的spark context，负责job的执行分配
具体的流程就是，SparkContext向资源管理器注册并向着资源管理器申请运行Executor
资源管理器分配 Executor，然后资源管理器启动 Executor
Executor 发送心跳至资源管理器
SparkContext 构建 DAG 有向无环图
将 DAG 分解成 Stage（TaskSet）
把 Stage 发送给 TaskScheduler
Executor 向 SparkContext 申请 Task
TaskScheduler 将 Task 发送给 Executor 运行
同时 SparkContext 将应用程序代码发放给 Executor
Task 在Executor上运行，运行完成释放资源
- Spark中的RDD解释
RDD是Spark中的分布式数据集，可以理解为一种数据结构，其本身是存放在各个Task节点上的数据，在外在来看则是block和node之间的映射
因为并不是物理层面的实际数据，而是存放在各个Task节点上的数据，那么本质上就是一个抽象数据合集，所以就可以进行并行操作，比如有一个RDD，有90W数据，分为3个partition，每个分区都有30W数据，但在操作层面，我们会将这90W数据作为一个整体来看待。
- RDD中的reduceBykey和groupByKey的区别呢？
reduceBykey：将结果发给reduce之前，会在shuffle之前进行本地的merge，提前进行数据汇聚，能减少数据量交互
groupBykey：则是将本地聚合的原本数据数组发送给reduce端，会造成大量的数据交互
- Cgroup是什么？
是其中的一个函数，主要是针对多个RDD的进行聚合，可以将多个RDD中的相同key的数据进行合并
类似join的概念，比如两个RDD进行cogroup，那么返回的RDD的实例中的value包含两个Iterable的值，其中第一个值是RDD1中的值，第二个是RDD2中的值
- RDD中的宽窄依赖
对于RDD中的宽窄依赖，则是根据在分区后，会被多少个分区依赖来划分，如果一个分区会被多个子分区依赖，也就是涉及到了shuffle操作
对于这个窄依赖，直接运行就行，因为不涉及到task之间的交换
而对于宽依赖，则是需要等待上一阶段计算完成才能计算下一阶段
- Spark中的DAG
这个很简单，就是一个有向无环图，这是Spark Context在启动之后，联系Executor中的DAG Scheduler生成的运算流程
其中比较重要的概念是Stage，这个Stage则是DAG中的不同阶段，其划分的依据就是是否存在Shuffle操作
划分DAG的算法也很简单，本质上就是根据Action 算子，从这个算子开始往前推算。然后根据算子之间的操作是否存在Shuffle来进行划分
- Spark中的数据倾斜怎么解决
可以尝试方法reduce的算子数量，但是本质上指标不治本，还是数据本身的问题，可以考虑增加前缀或者替换partitioner来修改key 的分布
- Spark中的OOM问题
Map端的算子比如执行flatmap出现的错误，或者mapPartitions
Map端产生了大量的对象
这种情况，要么更换实际部署的集群内存，要么考虑增大涉及到的Task数量
或者drvier端出现了内存溢出
用户会在Dirver端生成了大对象，比如创建了一个大的集合数据结构，那么可以考虑增大driver端的内存
Shuffle后的内存溢出，那么也是考虑增大reduce的数量最好
- Spark中的数据位置是谁管理的
都是由BlockManager管理的，
按照数据来源内存还是磁盘，可以分为MemoryStore或者DiskBlockManager
- Spark中的join操作优化经验
对于其join，可以大致分为两类，分别是board join和shuffle join
对于board join则是直接将自己广播出去，这样需要占用driver空间，但是在join的时候速度更快，其次是shuffle join，因为设计到了shuffle的过程，所以会造成大量的网络和磁盘io的消耗，效率地下，这个过程是shuffle join
其次是对于join的建议，最好选择小表进行广播，除此之外就是进行提前的filter，可以减少join时的数据交换，从而提高效率。
- Spark和MapReduce的shuffle区别
虽然都是按照分区进行不同的分发，但是实际上Spark的Shuffle并不涉及到sort操作，而MR则是涉及到了排序
初次之外就是Spark在shuffle中尽量不落盘，而MR会进行落盘
- Spark的SQL执行过程
主要是因为Spark Sql 是基于Spark core之上封装的框架，核心本质还是没离开Spark Core
而Spark SQL中内部核心组件主要是由Catalyst和Tungsten
分别对应着生成执行语法树和实际的执行
对于语法树的生成，则是分为了parser，analyer，缓存替换，logical plan，生成spark plan
Spark plan准备阶段，构造RDD
最后交给Spark Core进行实际执行
- Spark怎么和Hive中的存储交互的
可以先直接输出为HDFS的文件，然后基于这个文件进行映射
或者利用相关的算子，直接插入到Hive表中，这种插入的方式可以使用JavaBean做映射，或者使用StructType进行映射。
- Spark的高效率来源
主要来源于内存计算，减少和磁盘的交互
高效的调度算法，基于DAG
- Hadoop和Spark的相同和不同处
对于算子的包括范围，Hadoop支持的操作较少，只有map和reduce两种，而Spark涉及的算子很多，比如map reduce filter flatmap groupbykey等
对于中间状态，MR则会涉及到大量的磁盘IO读写，但是spark中间涉及的内存较多，可能在Shuffle中涉及OOM
最后是阶段，MR中由于只存在Map 和 reduce操作，可能涉及的阶段就两个，但是Spark则是涉及了多个阶段。
- Hadoop和Spark使用场景
由于Hadoop的使用简单，不易宕机，更适合做离线型数据分析
而Spark更适合做一些迭代式的数据分析
- Spark中的Checkpoint机制
由于在Spark中，代码是按照阶段进行分割的，那么在其中如果某些Stage已经执行完成了，这时候发生了崩溃，那么如果重启之后，理论上应该跳过这些Stage，那么我们就需要进行跳过某些已经执行过的Stage，为了支持跳过，那么我们引申出来了检查点机制，其主要负责控制发生失败的时候重新计算的状态数
- Checkpoint和持久化机制的区别
对于持久话数据，则就是为了复用而进行持久化保存的，而checkpoint则不相同，则是为了进行在执行过程中，为了避免在多阶段执行过程中，出现数据丢失的问题。
- Spark Streaming以及基本原理
Spark Streaming也是基于Spark Core的一个扩展，利用秒级别的rdd，来做到实时处理的概念。可以从Kafka，Flume等消息引擎中读取数据，也可以使用spark的基本算子。
- DStream的基本工作原理
Spark Stream提供的一种类似DataFrame的高级抽象，可以给予数据源创建，比如Kafka，也可以从其他的DataFeam中创建而来，比如map reduce等。
- Spark Streaming 整合Kafka的两种模式
可以使用receiver进行使用，不过这样需要利用zookeeper进行偏移量的维护，这种方式效率低下，容易出现数据丢失。
这种方式下，如果需要进行高可用，需要启用Spark Streaming的预写日志机制，会讲Kafka的数据先写入到HDFS中，然后之后进行恢复。
除此外就是Direct的方式，这个是直接连接Kafka的分区之上，这样创建的RDD分区和Kafka的分区进行一一对应，而且在高可用的时候，只需要维护偏移量，在出现错误的时候，利用checkpoint恢复即可
- Spark的主备切换
Spark支持两种主备的方式，一种是基于文件系统的，这个需要在挂掉之后手动切换
另一种是基于Zookeeper的方式，可以自动的切换Master。
- Spark的主备切换状态中能否进行作业提交
不能进行作业提交，但是现在正在运行的作业不受影响。