我們使用spark-submit提交乙個spark作業之後，這個作業就會啟動乙個對應的driver程序。該程序是向集群管理器（yarn,k8s）申請執行spark作業需要使用的資源，這裡的資源指的就是executor程序。
yarn集群管理器會根據我們為spark作業設定的資源引數，在各個工作節點上，啟動一定數量的executor程序，每個executor程序都占有一定數量的記憶體和cpu core。
在申請到了作業執行所需的資源之後，driver程序就會開始排程和執行我們編寫的作業**了。
driver程序會將我們編寫的spark作業**分拆為多個stage，每個stage執行一部分**片段，並為每個stage建立一批task，然後將這些task分配到各個executor程序中執行。
task是最小的計算單元，負責執行一模一樣的計算邏輯（也就是我們自己編寫的某個**片段），只是每個task處理的資料不同而已。
乙個stage的所有task都執行完畢之後，會在各個節點本地的磁碟檔案中寫入計算中間結果，然後driver就會排程執行下乙個stage。
spark是根據shuffle類運算元來進行stage的劃分。如果我們的**中執行了某個shuffle類運算元（比如reducebykey、join等），那麼就會在該運算元處，劃分出乙個stage界限來。
可以大致理解為，shuffle運算元執行之前的**會被劃分為乙個stage，shuffle運算元執行以及之後的**會被劃分為下乙個stage。
因此乙個stage剛開始執行的時候，它的每個task可能都會從上乙個stage的task所在的節點，去通過網路傳輸拉取需要自己處理的所有key，然後對拉取到的所有相同的key使用我們自己編寫的運算元函式執行聚合操作（比如reducebykey()運算元接收的函式）。這個過程就是shuffle。
當我們在**中執行了cache/persist等持久化操作時，根據我們選擇的持久化級別的不同，每個task計算出來的資料也會儲存到executor程序的記憶體或者所在節點的磁碟檔案中。
因此executor的記憶體主要分為三塊：
第一塊是讓task執行我們自己編寫的**時使用，預設是佔executor總記憶體的20%；
第二塊是讓task通過shuffle過程拉取了上乙個stage的task的輸出後，進行聚合等操作時使用，預設也是佔executor總記憶體的20%；
第三塊是讓rdd持久化時使用，預設佔executor總記憶體的60%。
task的執行速度是跟每個executor程序的cpu core數量有直接關係的。乙個cpu core同一時間只能執行乙個執行緒。而每個executor程序上分配到的多個task，都是以每個task一條執行緒的方式，多執行緒併發執行的。
如果cpu core數量比較充足，而且分配到的task數量比較合理，那麼通常來說，可以比較快速和高效地執行完這些tas**程。
該引數用於設定spark作業總共要用多少個executor程序來執行。driver在向yarn集群管理器申請資源時，yarn集群管理器會盡可能按照你的設定來在集群的各個工作節點上，啟動相應數量的executor程序。這個引數非常之重要，如果不設定的話，預設只會給你啟動少量的executor程序，此時你的spark作業的執行速度是非常慢的。（建議50~100個左右的executor程序）
該引數用於設定每個executor程序的記憶體。executor記憶體的大小，很多時候直接決定了spark作業的效能，而且跟常見的jvm oom異常，也有直接的關聯。（根據作業大小不同，建議設定4g~8g，num-executors乘以executor-memory，是不能超過佇列的最大記憶體量的）
該引數用於設定每個executor程序的cpu core數量。這個引數決定了每個executor程序並行執行tas**程的能力。因為每個cpu core同一時間只能執行乙個tas**程，因此每個executor程序的cpu core數量越多，越能夠快速地執行完分配給自己的所有tas**程。（建議設定為2~4個，且num-executors * executor-cores不要超過佇列總cpu core的1/3~1/2）
該引數用於設定driver程序的記憶體（建議設定512m到1g）。
該引數用於設定每個stage的預設task數量。這個引數極為重要，如果不設定可能會直接影響你的spark作業效能。（建議為50~500左右，預設情況下spark自己根據底層hdfs的block數量來設定task的數量，預設是乙個hdfs block對應乙個task。spark官網建議設定該引數為num-executors * executor-cores的2~3倍較為合適）
該引數用於設定rdd持久化資料在executor記憶體中能佔的比例，預設是0.6（原則上是盡可能保證資料能夠全部在記憶體中，但如果發現作業發生頻繁的gc，就該考慮是否調小）
該引數用於設定shuffle過程中乙個task拉取到上個stage的task的輸出後，進行聚合操作時能夠使用的executor記憶體的比例，預設是0.2。也就是說，executor預設只有20%的記憶體用來進行該操作。shuffle操作在進行聚合時，如果發現使用的記憶體超出了這個20%的限制，那麼多餘的資料就會溢寫到磁碟檔案中去，此時就會極大地降低效能。（shuffle操作較多時，建議降低持久化操作的記憶體佔比，提高shuffle操作的記憶體佔比比例，避免shuffle過程中資料過多時記憶體不夠用，必須溢寫到磁碟上，降低了效能）
我的個人**：
hive效能優化指南 初級篇
這個標題也是用血的教訓換來的，希望對剛進入hive圈的童鞋和正在hive圈爬坑的童鞋有所幫助。打算分以下幾個部分去描述 這篇文章只是起個頭，為描述其他部分做下準備。下面我贅述下hive的結構和一些基本的操作。首先，我來說說什麼是hive what is hive?請看下圖 由於是在retina下截的...
Spark效能優化指南 資料傾斜
調優概述 有的時候，我們可能會遇到大資料計算中乙個最棘手的問題 資料傾斜，此時spark作業的效能會比期望差很多。資料傾斜調優，就是使用各種技術方案解決不同型別的資料傾斜問題，以保證spark作業的效能。資料傾斜發生時的現象 絕大多數task執行得都非常快，但個別task執行極慢。比如，總共有100...
unity效能優化初級入門篇
渲染優化的幾種手段 draw call statistics面板 資源優化標準 shader要減少複雜的數 算 texture長度要小於1024 減少discard操作 其他 貼圖優化 模型優化 資源監測與分析，我們可以在開始專案時就對資源進行嚴格的把控。也可以在打包後，利用第三方分析工具對asse...