萌兔兔MMQ！！

由于集群的 Spark History Server 还没安装调试好，没法通过 spark web UI 查看历史任务的可视化执行细节，所以我写了个小脚本分析了下前后具体的计算耗时信息，可以一目了然的看到是哪个 stage 的问题，有针对性的优化。从上面这个 case 可以看到，会用 spark、会调 API 和能用好 spark，用的恰到好处是两码事，这要求咱们不仅了解其原理，还要了解业务场景，将合适的技术方案、工具和合适的业务场景结合——这世上本就不存在什么银弹。除非你是火花壳，一般1-2g就够了。

加粗样式

4、如果executor端用到了Driver的变量，如果不使用广播变量在Executor有多少task就有多少Driver端的变量副本。如果executor端用到了Driver的变量，如果不使用广播变量在Executor有多少task就有多少Driver端的变量副本。3）在Driver端可以修改广播变量的值，在Executor端无法修改广播变量的值。3、在Driver端可以修改广播变量的值，在Executor端无法修改广播变量的值。2、广播变量只能在Driver端定义，不能在Executor端定义。

task在运行的时候，想要使用广播变量中的数据，此时首先会在自己本地的Executor对应的BlockManager中，尝试获取变量副本；500M的数据，网络传输，而且不一定都是从Driver传输到每个节点，还可能是就近从最近的节点的executor的bockmanager上拉取变量副本，网络传输速度大大增加；总共，你前面调优都调的特好，资源给的到位，配合着资源，并行度调节的绝对到位，1000个task。这种默认的，task执行的算子中，使用了外部的变量，每个task都会获取一份变量的副本，有什么缺点呢？