ApacheSparkBook icon indicating copy to clipboard operation
ApacheSparkBook copied to clipboard

Results 26 ApacheSparkBook issues
Sort by recently updated
recently updated
newest added

利杰你好,我有个问题想请教你。我在看Spark源码时,发现Shuffle Write是先往Map里插入值,然后再判断是否需要溢写;而Shuffle Read是先判断是否需要溢写,然后再插入值。按照我个人理解,采用Shuffle Read的方式内存溢出的风险会更低,Shuffle Write可能会在扩容时导致溢出。你知道Spark为什么要这样设计吗 Shuffle Map ![image](https://user-images.githubusercontent.com/44421159/211145164-c19c06d9-d203-4154-968e-e9711038f64c.png) Shuffle Read ![image](https://user-images.githubusercontent.com/44421159/211145196-2e8cabb7-196e-4c40-9cee-5350a066686b.png)

P236中间有这么一句话:"框架执行空间不足时,可以向数据缓存空间借用空间,但至少要保证数据缓存空间具有约50%左右的空间?",这句话看起来好像框架执行空间最多只能占用50%的空间,但实际上在缓存空间用了少于50%,比如20%的时候,框架执行内存还是可以使用80%的吧?我理解是只有数据缓存空间真的用了50%的时候,框架执行空间才只能占用50%。

我在看书籍图3.2的时候发现ManyToManyDependency和ShuffleDependency很像,但ManyToManyDependency属于NarrowDependency,那么Stage划分的时候不会分成两个分区,这样按照P103的想法2,每次计算child RDD的每个分区的时候都需要重复计算全部的父RDD,因此将ManyToManyDependency划分为ShuffleDependency会不会更好一点呢?ManyToManyDependency可以看作在shuffle write的时候写入整个分区到各个子RDD的ShuffleDependency。

假如有A、B、C三个表,下面两种操作 (A union B) join C 会比 (A join C) union (B join C) 更快吗?考虑到网络IO和Hash Join等操作的情况下。

• 到github下载ComplexApplication.scala • 将ComplexApplication.scala放到一个工程中编译成Jar包 • 上传到虚拟机 • 设置卷映射,使得当前的Jar包能被spark-master的容器读取到 ![image](https://user-images.githubusercontent.com/97745253/155868559-283e6dfb-7840-4f56-ae00-f26eda483ba7.png) • 运行提交应用的命令 docker exec -it spark-master /spark/bin/spark-submit --class ComplexApplication /apps/ComplexApplication.jar • 查看18080端口可以看到应用成功运行了 ![image](https://user-images.githubusercontent.com/97745253/155868566-34e72be5-7488-4331-8b42-a82e65ba46a0.png) • 设置alias alias run_complex=' docker exec -it spark-master...