Hadoop中的通用分佈式計算框架

本文的內容是對本人近期學習hadoop系統過程的總結和思考，接觸的通用計算框架有限，錯誤在所不免，歡迎指正和討論

我接觸的hadoop中的通用計算框架主要是mapreduce和spark。其中mapreduce在hadoop 2.0中被簡化，將資源管理的功能抽象、獨立出來，造成了yarn，一個通用的資源管理框架。而mapreduce則成爲一個存粹的計算框架。隨着spark的流行，mapreduce因爲框架的限制、性能等緣由被使用的愈來愈少了。

mapreduce於2006提出，因爲其大大簡化了分佈式計算的程序的編寫，而迅速流行起來。在我能讀懂mapreduce的論文以後（論文發表N年後），讓我驚訝的是mapreduce提出的運行方式與我工做中的程序運行方式有很大不一樣：

• mapreduce在一開始就將數據分紅了多份，並將同一個程序複製到不一樣機器（節點）中執行，最後將結果聚合
• 通常互聯網應用的開發方式（不考慮橫向擴展的狀況下）是將一個任務分紅多個階段（驗證，業務執行，落庫等），每一個階段由不一樣的機器（節點）執行。

由此也能夠看出大數據系統與互聯網應用的異同。而將數據分批分片執行的操做也是我以前看不懂mapreduce的主要緣由（另外一個緣由是貧窮限制了個人想象力，當時不明白爲何須要那麼多機器）。

mapreduce將計算過程分爲map和reduce兩個階段，在當時可以知足大部分的需求，但隨着人工智能和實時計算的興起，mapreduce的侷限愈來愈大。mapreduce主要有兩個侷限：

• 將計算過程抽象爲map和reduce，如今看來過於簡單。若是將分佈式計算任務類比爲面向對象編程中的interface，該interface將計算任務劃分爲任意個階段（phase），那麼mapreduce就是一個只有兩個階段的抽象類（abstract class），而繼承了mapreduce的具體計算任務可發揮的餘地就很小了。
• 缺乏對數據的抽象。對於mapreduce框架，主要是提供了容錯機制，將分佈式計算的複雜性隱藏起來，而對於數據，則徹底由具體的任務來解析。

因爲mapreduce框架自己的缺陷，已經不能適應當前對大數據計算的需求，所以逐漸地被spark等框架取代。

spark做爲新一代的通用計算平臺，解決了mapreduce中存在的固有問題：

• 首先，spark沒有再限制任務能夠分爲幾個階段，而是直接實現了分佈式計算任務這個interface，考慮到易用性，任務該如何劃分是由spark的引擎決定的，而不須要首先代碼來控制。另外提供類sql語言來定義分佈式計算任務，spark引擎再將sql轉換爲分佈式任務。
• 對數據的抽象：spark使用rdd來表示數據，一個rdd中包含的數據可能分佈在多個節點上。計算任務都是基於rdd來完成的。spark但願使用rdd來完成批處理，交互查詢，迭代計算，流處理等需求，但在流處理方面，spark將流看做一段一段的數據，當對實時性要求愈來愈嚴格時，就有點力不從心。

聽說apache flink使用了不一樣的數據抽象，更能知足對實時性的要求，不過我還沒用過flink。有熟悉的歡迎指教。

將來，新的分佈式計算平臺主要仍是看如何對數據進行抽象，以知足各類計算需求。對於使用大數據計算平臺的公司，根據公司的規模以及開發的週期能夠採起以下幾種方式不斷改進計算任務：

• 根據業務的需求，以及技術人員對於分佈式計算的理解，開發本身的分佈式計算平臺。但這須要強大的財力支持，也須要深厚的技術儲備，只適用於大公司，也是一個長期的規劃。開發出新的計算平臺是最難的，由於新的計算平臺必定是要大大超越已有計算平臺的，不然不必從新發明輪子。而要超越已有的計算平臺，就須要對分佈式計算有新的、更高級的認識，須要質變，而不能僅僅是量變。
• 改進現有的通用計算平臺，這種改進多是在長期使用過程當中積累的經驗，也多是根據最新的學術研究成果。這適合於大中型公司，是一箇中長期規劃。
• 優化現有的計算任務。這是一個短時間的、適用於任何公司的計劃。也是大部分公司都在作的。

這幾種方式能夠並行進行，也多是層層遞進的。好比在大量的短時間優化計算任務後，將通用的部分提出來改進計算平臺。屢次改進計算平臺後使用計算平臺有了新的理解，開發出屬於本身的分佈式計算平臺。

(廣告，我正在學習Hadoop系統，包括讀書和讀源碼，但願能和正在學習的小夥伴一塊兒交流，若是你也有這樣的想法，而且願意常常分享你的所學，歡迎掃碼進羣)