假設我們修復了一個spark作業的內核總數和總內存大小，並且輸入數據中有很多分區。這兩種配置進行比較：對於每個執行 將增加spark.executor.cores使洗牌更快
在這裏爲每個執行
#executor和#executor cores之間的主要權衡是IO嗎？感謝
Q1。有時我發現NODE_LOCAL任務從網絡而不是內存/磁盤獲取輸入，這是否意味着在同一臺機器上執行兩個執行程序進程之間的通信？
NODE_LOCAL任務可能從同一節點的其他執行者獲得輸入，或者需要從HDFS，緩存等系統中檢索。是的，NODE_LOCAL任務意味着同一節點中兩個執行者進程之間的通信。 RACK_LOCAL表示數據在另一個節點中，因此它需要在執行前進行傳輸。
Q2.如果1是真的，第二個會更快，因爲洗牌可以更「過程本地」？
20執行人，50G存儲器和5個核爲每個執行
1是真實的，但在決定哪個選項會更快取決於幾個因素（執行者數量vs執行者核心數量）。
火花提交存儲器參數，諸如「執行者的數量」和「執行核心數」屬性影響數據火花的量可以緩存，以及用於混洗的數據結構的最大尺寸用於分組，彙總和連接。運行內存過多的執行程序通常會導致垃圾收集過多延遲。
cores屬性控制執行程序可以運行的併發任務數。據觀察，每個執行器有5個任務可以實現全寫入吞吐量。每個執行器的大量內核導致HDFS I/O吞吐量，因此顯着減慢了應用程序。
運行具有單個內核和更少內存的執行程序會拋棄在單個JVM中運行多個任務所帶來的好處。例如，廣播變量需要在每個執行器上覆制一次，因此許多小的執行器會導致更多的數據副本。
要優化Spark的內存消耗，請確定您的數據集需要多少內存。爲此，您可以創建DataFrame，對其進行緩存並檢查Spark UI的「存儲」選項卡中的數據集大小。根據數據集大小和類型的操作你可以派生出最佳數量的執行者核心。
備選地 - 可以避免由與spark.dynamicAllocation.enabled property.Dynamic分配接通動態分配設置所有這些存儲器性能使火花應用程序請求執行器在存在待決的積壓閒置時釋放執行者的任務。
Q3。如果只有地圖任務，第二個會像第一個一樣快嗎？
可能是的。根據Cloudera的建議。第二個選項比第一個更好，但它取決於數據集大小。
Q4.我可以說#executor和#executor核心之間的主要權衡是IO嗎？
不確定這個問題，但推薦使用與數據節點一樣多的執行程序以及從羣集中獲取的儘可能多的內核。
Q4.我可以說#executor和#executor核心之間的主要權衡是IO嗎？
主要的權衡是內存管理和IO。如果你用簡單的映射運行一些簡單的多級DAG並減少，你會在spark-history中看到4個節點和2個內核每個將處理與8個內核的1個節點並行的任務。在階段開始時，您仍然會對每個初始任務負載發生反序列化。
最大的區別在於內存開銷的減少。在具有大量RAM的現代服務器中不是這樣一個大問題。
由於線程調度程序中的性能下降曲線，您很難每找到一個人推薦多於5個核心的執行程序。
拇指爲起始簇/執行上漿一個很好的規則如下：
（天花板（total_host_physical_cores * 1.15） - 2）/ executor.cores = 執行人的每個主機數
啓動與executor.cores = 2是一個很好的安全賭注。
每執行者的內存更多的是關於你的DAG和你的攝取大小。
不太可能。洗牌受限於 - 網絡IO。 - 磁盤IO（寫入shuffle文件）。 第二部分不會受到影響。您可能會看到更大的執行程序帶來的其他好處（更好的廣播，更低的總內存使用率）。 – 2016-11-19 15:43:29