works集合為什麼要使用hashset？
driver程序是怎麼啟動起來的？
掙扎的（掉隊的）任務
配置資訊的使用
重試機制
粗細粒度排程
spark在yarn集群上的兩種提交方式
spark-submit --excutor -cores啟動excutor的時候根本沒有考慮資料的位置，但是啟動方式有利於資料本地化（輪訓啟動，在每乙個worker節點上都會啟動乙個excutor）
多個job：
若是多個job都執行在一台節點上，此時計算的資料可能不在這個節點上，或者只有一部分在這個節點上，那麼就要從別的節點上拉取資料，那麼就要走網路傳輸，這就導致資料找計算，不是我們想要的。若是多個job都執行在一台節點上，此時計算的資料可能不在這個節點上，或者只有一部分在這個節點上，那麼就要從別的節點上拉取資料，那麼就要走網路傳輸，這就導致資料找計算，不是我們想要的。
task的執行效率以及時間
若是多個task都執行在一台節點上，那麼會採用阻塞執行的方式，這樣只有等這個任務執行完才能行執行別的task，不能並行處理，效率也就大大降低，時間也隨之加長。
–executor-cores：每個executor需要的核；ec
–executor-memory：每個executor需要記憶體；em
worker num：worker節點個數；wn
worker memory：worker節點的記憶體；wm
worker core：worker節點的核；wc
比如1000個task中，有9999個任務執行完成，只有乙個task正在執行，那麼這個任務就叫掙扎的任務。
taskschedule遇到掙扎的任務也會重試，此時taskschedule會重新提交乙個和掙扎的task一模一樣的task到集群中執行，但掙扎的task不會被kill掉，會讓他們在集群中比賽執行，誰先執行完畢，就以誰的結果為準。
用來判斷哪些task是掙扎的。
當所有的task 75%以上都執行完畢，那麼taskschedule才會每隔100ms計算一下哪些task需要推測執行。
例如：100個task中有76個task已經執行完畢，24個task沒有執行完畢，此時它會計算出這24個task已經執行時間的中位數，然後將中位數*1.5得到最終的時間，拿到這個最終計算出來的時間，去檢視哪一些task超時，此時這些task就是掙扎的task。
在**中sparkconf中修改。
（spark-submit --master --conf k=v）taskschedule會實時跟蹤每乙個task的執**況，若是執行失敗，taskschedule會重試提交task，但是不會無休止的重試，預設是重試3次，若果重試3次依舊失敗，那麼這個task所在的stage就失敗了，此時會向dagschedule匯報，任務執行失敗。
dagschedule會重試提交stage，如果dagschedule重試了4次，依然失敗，那麼stage所在的job就失敗了，job失敗是不會重試的。
注意：每一次重試提交stage，已經成功執行的不會被再次分發到excutor程序執行，只是提交重試失敗的stage。
典型代表：spark
描述：在任務執行前，會先將資源申請完畢，當所有的task執行完畢，才會釋放這部分資源。
缺點：需要所有的task都執行完畢才會使用資源 假設10000個task ，9999task執行完畢了，不會釋放直到最後乙個task執行完畢，才會釋放資源，集群的資源就無法充分的利用了。
典型代表：mapreduce
描述：在任務提交的時候，每乙個task自己去申請資源，申請到了才會執行，執行完立馬釋放資源。
請參考下篇部落格
spark資源排程和任務排程
資源排程 1 executor預設在集群中分散啟動，可通過引數配置集中在某個work啟動，不過分散啟動有利於資料本地化。2 如果spark submit提交任務時，如果不指定 executor cores，則spark會在每個work中啟動乙個executor並消耗掉work中的所有core和1g的...
整合任務排程服務
jdk中任務排程核心是timer類的schedule方法，傳遞乙個繼承timertask實現了run方法的類。在spring的xml檔案中配置 b 使用quartz排程任務 b quartz中的幾個概念 job 定義乙個任務，job只管執行，不管什麼時間執行，不管執行多少次 trigger 定義乙個...
Spark資源排程和任務排程概述
以standalone client模式為例，序列圖如下 圖中 1 6 資源排程 7 11 任務排程 spark資源排程和任務排程的流程 總結 taskscheduler不僅可以重試失敗的task，還可以重新執行緩慢的task，這是spark中的推測執行機制，預設關閉，對於資料清洗的場景要關閉，防止...