在近的时间里，我听到了很多关于该主题的讨论。同样，这是一个非常受欢迎的问题，是由在“大数据”领域经验不足的客户提出的。实际上，我不喜欢这个含糊不清的流行语，但这就是客户通常会来找我们的原因，因此我必须使用它。
如果回头看5年前，那是大多数公司都不选择Hadoop的时候，尤其是对于那些要求稳定和成熟平台的企业而言。那时，选择非常简单：当分析数据库的大小超过5-7 TB时，您只需启动一个MPP迁移项目，然后迁移到一种成熟的企业MPP解决方案中。没有人听说过“ 非结构化 ”数据–如果您要分析日志，只需使用Perl / Python / Java / C ++对其进行分析并加载到分析DBMS中即可。没人听说过高速数据 –只需使用传统的OLTP RDBMS进行频繁的更新，然后将其分块以插入到分析DWH中即可。
但是随着时间的流逝，“大数据”这个流行词开始在空中传播，在大众媒体和社交网络中也开始流行。这是“ 大数据 ” 的google趋势图：
人们正在讨论“ 三个V ”以及处理这些海量数据的方法。Hadoop已从利基技术发展成为一种用于数据处理的工具，通过开始广泛的Hadoop 实施或通过投资 Hadoop供应商之一，或通过 自己成为 Hadoop供应商。随着Hadoop越来越流行，MPP数据库开始下降。您可以以Teradata 股票为例，在过去三年中，它们一直在下跌，其主要原因是新参与者进入了他们的市场，而Hadoop是。
因此，新人提出的关于“我应该选择MPP解决方案还是基于Hadoop的解决方案？”的问题变得非常流行。许多供应商都将Hadoop定位为传统数据仓库的替代品，这意味着这是MPP解决方案的替代品。当Hadoop和MPP彼此分开并集成到一个解决方案中时，其中一些在消息传递和推进Data Lake / Data Hub概念方面更为保守。
那么什么是MPP？MPP代表大规模并行处理，当网格的所有单独节点都参与协调计算时，这是网格计算中的方法。MPP DBMS是基于此方法构建的数据库管理系统。在这些系统中，您正在注视的每个查询被分解为由MPP网格的节点并行执行的一组协调过程，从而以比传统SMP RDBMS系统更快的速度运行计算。这种体系结构为您提供的另一个优势是可伸缩性，因为您可以通过在网格中添加新节点来轻松扩展网格。为了能够处理大量数据，这些解决方案中的数据通常按每个节点仅处理其本地数据的方式在节点之间拆分（分片）。这进一步加快了数据的处理速度，因为将共享存储用于这种设计将是一个巨大的矫kill过正-更复杂，更昂贵，可伸缩性更低，网络利用率更高，并行性更低。这就是为什么大多数MPP DBMS解决方案都是不共享的，并且不能在DAS存储或在小型服务器组之间共享的一组存储架上工作的原因。Teradata，Greenplum，Vertica，Netezza和其他类似解决方案都采用了这种方法。它们都具有专门为MPP解决方案开发的复杂而成熟的SQL优化器。所有这些都可以通过内置语言进行扩展，并且围绕这些解决方案的工具集几乎可以满足任何客户的需求，无论是地理空间分析，数据挖掘的全文本搜索。它们都是开源的复杂企业解决方案（但仅供参考，开源于 2015年第4季度），在该行业已经存在多年了，它们足够稳定，可以运行用户的关键任务工作负载。
Hadoop呢？这不是一项单独的技术，而是一个相关项目的生态系统，它有其优点和缺点。大的优点是可扩展性–出现了许多新组件（如一段时间前的Spark），并且它们与基础Hadoop的核心技术保持集成，从而避免了锁定并允许进一步扩展集群用例。作为一个缺点，我可以说一个事实，那就是，您自己要构建单独技术的平台是一项艰巨的工作，并且现在还没有人手动进行，大多数公司都在运行由Cloudera和Hortonworks。
Hadoop存储技术基于完全不同的方法。它不是根据某种密钥来分片数据，而是将数据分块为固定大小（可配置）的块，然后在节点之间进行拆分。这些块很大，它们以及整个文件系统（HDFS）都是只读的。简而言之，将小的100行表加载到MPP中将使引擎根据表的键来分片数据，这样，在足够大的集群中，每个节点仅存储一个节点的可能性就很大。行。相反，在HDFS中，整个小表将写入单个块中，该块将表示为datanode的文件系统上的单个文件。
接下来，集群资源管理如何？与MPP设计相比，Hadoop资源管理器（YARN）为您提供了更细粒度的资源管理–与MPP相比，MapReduce作业不需要并行运行所有计算任务，因此您甚至可以处理大量的任务。如果完全利用了群集的其他部分，则在单个节点上运行的一组任务中的数据。它还具有一系列不错的功能，例如可扩展性，对长寿命容器的支持等。但是实际上，它比MPP资源管理器慢，有时在管理并发性方面不那么好。
接下来是Hadoop的SQL接口。在这里，您有各种各样的工具：它可能是Hive在MR / Tez / Spark 上运行，它可能是SparkSQL，它可能是Impala或HAWQ或IBM BigSQL，它可能与Splice Machine完全不同。您拥有广泛的选择，并且很容易迷失这种技术。
个选择是Hive，它是将SQL查询转换为MR / Tez / Spark作业并在集群上执行的引擎。所有作业均基于相同的MapReduce概念构建，并为您提供了良好的群集利用率选项以及与其他Hadoop堆栈的良好集成。但是缺点也很大-执行查询的延迟大，尤其是对于表联接的性能较低，没有查询优化器（至少目前是这样），因此即使是糟糕的选择，引擎也可以执行您要求的操作。这张图片涵盖了过时的MR1设计，但在我们的背景下并不重要：
诸如Impala和HAWQ之类的解决方案处于这一优势的另一端，它们是Hadoop之上的MPP执行引擎，可处理HDFS中存储的数据。与其他MPP引擎一样，它们可以为您提供更低的延迟和更短的查询处理时间，但代价是可伸缩性和稳定性较低。
SparkSQL是介于MapReduce和基于MPP-over-Hadoop的方法之间的另一种野兽，它试图兼顾两者，并有其自身的缺点。与MR相似，它将工作分解为一组单独计划的任务，以提供更好的稳定性。与MPP一样，它尝试在执行阶段之间流式传输数据以加快处理速度。它还使用MPP熟悉的固定执行程序概念（带有impalad和HAWQ段）来减少查询的延迟。但是它也结合了这些解决方案的缺点–速度不如MPP，不如MapReduce稳定和可扩展。
当我分别介绍所有技术时，在此表将所有内容汇总在一起：
有了所有这些信息，您就可以得出结论，为什么Hadoop不能完全替代传统企业数据仓库，而可以用作分布式处理大量数据并从数据中获得重要见解的引擎。Facebook安装了300PB Hadoop，但他们仍使用小型50TB Vertica群集，LinkedIn拥有庞大的Hadoop群集，仍使用Aster Data群集（Teradata购买的MPP），您可以继续使用此列表
