HADOOP與MPP是什麼關係?有什麼區別和聯絡?

適用範圍、應用領域分別是什麼?

其實MPP架構的關係型資料庫與Hadoop的理論基礎是極其相似的，都是將運算分佈到節點中獨立運算後進行結果合併。個人覺得區別僅僅在於前者跑的是SQL，後者底層處理則是MapReduce程式。

但是我們會經常聽到對於MPP而言，雖說是宣稱也可以橫向擴充套件Scale OUT，但是這種擴充套件一般是擴到100左右，而Hadoop一般可以擴充套件1000+，這也是經常被大家拿來區分這兩種技術的一個說詞。

這是為什麼呢?其實可以從CAP理論上來找到一些理由。因為MPP始終還是DB，一定要考慮C(Consistency)，其次考慮 A(Availability)，最後才在可能的情況下儘量做好P(Partition-tolerance)。而Hadoop就是為了並行處理和儲存設計的，所有資料都是以檔案儲存，所以優先考慮的是P，然後是A，最後再考慮C。所以後者的可擴充套件性當然好於前者。

以下幾個方面制約了MPP資料庫的擴充套件

1、高可用：MPP DB是通過Hash計算來確定資料行所在的物理機器(而Hadoop無需此操作)，對儲存位置的不透明導致MPP的高可用很難辦。

2、並行任務：資料是按照Hash來切分了，但是任務沒有。每個任務，無論大小都要到每個節點去走一圈。

3、檔案系統：資料切分了，但是檔案數沒有變少，每個表在每個節點上一定有一到多個檔案。同樣節點數越多，儲存的表就越多，導致每個檔案系統上有上萬甚至十萬多個檔案。

4、網路瓶頸：MPP強調對等的網路，點對點的連線也消耗了大量的網路頻寬，限制了網路上的線性擴充套件(想象一臺機器可能要給1000臺機器傳送資訊)。更多的節點並沒有提供更高的網路頻寬，反而導致每個組節點間平均頻寬降低。

5、其他關係資料庫的枷鎖：比如鎖、日誌、許可權、管理節點瓶頸等均限制了MPP規模的擴大。

但是MPP資料庫有對SQL的完整相容和一些事務處理功能，對於使用者來說，在實際的使用場景中，如果資料擴充套件需求不是特別大，需要的處理節點不多，資料都是結構化資料，習慣使用傳統RDBMS的很多特性的場景，可以考慮MPP如Greenplum/Gbase等。

但是如果有很多非結構化資料，或者資料量巨大，有需要擴充套件到成百上千個數據節點需求的，這個時候Hadoop是更好的選擇。

其實MPP架構的關係型資料庫與Hadoop的理論基礎是極其相似的，都是將運算分佈到節點中獨立運算後進行結果合併。個人覺得區別僅僅在於前者跑的是SQL，後者底層處理則是MapReduce程式。

但是我們會經常聽到對於MPP而言，雖說是宣稱也可以橫向擴充套件Scale OUT，但是這種擴充套件一般是擴到100左右，而Hadoop一般可以擴充套件1000+，這也是經常被大家拿來區分這兩種技術的一個說詞。

這是為什麼呢?其實可以從CAP理論上來找到一些理由。因為MPP始終還是DB，一定要考慮C(Consistency)，其次考慮 A(Availability)，最後才在可能的情況下儘量做好P(Partition-tolerance)。而Hadoop就是為了並行處理和儲存設計的，所有資料都是以檔案儲存，所以優先考慮的是P，然後是A，最後再考慮C。所以後者的可擴充套件性當然好於前者。

以下幾個方面制約了MPP資料庫的擴充套件

1、高可用：MPP DB是通過Hash計算來確定資料行所在的物理機器(而Hadoop無需此操作)，對儲存位置的不透明導致MPP的高可用很難辦。

2、並行任務：資料是按照Hash來切分了，但是任務沒有。每個任務，無論大小都要到每個節點去走一圈。

3、檔案系統：資料切分了，但是檔案數沒有變少，每個表在每個節點上一定有一到多個檔案。同樣節點數越多，儲存的表就越多，導致每個檔案系統上有上萬甚至十萬多個檔案。

4、網路瓶頸：MPP強調對等的網路，點對點的連線也消耗了大量的網路頻寬，限制了網路上的線性擴充套件(想象一臺機器可能要給1000臺機器傳送資訊)。更多的節點並沒有提供更高的網路頻寬，反而導致每個組節點間平均頻寬降低。

5、其他關係資料庫的枷鎖：比如鎖、日誌、許可權、管理節點瓶頸等均限制了MPP規模的擴大。

但是MPP資料庫有對SQL的完整相容和一些事務處理功能，對於使用者來說，在實際的使用場景中，如果資料擴充套件需求不是特別大，需要的處理節點不多，資料都是結構化資料，習慣使用傳統RDBMS的很多特性的場景，可以考慮MPP如Greenplum/Gbase等。

但是如果有很多非結構化資料，或者資料量巨大，有需要擴充套件到成百上千個數據節點需求的，這個時候Hadoop是更好的選擇。