Spark 原理与实践 课后习题 | 青训营笔记

dadongc
191 阅读7分钟

这是我参与「第四届青训营 」笔记创作活动的第5天

题目来源：【大数据专场 学习资料二】第四届字节跳动青训营 - 掘金

  1. 大数据的基础链路是？

    1. 数据收集

      1. 数据库/日志等

    2. 数据存储

      1. 元数据
      2. 数据格式：Iceberg、Parquet、ORC等
      3. 数据存储：HDFS、Kafka、HBase、TOS等

    3. 数据计算

      1. 计算框架：Spark、Flink、Clickhouse
      2. 资源调度：Yarn、K8s

    4. 数据应用：报表、大盘、广告、推荐

  1. Spark RDD是如何执行的？如何划分stage？

    1. 当RDD对象创建后，SparkContext会根据RDD对象构建DAG有向无环图，然后将Task提交给DAGScheduler。DAGScheduler根据ShuffleDependency将DAG划分为不同的Stage，为每个Stage生成TaskSet任务集合，并以TaskSet为单位提交给TaskScheduler。TaskScheduler根据调度算法(FIFO/FAIR)对多个TaskSet进行调度，并通过集群中的资源管理器(Standalone模式下是Master，Yarn模式下是ResourceManager)把Task调度(locality)到集群中Worker的Executor，Executor由SchedulerBackend提供。
    2. 划分Stage的整体思路：从后往前推，遇到宽依赖就断开，划分为一个Stage。遇到窄依赖，就将这个RDD加入该Stage中，DAG最后一个阶段会为每个结果的Partition生成一个ResultTask。每个Stage里面的Task数量由最后一个RDD的Partition数量决定，其余的阶段会生成ShuffleMapTask。

  1. Spark内存是如何管理的？有什么特别机制？

    1. Spark 作为一个基于内存的分布式计算引擎，Spark采用统一内存管理机制。分成Execution Memory（任务执行内存）、Storage Memory（任务存储内存）、User Memory（存储用户自定义的数据结构或者spark内部元数据）、Reserverd Memory（预留内存，防止OOM），还有堆内(On-Heap)内存/堆外(Off-Heap)内存：Executor 内运行的并发任务共享 JVM 堆内内存。为了进一步优化内存的使用以及提高 Shuffle 时排序的效率，Spark 可以直接操作系统堆外内存，存储经过序列化的二进制数据。减少不必要的内存开销，以及频繁的 GC 扫描和回收，提升了处理性能。
    2. 特别机制：动态占用机制。
    3. 设定基本的存储内存(Storage)和执行内存(Execution)区域，该设定确定了双方各自拥有的空间的范围，UnifiedMemoryManager统一管理Storage/Execution内存
    4. 双方的空间都不足时，则存储到硬盘；若己方空间不足而对方空余时，可借用对方的空间
    5. 当Storage空闲，Execution可以借用Storage的内存使用，可以减少spill等操作， Execution内存不能被Storage驱逐。Execution内存的空间被Storage内存占用后，可让对方将占用的部分转存到硬盘，然后"归还"借用的空间
    6. 当Execution空闲，Storage可以借用Execution内存使用，当Execution需要内存时，可以驱逐被Storage借用的内存，可让对方将占用的部分转存到硬盘，然后"归还"借用的空间

  1. Spark Shuffle是怎么产生的？基本流程是？

    1. 当parent task一对多child task时，就需要进行spark shuffle，从不同节点传输数据
    2. spark会创建一个shuffle manager，当rdd一个stage compute完后，对数据sort和split，然后合并成一个磁盘文件和索引文件，下一个stage来时，可以根据索引文件找到数据

  1. SparkSQL执行流程有哪些步骤？每个步骤的左右是？

    1. SQL Parse： 将SparkSQL字符串或DataFrame解析为一个抽象语法树/AST，即Unresolved Logical Plan
    2. Analysis：遍历整个AST，并对AST上的每个节点进行数据类型的绑定以及函数绑定，然后根据元数据信息Catalog对数据表中的字段进行解析。 利用Catalog信息将Unresolved Logical Plan解析成Analyzed Logical plan
    3. Logical Optimization：该模块是Catalyst的核心，主要分为RBO和CBO两种优化策略，其中RBO是基于规则优化，CBO是基于代价优化。 利用一些规则将Analyzed Logical plan解析成Optimized Logic plan
    4. Physical Planning: Logical plan是不能被spark执行的，这个过程是把Logic plan转换为多个Physical plans
    5. CostModel: 主要根据过去的性能统计数据，选择最佳的物理执行计划(Selected Physical Plan)。
    6. Code Generation: sql逻辑生成Java字节码

  1. Runtime优化的方式都有哪些？

    1.   AQE

      1.   AQE对于整体的Spark SQL的执行过程做了相应的调整和优化，它最大的亮点是可以根据已经完成的计划结点真实且精确的执行统计结果来不停的反馈并重新优化剩下的执行计划。
      2.   AQE框架三种优化场景：
      3. 动态合并shuffle分区（Dynamically coalescing shuffle partitions）
      4. 动态调整Join策略（Dynamically switching join strategies）
      5. 动态优化数据倾斜Join（Dynamically optimizing skew joins）

    2.   RuntimeFilter

      1.   实现在Catalyst中。动态获取Filter内容做相关优化，当我们将一张大表和一张小表等值连接时，我们可以从小表侧收集一些统计信息，并在执行join前将其用于大表的扫描，进行分区修剪或数据过滤。可以大大提高性能
      2.   Runtime优化分两类：
        1. 全局优化：从提升全局资源利用率、消除数据倾斜、降低IO等角度做优化。包括AQE。
        2. 局部优化：提高某个task的执行效率，主要从提高CPU与内存利用率的角度进行优化。依赖Codegen技术。

    3.   Codegen

      1.   从提高cpu的利用率的角度来进行runtime优化。
      2. Expression级别
        1.   表达式常规递归求值语法树。需要做很多类型匹配、虚函数调用、对象创建等额外逻辑，这些overhead远超对表达式求值本身，为了消除这些overhead，Spark Codegen直接拼成求值表达式的java代码并进行即时编译
      3. WholeStage级别
        1.   传统的火山模型：SQL经过解析会生成一颗查询树，查询树的每个节点为Operator，火山模型把operator看成迭代器，每个迭代器提供一个next()接口。通过自顶向下的调用 next 接口，数据则自底向上的被拉取处理，火山模型的这种处理方式也称为拉取执行模型，每个Operator 只要关心自己的处理逻辑即可，耦合性低。
        2.   火山模型问题：数据以行为单位进行处理，不利于CPU cache 发挥作用；每处理一行需要调用多次next() 函数，而next()为虚函数调用。会有大量类型转换和虚函数调用。虚函数调用会导致CPU分支预测失败，从而导致严重的性能回退
        3.   Spark WholestageCodegen：为了消除这些overhead，会为物理计划生成类型确定的java代码。并进行即时编译和执行。
      4.   Codegen打破了Stage内部算子间的界限，拼出来跟原来的逻辑保持一致的裸的代码（通常是一个大循环）然后把拼成的代码编译成可执行文件。

  1. Spark业界面临的问题是如何产生的？都有什么优化方向？

    1. Shuffle稳定性

      1. 问题：现有机制容易带来大量随机读导致磁盘IOPS瓶颈、Fetch请求积压等问题，导致经常出现Stage重算甚至作业失败的问题，继而引起资源利用的恶性循环，严重影响SLA
      2. 优化方向：远端存储数据，map和reduce端在partition的数据尽可能在shuffle时就聚合，减少排序操作

    2. SQL执行性能

      1. 问题：CPU瓶颈
      2. 优化方向：CPU流水线/分支预测/乱序执行/SIMD/CPU缓存友好等，Vectorized/Codegen，C++/Java

    3. 参数推荐/业务诊断

      1. 问题：参数过多，调参难度大，参数不合理，资源利用率/Shuffle稳定性/性能有较大影响
      2. 优化方向：自动参数推荐/业务诊断
avatar
文章
阅读
粉丝