2025年spark面试题及答案

2025年spark面试题及答案1.请说明Spark中Driver、Executor、ClusterManager的核心职责及三者协作流程。Driver是Spark应用的主进程，负责解析用户代码提供DAG（有向无环图），通过DAGScheduler划分Stage，再由TaskScheduler将Task分发到集群执行，并监控任务状态和处理结果。Executor是工作节点上的进程，负责实际执行Task，管理内存和计算资源，缓存RDD或DataFrame数据，并将任务结果返回给Driver。ClusterManager（如YARN、Kubernetes）负责集群资源的分配与管理，为Driver和Executor分配计算资源（CPU、内存），确保应用按需获取资源。协作流程：用户提交应用后，ClusterManager为Driver分配资源启动Driver进程；Driver根据代码逻辑提供DAG，划分Stage并提供Task集合；TaskScheduler向ClusterManager申请Executor资源，启动Executor后将Task分发至Executor执行；Executor执行完成后将结果反馈Driver，Driver汇总所有结果并返回给用户。2.RDD、DataFrame、DataSet的核心区别是什么？在Spark3.x中如何选择使用？RDD（弹性分布式数据集）是Spark1.x的核心抽象，存储未结构化的Java/Scala对象，支持丰富的转换（Transform）和行动（Action）操作，但缺乏结构化信息（Schema），无法利用Catalyst优化器进行高级优化。DataFrame是带Schema的分布式数据集，类似关系型数据库的表，通过Catalyst优化器对SQL和DataFrame操作进行逻辑计划和物理计划的优化，提升执行效率，但编译时不检查类型（如Scala中为Row类型）。DataSet是DataFrame的扩展，结合了RDD的类型安全（强类型）和DataFrame的Schema特性，每个元素是明确的类型对象（如caseclass），在Spark2.x中被引入以平衡类型安全与优化能力。在Spark3.x中，DataFrame与DataSet的API已高度融合（DataFrame是DataSet[Row]的别名），推荐优先使用DataFrame/DataSet（DSL或SQL），因其能利用Catalyst的执行计划优化（如谓词下推、列剪枝）、Tungsten引擎的内存管理（二进制存储，减少GC）。仅当需要更细粒度控制数据处理逻辑（如自定义分区逻辑）或处理非结构化数据时，才考虑使用RDD。若需类型安全（如避免运行时类型错误），可使用DataSet（如DataSet[User]）。3.简述Spark中DAG的提供过程及Stage的划分依据。DAG（有向无环图）由Driver根据用户代码中的RDD/DataFrame转换操作提供。每个转换操作（如map、filter、join）会提供新的RDD/DataFrame，形成父子依赖关系，最终所有操作构成一个由多个RDD/DataFrame节点组成的DAG。Stage（阶段）的划分由DAGScheduler完成，核心依据是RDD之间的依赖类型：窄依赖（NarrowDependency）和宽依赖（WideDependency）。窄依赖指父RDD的一个分区仅被一个子RDD分区使用（如map、filter），计算可在单个节点内完成；宽依赖指父RDD的分区被多个子RDD分区使用（如shuffle操作，如groupByKey、reduceByKey），需跨节点传输数据。DAGScheduler会在宽依赖处划分Stage边界：每个Stage包含从数据源到宽依赖前的所有窄依赖操作，宽依赖后的操作作为下一个Stage。最终，DAG被划分为多个Stage，每个Stage内的任务（Task）可并行执行，Stage之间按顺序执行（前一个Stage完成后，下一个Stage开始）。4.SparkShuffle的核心流程是怎样的？Spark3.x对Shuffle做了哪些优化？Shuffle是宽依赖操作（如join、groupBy）中数据重组的过程，分为ShuffleWrite和ShuffleRead两个阶段。ShuffleWrite阶段：Executor在计算完当前Stage的Task后，将需要Shuffle的数据按目标分区（由分区器决定，如HashPartitioner）写入本地磁盘（或内存，视配置而定），每个分区对应一个临时文件。ShuffleRead阶段：下一个Stage的Executor从所有上游Executor的本地磁盘读取对应分区的数据，合并后进行聚合或其他操作。Spark3.x对Shuffle的优化包括：UnifiedShuffleService：将Shuffle文件管理从Executor剥离，由独立的ShuffleService进程管理，避免Executor重启导致Shuffle文件丢失（需配合YARN或Kubernetes）。ShuffleMerge（Spark3.2+）：在ShuffleWrite阶段合并小文件，减少磁盘I/O和文件句柄开销。例如，当使用SortShuffleManager时，多个Task的Shuffle数据可合并写入同一文件，通过索引文件管理分区偏移量。自适应分区合并（AQE中的ShufflePartitionMerging）：在自适应查询执行（AQE）中，根据数据量动态调整Shuffle分区数。若发现某些分区数据量过小（如小于阈值），合并这些分区以减少后续Stage的Task数量，降低任务调度和执行开销。5.如何诊断和解决Spark任务中的数据倾斜问题？请结合具体场景说明。数据倾斜表现为任务执行时间极不均衡，部分Task耗时远高于其他Task（可通过SparkUI的Stage详情页查看Task运行时间分布，或通过日志发现某些Executor的磁盘/网络I/O激增）。根本原因是某几个Key的数量远大于其他Key（如用户行为数据中某热门商品的点击量占比90%）。诊断步骤：查看SparkUI的Stage详情，定位耗时Task对应的Shuffle操作（如join、groupByKey）。对倾斜Key进行采样：在Shuffle前添加采样逻辑（如对RDD使用sample方法），统计Key的分布，找出高频Key。解决方法（按场景选择）：聚合前置：若倾斜发生在groupByKey后聚合（如count），改用reduceByKey或aggregateByKey，在Map端先局部聚合，减少Shuffle数据量。例如，将rdd.groupByKey().mapValues(_.sum())改为rdd.reduceByKey(_+_)。加盐分桶：对倾斜Key添加随机前缀（如0~n的随机数），将原Key拆分为多个子Key（如key_0,key_1），分散到不同分区。例如，处理groupByKey倾斜时，对Key进行map操作：key=>(key+"_"+Random.nextInt(10),value)，分组后聚合，再去除前缀合并结果。广播小表：若倾斜发生在join操作且其中一张表较小（如维度表），使用broadcastjoin替代shufflejoin。例如，将df.join(bigDf,"id")改为df.join(broadcast(smallDf),"id")，避免Shuffle。动态调整分区数：通过spark.sql.shuffle.partitions（默认200）增大分区数，分散倾斜Key到更多分区（仅当数据量极大时有效，需权衡分区数过多导致的任务数增加）。示例场景：某电商用户行为日志中，某商品ID（如item_1001）的点击量占总数据的80%，导致groupBy(item_id).count()时对应Task耗时30分钟，其他Task仅耗时30秒。解决方案：对item_id添加0~9的随机前缀，转换为item_1001_0到item_1001_9，分组统计后，再按原item_id合并结果，将原单个倾斜Task拆分为10个小Task，总耗时降至5分钟。6.简述Spark内存管理机制（堆内/堆外内存）及关键参数配置。Spark内存分为堆内内存（On-Heap，JVM堆内存）和堆外内存（Off-Heap，直接内存）。堆内内存由JVM管理，受GC影响；堆外内存由Spark直接管理（通过UnsafeAPI），减少GC开销，提升内存使用效率（如Tungsten引擎的二进制存储）。内存分配核心参数（以Executor内存为例，总内存由spark.executor.memory指定）：Execution内存：用于Shuffle、join、sort、aggregation等计算过程中的数据缓存和中间结果存储。堆内Execution内存由spark.shuffle.memoryFraction（默认0.2）控制，堆外由spark.memory.offHeap.size（需启用spark.memory.offHeap.enabled=true）。Storage内存：用于缓存RDD、DataFrame（如persist()、cache()）。堆内Storage内存由spark.storage.memoryFraction（默认0.6）控制，与Execution内存共享统一内存池（Spark1.6+引入统一内存管理，两者可动态调整，如Storage不足时可借用Execution内存，反之亦然）。Other内存：用于用户代码（如UDF执行）、JVM元数据等，占剩余内存。关键优化参数：spark.executor.memory：单个Executor的总内存，建议设置为16~64GB（根据集群资源调整）。spark.memory.offHeap.enabled：启用堆外内存，适用于内存密集型任务（如大表join），减少GC停顿。spark.memory.fraction（默认0.6）：统一内存池中用于Execution和Storage的比例，剩余0.4用于Other内存。spark.shuffle.spill.batchSize：Shuffle过程中内存缓存的批大小，调小可减少内存压力，但增加磁盘溢出（spill）次数。7.Spark任务提交时，如何选择集群模式（Client/Cluster）？Driver节点的位置对任务有何影响？Client模式下，Driver运行在任务提交的客户端机器（如本地笔记本或提交脚本所在节点），Executor运行在集群节点。适用于开发调试（可直接查看Driver日志），但需注意客户端与集群的网络延迟（如提交脚本在公网，集群在私有云，可能导致心跳超时）。Cluster模式下，Driver运行在集群的某个节点（由ClusterManager分配，如YARN的ApplicationMaster），客户端提交任务后可断开连接。适用于生产环境，避免客户端网络中断导致任务失败。Driver节点的位置直接影响任务稳定性和性能：网络延迟：Driver需与所有Executor通信（发送Task、接收状态），若Driver与Executor跨机房或网络带宽不足，会导致任务超时（如work.timeout默认120s）。资源占用：Driver本身需要一定资源（CPU、内存），生产环境建议为Driver分配独立资源（如YARN中通过--driver-memory指定内存，--driver-cores指定CPU核数），避免与Executor竞争资源。日志收集：Client模式下，Driver日志输出到客户端，方便实时查看；Cluster模式下，Driver日志需通过集群日志系统（如YARN的logs命令）获取，调试时需额外操作。8.解释Spark中的推测执行（SpeculativeExecution）机制，其触发条件和潜在问题是什么？推测执行是Spark为解决任务执行缓慢（StragglerTask）而设计的容错机制。当某个Stage中存在Task运行时间明显长于其他Task时，Spark会在其他Executor上启动该Task的副本（SpeculativeTask），取最先完成的结果作为最终结果，终止其他副本。触发条件（由spark.speculation控制，默认false）：当前Stage已完成的Task数量超过总Task数的50%（spark.speculation.quantile，默认0.75）。缓慢Task的运行时间超过已完成Task平均时间的spark.speculation.multiplier倍（默认1.5）。潜在问题：资源浪费：同时运行多个Task副本会增加集群资源消耗（CPU、内存），可能导致其他任务资源不足。数据一致性风险：若Task包含副作用（如写入外部存储），多个副本执行可能导致重复写入（需避免在Action操作中使用有副作用的代码）。误判可能：某些Task本身需要处理更多数据（如数据倾斜），推测执行可能无法解决根本问题，反而加重集群负载。建议仅在数据分布均匀、Task执行时间稳定的场景启用（如日志清洗、简单聚合），数据倾斜场景需优先解决倾斜问题而非依赖推测执行。9.如何优化SparkSQL的查询性能？请列举至少5种常见优化手段。（1）谓词下推（PredicatePushdown）：将过滤条件尽可能下推到数据源（如Hive、JDBC），减少数据读取量。SparkSQL会自动优化，但需确保数据源支持（如使用Parquet时，谓词下推可直接跳过无关RowGroup）。（2）列剪枝（ColumnPruning）：仅读取查询需要的列，减少I/O。通过SELECT指定列或使用DataFrame的select方法实现，SparkCatalyst优化器会自动处理。（3）分区裁剪（PartitionPruning）：对分区表（如Hive分区表），在WHERE子句中过滤分区列（如dt='2024-01-01'），避免扫描全部分区。需确保分区列被正确使用（如直接比较常量，而非函数处理后的列）。（4）选择合适的Join策略：根据表大小选择广播Join（broadcastjoin，小表广播）、ShuffleHashJoin（大表与中等表）、SortMergeJoin（大表与大表，需排序）。可通过spark.sql.autoBroadcastJoinThreshold（默认10MB）调整广播表大小阈值，或手动使用broadcast()函数指定。（5）优化UDF性能：避免使用普通UDF（每行调用一次，性能差），改用向量化UDF（VectorizedUDF，基于Arrow，批量处理数据）。在Spark3.x中，通过@VectorizedUDF注解（Scala）或pandas_udf（Python）实现，减少函数调用开销。（6）调整Shuffle分区数：通过spark.sql.shuffle.partitions（默认200）设置Shuffle操作的分区数。数据量较大时（如100GB+），增大分区数（如500）可提升并行度；数据量较小时，减小分区数（如100）可减少Task数，降低调度开销。（7）启用AQE（AdaptiveQueryExecution）：Spark3.x的自适应查询执行功能，可动态调整执行计划。例如，根据Shuffle阶段的统计信息（如分区大小）动态合并小分区、调整Join策略（如将SortMergeJoin切换为HashJoin），提升复杂查询的性能。10.简述SparkStreaming与StructuredStreaming的核心区别，StructuredStreaming的优势有哪些？SparkStreaming基于微批处理（Micro-Batch），将输入数据流按固定时间窗口（如1秒）划分为多个RDD批次，处理逻辑基于DStream（离散流）。StructuredStreaming是Spark2.x引入的流处理框架，基于DataFrame/DataSetAPI，采用“连续处理”模型（本质是增量微批处理，但对外表现为持续流），底层通过检查点（Checkpoint）记录偏移量，保证端到端的精确一次（Exactly-Once）语义。StructuredStreaming的优势：统一API：使用DataFrame/DataSet的DSL或SQL，与批处理逻辑一致（如同一套代码可处理批数据和流数据），降低开发成本。更强大的容错性：通过检查点（存储偏移量、中间状态）实现故障恢复，无需手动管理RDD的容错。支持事件时间（EventTime）和水纹（Watermark）：可处理乱序数据（如延迟到达的日志），通过watermark定义延迟容忍时间，确保准确的时间窗口聚合（如每小时的用户行为统计）。自动背压（Backpressure）：根据下游处理能力自动调整读取速率，避免内存溢出（通过spark.streaming.backpressure.enabled控制，StructuredStreaming默认启用）。支持长期运行的状态管理：对有状态操作（如窗口聚合、去重），StructuredStreaming优化了状态存储（如使用RocksDB），支持更大规模的状态数据，避免SparkStreaming中因状态过大导致的性能下降。11.当Spark任务出现OOM（OutOfMemory）时，可能的原因及解决方法有哪些？可能原因：（1）Executor内存不足：单个Executor分配的内存（spark.executor.memory）过小，无法存储Shuffle中间结果或缓存数据。（2）数据倾斜：某Task处理的数据量远大于其他Task，导致该Executor内存耗尽（如倾斜Key对应的Task处理10GB数据，其他Task仅处理1GB）。（3）缓存过多：大量使用persist(StorageLevel.MEMORY_ONLY)缓存RDD/DataFrame，超出Executor内存容量。（4）大对象或未释放的资源：用户代码中创建大对象（如超大数组）或未关闭的资源（如打开的文件流），占用堆内存。（5）Shuffle过程内存溢出：ShuffleRead阶段拉取的数据量过大，超出Execution内存限制，导致频繁磁盘溢出（spill）或OOM。解决方法：（1）增加Executor内存：调大spark.executor.memory（如从8GB增至16GB），或启用堆外内存（spark.memory.offHeap.enabled=true并设置spark.memory.offHeap.size）。（2）优化数据倾斜：参考问题5的方法，分散倾斜Key的数据量，减少单个Task的处理压力。（3）调整缓存策略：将MEMORY_ONLY改为MEMORY_AND_DISK（内存不足时溢写磁盘），或降低缓存级别（如使用MEMORY_ONLY_SER，序列化存储减少内存占用）。（4）优化代码逻辑：避免在闭包中引用大对象（如在map操作中引用全局大数组），及时释放不再使用的变量（如调用unpersist()释放缓存）。（5）调整Shuffle参数：增大spark.shuffle.memoryFraction（Execution内存占比），或调小spark.shuffle.spill.batchSize（减少单次缓存的数据量，增加磁盘溢出次数但降低内存压力）。（6）减少并行度：降低spark.default.parallelism或spark.sql.shuffle.partitions，减少同时运行的Task数，每个Task分配更多内存（需权衡并行度降低导致的总耗时增加）。12.解释Spark中的Checkpoint机制，与RDD缓存（persist）有何区别？何时需要使用Checkpoint？Checkpoint（检查点）是将RDD的部分中间结果持久化到可靠存储（如HDFS、S3）的机制，用于切断RDD的依赖链，提升容错能力。RDD缓存（persist/cache）是将数据存储在内存或磁盘（Executor本地），依赖链仍保留（丢失数据时通过父RDD重算）。核心区别：存储位置：Checkpoint数据存储在外部可靠存储（如HDFS），缓存数据存储在Executor本地（内存/磁盘）。依赖链：Checkpoint会切断RDD的父依赖（RDD的dependencies变为空），缓存保留依赖链。容错性：Checkpoint数据不会因Executor故障丢失（外部存储），缓存数据可能因Executor重启丢失（需重算）。使用场景：（1）长依赖链的RDD：如多次转换后的RDD（如经过10次map、filter操作），重算成本高（需从数据源重新计算所有父RDD），Checkpoint可避免重复计算。（2）迭代计算：如MLlib的迭代算法（梯度下降），每次迭代依赖前一次结果，Checkpoint可保存中间状态，避免某轮迭代失败后从头开始。（3）关键中间结果：如需要长期保留的聚合结果（如每日交易总额），Checkpoint到HDFS可作为冷备份。使用注意事项：Checkpoint会带来额外的I/O开销（写入外部存储），需选择合适的时机（如在Stage结束后调用），并配合缓存（先cache再checkpoint）减少重算开销（spark.sparkContext.setCheckpointDir设置检查点目录）。13.如何监控Spark任务的运行状态？常用指标有哪些？监控手段：SparkUI：Driver进程启动的Web界面（默认端口4040），提供Stage、Task、Executor的详细信息（如运行时间、输入输出数据量、Shuffle读写量）。Metrics系统：通过spark.metrics.conf配置，将指标导出到Prometheus、Grafana、Datadog等监控平台。常见指标包括Executor内存使用率、GC时间、Shuffle速率、Task成功率。日志分析：收集Driver和Executor的日志（如stdout、stderr），通过ELK（Elasticsearch、Logstash、Kibana）或Splunk分析异常（如OOM堆栈、连接超时）。第三方工具：如ApacheZeppelin、JupyterNotebook的Spark监控插件，或云厂商提供的管理控制台（如AWSEMR、阿里云E-MapReduce）。关键监控指标：（1）Executor相关：活跃Executor数（若持续减少可能是资源不足或节点故障）、Executor内存使用率（超过80%需关注OOM风险）、ExecutorGC时间（过长的GC停顿会影响任务执行，如YoungGC超过500ms/次）。（2）Task相关：Task执行时间分布（是否存在StragglerTask）、Task失败率（失败原因如数据倾斜、内存溢出）、Task输入输出数据量（如ShuffleRead大小异常可能是数据倾斜）。（3）Shuffle相关：ShuffleWrite/Read数据量（过大的Shuffle量需优化Join或GroupBy逻辑）、ShuffleSpill大小（频繁溢写磁盘说明内存不足）。（4）作业进度：Stage完成百分比、剩余Stage数（预测任务完成时间）。14.简述Spark3.x的主要新特性及其对开发的影响。（1）自适应查询执行（AQE，AdaptiveQueryExecution）：动态调整执行计划，根据运行时统计信息优化。例如，自动合并小Shuffle分区（减少后续Task数）、切换Join策略（如根据小表大小将SortMergeJoin改为HashJoin）、动态调整倾斜分区的处理方式。对开发的影响：减少手动调优（如调整分区数、选择Join策略），提升复杂查询的性能稳定性。（2）矢量计算（VectorizedProcessing）：DataFrame的UDF支持向量化执行（基于Arrow），批量处理数据（如10000行/批）而非逐行处理，显著提升UDF性能（PythonUDF性能可提升10~100倍）。开发时推荐使用pandas_udf（Python）或@VectorizedUDF（Scala）替代普通UDF。（3）DeltaLake集成：Spark3.x与DeltaLake深度集成，支持ACID事务、时间旅行（TimeTravel）、增量读取（IncrementalRead）。开发流批一体（Batch+Streaming）应用时，可使用DeltaLake作为统一存储，简化架构（如用StructuredStreaming读取Delta表，支持Exactly-Once写入）。（4）优化的空值处理：支持ANSISQL的空值排序（NULLSFIRST/LAST），并优化了空值在Shuffle和Join中的处理逻辑，减少因空值导致的数据倾斜（如将NULL视为一个普通Key，而非分散到多个分区）。（5）改进的资源管理：支持Kubernetes原生调度（SparkonKubernetes），提升容器化部署的效率；引入动态资源分配（DynamicAllocation）的优化策略，根据任务负载自动调整Executor数量（减少空闲资源浪费）。（6）Scala2.13支持：Spark3.x开始支持Scala2.13，兼容最新Scala特性（如UnionTypes、OpaqueTypes），提升代码的可维护性。15.如何设计一个高并发、低延迟的Spark实时数据处理系统？需要考虑哪些关键因素？（1）数据流模型选择：使用StructuredStreaming而非SparkStreaming，利用其事件时间处理、水纹机制和自动背压，支持高并发的乱序数据。（2）输入源优化：选择高吞吐、低延迟的消息队列（如Kafka）作为输入源，配置合理的分区数（与Executor数匹配），提升并行读取能力（如Kafka分区数=Executor数×每个Executor的Core数）。（3）处理逻辑优化：避免复杂的Shuffle操作（如减少groupByKey，改用reduceByKey或窗口聚合）。使用向量化UDF提升处理速度，避免在流处理中使用耗时的外部调用（如频繁查询数据库，可改为广播维度表或使用本地缓存）。合理设置窗口大小（如滑动窗口1分钟，窗口长度5分钟），平衡延迟与准确性。（4）资源分配：增加Executor数量和Core数（如每个Executor8核），提升并行度。调整内存分配（spark.executor.memory=32GB），增大Execution内存占比（spark.memory.fraction=0.7），减少Shuffle溢写磁盘的概率。启用堆外内存（spark.memory.offHeap.enabled=true），降低GC对实时性的影响。（5）容错与恢复：启用Checkpoint（设置checkpointLocation到HDFS/S3），确保故障恢复时数据不丢失。配置合理的重试策略（如Kafka消费者的自动重平衡、StructuredStreaming的故障重试次数）。（6）输出Sink优化：选择支持批量写入、事务的输出系统（如DeltaLake、HBase、JDBCwithbatch），减少逐条写入的开销。对于低延迟要求，可配置异步写入或缓存批量数据（如每1000条写入一次）。（7）监控与调优：实时监控Task延迟、Executor内存使用率、Kafka消费滞后（Lag），通过AQE动态调整执行计划，根据负载动态扩缩容Executor（结合Kubernetes的HorizontalPodAutoscaler）。16.解释Spark中的Catalyst优化器的工作流程，它是如何提升查询性能的？Catalyst优化器是SparkSQL的核心组件，负责将用户的SQL或DataFrame操作转换为高效的执行计划。工作流程分为四个阶段：（1）分析（Analysis）：将未解析的逻辑计划（UnresolvedLogicalPlan）转换为解析后的逻辑计划（ResolvedLogicalPlan）。通过Catalog（元数据存储）解析表名、列名、函数名（如识别df("age")中的age列是否存在），解决歧义（如同名表）。（2）逻辑优化（LogicalOptimization）：对解析后的逻辑计划应用一系列优化规则（Rule），提供优化的逻辑计划（OptimizedLogicalPlan）。常见规则包括谓词下推（PredicatePushdown）、列剪枝（ColumnPruning）、常量折叠（ConstantFolding，如将1+2转换为3）、条件合并（CombiningConditions）等。（3）物理计划提供（PhysicalPlanning）：将优化的逻辑计划转换为多个可能的物理计划（PhysicalPlan），每个物理计划对应具体的执行算子（如ShuffleHashJoin、SortMergeJoin）。Catalyst会根据统计信息（如表大小、列基数）选择成本最低的物理计划（Cost-BasedOptimization，CBO）。（4）代码提供（CodeGeneration）：将物理计划转换为可执行的Java字节码（通过Tungsten引擎），使用代码提供技术（如Whole-StageCodeGeneration）将多个算子合并为一个函数，减少虚函数调用和中间对象创建，提升执行速度。Catalyst通过逻辑优化（消除冗余操作）、物理计划选择（基于成本的最优算子组合）和代码提供（提升执行效率）三方面提升查询性能。例如，对SELECTCOUNT()FROMuserWHEREage>18，Catalyst会先应用谓词下推（仅读取age>18的行），再应用列剪枝（仅读取age列），最后选择高效的聚合算子（如HashAggregate），并通过代码提供将过滤和计数合并为一个循环，减少数据处理的中间步骤。17.如何处理Spark任务中的外部依赖（如第三方JAR包）？不同提交模式（Client/Cluster）下有何区别？处理外部依赖的方法：（1）--jars参数：提交任务时通过--jars指定本地或HDFS路径的JAR包，Spark会将这些JAR包分发到所有Executor和Driver节点。例如：spark-submit--jars/path/to/mysql-connector.jar,/path/to/my-udf.jar...（2）打包到应用JAR中：使用sbt-assembly或MavenShadePlugin将依赖JAR包打入应用的fatJAR中（需注意冲突，如不同版本的Guava）。（3）HDFS或分布式存储：将JAR包上传到HDFS或S3，通过--jarshdfs:///path/to/jar指定，避免本地路径导致的分发失败。不同提交模式的区别：Client模式：Driver运行在客户端，--jars指定的JAR包会从客户端分发到集群的Executor节点。需确保客户端与集群节点有相同的文件路径或可访问的HDFS路径。Cluster模式：Driver运行在集群节点，--jars指定的JAR包需从提交客户端上传到集群（通过Spark的分发机制），或直接使用HDFS/S3路径（避免客户端与集群网络问题导致的分发失败）。注意事项：若依赖JAR包较大（如100MB+），使用--jars分发可能影响任务启动时间（需传输到所有节点），建议上传到HDFS并通过HDFS路径引用。对于Scala版本不兼容的JAR包（如Spark3.x使用Scala2.12，而依赖JAR包为Scala2.13），需选择与Spark兼容的版本，避免类加载错误（如NoClassDefFoundError）。18.简述SparkMLlib的核心设计思想，与传统机器学习库（如Scikit-learn）相比有何优势？MLlib的核心设计思想是“分布式机器学习”，通过Spark的分布式计算能力处理海量数据（TB级以上），同时提供与SparkDataFrame集成的高层API（如Pipeline），支持从数据加载、特征工程到模型训练、评估的全流程。与Scikit-learn相比的优势：（1）分布式处理：支持在集群上并行训练模型（如线性回归、随机森林），处理单节点无法容纳的大规模数据。（2）与Spark生态集成：直接使用DataFrame作为输入，无缝衔接SparkSQL和SparkStreaming（如实时特征提取+在线模型训练）。（3）可扩展的算法：基于RDD/DataFrame的分布式计算框架，算法设计考虑了数据分区、Shuffle优化（如矩阵乘法的分块计算），提升大规模数据下的训练效率。（4）Pipeline支持：通过Transformer（特征转换）和Estimator（模型训练）的组合，定义端到端的机器学习流程，支持模型版本管理和参数调优（如CrossValidator）。局限性：MLlib的算法种类（如深度神经网络支持有限）和实时性（批量训练为主）不如专用框架（如TensorFlow、PyTorch），但在分布式特征工程和大规模统计学习场景中优势显著。19.当Spark任务长时间卡在“Running”状态但无进展时，可能的原因及排查步骤是什么？可能原因：（1）资源不足：集群CPU、内存不足，无法分配足够的Executor或Core，导致Task无法启动（如YARN的ResourceManager无可用资源）。（2）死锁或线程阻塞：用户代码中存在死锁（如多个线程争夺同一锁）或阻塞操作（如调用Thread.sleep()、等待外部API响应