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是更好的选择。