共计 8799 个字符，预计需要花费 22 分钟才能阅读完成。
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 在线程中可能会占满整个内存，分片数据
