2018优就业人保合作
 上海
400-650-7353
首页 > 面试技巧 > 2018大数据面试题及答案超100道(spark、Java、Hadoop等)

2018大数据面试题及答案超100道(spark、Java、Hadoop等)

2018-09-14 20:35:33 来源:互联网 荐:IT资料豪华升级版,点击加群领取

本文2018大数据面试题及答案超100道(spark、Java、Hadoop等)由上海优就业整理。

有更多IT面试题

上海优就业为求职转行者答疑解惑,提供IT面试题、名企面试题、面试常见困惑解决方式、招聘信息、IT面试题汇总、HR会问的面试题汇总,在求职过程中,如遇到很难解决的问题,欢迎扫描文章底部官微,后台可直接询问小编,或加群找小伙伴一起探讨,祝面试顺利。

面试问题(一)

kafka的message包括哪些信息

一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成

header部分由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body消息体是否正常)构成。当magic的值为1的时候,会在magic和crc32之间多一个字节的数据:attributes(保存一些相关属性,比如是否压缩、压缩格式等等);如果magic的值为0,那么不存在attributes属性

body是由N个字节构成的一个消息体,包含了具体的key/value消息

怎么查看kafka的offset

0.9版本以上,可以用最新的Consumer client 客户端,有consumer.seekToEnd() / consumer.position() 可以用于得到当前最新的offset:

hadoop的shuffle过程

一、Map端的shuffle

Map端会处理输入数据并产生中间结果,这个中间结果会写到本地磁盘,而不是HDFS。每个Map的输出会先写到内存缓冲区中,当写入的数据达到设定的阈值时,系统将会启动一个线程将缓冲区的数据写到磁盘,这个过程叫做spill。

在spill写入之前,会先进行二次排序,首先根据数据所属的partition进行排序,然后每个partition中的数据再按key来排序。partition的目是将记录划分到不同的Reducer上去,以期望能够达到负载均衡,以后的Reducer就会根据partition来读取自己对应的数据。接着运行combiner(如果设置了的话),combiner的本质也是一个Reducer,其目的是对将要写入到磁盘上的文件先进行一次处理,这样,写入到磁盘的数据量就会减少。最后将数据写到本地磁盘产生spill文件(spill文件保存在{mapred.local.dir}指定的目录中,Map任务结束后就会被删除)。

最后,每个Map任务可能产生多个spill文件,在每个Map任务完成前,会通过多路归并算法将这些spill文件归并成一个文件。至此,Map的shuffle过程就结束了。

二、Reduce端的shuffle

Reduce端的shuffle主要包括三个阶段,copy、sort(merge)和reduce。

首先要将Map端产生的输出文件拷贝到Reduce端,但每个Reducer如何知道自己应该处理哪些数据呢?因为Map端进行partition的时候,实际上就相当于指定了每个Reducer要处理的数据(partition就对应了Reducer),所以Reducer在拷贝数据的时候只需拷贝与自己对应的partition中的数据即可。每个Reducer会处理一个或者多个partition,但需要先将自己对应的partition中的数据从每个Map的输出结果中拷贝过来。

接下来就是sort阶段,也成为merge阶段,因为这个阶段的主要工作是执行了归并排序。从Map端拷贝到Reduce端的数据都是有序的,所以很适合归并排序。最终在Reduce端生成一个较大的文件作为Reduce的输入。

最后就是Reduce过程了,在这个过程中产生了最终的输出结果,并将其写到HDFS上。

spark集群运算的模式

Spark 有很多种模式,最简单就是单机本地模式,还有单机伪分布式模式,复杂的则运行在集群中,目前能很好的运行在 Yarn和 Mesos 中,当然 Spark 还有自带的 Standalone 模式,对于大多数情况 Standalone 模式就足够了,如果企业已经有 Yarn 或者 Mesos 环境,也是很方便部署的。

standalone(集群模式):典型的Mater/slave模式,不过也能看出Master是有单点故障的;Spark支持ZooKeeper来实现 HA

on yarn(集群模式): 运行在 yarn 资源管理器框架之上,由 yarn 负责资源管理,Spark 负责任务调度和计算

on mesos(集群模式): 运行在 mesos 资源管理器框架之上,由 mesos 负责资源管理,Spark 负责任务调度和计算

on cloud(集群模式):比如 AWS 的 EC2,使用这个模式能很方便的访问 Amazon的 S3;Spark 支持多种分布式存储系统:HDFS 和 S3

HDFS读写数据的过程

读:

