來自似乎亞裔博主Ricky ho的一篇文章：What Hadoop is Good At，大意翻譯轉貼如下：

多執行緒程式設計模型允許多個帶有不同執行邏輯的處理單元訪問共享的資料，為了維護資料的完整性，處理單元需要通過鎖或Semaphores機制來協調對共享資料的訪問，但是會帶來"race condition競爭條件", "deadlocks死鎖" 等問題，非常難於除錯(banq注：這也是JavaEE的JSP/Servlet封裝多執行緒原因，但是本質上還是多執行緒，所以JavaEE逃不過多執行緒的問題。)，這使得多執行緒程式難於編寫和難於維護，Java提供了併發包來降低這種難度。

資料驅動程式設計模型是將資料餵給不同的處理單元(帶有相同或不同的執行邏輯). 執行是被資料的到達觸發。因為處理只能訪問分給它的資料， 因為資料共享天然被禁止了，就因為這樣，所以沒有必須進行協調資料的訪問了，也就沒有死鎖等問題。

這不意味著一點也不需要資料訪問協調，我們認為協調已經完成：定義處理單元是如何通過資料管道彼此連線的。

Map-Reduce程式設計模型是資料驅動程式設計模型的一個專門實現，，這種協調圖是使用MapReduce工作job順序完成的，在每個Map/Reduce工作中, 執行被切分成一個"map"段和一個"reduce"段phase. 在map段中, 每個被劃分資料被處理，一個或多個結果產生，這些結果都帶有一個key. 這個key用於路由輸出結果給下第二個"reduce" 段phase, 在那裡，帶有同樣key的資料被收集在一起，然後以一種聚合方式被處理。

注意在Map/Reduce模型中, 並行只有在一個工作job中發生，工作job之間是通過順序方式實現的，不同的工作jobs 可以訪問同樣的資料, 必須瞭解工作job的序列執行可以消除資料之間協調訪問的需要。

Hadoop 處理特點：

1. Hadoop是資料並行，處理序列. 在一個工作中job, 並行只在一個map段和一個reduce段中發生. 但是這兩個段不能並行執行, reduce段直到map段完全完成後才能開始。

2.所有被map過程訪問的資料都必須被凍結 (也不能有修改發生)，直至整個工作job完成. 這就意味做Hadoop處理資料是在一個面向批處理batch-oriented風格的鏈條中實現的，, 這就註定它不適合在基於流stream-based處理的方式，在流處理中，資料流是持續的必須立即得到及時處理。

3.資料之間聯絡是通過一個分散式檔案系統(HDFS)完成. 延遲會因為網路I/O開銷發生了，這種延遲不會成為面向批處理模式的主要問題，在面向批處理模式中，吞吐量才是首要考慮的，但是這意味做Hadoop不適合實現對延遲要求很嚴格，甚至不允許有延遲發生的線上實時系統。

根據Hadoop以上特點，給出下來Hadoop不適合的場合：

1.需要資料低延遲性的線上資料處理，（比如股票系統，更新需要讓所有人及時知道，不能有絲毫延遲。)

2.在一個大資料集中執一個小資料集的隨機ad/hoc處理。

3.執行實時/基於流的處理模式，資料持續到達需要立即被處理(如視訊等)。

感謝作者寫了這篇通俗易懂的雲端計算文章：What Hadoop is Good At

[該貼被banq於2009-11-09 10:21修改過]