淺談Hadoop的小發展
遙想十多年前國內IT圈還不知道什麼是Hadoop，現如今，幾乎所有的互聯網企業都擁有了自己的Hadoop集羣，人們提起大數據，就會想起Hadoop，Hadoop儼然成爲了大數據時代的代名詞。樓主就不再贅述Hadoop啦，今天樓主儘量用大白話帶着大家瞭解它的不足之處以及大佬們是如何改進的。
不足之處
隨着計算機硬件的發展，存儲介質不再是掣肘大數據發展的因素，大數據越來越火的今天人們對分佈式計算的要求也越來越高，很顯然Hadoop這項十多年前就起源的技術必須跟着時代潮流向前發展了。那麼Hadoop到底有什麼不足之處呢？
大家都知道，分佈式計算之所以能夠引領一個時代是因爲它將複雜計算劃分開來，在很多臺機器上同時處理，故而它處理速度快。但是在新時代人們對事務處理的效率又有了新的需求，Hadoop要等待計算全部結束才能獲取結果，那如果中間結果就能夠滿足用戶對精度的要求，Hadoop還是要等全部節點計算結束才能夠返回結果，如此這般，不僅響應速度慢，也造成一定的資源浪費。有需求就有進步，大牛們開始想辦法了，能不能在一部分計算結束後，先返回一箇中間結果給用戶呢？
產生中間結果
樓主看來應用最廣泛的是2010年Tyson Condie等人提出的HOP（hadoop online prototype）方法。該改進方法的大致思路是利用“snapshot”將Map的結果用管道傳輸給Reduce，Reduce接收到部分數據並來產生中間結果。這需要用戶提交任務後JobTracher就分配好相應的map任務和reduce任務，並將每個map任務的位置發送給reduce。管道的使用方便了map產生的數據發送給reduce，增加了並行機會，提高了利用率，減少了響應時間。在這種情況下，map一旦產生數據，reduce就開始處理，它們可以在執行過程中生成並改善最終結果的近似值。管道這種思路還拓寬了分佈式計算可被應用的領域，HOP可以被用於連續查詢。HOP解決了產生中間結果的問題，但它也不是完美的，HOP產生的中間結果跟最終結果之間無聯繫，也就是說算了耗費資源半天的中間結果只是爲了看一眼，那麼這種浪費是否值得呢？
考慮資源消耗
HOP在中間結果的計算上頗爲浪費資源，樓主再介紹一種新的改進方法—2011年N. Pansare等人在PVLDB上發表的文章。這篇文章提出了一個適用於大規模分佈式計算的OLA系統模型，它花費更少的代價，並且中間結果可以參與到最終結果計算中去，它的改進主要在兩方面。首先它將所有數據結構化成數據塊，再隨機分配數據塊到map中。強調隨機兩個字，因爲計算只涉及到一部分數據塊，如果數據不隨機，那麼中間結果和最終結果的偏差將會很大。Reduce階段的主要革新是一種叫estimator（評估器）的方法。評估器是該方法種比較重要的一部分，它根據從部分map上傳回來的數據計算得到一箇中間結果，並估計該結果的可信度。在實際生活中，我們並不能保證數據是隨機的，所以這種方法有一定侷限性。
後面零零星星出現了很多在產生中間結果上的改進，在這裏不一一介紹啦，以上純屬樓主自己的理解，如有錯誤歡迎大家指正，期待和更多道友一起進步！