1、跟namenode通信查询元数据,找到文件块所在的datanode服务器

2、挑选一台datanode(就近原则,然后随机)服务器,请求建立socket流

3、datanode开始发送数据(从磁盘里面读取数据放入流,以packet为单位来做校验)

4、客户端以packet为单位接收,现在本地缓存,然后写入目标文件

写:

1、根namenode通信请求上传文件,namenode检查目标文件是否已存在,父目录是否存在

2、namenode返回是否可以上传

3、client请求第一个 block该传输到哪些datanode服务器上

4、namenode返回3个datanode服务器ABC

5、client请求3台dn中的一台A上传数据(本质上是一个RPC调用,建立pipeline),A收到请求会继续调用B,然后B调用C,将真个pipeline建立完成,逐级返回客户端

6、client开始往A上传第一个block(先从磁盘读取数据放到一个本地内存缓存),以packet为单位,A收到一个packet就会传给B,B传给C;A每传一个packet会放入一个应答队列等待应答

7、当一个block传输完成之后,client再次请求namenode上传第二个block的服务器。

RDD中reduceBykey与groupByKey哪个性能好,为什么

reduceByKey:reduceByKey会在结果发送至reducer之前会对每个mapper在本地进行merge,有点类似于在MapReduce中的combiner。这样做的好处在于,在map端进行一次reduce之后,数据量会大幅度减小,从而减小传输,保证reduce端能够更快的进行结果计算。

groupByKey:groupByKey会对每一个RDD中的value值进行聚合形成一个序列(Iterator),此操作发生在reduce端,所以势必会将所有的数据通过网络进行传输,造成不必要的浪费。同时如果数据量十分大,可能还会造成OutOfMemoryError。

通过以上对比可以发现在进行大量数据的reduce操作时候建议使用reduceByKey。不仅可以提高速度,还是可以防止使用groupByKey造成的内存溢出问题。

spark sql怎么取数据的差集

好像不支持

spark2.0的了解

更简单:ANSI SQL与更合理的API

速度更快:用Spark作为编译器

更智能:Structured Streaming

rdd 怎么分区宽依赖和窄依赖

宽依赖:父RDD的分区被子RDD的多个分区使用 例如 groupByKey、reduceByKey、sortByKey等操作会产生宽依赖,会产生shuffle

窄依赖:父RDD的每个分区都只被子RDD的一个分区使用 例如map、filter、等操作会产生窄依赖

spark streaming 读取kafka数据的两种方式

这两种方式分别是:

Receiver-base

使用Kafka的高层次Consumer API来实现。receiver从Kafka中获取的数据都存储在Spark Executor的内存中,然后Spark Streaming启动的job会去处理那些数据。然而,在默认的配置下,这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制,让数据零丢失,就必须启用Spark Streaming的预写日志机制(Write Ahead Log,WAL)。该机制会同步地将接收到的Kafka数据写入分布式文件系统(比如HDFS)上的预写日志中。所以,即使底层节点出现了失败,也可以使用预写日志中的数据进行恢复。

Direct

Spark1.3中引入Direct方式,用来替代掉使用Receiver接收数据,这种方式会周期性地查询Kafka,获得每个topic+partition的最新的offset,从而定义每个batch的offset的范围。当处理数据的job启动时,就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。

kafka的数据存在内存还是磁盘

Kafka最核心的思想是使用磁盘,而不是使用内存,可能所有人都会认为,内存的速度一定比磁盘快,我也不例外。在看了Kafka的设计思想,查阅了相应资料再加上自己的测试后,发现磁盘的顺序读写速度和内存持平。

而且Linux对于磁盘的读写优化也比较多,包括read-ahead和write-behind,磁盘缓存等。如果在内存做这些操作的时候,一个是JAVA对象的内存开销很大,另一个是随着堆内存数据的增多,JAVA的GC时间会变得很长,使用磁盘操作有以下几个好处:

磁盘缓存由Linux系统维护,减少了程序员的不少工作。

磁盘顺序读写速度超过内存随机读写。

JVM的GC效率低,内存占用大。使用磁盘可以避免这一问题。

系统冷启动后,磁盘缓存依然可用。

怎么解决kafka的数据丢失

producer端:

宏观上看保证数据的可靠安全性,肯定是依据分区数做好数据备份,设立副本数。

broker端:

topic设置多分区,分区自适应所在机器,为了让各分区均匀分布在所在的broker中,分区数要大于broker数。

分区是kafka进行并行读写的单位,是提升kafka速度的关键。

