首先看没有map join的第2任务:
时间线如下
接着是对应id的算子计算时间表
| Stage Id | Description | Submitted | Duration | Tasks: Succeeded/Total | Input | Output | Shuffle Read | Shuffle Write |
|---|---|---|---|---|---|---|---|---|
| 13 | | 2019/01/29 11:19:02 | 59 ms | 41/41 | 235.3 KB | |||
| 12 | | 2019/01/29 11:19:02 | 0.1 s | 41/41 | 383.2 KB | 235.3 KB | ||
| 11 | | 2019/01/29 11:19:02 | 95 ms | 41/41 | 99.3 KB | 246.2 KB | ||
| 9 | | 2019/01/29 11:19:01 | 0.5 s | 41/41 | 767.7 KB | 99.3 KB | ||
| 8 | | 2019/01/29 11:19:01 | 0.5 s | 41/41 | 752.0 KB | |||
| 7 | | 2019/01/29 11:19:01 | 0.3 s | 1/1 | 15.7 KB | |||
| 10 | | 2019/01/29 11:19:01 | 0.5 s | 41/41 | 137.0 KB |
城市区域表(对应id 10)和商品列表(对应id 7)的数据量比较小，但在集群中的运行时间还是比较长的
不过因为是并行化运行，点击记录(对应id 8)的处理很快就完毕
并且id 9(把数据转换为key是区域+商品id，value是城市信息的组合)的运行时间也不长
在程序只是简单转换为RDD的情况下也能发挥优化效果
相比上述程序，speedUp版程序执行效率没有多大提升。
时间线如下
时间表如下
| Stage Id | Description | Submitted | Duration | Tasks: Succeeded/Total | Input | Output | Shuffle Read | Shuffle Write |
|---|---|---|---|---|---|---|---|---|
| 17 | | 2019/01/29 11:19:03 | 53 ms | 41/41 | 246.7 KB | |||
| 16 | | 2019/01/29 11:19:03 | 0.1 s | 41/41 | 475.6 KB | 246.7 KB | ||
| 15 | | 2019/01/29 11:19:02 | 0.6 s | 41/41 | 475.9 KB |
把城市区域表和商品列表转换为broadcast大变量，给id 15的算子进行map join的做法反而增加了driver的计算量，并且由于被统一到一个算子中运算，丢失了并行化的优势
像12月那次的调试，还出现了优化后运行时间倒挂的情况，就是id 15的运行时间拖慢了(map join用的HashMap，不知道是不是这个原因)
算上job id 2的运行时间(才28ms...)speedUp的运行时间比不带speedUp的短了20%
另外由于只有3台,数据倾斜造成的运算拖慢很难表现出来，此处就不演示均衡数据优化了