1、spark的有几种部署模式,每种模式特点?(☆☆☆☆☆)
1)本地模式
Spark不肯定非要跑在hadoop集群,能够在本地,起多个线程的形式来指定。将Spark利用以多线程的形式间接运行在本地,个别都是为了不便调试,本地模式分三类
local:只启动一个executor
local[k]:启动k个executor
local[*]:启动跟cpu数目雷同的 executor
2)standalone模式
分布式部署集群,自带残缺的服务,资源管理和工作监控是Spark本人监控,这个模式也是其余模式的根底。
3)Spark on yarn模式
分布式部署集群,资源和工作监控交给yarn治理,然而目前仅反对粗粒度资源分配形式,蕴含cluster和client运行模式,cluster适宜生产,driver运行在集群子节点,具备容错性能,client适宜调试,dirver运行在客户端。
4)Spark On Mesos模式。
官网举荐这种模式(当然,起因之一是血缘关系)。正是因为Spark开发之初就思考到反对Mesos,因而,目前而言,Spark运行在Mesos上会比运行在YARN上更加灵便,更加天然。用户可抉择两种调度模式之一运行本人的应用程序:
(1)粗粒度模式(Coarse-grained Mode):每个应用程序的运行环境由一个Dirver和若干个Executor组成,其中,每个Executor占用若干资源,外部可运行多个Task(对应多少个“slot”)。应用程序的各个工作正式运行之前,须要将运行环境中的资源全副申请好,且运行过程中要始终占用这些资源,即便不必,最初程序运行完结后,回收这些资源。
(2)细粒度模式(Fine-grained Mode):鉴于粗粒度模式会造成大量资源节约,Spark On Mesos还提供了另外一种调度模式:细粒度模式,这种模式相似于当初的云计算,思维是按需分配。
2、Spark为什么比mapreduce快?(☆☆☆☆☆)
1)基于内存计算,缩小低效的磁盘交互;
2)高效的调度算法,基于DAG;
3)容错机制Linage,精髓局部就是DAG和Lingae
3、简略说一下hadoop和spark的shuffle雷同和差别?(☆☆☆☆☆)
1)从 high-level 的角度来看,两者并没有大的差异。 都是将 mapper(Spark 里是 ShuffleMapTask)的输入进行 partition,不同的 partition 送到不同的 reducer(Spark 里 reducer 可能是下一个 stage 里的 ShuffleMapTask,也可能是 ResultTask)。Reducer 以内存作缓冲区,边 shuffle 边 aggregate 数据,等到数据 aggregate 好当前进行 reduce() (Spark 里可能是后续的一系列操作)。
2)从 low-level 的角度来看,两者差异不小。 Hadoop MapReduce 是 sort-based,进入 combine() 和 reduce() 的 records 必须先 sort。这样的益处在于 combine/reduce() 能够解决大规模的数据,因为其输出数据能够通过外排失去(mapper 对每段数据先做排序,reducer 的 shuffle 对排好序的每段数据做归并)。目前的 Spark 默认抉择的是 hash-based,通常应用 HashMap 来对 shuffle 来的数据进行 aggregate,不会对数据进行提前排序。如果用户须要通过排序的数据,那么须要本人调用相似 sortByKey() 的操作;如果你是Spark 1.1的用户,能够将spark.shuffle.manager设置为sort,则会对数据进行排序。在Spark 1.2中,sort将作为默认的Shuffle实现。
3)从实现角度来看,两者也有不少差异。 Hadoop MapReduce 将解决流程划分出显著的几个阶段:map(), spill, merge, shuffle, sort, reduce() 等。每个阶段各司其职,能够依照过程式的编程思维来逐个实现每个阶段的性能。在 Spark 中,没有这样性能明确的阶段,只有不同的 stage 和一系列的 transformation(),所以 spill, merge, aggregate 等操作须要蕴含在 transformation() 中。
如果咱们将 map 端划分数据、长久化数据的过程称为 shuffle write,而将 reducer 读入数据、aggregate 数据的过程称为 shuffle read。那么在 Spark 中,问题就变为怎么在 job 的逻辑或者物理执行图中退出 shuffle write 和 shuffle read的解决逻辑?以及两个解决逻辑应该怎么高效实现?
Shuffle write因为不要求数据有序,shuffle write 的工作很简略:将数据 partition 好,并长久化。之所以要长久化,一方面是要缩小内存存储空间压力,另一方面也是为了 fault-tolerance。
4、spark工作机制?(☆☆☆☆☆)
① 构建Application的运行环境,Driver创立一个SparkContext
② SparkContext向资源管理器(Standalone、Mesos、Yarn)申请Executor资源,资源管理器启动StandaloneExecutorbackend(Executor)
③ Executor向SparkContext申请Task
④ SparkContext将应用程序分发给Executor
⑤ SparkContext就建成DAG图,DAGScheduler将DAG图解析成Stage,每个Stage有多个task,造成taskset发送给task Scheduler,由task Scheduler将Task发送给Executor运行
⑥ Task在Executor上运行,运行完开释所有资源
5、spark的优化怎么做? (☆☆☆☆☆)
spark调优比较复杂,然而大体能够分为三个方面来进行
1)平台层面的调优:避免不必要的jar包散发,进步数据的本地性,抉择高效的存储格局如parquet
2)应用程序层面的调优:过滤操作符的优化升高过多小工作,升高单条记录的资源开销,解决数据歪斜,复用RDD进行缓存,作业并行化执行等等
3)JVM层面的调优:设置适合的资源量,设置正当的JVM,启用高效的序列化办法如kyro,增大off head内存等等
6、数据本地性是在哪个环节确定的?(☆☆☆☆☆)
具体的task运行在那他机器上,dag划分stage的时候确定的
7、RDD的弹性体现在哪几点?(☆☆☆☆☆)
1)主动的进行内存和磁盘的存储切换;
2)基于Lineage的高效容错;
3)task如果失败会主动进行特定次数的重试;
4)stage如果失败会主动进行特定次数的重试,而且只会计算失败的分片;
5)checkpoint和persist,数据计算之后长久化缓存;
6)数据调度弹性,DAG TASK调度和资源无关;
7)数据分片的高度弹性。
8、RDD有哪些缺点?(☆☆☆☆☆)
1)不反对细粒度的写和更新操作(如网络爬虫),spark写数据是粗粒度的。所谓粗粒度,就是批量写入数据,为了提高效率。然而读数据是细粒度的也就是说能够一条条的读。
2)不反对增量迭代计算,Flink反对
9、Spark的shuffle过程?(☆☆☆☆☆)
从上面三点去开展
1)shuffle过程的划分
2)shuffle的两头后果如何存储
3)shuffle的数据如何拉取过去
能够参考这篇博文:http://www.cnblogs.com/jxhd1/...
10、 Spark的数据本地性有哪几种?(☆☆☆☆☆)
Spark中的数据本地性有三种:
1)PROCESS_LOCAL是指读取缓存在本地节点的数据
2)NODE_LOCAL是指读取本地节点硬盘数据
3)ANY是指读取非本地节点数据
通常读取数据PROCESS_LOCAL>NODE_LOCAL>ANY,尽量使数据以PROCESS_LOCAL或NODE_LOCAL形式读取。其中PROCESS_LOCAL还和cache无关,如果RDD常常用的话将该RDD cache到内存中,留神,因为cache是lazy的,所以必须通过一个action的触发,能力真正的将该RDD cache到内存中。
11、Spark为什么要长久化,个别什么场景下要进行persist操作?(☆☆☆)
为什么要进行长久化?
spark所有简单一点的算法都会有persist身影,spark默认数据放在内存,spark很多内容都是放在内存的,非常适合高速迭代,1000个步骤只有第一个输出数据,两头不产生长期数据,但分布式系统危险很高,所以容易出错,就要容错,rdd出错或者分片能够依据血统算进去,如果没有对父rdd进行persist 或者cache的化,就须要重头做。
以下场景会应用persist
1)某个步骤计算十分耗时,须要进行persist长久化
2)计算链条十分长,从新复原要算很多步骤,很好使,persist
3)checkpoint所在的rdd要长久化persist。checkpoint前,要长久化,写个rdd.cache或者rdd.persist,将后果保存起来,再写checkpoint操作,这样执行起来会十分快,不须要从新计算rdd链条了。checkpoint之前肯定会进行persist。
4)shuffle之后要persist,shuffle要进性网络传输,危险很大,数据失落重来,复原代价很大
5)shuffle之前进行persist,框架默认将数据长久化到磁盘,这个是框架主动做的。
12、介绍一下join操作优化教训?(☆☆☆☆☆)
join其实常见的就分为两类: map-side join 和 reduce-side join。当大表和小表join时,用map-side join能显著提高效率。将多份数据进行关联是数据处理过程中十分广泛的用法,不过在分布式计算零碎中,这个问题往往会变的十分麻烦,因为框架提供的 join 操作个别会将所有数据依据 key 发送到所有的 reduce 分区中去,也就是 shuffle 的过程。造成大量的网络以及磁盘IO耗费,运行效率极其低下,这个过程个别被称为 reduce-side-join。如果其中有张表较小的话,咱们则能够本人实现在 map 端实现数据关联,跳过大量数据进行 shuffle 的过程,运行工夫失去大量缩短,依据不同数据可能会有几倍到数十倍的性能晋升。
备注:这个题目面试中十分十分大概率见到,务必搜寻相干材料把握,这里抛砖引玉。
13、形容Yarn执行一个工作的过程?(☆☆☆☆☆)
1)客户端client向ResouceManager提交Application,ResouceManager承受Application并依据集群资源情况选取一个node来启动Application的任务调度器driver(ApplicationMaster)。
2)ResouceManager找到那个node,命令其该node上的nodeManager来启动一个新的 JVM过程运行程序的driver(ApplicationMaster)局部,driver(ApplicationMaster)启动时会首先向ResourceManager注册,阐明由本人来负责以后程序的运行。
3)driver(ApplicationMaster)开始下载相干jar包等各种资源,基于下载的jar等信息决定向ResourceManager申请具体的资源内容。
4)ResouceManager承受到driver(ApplicationMaster)提出的申请后,会最大化的满足 资源分配申请,并发送资源的元数据信息给driver(ApplicationMaster)。
5)driver(ApplicationMaster)收到发过来的资源元数据信息后会依据元数据信息发指令给具体机器上的NodeManager,让其启动具体的container。
6)NodeManager收到driver发来的指令,启动container,container启动后必须向driver(ApplicationMaster)注册。
7)driver(ApplicationMaster)收到container的注册,开始进行工作的调度和计算,直到 工作实现。
留神:如果ResourceManager第一次没有可能满足driver(ApplicationMaster)的资源申请 ,后续发现有闲暇的资源,会被动向driver(ApplicationMaster)发送可用资源的元数据信息以提供更多的资源用于以后程序的运行。
14、Spark on Yarn 模式有哪些长处?(☆☆☆☆☆)
1)与其余计算框架共享集群资源(Spark框架与MapReduce框架同时运行,如果不必Yarn进行资源分配,MapReduce分到的内存资源会很少,效率低下);资源按需分配,进而进步集群资源利用等。
2)相较于Spark自带的Standalone模式,Yarn的资源分配更加粗疏。
3)Application部署简化,例如Spark,Storm等多种框架的利用由客户端提交后,由Yarn负责资源的治理和调度,利用Container作为资源隔离的单位,以它为单位去应用内存,cpu等。
4)Yarn通过队列的形式,治理同时运行在Yarn集群中的多个服务,可依据不同类型的应用程序负载状况,调整对应的资源使用量,实现资源弹性治理。
15、谈谈你对container的了解?(☆☆☆☆☆)
1)Container作为资源分配和调度的根本单位,其中封装了的资源如内存,CPU,磁盘,网络带宽等。 目前yarn仅仅封装内存和CPU
2)Container由ApplicationMaster向ResourceManager申请的,由ResouceManager中的资源调度器异步调配给ApplicationMaster
3)Container的运行是由ApplicationMaster向资源所在的NodeManager发动的,Container运行时需提供外部执行的工作命令
16、Spark应用parquet文件存储格局能带来哪些益处?(☆☆☆☆☆)
1)如果说HDFS是大数据时代分布式文件系统首选规范,那么parquet则是整个大数据时代文件存储格局实时首选规范。
2)速度更快:从应用spark sql操作一般文件CSV和parquet文件速度比照上看,绝大多数状况会比应用csv等一般文件速度晋升10倍左右,在一些一般文件系统无奈在spark上胜利运行的状况下,应用parquet很多时候能够胜利运行。
3)parquet的压缩技术十分稳固杰出,在spark sql中对压缩技术的解决可能无奈失常的实现工作(例如会导致lost task,lost executor)然而此时如果应用parquet就能够失常的实现。
4)极大的缩小磁盘I/o,通常状况下可能缩小75%的存储空间,由此能够极大的缩小spark sql解决数据的时候的数据输出内容,尤其是在spark1.6x中有个下推过滤器在一些状况下能够极大的缩小磁盘的IO和内存的占用,(下推过滤器)。
5)spark 1.6x parquet形式极大的晋升了扫描的吞吐量,极大进步了数据的查找速度spark1.6和spark1.5x相比而言,晋升了大概1倍的速度,在spark1.6X中,操作parquet时候cpu也进行了极大的优化,无效的升高了cpu耗费。
6)采纳parquet能够极大的优化spark的调度和执行。咱们测试spark如果用parquet能够无效的缩小stage的执行耗费,同时能够优化执行门路。
17、介绍parition和block有什么关联关系?(☆☆☆☆☆)
1)hdfs中的block是分布式存储的最小单元,等分,可设置冗余,这样设计有一部分磁盘空间的节约,然而参差的block大小,便于疾速找到、读取对应的内容;
2)Spark中的partion是弹性分布式数据集RDD的最小单元,RDD是由散布在各个节点上的partion组成的。partion是指的spark在计算过程中,生成的数据在计算空间内最小单元,同一份数据(RDD)的partion大小不一,数量不定,是依据application里的算子和最后读入的数据分块数量决定;
3)block位于存储空间、partion位于计算空间,block的大小是固定的、partion大小是不固定的,是从2个不同的角度去看数据。
18、Spark应用程序的执行过程是什么?(☆☆☆☆☆)
1)构建Spark Application的运行环境(启动SparkContext),SparkContext向资源管理器(能够是Standalone、Mesos或YARN)注册并申请运行Executor资源;
2)资源管理器调配Executor资源并启动StandaloneExecutorBackend,Executor运行状况将随着心跳发送到资源管理器上;
3)SparkContext构建成DAG图,将DAG图分解成Stage,并把Taskset发送给Task Scheduler。Executor向SparkContext申请Task,Task Scheduler将Task发放给Executor运行同时SparkContext将利用程序代码发放给Executor;
4)Task在Executor上运行,运行结束开释所有资源。
19、不须要排序的hash shuffle是否肯定比须要排序的sort shuffle速度快?(☆☆☆☆☆)
不肯定,当数据规模小,Hash shuffle快于Sorted Shuffle数据规模大的时候;当数据量大,sorted Shuffle会比Hash shuffle快很多,因为数量大的有很多小文件,不平均,甚至呈现数据歪斜,耗费内存大,1.x之前spark应用hash,适宜解决中小规模,1.x之后,减少了Sorted shuffle,Spark更能胜任大规模解决了。
20、Sort-based shuffle的缺点? (☆☆☆☆☆)
1)如果mapper中task的数量过大,依旧会产生很多小文件,此时在shuffle传递数据的过程中reducer段,reduce会须要同时大量的记录进行反序列化,导致大量的内存耗费和GC的微小累赘,造成零碎迟缓甚至解体。
2)如果须要在分片内也进行排序,此时须要进行mapper段和reducer段的两次排序。
21、spark.storage.memoryFraction参数的含意,理论生产中如何调优?(☆☆☆☆☆)
1)用于设置RDD长久化数据在Executor内存中能占的比例,默认是0.6,,默认Executor 60%的内存,能够用来保留长久化的RDD数据。依据你抉择的不同的长久化策略,如果内存不够时,可能数据就不会长久化,或者数据会写入磁盘;
2)如果长久化操作比拟多,能够进步spark.storage.memoryFraction参数,使得更多的长久化数据保留在内存中,进步数据的读取性能,如果shuffle的操作比拟多,有很多的数据读写操作到JVM中,那么应该调小一点,节约出更多的内存给JVM,防止过多的JVM gc产生。在web ui中察看如果发现gc工夫很长,能够设置spark.storage.memoryFraction更小一点。
22、介绍一下你对Unified Memory Management内存治理模型的了解?(☆☆☆☆☆)
Spark中的内存应用分为两局部:执行(execution)与存储(storage)。执行内存次要用于shuffles、joins、sorts和aggregations,存储内存则用于缓存或者跨节点的外部数据传输。1.6之前,对于一个Executor,内存都由以下局部形成:
1)ExecutionMemory。这片内存区域是为了解决 shuffles,joins, sorts and aggregations 过程中为了防止频繁IO须要的buffer。 通过spark.shuffle.memoryFraction(默认 0.2) 配置。
2)StorageMemory。这片内存区域是为了解决 block cache(就是你显示调用rdd.cache, rdd.persist等办法), 还有就是broadcasts,以及task results的存储。能够通过参数 spark.storage.memoryFraction(默认0.6)设置。
3)OtherMemory。给零碎预留的,因为程序自身运行也是须要内存的(默认为0.2)。
传统内存治理的有余:
1)Shuffle占用内存0.2*0.8,内存调配这么少,可能会将数据spill到磁盘,频繁的磁盘IO是很大的累赘,Storage内存占用0.6,次要是为了迭代解决。传统的Spark内存调配对操作人的要求十分高。(Shuffle分配内存:ShuffleMemoryManager, TaskMemoryManager, ExecutorMemoryManager)一个Task取得全副的Execution的Memory,其余Task过去就没有内存了,只能期待;
2)默认状况下,Task在线程中可能会占满整个内存,分片数据