文章目录
- Spark RDD及内存计算
- 性能调优
- RDD 的核心特征和属性
- 内存计算
Spark RDD及内存计算
性能调优
性能调优的本质：
-
性能调优不是一锤子买卖，补齐一个短板，其他板子可能会成为新的短板。因此，它是 一个动态、持续不断的过程；
-
性能调优的手段和方法是否高效，取决于它针对的是木桶的长板还是瓶颈。针对瓶颈， 事半功倍；针对长板，事倍功半；
-
性能调优的方法和技巧，没有一定之规，也不是一成不变，随着木桶短板的此消彼长需要相应地动态切换；
-
性能调优的过程收敛于一种所有木板齐平、没有瓶颈的状态。
系统化的性能调优方法论：
-
通过不同的途径如专家经验或运行时诊断来定位性能瓶颈；
-
从不同场景（典型场景）、不同视角（硬件资源）出发，综合运用不同层面（应用代码、Spark 配置项）的调优手段和方法；
-
随着性能瓶颈的此消彼长，动态灵活地在不同层面之间切换调优方法；
-
让性能调优的过程收敛于不同硬件资源在运行时达到一种平衡、无瓶颈的状态。
RDD 的核心特征和属性
RDD，全称 Resilient Distributed Datasets，弹性分布式数据集。本质上，它是对于数据模型的抽象，用于囊括所有内存中和磁盘中的分布式数据实体。
RDD 具有 4 大属性，分别是 partitions、partitioner、 dependencies 和 compute 属性。
在分布式运行环境中，RDD 封装的数据在物理上散落在不同计算节点的内存或是磁盘中，这些散落的数据被称“数据分片”，RDD 的分区规则决定了哪些数据分片应该散落到哪些节点中去。RDD 的 partitions 属性对应着 RDD 分布式数据实体中所有的数据分片，而 partitioner 属性则定义了划分数据分片的分区规则。
在 Spark 中，任何一个 RDD 都不是凭空产生的，每个 RDD 都是基于某种计算逻辑从某个父RDD转换而来。RDD 的 dependencies 属性记录了生成 RDD 所需的父RDD，compute 方法则封装了从父 RDD 到当前 RDD 转换的计算逻辑。
基于数据源和转换逻辑，无论 RDD 有什么差池（如节点宕机造成部分数据分片丢失），在 dependencies 属性记录的父 RDD 之上，都可以通过执行 compute 封装的计算逻辑再次得到当前的 RDD。
内存计算
在 Spark 中，内存计算有两层含义：
-
分布式数据缓存
分布式数据集缓存到计算节点内存中，从而对其高效访问；
-
Stage 内的Pipeline（流水线式）计算模式
Stage 划分：以 Actions 算子为起点，从后向前回溯 DAG，以 Shuffle 操作为边界去划分 Stages。
Stage 中的内存计算
MapReduce 提供两类计算抽象，分别是 Map 和 Reduce：Map 抽象允许开发者通过实现 map 接口来定义数据处理逻辑；Reduce 抽象则用于封装数据聚合逻辑。MapReduce 计算模型最大的问题在于，所有操作之间的数据交换都以磁盘为媒介，频繁的磁盘 I/O 必定会影响用户应用端到端的执行性能。
“跟 MapReduce 相比，spark就是把数据和计算都挪到内存里去了吗？” 如果Spark 每一个算子计算得到的中间结果都会在内存中缓存一份，以备下一个算子运算，这个过程与开发者在应用代码中滥用 RDD cache 简直如出一辙。采用这种计算模式，Spark 的执行性能不见得比 MapReduce 好，尤其是在 Stages 中的算子数量较多的时候。
在 Spark 中，流水线计算模式指的是：在同一 Stage 内部，所有算子融合为一个函数，Stage 的输出结果由这个函数一次性作用在输入数据集而产生（类似函数链式调用），在内存中不产生任何中间数据形态。