Consumer端

consumer端丢失消息的情形比较简单:如果在消息处理完成前就提交了offset,那么就有可能造成数据的丢失。由于Kafka consumer默认是自动提交位移的,所以在后台提交位移前一定要保证消息被正常处理了,因此不建议采用很重的处理逻辑,如果处理耗时很长,则建议把逻辑放到另一个线程中去做。为了避免数据丢失,现给出两点建议:

enable.auto.commit=false 关闭自动提交位移

在消息被完整处理之后再手动提交位移

hadoop 的 namenode 宕机,怎么解决

先分析宕机后的损失,宕机后直接导致client无法访问,内存中的元数据丢失,但是硬盘中的元数据应该还存在,如果只是节点挂了,

重启即可,如果是机器挂了,重启机器后看节点是否能重启,不能重启就要找到原因修复了。但是最终的解决方案应该是在设计集群的初期

就考虑到这个问题,做namenode的HA。

一个datanode 宕机,怎么一个流程恢复

Datanode宕机了后,如果是短暂的宕机,可以实现写好脚本监控,将它启动起来。如果是长时间宕机了,那么datanode上的数据应该已经

被备份到其他机器了,那这台datanode就是一台新的datanode了,删除他的所有数据文件和状态文件,重新启动。

Hbase 的特性,以及你怎么去设计 rowkey 和 columnFamily ,怎么去建一个table

因为hbase是列式数据库,列非表schema的一部分,所以在设计初期只需要考虑rowkey 和 columnFamily即可,rowkey有位置相关性,所以

如果数据是练习查询的,最好对同类数据加一个前缀,而每个columnFamily实际上在底层是一个文件,那么文件越小,查询越快,所以讲经

常一起查询的列设计到一个列簇,但是列簇不宜过多。

Redis,传统数据库,hbase,hive 每个之间的区别(问的非常细)

Redis是缓存,围绕着内存和缓存说

Hbase是列式数据库,存在hdfs上,围绕着数据量来说

Hive是数据仓库,是用来分析数据的,不是增删改查数据的。

公司之后倾向用spark 开发,你会么(就用java代码去写)

会,spark使用scala开发的,在scala中可以随意使用jdk的类库,可以用java开发,但是最好用原生的scala开发,兼容性好,scala更灵活。

面试问题(二)

1.笔试: java基础(基本全忘,做的很烂,复习大数据连单例都忘了怎么写)

复习java面试宝典

2.开始介绍项目,直接用大数据项目介绍,项目经理也懂大数据

3.Mapreduce 一些流程,经过哪些步骤

Map—combiner—partition—sort—copy—sort—grouping—reduce

4.说下对hadoop 的一些理解,包括哪些组件

详谈hadoop的应用,包括的组件分为三类,分别说明hdfs,yarn,mapreduce

5.详细讲解下你流式实时计算的项目部署以及收集的结果情况

讲解storm集群的部署方案,项目的大小,使用的worker数,数据收集在hbase或者hdfs,好处是什么

6.你的数据库是不是很大么,有没有分表,分区,你是怎么实现的

数据库的分表在设计初期是按照月份进行拆分的,不同的月份查询不同的表。分区没弄过。

7.开始问java的一些东西(从各种框架原理到各种复杂SQL)

8.多线程,并发,垃圾回收机制,数据结构(问这些,基本觉得看你是不是高级程序员了)

多线程要知道操作方式,线程安全的锁,并且要知道lock锁

垃圾回收机制需要详细了解(见云笔记),主要从内存划分,垃圾回收主要的工作区域,垃圾回收器的种类,各有什么优缺点,

用在哪里合适。

数据结构基本的要知道,复杂的参考相关的书籍。

面试问题(三)

2.数据量多少,集群规模多大,型号

一般中型的电商或者互联网企业,日志量每天在200-500M左右,集群规模在30-50台左右,机器一般为dell的2000左右的服务器,型号不定

大型的互联网公司据网上资料显示,日志量在GP-PB不等,集群规模在500-4000不等,甚至更多,机器型号不确定。

3.项目,mapreduce

介绍整个mapreduce项目流程,数据采集—数据聚合—数据分析—数据展示等

4.实时流式计算框架,几个人,多长时间,细节问题,包括讲flume ,kafka ,storm 的各个的组件组成,你负责那一块,如果需要你搭建你可以

完成么?

5.你觉得spark 可以完全替代hadoop 么?

面试问题(四)

