大数据培训：Hadoop 和 MPP 有什么区别

​

在最近的时间里，我听到了很多关于该主题的讨论。同样，这是一个非常受欢迎的问题，是由在“大数据”领域经验不足的客户提出的。实际上，我不喜欢这个含糊不清的流行语，但这就是客户通常会来找我们的原因，因此我必须使用它。如果回头看 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），您可以继续使用此列表

文章来源于侠梦的开发笔记

​