大数据分析Spark试题及解析

大数据分析Spark试题及解析一、单项选择题（共10题，每题1分，共10分）以下哪一项是Spark生态体系中最核心的分布式内存抽象概念A.Hadoop分布式文件系统B.弹性分布式数据集（RDD）C.MapReduce计算模型D.YARN资源调度框架答案：B解析：正确选项B的依据是RDD是Spark从底层设计之初就定义的核心分布式抽象，支持数据在内存中进行迭代计算。A选项的HDFS是分布式存储系统，不属于Spark的抽象概念；C选项的MapReduce是Hadoop生态下的批处理计算模型，并非Spark的原生组件；D选项的YARN是通用资源调度框架，不属于Spark的核心数据抽象。Spark运行时负责对任务进行DAG调度、阶段划分的核心组件是A.ExecutorB.TaskC.DAGSchedulerD.ShuffleManager答案：C解析：正确选项C的依据是DAGScheduler是Spark调度层的核心模块之一，负责根据算子依赖关系构建有向无环图、划分宽窄依赖对应的任务阶段。A选项的Executor是运行在工作节点上执行具体任务的进程；B选项的Task是Spark中最小的执行单元；D选项的ShuffleManager是负责管理shuffle过程数据读写的组件，不承担DAG调度的职责。以下Spark提供的算子中，属于转换类算子而非行动类算子的是A.countB.mapC.collectD.saveAsTextFile答案：B解析：正确选项B的map是典型的转换算子，作用是对RDD中每一条元素执行映射转换生成新的RDD，不会直接触发计算。A选项的count用于统计RDD元素总数、C选项的collect用于拉取所有元素到驱动端、D选项的saveAsTextFile用于将结果写入文件系统，三者都会触发实际的计算执行，都属于行动算子。以下关于宽依赖的描述中，符合Spark依赖定义的是A.父RDD的一个分区只会被子RDD的一个分区所依赖使用B.子RDD的一个分区只会关联父RDD的一个分区C.父RDD的多个分区会被子RDD的同一个分区所依赖使用D.宽依赖场景下任务失败不需要重新计算任何父分区答案：C解析：正确选项C的依据是宽依赖也叫Shuffle依赖，父RDD的多个分区的数据会通过shuffle过程分发到子RDD的同一个分区中。A和B描述的都是窄依赖的核心特征，和宽依赖定义完全相反；D选项的宽依赖场景下子分区失败需要重新计算所有关联的父分区，容错成本远高于窄依赖。SparkSQL中用于处理结构化和半结构化数据的核心抽象是A.DataFrameB.Broadcast广播变量C.Accumulator累加器D.DStream离散流答案：A解析：正确选项A的DataFrame是SparkSQL的核心数据抽象，自带schema元信息，支持类SQL的查询优化。B选项的广播变量是用于小数据高效分发的共享变量；C选项的累加器是用于分布式环境下全局计数的共享变量；D选项的DStream是SparkStreaming的核心抽象，不属于SparkSQL模块。SparkStreaming架构中，把实时流数据按照固定时间间隔切分成批量数据的核心组件是A.Receiver接收器B.BlockManager块管理器C.JobScheduler任务调度器D.批间隔生成器答案：A解析：正确选项A的Receiver负责从各类数据源拉取实时流数据，按照时间间隔切分生成对应批次的小批量RDD。B选项的BlockManager是Spark统一的块存储管理组件；C选项的JobScheduler负责提交生成的批次任务到集群执行；D选项不属于SparkStreaming的官方定义组件名称。Spark本地运行模式中，配置字符串local[*]里的符号*代表的含义是A.使用固定1个CPU核心执行任务B.使用当前机器所有可用的CPU核心执行任务C.不分配任何CPU核心，仅在内存中模拟执行D.使用指定数量的磁盘IO线程执行任务答案：B解析：正确选项B的依据是Spark官方定义中local[*]的星号会自动探测当前运行节点的CPU逻辑核心总数，分配对应数量的执行线程。A选项对应的配置是local[1]，和题干表述不符；C选项对应的配置是local，没有任何后缀；D选项的描述完全不属于本地模式配置的定义范畴。以下哪一种部署模式下，Spark的驱动程序会运行在YARN集群的工作节点容器中A.YARNClient模式B.Standalone独立模式C.YARNCluster模式D.本地运行模式答案：C解析：正确选项C的YARNCluster模式会将驱动程序启动在集群的ApplicationMaster容器内部，完全在集群内部运行。A选项的YARNClient模式驱动程序运行在提交任务的本地节点上；B选项的Standalone模式驱动默认运行在提交任务的节点，也可以手动配置但不属于YARN体系；D选项的本地模式所有组件都运行在同一个进程内部。当我们需要在Spark任务中共享一个只读的大维度表数据，避免每个Executor多次复制该数据，最优的实现方式是使用A.Accumulator累加器B.RDD的普通转换算子C.Broadcast广播变量D.自定义排序器答案：C解析：正确选项C的广播变量只会把数据分发到每个Executor节点一次，Executor上的所有共享同一个副本，大幅减少数据传输量。A选项的累加器只能用于全局计数类的写操作，无法承载只读大维度表；B选项的普通RDD变量会被分发到每一个任务线程，Executor有多少个任务就会复制多少份数据，产生大量冗余传输；D选项的自定义排序器仅用于修改排序逻辑，和数据共享无关。Spark作业在运行过程中产生shuffle阶段的触发条件是以下哪一类算子A.不需要跨节点数据重分布的转换算子B.行动算子C.需要对全局数据按照指定key进行分组、聚合、关联的算子D.只在本地节点执行的无依赖map类算子答案：C解析：正确选项C的依据是分组、聚合、关联类算子都要求相同key的数据进入同一个子分区，必须触发跨节点的数据shuffle重分布。A和D描述的算子都属于窄依赖算子，不会触发shuffle；B选项的行动算子只是触发整个任务的提交执行，本身不会直接生成shuffle阶段。一、多项选择题（共10题，每题2分，共20分）以下属于Spark官方生态原生自带的核心计算组件的有A.SparkCore批处理核心组件B.SparkSQL结构化数据处理组件C.SparkStreaming实时流处理组件D.HBase分布式非关系型数据库答案：ABC解析：正确选项A、B、C都是Spark官方生态原生提供的核心计算模块，分别负责基础批处理、结构化查询、实时流处理三类核心场景。D选项的HBase属于Hadoop生态下的独立分布式存储组件，不属于Spark体系自带的计算组件。以下属于Spark中窄依赖典型应用场景的有A.对父RDD执行一对一的map映射转换B.对父RDD执行过滤筛选过滤符合条件的元素C.对两个父RDD执行基于相同key的join关联操作，且两个RDD已经提前做过分区数对齐和相同规则的分区D.执行reduceByKey全局聚合操作答案：ABC解析：正确选项A、B、C的场景中，子RDD的每一个分区只会依赖父RDD的某一个固定分区，都属于窄依赖，不会触发shuffle。D选项的reduceByKey会要求全局相同key的数据聚合，必须触发跨节点的shuffle操作，属于宽依赖场景。以下关于Spark惰性执行特性的描述正确的有A.所有转换算子都不会立即触发实际计算B.惰性执行可以帮助Spark在最终触发计算的时候构建完整的DAG链，执行全局优化C.调用行动算子之后才会从后往前回溯生成完整的执行计划，提交任务运行D.惰性执行会导致Spark任务运行速度比MapReduce慢很多答案：ABC解析：正确选项A、B、C都是Spark惰性求值机制的核心定义和优势，Spark基于完整的DAG可以做很多类似合并相邻算子、预分区优化等全局优化。D选项的描述完全错误，惰性执行是Spark性能远优于传统MapReduce的核心原因之一，不会拖慢运行速度。Spark中提供的持久化缓存级别，支持把数据同时存储在内存和磁盘中的选项有A.MEMORY_ONLYB.MEMORY_AND_DISKC.MEMORY_ONLY_SERD.MEMORY_AND_DISK_SER答案：BD解析：正确选项B和D的缓存级别都定义了如果内存放不下缓存的所有数据，会把溢出的部分写到磁盘中，区别只是后者会以序列化的形式存储数据进一步降低内存占用。A选项的MEMORY_ONLY仅在内存中存储未序列化的RDD分区，内存不足就直接丢弃数据重新计算；C选项的MEMORY_ONLY_SER仅在内存中以序列化形式存储数据，不会写入磁盘。以下属于Spark支持的主流部署运行模式的有A.本地单机运行模式B.Standalone独立资源集群模式C.YARN资源集群模式D.仅支持在移动端运行的嵌入式模式答案：ABC解析：正确选项A、B、C都是Spark官方正式支持的部署模式，覆盖开发测试、独立集群运行、对接现有Hadoop集群资源三类主流场景。D选项的嵌入式移动端模式从未被Spark官方支持，不属于合法的部署模式。以下算子中，会触发shuffle过程的算子有A.groupByKey分组算子B.sortByKey全排序算子C.union合并两个同类型RDD的算子D.join普通关联算子（未提前预分区）答案：ABD解析：正确选项A、B、D的算子都要求全局数据按照key做重分布，触发跨节点的shuffle过程。C选项的union算子只是把两个RDD的分区直接合并到新的RDD中，不需要跨节点数据分发，属于窄依赖不会触发shuffle。相比传统的MapReduce计算引擎，Spark的性能优势主要来源于以下哪些特性A.基于内存的分布式计算，中间计算结果优先存储在内存中不需要频繁落盘B.DAG层面的全局执行优化，减少不必要的磁盘IO开销C.支持迭代计算和交互式查询场景，不需要多次启动MapReduce任务D.完全不依赖任何磁盘存储，所有数据都永远放在内存中运行答案：ABC解析：正确选项A、B、C都是Spark性能远高于MapReduce的核心特性，大幅降低了磁盘读写和任务调度的额外开销。D选项的描述完全错误，Spark不是完全不依赖磁盘，当内存不足的时候会自动将溢出的数据写入磁盘，本身也支持磁盘持久化的配置。Spark共享变量体系中，官方原生支持的两类共享变量是A.Broadcast广播变量B.自定义全局静态变量C.Accumulator累加器D.分布式锁变量答案：AC解析：正确选项A和C是Spark官方原生提供的两类专门适配分布式执行场景的共享变量，分别用于高效分发只读大数据和实现分布式全局计数。B选项的普通静态变量在分布式环境下只会在每个节点单独创建副本，无法实现全局共享；D选项的分布式锁变量不属于Spark官方原生提供的共享变量类型。以下关于StructuredStreaming实时处理框架的描述，正确的有A.它是基于SparkSQL引擎构建的流处理框架B.它支持流批一体的处理逻辑，离线批处理和实时流处理可以复用同一套代码C.它的语义定义是把实时流数据当成不断增长的静态表来处理D.它完全不支持窗口聚合、Watermark晚到数据处理的能力答案：ABC解析：正确选项A、B、C都是StructuredStreaming的核心设计特性，大幅降低了流批场景的开发和维护成本。D选项的描述完全错误，StructuredStreaming提供了非常完善的窗口聚合、水位线晚到数据处理的原生支持，是工业界主流的实时流处理方案。SparkSQL支持直接读取对接的数据源类型有A.本地文本文件、分布式文件系统上的文件B.关系型数据库的表数据C.分布式消息队列的实时数据D.结构化的JSON、Parquet、ORC格式文件答案：ABCD解析：四个选项的数据源都是SparkSQL原生支持直接对接的类型，开发者只需要通过简单的配置就可以完成数据的读取和写入，不需要额外编写复杂的适配逻辑。一、判断题（共10题，每题1分，共10分）Spark中所有的转换算子都是惰性执行的，只有调用行动算子的时候才会触发整个任务的实际提交和运行。答案：正确解析：该描述符合Spark的惰性求值核心机制，Spark会在行动算子调用前完整记录所有转换算子的依赖链，生成完整的执行计划，再提交运行，避免不必要的计算开销。窄依赖场景下如果某一个子分区的计算失败，Spark只需要重新计算父RDD对应的一个关联分区就可以完成容错，容错成本远低于宽依赖。答案：正确解析：窄依赖的分区一对一关系决定了单个分区失败只需要回溯计算对应的单个父分区，不需要重新计算大量节点的相关数据，容错开销很低。使用SparkSQL编写的SQL查询语句，经过Catalyst优化器优化之后执行效率一定会比手动编写的原生RDD计算代码更高。答案：错误解析：Catalyst优化器可以完成大部分场景的执行计划优化，但是对于逻辑非常复杂的自定义迭代计算场景，手动编写的RDD代码可以更灵活的实现自定义优化，性能不一定低于SparkSQL自动生成的执行计划。Spark中使用缓存持久化的RDD，一旦执行完成对应的任务缓存就会自动永久保存在集群所有节点的内存中，不会被系统清理。答案：错误解析：Spark的缓存数据会由集群的内存管理模块统一调度，当新的任务需要占用更多内存的时候，旧的缓存数据如果长时间未被访问就会按照缓存淘汰规则被清理，并不会永久保留。Spark的一个Application应用程序可以包含多个Job作业，每调用一次行动算子就会生成一个新的Job。答案：正确解析：Spark的Application是最顶层的应用实例，每触发一次行动算子就会生成一个独立的Job，多个Job共享同一个Application的资源和调度上下文。在YARN模式下运行Spark任务，Driver端生成的所有执行计划都会直接发送给YARN的ResourceManager，不需要经过任何其他组件转发。答案：错误解析：YARN模式下Driver生成的执行计划会先提交给集群的ApplicationMaster，再由ApplicationMaster和ResourceManager申请资源，分发任务到对应的Executor节点执行，并不会直接发送给ResourceManager。DStream是SparkStreaming的核心抽象，本质上是由一系列连续的小批次RDD组成的序列。答案：正确解析：SparkStreaming的微批处理架构本质就是把实时流按照指定的时间间隔切分成一个个小的批数据，每一个批次对应一个RDD，多个连续的RDD组成DStream。配置Spark的并行度的时候，把并行度设置的越高，任务的运行速度就一定会越快。答案：错误解析：并行度过高会产生大量的小任务调度开销和大量的线程上下文切换，当并行度超过节点CPU核心数的数倍阈值之后，任务的整体运行速度反而会下降，需要根据集群资源和数据量设置合理的并行度。广播变量可以在分布式运行的所有Executor节点上直接修改，修改之后的结果可以同步回传到Driver端。答案：错误解析：广播变量的设计定位是只读的共享变量，Executor端不允许修改广播变量的数据，只可以读取，无法将修改同步回Driver端。StructuredStreaming的exactly-once语义保证，可以实现处理过程中即使节点故障重启，也不会出现重复计算或者丢失数据的情况。答案：正确解析：StructuredStreaming通过内置的偏移量自动管理、事务性写入检查点的机制，完全可以实现端到端的精确一次语义保证，不会出现数据重复或者丢失。一、简答题（共5题，每题6分，共30分）请简要描述Spark核心抽象RDD的五大核心特性答案：第一，RDD是由一系列连续的分区（分片）组成的集合，每一个分区对应数据的一个子集，分布在集群不同的节点上；第二，每一个RDD都提供了核心的compute计算函数，该函数会作用在每一个分区上，生成该分区对应的计算结果；第三，每一个RDD都维护了完整的依赖关系列表，记录了该RDD生成所依赖的父RDD的全部信息，用于任务容错和DAG调度；第四，键值对类型的RDD可以选择性的指定自定义分区器，控制数据按照指定规则分布到不同的子分区中，常用的分区器比如哈希分区器、范围分区器；第五，每一个RDD的分区都保留了优先位置信息，Spark调度任务的时候会优先将任务分配到数据所在的节点上，实现移动计算不移动数据，减少数据跨节点传输的开销。解析：五大特性是RDD从设计层面解决分布式系统容错、调度、数据本地化三大核心痛点的核心依据，每一个特性都对应了Spark的一项核心能力，在实际开发中可以基于这些特性针对性做优化，比如自定义分区器减少shuffle开销。请简要描述Spark中窄依赖和宽依赖的核心区别答案：第一，依赖关系不同，窄依赖的子RDD一个分区只依赖父RDD的一个分区，是一对一的映射关系；宽依赖的子RDD一个分区会依赖父RDD的多个分区，是一对多的映射关系；第二，性能开销不同，窄依赖没有shuffle过程，不会产生大量跨节点网络传输开销，运行速度更快；宽依赖必须经过shuffle过程，会产生大量的磁盘读写和网络传输开销，是Spark任务性能的主要瓶颈点；第三，容错成本不同，窄依赖场景下分区失败只需要重新计算单个父分区即可，容错成本极低；宽依赖场景下子分区失败需要重新计算所有关联的父分区数据，容错成本很高；第四，任务阶段划分不同，Spark的DAGScheduler会把连续的多个窄依赖算子放到同一个任务阶段中执行，遇到宽依赖就会切分出新的任务阶段，作为不同阶段的分界点。解析：宽窄依赖的区分是Spark任务调度和性能优化的核心基础，开发者在实际开发中要尽可能多使用窄依赖算子，减少不必要的宽依赖shuffle操作，大幅提升任务运行效率。请简要描述Spark一个完整的作业从提交到运行结束的核心流程答案：第一，用户提交Spark应用程序，驱动程序启动初始化SparkContext上下文，向集群资源管理器申请资源，注册当前应用的信息；第二，资源管理器根据当前集群的资源使用情况，分配对应的工作节点容器，启动Executor进程，Executor向驱动端的SparkContext进行反向注册，汇报自身的可用资源信息；第三，用户代码中的转换算子逐步生成对应的RDD依赖链，当遇到第一个行动算子的时候触发Job的提交，DAGScheduler遍历RDD依赖链构建完整的DAG图，根据宽窄依赖关系划分任务阶段，生成每一个阶段对应的任务集合；第四，TaskScheduler把生成的任务集合按照数据本地化规则分发到对应的Executor节点上，Executor启动线程池执行分配到的具体任务；第五，所有任务执行完成之后释放集群占用的资源，驱动程序输出最终的计算结果，整个作业运行结束。解析：该流程覆盖了Spark从资源申请、DAG构建、任务分发到执行结束的全生命周期，理解整个运行流程可以帮助开发者快速定位任务运行过程中资源不足、任务调度慢、数据本地化率低等常见问题。请简要描述Spark中累加器的核心使用场景和注意事项答案：第一，累加器的核心使用场景是分布式环境下实现全局统一计数，比如统计整个任务运行过程中处理的元素总数量、异常数据的条数、符合特定条件的元素数量等，避免通过普通shuffle实现全局计数带来的额外开销；第二，累加器只能在驱动端进行初始化赋值，分布式的任务节点上只能对累加器执行累加操作，不能直接读取累加器的最终值，累加器的最终值只有在驱动端可以读取；第三，累加器的更新操作只会在任务执行过程中生效，如果任务发生重试或者推测执行，累加器的数值可能会被重复累加，导致最终结果出现偏差；第四，官方只原生支持数值类型的累加器，开发者也可以自定义实现自定义类型的累加器，实现分布式场景下的全局聚合逻辑。解析：累加器是Spark非常重要的共享变量，使用不当很容易出现结果重复累加的bug，实际生产中要尽可能避免在可能出现重试的算子中执行累加器更新操作，保证统计结果的准确性。请简要描述Spark相比传统Hive计算引擎的核心性能优势答案：第一，Spark的计算模型基于分布式内存抽象，中间计算结果优先存储在内存中，相比Hive依赖MapReduce多轮落盘的计算模型，减少了大量不必要的磁盘IO开销；第二，Spark的Catalyst优化器会对SQL语句进行多层级的全局优化，包括逻辑计划优化、物理计划优化、代价估算等，生成的执行计划执行效率远高于Hive简单生成的MapReduce执行计划；第三，Spark支持DAG任务调度，可以把多个连续的算子放到同一个流程中执行，不需要像Hive一样每一个MapReduce任务都启动独立的JVM进程，大幅降低了任务调度的额外开销；第四，Spark支持流批一体的处理模式，同一份数据的离线批处理计算和实时增量计算可以复用几乎相同的逻辑，大幅降低开发和维护成本。解析：这些优势也是目前Spark逐步取代传统HiveMapReduce引擎成为大数据离线计算主流选择的核心原因，在大数据生产环境中绝大多数的离线数仓任务都已经迁移到Spark引擎上运行。一、论述题（共3题，每题10分，共30分）结合实际的离线用户行为数据分析场景，论述Spark中Shuffle过程的常见性能问题和对应的优化策略答案：首先，Shuffle是Spark任务性能最主要的瓶颈点，在用户行为数据分析场景中，经常需要对海量用户的行为日志按照用户ID分组聚合，统计每个用户的访问总次数、停留时长等指标，这个过程会触发大量的shuffle操作，很容易出现运行慢、节点卡顿、数据倾斜等问题。第一类常见问题是shuffle过程产生大量临时文件，磁盘IO阻塞。默认的Sparkshuffle实现会生成大量的小分区数据文件，海量的小文件读写会导致磁盘的随机IO压力剧增，任务大量时间卡在读写磁盘的环节。对应的优化策略可以替换为shuffle的排序优化实现，开启合并shuffle文件的配置，减少生成的临时小文件数量，同时可以配置使用SSD磁盘存储shuffle中间数据，大幅提升磁盘读写速度，某互联网公司的用户行为统计任务开启合并shuffle配置之后，shuffle阶段的运行时间直接降低了百分之四十以上。第二类常见问题是shuffle的并行度设置不合理，并行度过低会导致单个分区处理的数据量过大，出现内存溢出，并行度过高会生成大量小任务，调度开销剧增。对应的优化策略是根据输入的总数据量设置合理的shuffle并行度，一般保证每一个shuffle分区的大小在一百多MB到两百多MB之间最优，比如处理一百亿条总大小1TB的用户行为日志，把shuffle并行度设置为八千左右，每个分区的数据量刚好控制在一百多MB，不会出现单个分区数据过大的情况。第三类常见问题是shuffle数据倾斜，某几个key的数量远大于其他key，导致对应的单个任务运行时间长达数小时，其他任务几分钟就运行完成，整个作业被拖慢。对应的优化策略可以采用预聚合、加盐打散key、小表广播join的方式，比如统计用户行为的时候，某个头部大V用户的行为数据量占了总数据的百分之三十，直接分组聚合会出现严重倾斜，我们可以先把大V用户的ID加上随机后缀打散分成多个子分组，先做局部聚合再去掉后缀做第二次全局聚合，就可以把倾斜的压力分散到多个任务中，避免单个任务压力过大。最后，通过上述一系列shuffle优化策略，可以将原本运行超过两个小时的用户行为数据分析任务优化到二十分钟以内运行完成，性能得到数倍的提升，完全可以满足生产环境定时任务的运行时效要求。结合实时网站访问日志统计的场景，论述SparkStreaming和StructuredStreaming的差异，说明不同场景下的选型逻辑答案：首先，两个框架都是Spark生态下的实时流处理组件，但是二者的底层设计思路有很大的差异，分别适配不同的实时处理场景。第一点差异是底层抽象不同，SparkStreaming是基于微批处理的DStream抽象，每一个批次本质是独立的RDD，API设计和SparkCore的RDD高度相似，开发人员可以用传统的RDD算子编写流处理逻辑，但是流和批的代码逻辑差异很大，很难复用。而StructuredStreaming是基于SparkSQL引擎构建的流处理框架，把实时流数据当成一张不断增长的静态表来处理，开发者可以直接用SQL语句编写流处理逻辑，离线批处理和实时流处理可以完全复用同一套SQL代码，实现流批一体。在网站访问日志统计的场景中，我们同时需要离线统计昨天全量日志的访问量，也需要实时统计最近一分钟的访问量，如果用StructuredStreaming实现，同一套统计逻辑既可以跑离线批也可以跑实时流，不需要维护两套代码，大幅降低维护成本。第二点差异是处理能力的丰富度不同，传统SparkStreaming原生支持的窗口聚合、状态管理能力比较简单，复杂的晚到数据处理需要开发者自己手动实现，而StructuredStreaming原生内置了水位线机制，可以自动处理晚到的数据，自动清理过期的状态数据，不需要开发者自己管理状态的过期逻辑。比如网站日志经常有网络延迟导致的晚到几分钟的日志，用StructuredStreaming的Watermark配置十分钟的允许晚到时间，框架会自动处理晚到数据更新对应的统计结果，不会出现统计数据不准的问题。第三点差异是容错语义的实现复杂度不同，SparkStreaming要实现端到端的精确一次语义，需要开发者自己手动维护偏移量、手动实现事务写入，开发复杂度很高，而StructuredStreaming内置了自动的偏移量管理和检查点机制，开发者不需要额外编写代码，默认就可以实现精确一次的语义保证，避免数据重复统计或者丢失。选型逻辑方面，如果是非常老的存量项目，之前的代码都是用RDD原生API编写，没有结构化数据处理需求，团队对SparkStreaming的使用经验很丰富，可以选择SparkStreaming；如果是新开发的实时流处