1.一些传统的hadoop 问题,mapreduce 他就问shuffle 阶段,你怎么理解的

Shuffle意义在于将不同map处理后的数据进行合理分配,让reduce处理,从而产生了排序、分区。

2.Mapreduce 的 map 数量 和 reduce 数量 怎么确定 ,怎么配置

Map无法配置,reduce随便配置

3.唯一难住我的是他说实时计算,storm 如果碰上了复杂逻辑,需要算很长的时间,你怎么去优化

拆分复杂的业务到多个bolt中,这样可以利用bolt的tree将速度提升

4.Hive 你们用的是外部表还是内部表,有没有写过UDF(当然吹自己写过了),hive 的版本

外部表,udf,udaf等,hive版本为1.0

5.Hadoop 的版本

如果是1.0版本就说1.2,如果是2.0版本,就说2.6或者2.7

1.2为官方稳定版本,2.7为官方稳定版本。

Apache Hadoop 2.7.1于美国时间2015年07月06日正式发布,本版本属于稳定版本,是自Hadoop 2.6.0以来又一个稳定版,同时也是

Hadoop 2.7.x版本线的第一个稳定版本,也是 2.7版本线的维护版本,变化不大,主要是修复了一些比较严重的Bug

6.实时流式计算的结果内容有哪些,你们需要统计出来么(我就说highchart展示)

简单介绍日志监控、风控等结果内容,统计出来显示在报表或者邮件中。

7.开始问java相关,包括luecne,solr(倒排索引的原理),框架呀,redis呀

京东商城 - 大数据面试问题(五)

(1)Java篇

1、JVM,GC(算法,新生代,老年代),JVM结构

2、hashcode,hashMap,list,hashSet,equals(结构原理),A extends B(类的加载顺序)

1.父类静态代码块;

2.子类静态代码块;

3.父类非静态代码块;

4.父类构造函数;

5.子类非静态代码块;

6.子类构造函数;

3、多线程,主线程,次线程,唤醒,睡眠

4、常见算法:冒泡算法,排序算法,二分查找,时间复杂度

(2)Flume篇

1、数据怎么采集到Kafka,实现方式

使用官方提供的flumeKafka插件,插件的实现方式是自定义了flume的sink,将数据从channle中取出,通过kafka的producer写入到kafka中,

可以自定义分区等。

2、flume管道内存,flume宕机了数据丢失怎么解决

1、Flume的channel分为很多种,可以将数据写入到文件

2、防止非首个agent宕机的方法数可以做集群或者主备

3、flume配置方式,flume集群(问的很详细)

Flume的配置围绕着source、channel、sink叙述,flume的集群是做在agent上的,而非机器上。

4、flume不采集Nginx日志,通过Logger4j采集日志,优缺点是什么?

优点:Nginx的日志格式是固定的,但是缺少sessionid,通过logger4j采集的日志是带有sessionid的,而session可以通过redis共享,

保证了集群日志中的同一session落到不同的tomcat时,sessionId还是一样的,而且logger4j的方式比较稳定,不会宕机。

缺点:不够灵活,logger4j的方式和项目结合过于紧密,而flume的方式比较灵活,拔插式比较好,不会影响项目性能。

spark streaming从1.2开始提供了数据的零丢失,想享受这个特性,需要满足如下条件:

1. 数据输入需要可靠的sources和可靠的receivers

2. 应用metadata必须通过应用driver checkpoint

3. WAL(write ahead log)

1.1. 可靠的sources和receivers

spark streaming可以通过多种方式作为数据sources(包括kafka),输入数据通过receivers接收,通过replication存储于spark中(为了faultolerance,默认复制到两个spark executors),如果数据复制完成,receivers可以知道(例如kafka中更新offsets到zookeeper中)。这样当receivers在接收数据过程中crash掉,不会有数据丢失,receivers没有复制的数据,当receiver恢复后重新接收。

1.2. metadata checkpoint

可靠的sources和receivers,可以使数据在receivers失败后恢复,然而在driver失败后恢复是比较复杂的,一种方法是通过checkpoint metadata到HDFS或者S3。metadata包括:

· configuration

· code

· 一些排队等待处理但没有完成的RDD(仅仅是metadata,而不是data)

这样当driver失败时,可以通过metadata checkpoint,重构应用程序并知道执行到那个地方。

1.3. 数据可能丢失的场景

可靠的sources和receivers,以及metadata checkpoint也不可以保证数据的不丢失,例如:

· 两个executor得到计算数据,并保存在他们的内存中

