1 Overview

假设程序中需要对一个接近 3T 的模型文件进行 cache。

3T 的文件: hdfs://xxx:9000/xxx_graph

object Persona {
def main(args: Array[String]): Unit = {
val spark = SparkSession
.builder
.appName("模型 cache 测试")
.getOrCreate()
val actions = spark.sparkContext.textFile(args(0)).persist(StorageLevel.MEMORY_AND_DISK).setName("model")
// 触发 cache，没有实际意义
println(s"number of actions: ${actions.count()}")
// 10 mins
Thread.sleep(1000 * 60 * 10)
}
}

测试思路，3T 的模型，如果要 cache 住，50G 的 Executor，至少需要 3T * 1024G/T / 50G * 2 = 125个左右。（乘以2是因为 Executor 的 JVM 默认大概会用 50% 的 Host 内存）。测试中使用20个。

代码如果使用 StorageLevel.MEMORY_AND_DISK，会有个问题，因为20个 Executor，纯内存肯定是不能 Cache 整个模型的，模型数据会 spill 到磁盘，同时 JVM 会处于经常性的 GC，这样这个操作肯定是非常耗时的。

如下图，560G 基本是可用于 Cache 的内存了，其余时间一直在刷盘。

所有 Executor 一直处于频繁的 GC。

Memory 撑爆，CPU 一直繁忙。

光是一个 Job 引发的 cache 模型，目测至少需要一个小时。

以下是调整了 cache 级别，改为 StorageLevel.DISK_ONLY。没有了 GC 消耗。

10分钟已经完成30%的 task 了。

2 Summary

针对大数据集，如果在 Memory 不足够的情况下（TB 级别的基本都很难有匹配的资源），可以让其直接落到磁盘，通过减少 GC Time 来改善程序的 Performance。

最后

以上就是端庄大门为你收集整理的Spark persist MEMORY_AND_DISK & DISK_ONLY1 Overview2 Summary的全部内容，希望文章能够帮你解决Spark persist MEMORY_AND_DISK & DISK_ONLY1 Overview2 Summary所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。