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是更好的選擇。
京公網安備 11010502049343號