· receivers知道数据已经输入

· executors开始计算数据

· driver突然失败

· driver失败,那么executors都会被kill掉

· 因为executor被kill掉,那么他们内存中得数据都会丢失,但是这些数据不再被处理

· executor中的数据不可恢复

1.4. WAL

为了避免上面情景的出现,spark streaming 1.2引入了WAL。所有接收的数据通过receivers写入HDFS或者S3中checkpoint目录,这样当driver失败后,executor中数据丢失后,可以通过checkpoint恢复。

1.5. At-Least-Once

尽管WAL可以保证数据零丢失,但是不能保证exactly-once,例如下面场景:

· Receivers接收完数据并保存到HDFS或S3

· 在更新offset前,receivers失败了

· Spark Streaming以为数据接收成功,但是Kafka以为数据没有接收成功,因为offset没有更新到zookeeper

· 随后receiver恢复了

· 从WAL可以读取的数据重新消费一次,因为使用的kafka High-Level消费API,从zookeeper中保存的offsets开始消费

1.6. WAL的缺点

通过上面描述,WAL有两个缺点:

· 降低了receivers的性能,因为数据还要存储到HDFS等分布式文件系统

· 对于一些resources,可能存在重复的数据,比如Kafka,在Kafka中存在一份数据,在Spark Streaming也存在一份(以WAL的形式存储在hadoop API兼容的文件系统中)

1.7. Kafka direct API

为了WAL的性能损失和exactly-once,spark streaming1.3中使用Kafka direct API。非常巧妙,Spark driver计算下个batch的offsets,指导executor消费对应的topics和partitions。消费Kafka消息,就像消费文件系统文件一样。

1. 不再需要kafka receivers,executor直接通过Kafka API消费数据

2. WAL不再需要,如果从失败恢复,可以重新消费

3. exactly-once得到了保证,不会再从WAL中重复读取数据

1.8. 总结

主要说的是spark streaming通过各种方式来保证数据不丢失,并保证exactly-once,每个版本都是spark streaming越来越稳定,越来越向生产环境使用发展。

5、flume和kafka采集日志区别,采集日志时中间停了,怎么记录之前的日志。

Flume采集日志是通过流的方式直接将日志收集到存储层,而kafka试讲日志缓存在kafka集群,待后期可以采集到存储层。

Flume采集中间停了,可以采用文件的方式记录之前的日志,而kafka是采用offset的方式记录之前的日志。

(3)Kafka篇

1、容错机制

分区备份,存在主备partition

2、同一topic不同partition分区????

3、kafka数据流向

Producer leader partition follower partition(半数以上) consumer

4、kafka+spark-streaming结合丢数据怎么解决?5、kafka中存储目录data/dir.....topic1和topic2怎么存储的,存储结构,data.....目录下有多少个分区,每个分区的存储格式是什么样的?

1、topic是按照“主题名-分区”存储的

2、分区个数由配置文件决定

3、每个分区下最重要的两个文件是0000000000.log和000000.index,0000000.log以默认1G大小回滚。

(4)Hive篇

1、hive partition分区

分区表,动态分区

2、 和 override write区别?

:将某一张表中的数据写到另一张表中

override write:覆盖之前的内容。

3、假如一个分区的数据主部错误怎么通过hivesql删除hdfsalter table ptable drop partition (daytime='20140911',city='bj');

元数据,数据文件都删除,但目录daytime= 20140911还在

(5)Storm篇

1、开发流程,容错机制

开发流程:

1、写主类(设计spout和bolt的分发机制)

2、写spout收集数据

3、写bolt处理数据,根据数据量和业务的复杂程度,设计并行度。

容错机制:采用ack和fail进行容错,失败的数据重新发送。

2、storm和spark-streaming:为什么用storm不同spark-streaming

3、mr和spark区别,怎么理解spark-rdd

Mr是文件方式的分布式计算框架,是将中间结果和最终结果记录在文件中,map和reduce的数据分发也是在文件中。

spark是内存迭代式的计算框架,计算的中间结果可以缓存内存,也可以缓存硬盘,但是不是每一步计算都需要缓存的。

Spark-rdd是一个数据的分区记录集合………………

4、sqoop命令

sqoop import --connect jdbc:mysql://192.168.56.204:3306/sqoop --username hive --password hive --table jobinfo --target-dir /sqoop/test7 --inline-lob-limit 16777216 --fields-terminated-by '\t' -m 2

