分布式排程系統任務排程

這就是分布式任務排程所要解決的問題

舉個栗子：

如何快速的做出大量的熱狗？

如果將每乙個乙個熱狗按流程做的話，可見工作量會十分巨大而且效率低下

對任務按需求切分成多個子任務

再對所有的中間態結果進行reduce合併，得到最終結果

我們換個角度理解mapreduce操作：

還會有一些廚師，按照一定的比例，將處理好的原材料組裝成最終的熱狗，這一步叫做reducing操作

關於mapreduce，有乙個非常經典的案例就是word count，接下來通過一張圖了解word count的流程：

進行運算，並將結果寫到輸出檔案上

instance執行時是要讀取資料的，那麼最好是讓instance在本地讀取資料，因為如果遠端讀取資料的話，會涉及網路io，這樣會使效能下降，因此我們希望instance能夠多的在本地讀取資料。下面舉乙個栗子

表中是每乙個instance在不同節點上的資料分布情況。為了使instance盡可能多的在本地讀取資料，我們可以這樣分配instance的儲存節點

但是，這樣還是存在問題，就是node3是空閒的，而node2非常繁忙

那麼為了最大化的利用資源，究竟怎麼重新分配instance2和instance3呢？

一種方法是這樣：

這樣一來，雖然每個節點都分配了instance，但是可以發現，instance3將會多出50%的遠端資料讀取消耗

如果我們這樣分配：

那麼，只需要犧牲10%的遠端資料讀取消耗就可以最大化的利用資源，同時提高效率

因此，不是一味地追求資料的本地化，而要全盤考慮資源的負載是否均衡

資料的shuffle主要就是負責map和reduce之間的資料傳遞，其主要有這樣幾種模式：

通常，map的結果需要寫入分布式儲存系統中去，然後reduce再從分布式儲存系統中拉取資料，因此這其中就涉及到了資料的格式問題，而現有的伺服器系統會將資料的格式化封裝到streamline包中，使用者只需要根據介面定義資料型別即可

錯誤在分布式系統中是十分常見的，對於不同的錯誤要有不同的處理方法

例如，當某乙個作業程序崩潰，或是某一台機器宕機，那麼任務排程系統，會立即將任務切換到另一台機器執行

還有一種情況是，執行並沒有問題，但是由於機器硬體的效能退化，導致執行緩慢，那麼這樣的問題如何處理呢？

分布式排程系統 任務排程