本篇blog講述在實際spark項目中可能需要注意的一個性能調優的一個點，就是broadcast大變量。
默認的在spark作業中，task執行的算子中，使用了外部的變量，每個task都會獲取一份變量的副本，有什麼缺點呢？<br>map，本身是不小，存放數據的一個單位是Entry，還有可能會用鏈表的格式的來存放Entry鏈條。所以map是比較消耗內存的數據格式。比如，map是1M。總共，你前面調優都調的特好，資源給的到位，配合着資源，並行度調節的絕對到位，1000個task。大量task的確都在並行運行。
這些task裏面都用到了佔用1M內存的map，那麼首先，map會拷貝1000份副本，通過網絡傳輸到各個task中去，給task使用。總計有1G的數據，會通過網絡傳輸。網絡傳輸的開銷，也許就會消耗掉你的spark作業運行的總時間的一小部分。map副本，傳輸到了各個task上之後，是要佔用內存的。1個map的確不大，1M；1000個map分佈在你的集羣中，一下子就耗費掉1G的內存。
在什麼情況下，會出現性能上的惡劣的影響呢？
不必要的內存的消耗和佔用，就導致了，你在進行RDD持久化到內存，也許就沒法完全在內存中放下；就只能寫入磁盤，最後導致後續的操作在磁盤IO上消耗性能；
你的task在創建對象的時候，也許會發現堆內存放不下所有對象，也許就會導致頻繁的垃圾回收器的回收，GC。GC的時候，一定是會導致工作線程停止，也就是導致Spark暫停工作那麼一點時間。頻繁GC的話，對Spark作業的運行的速度會有相當可觀的影響。
調優方案：廣播大變量
廣播變量，初始的時候，就在Drvier上有一份副本。
task在運行的時候，想要使用廣播變量中的數據，此時首先會在自己本地的Executor對應的BlockManager中，嘗試獲取變量副本；如果本地沒有，那麼就從Driver遠程拉取變量副本，並保存在本地的BlockManager中；此後這個executor上的task，都會直接使用本地的BlockManager中的副本。
executor的BlockManager除了從driver上拉取，也可能從其他節點的BlockManager上拉取變量副本，舉例越近越好。