sqoop create-hive-table --connect jdbc:mysql://192.168.56.204:3306/sqoop --table jobinfo --username hive --password hive --hive-table sqtest --fields-terminated-by "\t" --lines-terminated-by "\n";

(6)Redis篇

1、基本操作,存储格式

(7)Mysql篇

1、mysql集群的分布式事务

京东自主开发分布式MYSQL集群系统

2、mysql性能优化(数据方面)

数据的分表、分库、分区

(6)Hadoop篇

1、hadoop HA 两个namenode和zk之间的通信,zk的选举机制?

HA是通过先后获取zk的锁决定谁是主

Zk的选举机制,涉及到全新机群的选主和数据恢复的选主

2、mr运行机制

3、yarn流程

1) 用户向YARN 中提交应用程序, 其中包括ApplicationMaster 程序、启动ApplicationMaster 的命令、用户程序等。

2) ResourceManager 为该应用程序分配第一个Container, 并与对应的NodeManager 通信,要求它在这个Container 中启动应用程序

的ApplicationMaster。

3) ApplicationMaster 首先向ResourceManager 注册, 这样用户可以直接通过ResourceManage 查看应用程序的运行状态,然后它将

为各个任务申请资源,并监控它的运行状态,直到运行结束,即重复步骤4~7。

4) ApplicationMaster 采用轮询的方式通过RPC 协议向ResourceManager 申请和领取资源。

5) 一旦ApplicationMaster 申请到资源后,便与对应的NodeManager 通信,要求它启动任务。

6) NodeManager 为任务设置好运行环境(包括环境变量、JAR 包、二进制程序等)后,将任务启动命令写到一个脚本中,并通过运行

该脚本启动任务。

7) 各个任务通过某个RPC 协议向ApplicationMaster 汇报自己的状态和进度,以让ApplicationMaster 随时掌握各个任务的运行状态,

从而可以在任务失败时重新启动任务。在应用程序运行过程中,用户可随时通过RPC 向ApplicationMaster 查询应用程序的当前运行状态。

8) 应用程序运行完成后,ApplicationMaster 向ResourceManager 注销并关闭自己。

(7)Hbase

1、涉及到概念,文档

(8)Spark篇

1、spark原理

Spark应用转换流程

1、 spark应用提交后,经历了一系列的转换,最后成为task在每个节点上执行

2、 RDD的Action算子触发Job的提交,生成RDD DAG

3、 由DAGScheduler将RDD DAG转化为Stage DAG,每个Stage中产生相应的Task集合

4、 TaskScheduler将任务分发到Executor执行

5、 每个任务对应相应的一个数据块,只用用户定义的函数处理数据块

Driver运行在Worker上

通过org.apache.spark.deploy.Client类执行作业,作业运行命令如下:

作业执行流程描述:

1、客户端提交作业给Master

2、Master让一个Worker启动Driver,即SchedulerBackend。Worker创建一个DriverRunner线程,DriverRunner启动SchedulerBackend进程。

3、另外Master还会让其余Worker启动Exeuctor,即ExecutorBackend。Worker创建一个ExecutorRunner线程,ExecutorRunner会启动ExecutorBackend进程。

4、ExecutorBackend启动后会向Driver的SchedulerBackend注册。SchedulerBackend进程中包含DAGScheduler,它会根据用户程序,生成执行计划,并调度执行。对于每个stage的task,都会被存放到TaskScheduler中,ExecutorBackend向SchedulerBackend汇报的时候把TaskScheduler中的task调度到ExecutorBackend执行。

5、所有stage都完成后作业结束。

Driver运行在客户端

作业执行流程描述:

1、客户端启动后直接运行用户程序,启动Driver相关的工作:DAGScheduler和BlockManagerMaster等。

2、客户端的Driver向Master注册。

3、Master还会让Worker启动Exeuctor。Worker创建一个ExecutorRunner线程,ExecutorRunner会启动ExecutorBackend进程。

4、ExecutorBackend启动后会向Driver的SchedulerBackend注册。Driver的DAGScheduler解析作业并生成相应的Stage,每个Stage包含的Task通过TaskScheduler分配给Executor执行。

5、所有stage都完成后作业结束。

免责声明:本文来源于网络,由网友提供或网络搜集,仅供个人交流学习参考使用,不涉及商业盈利目的。如有版权问题,请联系本站管理员予以更改或删除。谢谢合作!

热门标签: IT面试问题

猜你喜欢

推荐阅读

 
 
咨询中心
优就业微信扫一扫
微信扫一扫

400-650-7353

加入官方微博


博聚网