cacheTable与uncacheTable

Myth丶恋晨 2022-12-29 11:30 10阅读 0赞

Spark相对于Hadoop MapReduce有一个很显著的特性就是“迭代计算”（作为一个MapReduce的忠实粉丝，能这样说，大家都懂了吧），这在我们的业务场景里真的是非常有用。

假设我们有一个文本文件“datas”，每一行有三列数据，以“\\t”分隔，模拟生成文件的代码如下：

![121862-20151104170658602-796033476.png][]

执行该代码之后，文本文件会存储于本地路径：/tmp/datas，它包含1000行测试数据，将其上传至我们的测试Hadoop集群，路径：/user/yurun/datas，命令如下：

![121862-20151104170710414-504683510.png][]

查询一下它的状态：

![121862-20151104170719414-628733565.png][]

我们通过Spark SQL API将其注册为一张表，代码如下：

![121862-20151104170731086-730282632.png][]

表的名称为source，它有三列，列名分别为：col1、col2、col3，类型都为字符串（str），测试打印其前10行数据：

![121862-20151104170742055-149586174.png][]

假设我们的分析需求如下：

（1）过滤条件：col1 = ‘col1\_50'，以col2为分组，求col3的最大值；

（2）过滤条件：col1 = 'col1\_50'，以col3为分组，求col2的最小值；

注意：需求是不是很变态，再次注意我们只是模拟。

通过情况下我们可以这么做：

![121862-20151104170752914-1646909864.png][]

每一个collect()（Action）都会产生一个Spark Job，

![121862-20151104170802914-1161277302.png][]

因为这两个需求的处理逻辑是类似的，它们都有两个Stage：

![121862-20151104170814852-132186487.png][]

![121862-20151104170824852-1213130521.png][]

可以看出这两个Job的数据输入量是一致的，根据输入量的具体数值，我们可以推断出这两个Job都是直接从原始数据（文本文件）计算的。

这种情况在Hive（MapReduce）的世界里是很难优化的，处理逻辑虽然简单，却无法使用一条SQL语句表述（有的是因为分析逻辑复杂，有的则因为各个处理逻辑的结果需要独立存储），只能一个需求对应一（多）条SQL语句（如上示例），带来的问题就是全量原始数据多次被分析，在海量数据的场景下必然带来集群资源的巨大浪费。

其实这两个需求有一个共同点：过滤条件相同（col1 = 'col1\_50'），一个很自然的想法就是将满足过滤条件的数据缓存，然后在缓存数据之上执行计算，Spark为我们做到了这一点。

![121862-20151104170835789-1524419733.png][]

依然是两个Job，每个Job仍然是两个Stage，但这两个Stage的输入数据量（Input）已发生变化：

![121862-20151104170847539-1610553294.png][]

![121862-20151104170902274-799006971.png][]

Job1的Input（数据输入量）仍然是63.5KB，是因为“cacheTable”仅仅在RDD（cacheRDD）第一次被触发计算并执行完成之后才会生效，因此Job1的Input是63.5KB；而Job2执行时“cacheTable”已生效，直接输入缓存中的数据即可，因此Job2的Input减少为3.4KB，而且因为所需缓存的数据量小，可以完全被缓存于内存中，因此效率极高。

我们也可以从Spark相关页面中确认“cache”确实生效：

![121862-20151104170924024-1233461362.png][]

我们也需要注意cacheTable与uncacheTable的使用时机，cacheTable主要用于缓存中间表结果，它的特点是少量数据且被后续计算（SQL）频繁使用；如果中间表结果使用完毕，我们应该立即使用uncacheTable释放缓存空间，用于缓存其它数据（示例中注释uncacheTable操作，是为了页面中可以清楚看到表被缓存的效果）。 原文：https://blog.csdn.net/bbbeoy/article/details/78496900?utm\_medium=distribute.pc\_relevant.none-task-blog-baidujs\_title-2&spm=1001.2101.3001.4242

[121862-20151104170658602-796033476.png]: /images/20221120/7627e2ca9deb41f6b0828ba067f73a20.png
[121862-20151104170710414-504683510.png]: /images/20221120/2796c2e312d9479fa310abd982e1eef9.png
[121862-20151104170719414-628733565.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170719414-628733565.png
[121862-20151104170731086-730282632.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170731086-730282632.png
[121862-20151104170742055-149586174.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170742055-149586174.png
[121862-20151104170752914-1646909864.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170752914-1646909864.png
[121862-20151104170802914-1161277302.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170802914-1161277302.png
[121862-20151104170814852-132186487.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170814852-132186487.png
[121862-20151104170824852-1213130521.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170824852-1213130521.png
[121862-20151104170835789-1524419733.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170835789-1524419733.png
[121862-20151104170847539-1610553294.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170847539-1610553294.png
[121862-20151104170902274-799006971.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170902274-799006971.png
[121862-20151104170924024-1233461362.png]: http://images2015.cnblogs.com/blog/121862/201511/121862-20151104170924024-1233461362.png