關於分布式流水作業架構的一點淺見(領導者壓力和瓶頸的解決方案和思路)

        這段時間其實一直在思考Hadoop的東西，主要是我準備用Dotnet來類比玩一下，這兩天剛好看到

http://blog.csdn.net/cenwenchu79/article/details/7206804 這篇文章，看來對hadoop的架構有看法的不止我一個，當然，別人都是牛人，有牛人敢懷疑，我也跟著說點看法。

首先，坦率的講，我沒有用過hadoop,我只是瞭解過其機制，根據上面那位牛人的看法，hadoop的master會成為瓶頸，因為其擔當的Reducer職責，就是最後歸併結果。因為我沒有實際用過hadoop，我沒有發現這個問題，只是我在準備類比hadoop的思考過程中，我覺得master的職責應該比較單一，如果master擔當的任務分割職責(比如大檔案切割)計算量和資料流量比較大的話，會很容易成為分散式運算系統的效能瓶頸。基於現實企業運作模式的類比思考，分布式流水作業叢集(包括hadoop叢集)其實就相當於一家代加工企業，具有銷售，生產，倉儲，管理，人力資源等角色（真的企業還要有財務等，但在這裡就不需要了）:
        銷售負責訂單接受和任務交付，生產負責具體的計算（Map,Reduce等，不局限於這些，只要符合流水生產特徵即可）。倉儲負責原料和成品的儲存，就是檔案或資料庫系統。管理者負責置中協調，為了不出現多頭領導的問題，管理角色分化為兩種角色，全域管理者(全域領導者 )和專案經理（事務領導者,每個訂單相當於一個項目），全域管理者(Master)就是公司總經理，負責指揮和協調，只能有一個，專案經理負責具體事務（按訂單）的管理，可以有多個，Master除了協調指揮外，當然還擔當著一個人力資源管理的角色，人力資源當然就需要管理生產者，專案經理，倉儲等角色的數量和狀態。而倉儲角色，則可以由專門的檔案系統來擔當，負責原料，半成品，成品的儲存。目前的hadoop從我得到的資訊來講，其Master一個人擔當了銷售，管理，生產者和人力資源四種角色，責任太重，容易成為瓶頸也是自然的事情。

我們知道，在企業管理中，多頭領導和責任重疊都是要極力避免的，當然，如果完全按照責任單一原則區分，在計算系統實現上一是沒有必要，二也會增加複雜度，得不償失。電腦誕生於人類生產生活，其實很多做法也都來自於現實生產生活中。人類的生產生活天生就是分布式和並發的。在現實中流水線生產不失為一種高效的生產方式，hadoop中的mp只是一種簡單的流水作業模式。當然，計算系統中，沒有現實生產生活這麼複雜，也沒有必要完全類比現實（同時也很難做到）。回來，我們分析一下hadoop的master的職責，多頭領導的問題當然不存在，人力資源角色因為要協調，所以是必需的(而且該資訊對於master來說非常關鍵,工作量不算很大,因此獨立出一個角色來管理沒有必要)，但部分生產者和專案管理職責則完全沒有必要，何況這兩種角色都是比較消耗資源的。何況全域管理者由於其特殊性，無法實現均衡負載，而且必須是固定的（因為是所有其他角色的中介者，必須是固定的，否則通訊和臨時選舉成本太高）。 但在這種分散式運算系統中，最終結果的合并由任務管理者來完成是個非常好的選擇（專門指定這種合并角色不是不可以，但會增加計算系統的複雜度和實現、管理難度） 
，由於這種合并基本上都是按項目（訂單任務）來的，因此交由專案經理角色完成比較好。業務的角色可以單獨設定，也可以由Master擔當，不過我覺得單獨設定會比較好，其實Master不必對外，由業務對外會比較好。

這種計算作業系統的整體商務邏輯及流程如下：

A)除Master外的其它角色都會通過心跳服務，向Master註冊和更新自己的狀態(其實Master崩潰的情況下，也可以通過這種機製做Master恢複(部分)，只是機制比較複雜點)；
B)業務在接到訂單(加工任務)後會先把訂單交給Master,業務並不需要儲存訂單資訊,這也決定了其可以實現負載平衡，是客戶與計算系統之間的互動中介;
C)Master根據勞動者狀態，分配加工任務給某個勞動者，並指定其為專案經理，具體的任務管理（專案管理）由專案經理去完成；
D)專案經理接到任務後對任務進行必要的拆分，並向Master申請勞動者資源並分配任務給這些資源，同時進行專案管理（項目情況彙報，項目成員工作中進度瞭解等）；
     專案經理在成員出現問題時採用的策略跟該職責在原來Master中實現一樣,只不過是由專案經理完成。當然，Master如果發現專案經理掛了，也可以基於同樣的策略，再任命一個專案經理重新開始任務。(後面有專文來探討這個問題的解決)
E) 各個勞動者接到專案經理的任務分配後，會執行具體的生產任務，並定期將情況彙報給專案經理，任務完成後也會將結果彙報給專案經理;
F)專案經理如果發現有成員任務沒完成，而且失去聯絡，則將該子任務重新指定勞動者去完成(可以內部協調，也可以向master申請新的資源);(為了提高效率，專案經理可以在勞動者完成任務後即報告給master,釋放控制權,但保留聯絡,只有在任務清場後才徹底脫離關係)
G)專案經理在項目完成後，會將結果合并，並將完成資訊報告給Master，Master接到報告後會通知業務去進行訂單互動；
H)具體的交付由客戶、業務和專案經理一起完成,當然會將互動結果彙報給Master.
I)訂單交付完成後，Master指示專案經理清場,並將專案經理解職(成員清場可以在專案經理確定任務完成時就進行)。
J)中途出現問題可以從C和E重新開始.

從上面的邏輯和過程可以看出，Master的職責比原來要單一很多，因為大的通訊和計算部分都是由可以負載和替換的具體勞動者完成，所以Master很難會成為瓶頸。這也是為什麼管理非常好的企業，總經理都比較閑的原因。但這種方式的劣勢是增加了設計和實現的難度，同時如果因為專案經理掛掉，重新啟動項目的成本也會比較高(也可以採用一些方法減少些成本)。當然，任何事情都不會是完美的，就看怎麼取捨了。

上面那位牛人提出的Master橫向擴充，不是不可以，但實現起來會很困難，因為如果要保證可靠性和一致性，最終一定有一個地方需要統一，只能由一個點來擔當這種統一的職責(但可以有對等的備份)，否則像Google這樣的大牛公司的GFS實現中的Master也肯定不會採用領導者選舉演算法來保證某一時刻只能有一個領導者的辦法。因此我覺得，要減輕領導者壓力，只能採用剝離其擔負的非關鍵性業務或者功能來實現。提高領導力，也只能升級裝置。

 

另外，由於原來master擔負的任務分割結果可能會重用，在這種模式下，需要增加一個指示來指示專案經理如何管理工作分割結果(比如大檔案分割等).當然，細節需要處理的地方還很多，套用一句話：思路決定高度，細節決定結果。   好的架構也必須契合好的管理，好多東西都是相互借鑒和滲透的，高層次上大家也都是統一的，隨著層次越高，統一性越強，最終上升到的高度就是哲學。

我目前在考慮的就是這種扁平化下的專案經理負責制，仿照現實生產活動中的敏捷製造方式。當然，這些也算是這段時間準備實現自己的mp，進行學習和思考的一點想法，寫得不好，歡迎大家拍磚.