Hadoop是很多元件的集合，主要包括但不限於MapReduce，HDFS，HBase，ZooKeeper。MapReduce模仿了Google MapReduce，HDFS模仿了Google File System，HBase模仿了Google BigTable，ZooKeeper或多或少模仿了Google Chubby（沒有前3個出名），所以下文就只提MapReduce、HDFS、HBase、ZooKeeper吧。


簡單來講，

• HDFS和HBase是依靠外存（即硬碟）的分散式檔案儲存實現和分散式表儲存實現。HDFS是一個分散式的“雲端儲存”檔案系統，它會把一個檔案分塊並分別儲存，取用時分別再取出、合併。重要的是，這些分塊通常會在3個節點（即叢集內的伺服器）上各有1個備份，因此即使出現少數節點的失效（如硬碟損壞、掉電等），檔案也不會失效。如果說HDFS是檔案級別的儲存，那HBase則是表級別的儲存。HBase是表模型，但比SQL資料庫的表要簡單的多，沒有連線、聚集等功能。HBase的表是物理儲存到HDFS的，比如把一個表分成4個HDFS檔案並存儲。由於HDFS級會做備份，所以HBase級不再備份。
• MapReduce則是一個計算模型，而不是儲存模型；MapReduce通常與HDFS緊密配合。舉個例子：假設你的手機通話資訊儲存在一個HDFS的檔案callList.txt中，你想找到你與同事A的所有通話記錄並排序。因為HDFS會把callLst.txt分成幾塊分別存，比如說5塊，那麼對應的Map過程就是找到這5塊所在的5個節點，讓它們分別找自己存的那塊中關於同事A的通話記錄，對應的Reduce過程就是把5個節點過濾後的通話記錄合併在一塊並按時間排序。MapReduce的計算模型通常把HDFS作為資料來源，很少會用到其它資料來源比如HBase。
• ZooKeeper本身是一個非常牢靠的記事本，用於記錄一些概要資訊。Hadoop依靠這個記事本來記錄當前哪些節點正在用，哪些已掉線，哪些是備用等，以此來管理機群。

相比較而言，

• Storm本身主要是一個分散式環境下的實時資料計算模型，沒有外存儲存部分。Storm的應用場景是，資料來的特別快、並且要求隨來隨處理。比如Twitter伺服器自身每秒收到來自全世界的推能達幾千條，並且要求收到後還需立即索引，以供查詢。這用傳統的方法乃至Hadoop都是比較難的，因為外存的使用會帶來較大的延遲，這時可以用Storm。Storm節點對記憶體中的資料進行操作，然後流出資料到下一個節點，以此來維繫節點間的協作、達到高速協同處理。
• Storm有一個總的控制節點Nimbus來與ZooKeeper交流、進行叢集管理。
  
• Storm還沒有做到資料備份，這是它的不足（2013年Update: 較新的Storm已引入了類事務的概念，會有重做的操作來保證資料的處理）。

所以，Hadoop和Storm都是分散式環境下的計算平臺，不過前者依賴外存，適應批處理情形，後者依賴記憶體，適應實時處理、超低延遲、無需大量儲存資料情形。前類出現的時間較早（03年GFS的論文），後類出現的時間較晚（10年Yahoo! S4的論文）。我不大讚同“Storm改進了Hadoop的缺點”的說法——這種說法有點像“輪船改進了汽車的哪些缺點”——因為它們本身即不太同類。Storm和Hadoop有很多相似也有很多區別，適用的場景是不一樣的，主要取決於使用者自己的需求。

*上面很多敘述方法是為了讀者的更好理解，不盡完全準確，比如HBase是有記憶體緩衝機制的，並非只依賴外存，再比如Nimbus實質上是某個節點上的守護程序，而非節點本身。

最終，關於這幾者各自具體是什麼，我的建議是讀下列論文：

• 2003 The Google file system
  
• 2005 MapReduce: Simplified data processing on large clusters
  
• 2008 TheBigtable: A distributed storage system for structured data Google file system
  
• 2010 S4: distributed stream computing platform
  
• 2011 Fast Crash Recovery in RAMCloud

和Storm的主頁： nathanmarz/storm · GitHub中wiki的Rational頁。