校园网二级网站的建设,岳阳网站设计,wordpress 调用最新文章,收益网站制作1、Hadoop 和 Spark 的相同点和不同点#xff1f;
Hadoop 底层使用 MapReduce 计算架构#xff0c;只有 map 和 reduce 两种操作#xff0c;表达能力比较欠缺#xff0c;而且在 MR 过程中会重复的读写 hdfs#xff0c;造成大量的磁盘 io 读写操作#xff0c;所以适合高时…1、Hadoop 和 Spark 的相同点和不同点
Hadoop 底层使用 MapReduce 计算架构只有 map 和 reduce 两种操作表达能力比较欠缺而且在 MR 过程中会重复的读写 hdfs造成大量的磁盘 io 读写操作所以适合高时延环境下批处理计算的应用 Spark 是基于内存的分布式计算架构提供更加丰富的数据集操作类型主要分成转化操作和行动操作包括 map、reduce、filter、flatmap、groupbykey、reducebykey、union 和 join 等数据分析更加快速所以适合低时延环境下计算的应用 Spark 与 hadoop 最大的区别在于迭代式计算模型。基于 mapreduce 框架的Hadoop 主要分为 map 和 reduce 两个阶段两个阶段完了就结束了所以在一个 job 里面能做的处理很有限Spark 计算模型是基于内存的迭代式计算模型可以分为 n 个阶段根据用户编写的 RDD 算子和程序在处理完一个阶段后可以继续往下处理很多个阶段而不只是两个阶段。所以 Spark 相较于mapreduce计算模型更加灵活可以提供更强大的功能。 但是 Spark 也有劣势由于 Spark 基于内存进行计算虽然开发容易但是真正面对大数据的时候在没有进行调优的情况下可能会出现各种各样的问题比如 OOM 内存溢出等情况导致 Spark程序可能无法运行起来而 mapreduce虽然运行缓慢但是至少可以慢慢运行完。
2、Hadoop 和 Spark 使用场景
Hadoop/MapReduce 和 Spark 最适合的都是做离线型的数据分析但 Hadoop 特别适合是单次分析的数据量“很大”的情景而 Spark 则适用于数据量不是很大的情景。 1 一般情况下对于中小互联网和企业级的大数据应用而言单次分析的数量都不会“很大”因此可以优先考虑使用 Spark。 2业务通常认为 Spark 更适用于机器学习之类的“迭代式”应用80GB 的压缩数据解压后超过 200GB10 个节点的集群规模跑类似“sumgroup-by”的应用MapReduce 花了 5 分钟而 spark 只需要 2分钟。
3、Spark 如何保证宕机迅速恢复?
1适当增加 spark standby master 2编写 shell 脚本定期检测 master 状态出现宕机后对 master 进行重启操作。
4、Spark 有哪些组件
1master管理集群和节点不参与计算 2worker计算节点进程本身不参与计算和 master 汇报 3Driver运行程序的 main 方法创建 spark context 对象 4spark context控制整个 application 的生命周期包括 dagsheduler 和 taskscheduler 等组件 5client用户提交程序的入口。
5、简述下Spark的运行流程。
1SparkContext 向资源管理器注册并向资源管理器申请运行 Executor 2 资源管理器分配 Executor然后资源管理器启动 Executor 3Executor 发送心跳至资源管理器 4SparkContext 构建 DAG 有向无环图 5将 DAG 分解成 StageTaskSet 6把 Stage 发送给 TaskScheduler 7Executor 向 SparkContext 申请 Task 8TaskScheduler 将 Task 发送给 Executor 运行 9同时 SparkContext 将应用程序代码发放给 Executor 10Task 在 Executor 上运行运行完毕释放所有资源。
6、简述下Spark 中的 RDD 机制。
RDD分布式弹性数据集简单的理解成一种数据结构是 spark 框架上的通用货币。所有算子都是基于 RDD来执行的不同的场景会有不同的 RDD实现类但是都可以进行互相转换。RDD 执行过程中会形成 dag 图然后形成 lineage 保证容错性等。从物理的角度来看 RDD 存储的是 block 和 node 之间的映射。 RDD 是 spark 提供的核心抽象全称为弹性分布式数据集。 RDD 在逻辑上是一个 hdfs 文件在抽象上是一种元素集合包含了数据。它是被分区的分为多个分区每个分区分布在集群中的不同结点上从而让 RDD中的数据可以被并行操作分布式数据集。
7、 RDD 中 reduceBykey 与 groupByKey 哪个性能好为什么
1reduceByKeyreduceByKey 会在结果发送至 reducer 之前会对每个 mapper 在本地进行 merge有点类似于在 MapReduce 中的 combiner。这样做的好处在于在 map 端进行一次 reduce 之后数据量会大幅度减小从而减小传输保证reduce 端能够更快的进行结果计算。 2groupByKeygroupByKey 会对每一个 RDD 中的 value 值进行聚合形成一个序列(Iterator)此操作发生在 reduce 端所以势必会将所有的数据通过网络进行传输造成不必要的浪费。同时如果数据量十分大可能还会造成 OutOfMemoryError。所以在进行大量数据的 reduce 操作时候建议使用 reduceByKey。不仅可以提高速度还可以防止使用 groupByKey 造成的内存溢出问题。
8、简述下cogroup RDD 实现原理。
1cogroup对多个2~4RDD 中的 KV 元素每个 RDD 中相同 key 中的元素分别聚合成一个集合。 2与 reduceByKey 不同的是reduceByKey 针对一个 RDD 中相同的 key 进行合并。而 cogroup 针对多个 RDD 中相同的 key 的元素进行合并。 3cogroup 的函数实现这个实现根据要进行合并的两个 RDD 操作生成一个CoGroupedRDD 的实例这个 RDD 的返回结果是把相同的 key 中两个 RDD分别进行合并操作最后返回的 RDD 的 value 是一个 Pair 的实例这个实例包含两个 Iterable 的值第一个值表示的是 RDD1 中相同 KEY 的值第二个值表示的是 RDD2 中相同 key 的值。 4由于做 cogroup 的操作需要通过 partitioner 进行重新分区的操作因此执行这个流程时需要执行一次 shuffle 的操作(如果要进行合并的两个 RDD 的都已经是 shuffle 后的 RDD同时他们对应的 partitioner 相同时就不需要执行shuffle)。
9、在哪里用过cogroup RDD 。
表关联查询或者处理重复的 key。
10、如何区分 RDD 的宽窄依赖
1窄依赖父 RDD 的一个分区只会被子 RDD 的一个分区依赖 2宽依赖父 RDD 的一个分区会被子 RDD 的多个分区依赖(涉及到 shuffle)。
11、为什么要设计宽窄依赖
1窄依赖 A、窄依赖的多个分区可以并行计算 B、窄依赖的一个分区的数据如果丢失只需要重新计算对应的分区的数据就可以了。 2宽依赖 划分 Stage(阶段)的依据:对于宽依赖,必须等到上一阶段计算完成才能计算下一阶段。
12、简述下DAG。
DAG(Directed Acyclic Graph 有向无环图)指的是数据转换执行的过程有方向无闭环(其实就是 RDD 执行的流程) 原始的 RDD 通过一系列的转换操作就形成了 DAG 有向无环图任务执行时可以按照 DAG 的描述执行真正的计算(数据被操作的一个过程)。
13、DAG 中为什么要划分 Stage
为了实现并行计算。 一个复杂的业务逻辑如果有 shuffle那么就意味着前面阶段产生结果后才能执行下一个阶段即下一个阶段的计算要依赖上一个阶段的数据。那么我们按照shuffle 进行划分(也就是按照宽依赖就行划分)就可以将一个 DAG 划分成多个Stage/阶段在同一个 Stage 中会有多个算子操作可以形成一个 pipeline 流水线流水线内的多个平行的分区可以并行执行。
14、如何划分 DAG 的 stage
1对于窄依赖partition 的转换处理在 stage 中完成计算不划分(将窄依赖尽量放在在同一个 stage 中可以实现流水线计算)。 2对于宽依赖由于有 shuffle 的存在只能在父 RDD 处理完成后才能开始接下来的计算也就是说需要要划分 stage。
15、简述下DAG 划分 Stage 的算法。
核心算法回溯算法。 从后往前回溯/反向解析遇到窄依赖加入本 Stage遇见宽依赖进行 Stage 切分。Spark 内核会从触发 Action 操作的那个 RDD 开始从后往前推首先会为最后一个 RDD 创建一个 Stage然后继续倒推如果发现对某个 RDD 是宽依赖那么就会将宽依赖的那个 RDD 创建一个新的 Stage那个 RDD 就是新的Stage 的最后一个 RDD。 然后依次类推继续倒推根据窄依赖或者宽依赖进行 Stage 的划分直到所有的 RDD 全部遍历完成为止。
16、 如何解决Spark 中的数据倾斜问题
前提是定位数据倾斜是 OOM 了还是任务执行缓慢看日志看 WebUI。 1避免不必要的 shuffle如使用广播小表的方式将 reduce-side-join 提升为 map-side-join 2分拆发生数据倾斜的记录分成几个部分进行然后合并 join 后的结果 3改变并行度可能并行度太少了导致个别 task 数据压力大 4两阶段聚合先局部聚合再全局聚合 5自定义 paritioner分散 key 的分布使其更加均匀。
17、简述下Spark 中的 OOM 问题。
1map 类型的算子执行中内存溢出如 flatMapmapPatitions。 原因map 端过程产生大量对象导致内存溢出这种溢出的原因是在单个 map 中产生了大量的对象导致的针对这种问题。 解决方案 A、增加堆内内存。 B、在不增加内存的情况下可以减少每个 Task 处理数据量使每个 Task产生大量的对象时Executor 的内存也能够装得下。具体做法可以在会产生大量对象的 map 操作之前调用 repartition 方法分区成更小的块传入map。 2shuffle 后内存溢出如 joinreduceByKeyrepartition。 shuffle 内存溢出的情况可以说都是 shuffle 后单个文件过大导致的。在shuffle 的使用需要传入一个 partitioner大部分 Spark 中的 shuffle 操作默认的 partitioner 都是 HashPatitioner默认值是父 RDD 中最大的分区数这个参数 spark.default.parallelism 只对 HashPartitioner 有效如果是别的 partitioner 导致的 shuffle 内存溢出就需要重写 partitioner 代码了。 3driver 内存溢出。 A、 用户在 Dirver 端口生成大对象比如创建了一个大的集合数据结构。解决方案将大对象转换成 Executor 端加载比如调用 sc.textfile 或者评估大对象占用的内存增加 dirver 端的内存 B、从 Executor 端收集数据collect回 Dirver 端建议将 driver 端对 collect回来的数据所作的操作转换成 executor 端 rdd 操作。
18、Spark 中数据的位置是被谁管理的
每个数据分片都对应具体物理位置数据的位置是被 blockManager 管理无论数据是在磁盘内存还是 tacyan都是由 blockManager 管理。
19、Spaek 程序执行有时候默认为什么会产生很多 task怎么修改默认 task 执行个数
1输入数据有很多 task尤其是有很多小文件的时候有多少个输入 block就会有多少个 task 启动 2spark 中有 partition 的概念每个 partition 都会对应一个 tasktask 越多在处理大规模数据的时候就会越有效率。不过 task 并不是越多越好如果平时测试或者数据量没有那么大则没有必要 task 数量太多。 3参数可以通过 spark_home/conf/spark-default.conf 配置文件设置: A、针对 spark sql 的 task 数量spark.sql.shuffle.partitions50 B、非 spark sql 程序设置生效spark.default.parallelism10。
20、介绍一下 join 操作优化经验
join 其实常见的就分为两类 map-side join 和 reduce-side join。 当大表和小表 join 时用 map-side join 能显著提高效率。 将多份数据进行关联是数据处理过程中非常普遍的用法不过在分布式计算系统中这个问题往往会变的非常麻烦因为框架提供的 join 操作一般会将所有数据根据 key 发送到所有的 reduce 分区中去也就是 shuffle 的过程。造成大量的网络以及磁盘 IO 消耗运行效率极其低下这个过程一般被称为reduce-side-join。 如果其中有张表较小的话我们则可以自己实现在 map 端实现数据关联跳过大量数据进行 shuffle 的过程运行时间得到大量缩短根据不同数据可能会有几倍到数十倍的性能提升。 在大数据量的情况下join 是一中非常昂贵的操作需要在 join 之前应尽可能的先缩小数据量。 对于缩小数据量有以下几条建议 1 若两个 RDD 都有重复的 keyjoin 操作会使得数据量会急剧的扩大。所有最好先使用 distinct 或者 combineByKey 操作来减少 key 空间或者用 cogroup 来处理重复的 key而不是产生所有的交叉结果。在 combine时进行机智的分区可以避免第二次 shuffle。 2如果只在一个 RDD 出现那你将在无意中丢失你的数据。所以使用外连接会更加安全这样你就能确保左边的 RDD 或者右边的 RDD 的数据完整性在 join 之后再过滤数据。 3 如果我们容易得到 RDD 的可以的有用的子集合那么我们可以先用filter 或者 reduce如何在再用 join。
31、Spark 与 MapReduce 的 Shuffle 的区别
1 相同点 都是将 mapper Spark 里是 ShuffleMapTask的输出进行 partition不同的 partition 送到不同的 reducerSpark 里 reducer 可能是下一个stage 里的 ShuffleMapTask也可能是 ResultTask。 2 不同点 A、MapReduce 默认是排序的spark 默认不排序除非使用 sortByKey 算子 B、 MapReduce 可以划分成 splitmap()、spill、merge、shuffle、sort、reduce()等阶段spark 没有明显的阶段划分只有不同的 stage 和算子操作 C、MR 落盘Spark 不落盘spark 可以解决 mr 落盘导致效率低下的问题。
32、简述下Spark SQL 执行的流程。
1parser基于 antlr 框架对 sql 解析生成抽象语法树 2变量替换通过正则表达式找出符合规则的字符串替换成系统缓存环境的变量SQLConf 中的 spark.sql.variable.substitute默认是可用的 3parser将 antlr 的 tree 转成 spark catalyst 的 LogicPlan也就是未解析的逻辑计划 4 analyzer通过分析器结合 catalog把 logical plan 和实际的数据绑定起来将 未解析的逻辑计划 生成 逻辑计划 5 缓存替换通过 CacheManager替换有相同结果的 logical plan逻辑计划 6 logical plan 优化基于规则的优化优化规则参考 Optimizer优化执行器 RuleExecutor 7生成 spark plan也就是物理计划参考 QueryPlanner 和 SparkStrategies 8 spark plan 准备阶段 9构造 RDD 执行涉及 spark 的 wholeStageCodegenExec 机制基于janino 框架生成 java 代码并编译。
33、Spark SQL 是如何将数据写到 Hive 表的
1方式一是利用 Spark RDD 的 API 将数据写入 hdfs 形成 hdfs 文件之后再将 hdfs 文件和 hive 表做加载映射。 2方式二利用 Spark SQL 将获取的数据 RDD 转换成 DataFrame再将DataFrame 写成缓存表最后利用 Spark SQL 直接插入 hive 表中。而对于利用 Spark SQL 写 hive 表官方有两种常见的 API第一种是利用JavaBean 做映射第二种是利用 StructType 创建 Schema 做映射。
34、Spark 与 MapReduce 相比运行效率更高来源于哪些内置机制
1基于内存计算减少低效的磁盘交互 2高效的调度算法基于 DAG 3容错机制 Linage。
35、简述下Hadoop 和 Spark 不同点。
1Hadoop 底层使用 MapReduce 计算架构只有 map 和 reduce 两种操作表达能力比较欠缺而且在 MR 过程中会重复的读写 hdfs造成大量的磁盘 io 读写操作所以适合高时延环境下批处理计算的应用 2Spark 是基于内存的分布式计算架构提供更加丰富的数据集操作类型主要分成转化操作和行动操作包括 map、reduce、filter、flatmap、groupbykey、reducebykey、union 和 join 等数据分析更加快速所以适合低时延环境下计算的应用 3spark 与 hadoop 最大的区别在于迭代式计算模型。基于 mapreduce 框架的Hadoop 主要分为 map 和 reduce 两个阶段两个阶段完了就结束了所以在一个 job 里面能做的处理很有限spark 计算模型是基于内存的迭代式计算模型可以分为 n 个阶段根据用户编写的 RDD 算子和程序在处理完一个阶段后可以继续往下处理很多个阶段而不只是两个阶段。所以 spark 相较于mapreduce计算模型更加灵活可以提供更强大的功能。 4但是 spark 也有劣势由于 spark 基于内存进行计算虽然开发容易但是真正面对大数据的时候在没有进行调优的情况下可能会出现各种各样的问题比如 OOM 内存溢出等情况导致 spark 程序可能无法运行起来而 mapreduce虽然运行缓慢但是至少可以慢慢运行完。
36、简述下Hadoop 和 Spark 使用场景。
Hadoop/MapReduce 和 Spark 最适合的都是做离线型的数据分析但 Hadoop 特别适合是单次分析的数据量“很大”的情景而 Spark 则适用于数据量不是很大的情景。 1一般情况下对于中小互联网和企业级的大数据应用而言单次分析的数量都不会“很大”因此可以优先考虑使用 Spark。 2业务通常认为 Spark 更适用于机器学习之类的“迭代式”应用80GB 的压缩数据解压后超过 200GB10 个节点的集群规模跑类似“sumgroup-by”的应用MapReduce 花了 5 分钟而 spark 只需要 2分钟。
37、Spark 如何保证宕机迅速恢复?
1适当增加 spark standby master 2编写 shell 脚本定期检测 master 状态出现宕机后对 master 进行重启操作。
38、简述下RDD 持久化原理。
spark 非常重要的一个功能特性就是可以将 RDD 持久化在内存中。调用 cache()和 persist()方法即可。cache()和 persist()的区别在于cache()是persist()的一种简化方式cache()的底层就是调用 persist()的无参版本persist(MEMORY_ONLY)将数据持久化到内存中。如果需要从内存中清除缓存可以使用 unpersist()方法。RDD 持久化是可以手动选择不同的策略的。在调用 persist()时传入对应的 StorageLevel 即可。
39、简述Checkpoint 检查点机制。
应用场景当 spark 应用程序特别复杂从初始的 RDD 开始到最后整个应用程序完成有很多的步骤而且整个应用运行时间特别长这种情况下就比较适合使用 checkpoint 功能。 原因对于特别复杂的 Spark 应用会出现某个反复使用的 RDD即使之前持久化过但由于节点的故障导致数据丢失了没有容错机制所以需要重新计算一次数据。 Checkpoint 首先会调用 SparkContext 的 setCheckPointDIR()方法设置一个容错的文件系统的目录比如说 HDFS然后对 RDD 调用 checkpoint()方法。之后在 RDD 所处的 job 运行结束之后会启动一个单独的 job来将 checkpoint 过的 RDD 数据写入之前设置的文件系统进行高可用、容错的类持久化操作。 检查点机制是我们在 spark streaming 中用来保障容错性的主要机制它可以使spark streaming 阶段性的把应用数据存储到诸如 HDFS 等可靠存储系统中以供恢复时使用。具体来说基于以下两个目的服务 1控制发生失败时需要重算的状态数。Spark streaming 可以通过转化图的谱系图来重算状态检查点机制则可以控制需要在转化图中回溯多远。 2提供驱动器程序容错。如果流计算应用中的驱动器程序崩溃了你可以重启驱动器程序并让驱动器程序从检查点恢复这样 spark streaming 就可以读取之前运行的程序处理数据的进度并从那里继续。
40、简述下 Checkpoint 和持久化机制的区别。
最主要的区别在于持久化只是将数据保存在 BlockManager 中但是 RDD 的lineage(血缘关系依赖关系)是不变的。但是 checkpoint 执行完之后rdd 已经没有之前所谓的依赖 rdd 了而只有一个强行为其设置的 checkpointRDDcheckpoint 之后 rdd 的 lineage 就改变了。 持久化的数据丢失的可能性更大因为节点的故障会导致磁盘、内存的数据丢失。但是 checkpoint 的数据通常是保存在高可用的文件系统中比如 HDFS 中所以数据丢失可能性比较低。
41、简述下Spark Streaming 以及基本工作原理。
Spark streaming 是 spark core API 的一种扩展可以用于进行大规模、高吞吐量、容错的实时数据流的处理。 它支持从多种数据源读取数据比如 Kafka、Flume、Twitter 和 TCP Socket并且能够使用算子比如 map、reduce、join 和 window 等来处理数据处理后的数据可以保存到文件系统、数据库等存储中。 Spark streaming 内部的基本工作原理是接受实时输入数据流然后将数据拆分成 batch比如每收集一秒的数据封装成一个 batch然后将每个 batch 交给spark 的计算引擎进行处理最后会生产处一个结果数据流其中的数据也是一个一个的 batch 组成的。
42、简述下DStream 以及基本工作原理。
DStream 是 spark streaming 提供的一种高级抽象代表了一个持续不断的数据流。 DStream 可以通过输入数据源来创建比如 Kafka、flume 等也可以通过其他DStream 的高阶函数来创建比如 map、reduce、join 和 window 等。 DStream 内部其实不断产生 RDD每个 RDD 包含了一个时间段的数据。Spark streaming 一定是有一个输入的 DStream 接收数据按照时间划分成一个一个的 batch并转化为一个 RDDRDD 的数据是分散在各个子节点的 partition中。
43、Spark Streaming 整合 Kafka 的有哪两种模式
Spark Streaming 整合 Kafka 的两种模式分别是基于 receiver 方式和基于 direct 方式。
44、简述下“基于 receiver 方式”的原理及特点。
1基于receiver 方式原理将数据拉取到 executor 中做操作若数据量大内存存储不下可以通过 WAL设置了本地存储保证数据不丢失然后使用 Kafka高级 API 通过 zk 来维护偏移量保证消费数据。receiver 消费的数据偏移量是在 zk 获取的此方式效率低容易出现数据丢失。 2receiver 方式的容错性在默认的配置下这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制让数据零丢失就必须启用 Spark Streaming 的预写日志机制Write Ahead LogWAL。该机制会同步地将接收到的 Kafka 数据写入分布式文件系统比如 HDFS上的预写日志中。所以即使底层节点出现了失败也可以使用预写日志中的数据进 行恢复。 3Kafka 中的 topic 的 partition与 Spark 中的 RDD 的 partition 是没有关系的。在 KafkaUtils.createStream()中提高 partition 的数量只会增加 Receiver 方式中读取 partition 的线程的数量。不会增加 Spark 处理数据的并行度。 可以创建多个 Kafka 输入 DStream使用不同的consumer group 和 topic来通过多个 receiver 并行接收数据。
45、简述下“基于 direct 方式”的原理及特点。
1基于 Direct 方式原理使用 Kafka 底层 Api其消费者直接连接 kafka 的分区上因为 createDirectStream 创建的 DirectKafkaInputDStream 每个 batch所对应的 RDD 的分区与 kafka 分区一一对应但是需要自己维护偏移量即用即取不会给内存造成太大的压力效率高。 2基于 Direct 方式的优点简化并行读取如果要读取多个 partition不需要创建多个输入DStream 然后对它们进行 union 操作。Spark 会创建跟 Kafka partition 一样多的 RDD partition并且会并行从 Kafka 中读取数据。所以在 Kafka partition 和 RDD partition 之间有一个一对一的映射关系。 3基于 Direct 方式的高性能如果要保证零数据丢失在基于 receiver 的方式中需要开启WAL 机制。这种方式其实效率低下因为数据实际上被复制了两份Kafka自己本身就有高可靠的机制会对数据复制一份而这里又会复制一份到WAL 中。而基于 direct 的方式不依赖 Receiver不需要开启 WAL 机制只要 Kafka 中作了数据的复制那么就可以通过 Kafka 的副本进行恢复。
46、“基于 receiver 方式”和 “基于 direct 方式”有什么区别
1基于 receiver 的方式是使用 Kafka 的高阶 API 来在 ZooKeeper 中保存消费过的 offset 的。这是消费 Kafka 数据的传统方式。这种方式配合着 WAL 机制可以保证数据零丢失的高可靠性但是却无法保证数据被处理一次且仅一次可能会处理两次。因为 Spark 和 ZooKeeper 之间可能是不同步的。 2基于 direct 的方式使用 Kafka 的低阶 APISpark Streaming 自己就负责追踪消费的 offset并保存在 checkpoint 中。Spark 自己一定是同步的因此可以保证数据是消费一次且仅消费一次。 3Receiver 方式是通过 zookeeper 来连接 kafka 队列Direct 方式是直接连接到 kafka 的节点上获取数据。
47、简述下Spark 主备切换机制原理。
Master 实际上可以配置两个Spark 原生的 standalone 模式是支持 Master 主备切换的。当 Active Master 节点挂掉以后我们可以将 Standby Master 切换为Active Master。 Spark Master 主备切换可以基于两种机制一种是基于文件系统的一种是基于ZooKeeper 的。 基于文件系统的主备切换机制需要在 Active Master 挂掉之后手动切换到Standby Master 上 而基于 Zookeeper 的主备切换机制可以实现自动切换 Master。
48、Spark 解决了 Hadoop 的哪些问题
1MR抽象层次低需要使用手工代码来完成程序编写使用上难以上手 SparkSpark 采用 RDD 计算模型简单容易上手。 2MR只提供 map 和 reduce 两个操作表达能力欠缺 SparkSpark 采用更加丰富的算子模型包括 map、flatmap、groupbykey、reducebykey 等 3MR一个 job 只能包含 map 和 reduce 两个阶段复杂的任务需要包含很多个 job这些 job 之间的管理以来需要开发者自己进行管理 SparkSpark 中一个 job 可以包含多个转换操作在调度时可以生成多个 stage而且如果多个 map 操作的分区不变是可以放在同一个 task里面去执行 4MR中间结果存放在 hdfs 中 SparkSpark 的中间结果一般存在内存中只有当内存不够了才会存入本地磁盘而不是 hdfs 5 MR只有等到所有的 map task 执行完毕后才能执行 reduce task SparkSpark 中分区相同的转换构成流水线在一个 task 中执行分区不同的需要进行 shuffle 操作被划分成不同的 stage 需要等待前面的stage 执行完才能执行。 6MR只适合 batch 批处理时延高对于交互式处理和实时处理支持不够 SparkSpark streaming 可以将流拆成时间间隔的 batch 进行处理实时计算。
49、数据倾斜怎么产生的怎么解决
数据倾斜以为着某一个或者某几个 partition 的数据特别大导致这几个partition 上的计算需要耗费相当长的时间。 在 spark 中同一个应用程序划分成多个 stage这些 stage 之间是串行执行的而一个 stage 里面的多个 task 是可以并行执行task 数目由 partition 数目决定如果一个 partition 的数目特别大那么导致这个 task 执行时间很长导致接下来的 stage 无法执行从而导致整个 job 执行变慢。 避免数据倾斜一般是要选用合适的 key或者自己定义相关的 partitioner通过加盐或者哈希值来拆分这些 key从而将这些数据分散到不同的 partition 去执行。 如下算子会导致 shuffle 操作是导致数据倾斜可能发生的关键点所在groupByKeyreduceByKeyaggregaByKeyjoincogroup。
50、Spark Master HA 主从切换过程不会影响到集群已有作业的运行为什么
不会的。 因为程序在运行之前已经申请过资源了driver 和 Executors 通讯不需要和master 进行通讯的。
51、Spark Master 使用 Zookeeper 进行 HA有哪些源数据保存到Zookeeper 里面
spark 通过这个参数 spark.deploy.zookeeper.dir 指定 master 元数据在 zookeeper中保存的位置包括 WorkerDriver 和 Application 以及 Executors。standby 节点要从 zk 中获得元数据信息恢复集群运行状态才能对外继续提供服务作业提交资源申请等在恢复前是不能接受请求的。
52、如何实现 Spark Streaming 读取 Flume 中的数据
1前期经过技术调研查看官网相关资料发现 sparkStreaming 整合 flume有 2 种模式一种是拉模式一种是推模式然后在简单的聊聊这 2 种模式的特点以及如何部署实现需要做哪些事情最后对比两种模式的特点选择那种模式更好 2推模式Flume 将数据 Push 推给 Spark Streaming 3拉模式Spark Streaming 从 flume 中 Poll 拉取数据。
53、在实际开发的时候是如何保证数据不丢失的
1flume 那边采用的 channel 是将数据落地到磁盘中保证数据源端安全性可以在补充一下flume 在这里的 channel 可以设置为 memory 内存中提高数据接收处理的效率但是由于数据在内存中安全机制保证不了故选择 channel 为磁盘存储。整个流程运行有一点的延迟性。 2parkStreaming 通过拉模式整合的时候使用了 FlumeUtils 这样一个类该类是需要依赖一个额外的 jar 包spark-streaming-flume_2.10。 3要想保证数据不丢失数据的准确性可以在构建 StreamingConext 的时候利用 StreamingContext.getOrCreatecheckpoint, creatingFunc: () StreamingContext来创建一个 StreamingContext,使用StreamingContext.getOrCreate 来创建 StreamingContext 对象传入的第一个参数是 checkpoint 的存放目录第二参数是生成 StreamingContext 对象的用户自定义函数。如果 checkpoint 的存放目录存在则从这个目录中生成StreamingContext 对象如果不存在才会调用第二个函数来生成新的StreamingContext 对象。在 creatingFunc 函数中除了生成一个新的StreamingContext 操作还需要完成各种操作然后调用ssc.checkpoint(checkpointDirectory)来初始化 checkpoint 功能最后再返回StreamingContext 对象。 这样在 StreamingContext.getOrCreate 之后就可以直接调用 start()函数来启动或者是从中断点继续运行流式应用了。如果有其他在启动或继续运行都要做的工作可以在 start()调用前执行。
54、RDD 有哪些缺陷
1不支持细粒度的写和更新操作Spark 写数据是粗粒度的所谓粗粒度就是批量写入数据目的是为了提高效率。但是 Spark 读数据是细粒度的也就是说可以一条条的读。 2不支持增量迭代计算如果对 Flink 熟悉可以说下 Flink 支持增量迭代计算。
