Hadoop 和 MPP 的比较

Posted 2021-01-04 金刀客

如果我们回顾5年前会发现，那就是当时Hadoop不是大多数公司的选择，特别是那些要求稳定和成熟的平台的企业。 在这一刻，选择非常简单：当您的分析数据库的大小超过5-7 TB时，您只需启动MPP迁移项目，并转移到经过验证的企业MPP解决方案之一。

没有人听说过“非结构化”数据 - 如果你要分析日志，只需用Perl / Python / Java / C解析它们并加载到分析数据库中。 没有人听说过高速数据 - 只需使用传统的OLTP RDBMS进行频繁更新，并将其块插入到分析DWH(数据仓库)中。
但是随着时间的流转，“大数据”的流行语开始被广泛使用，也在大众媒体和社交网络中传播。 以下是“大数据”这个词的google趋势图：

人们正在讨论“三V”(大数据的3个维度)和处理这些巨大数据的方法。Hadoop已经从利基技术发展成为数据处理的一流工具之一，越来越受到更多的大公司的投入研发，通过启动广泛的Hadoop实现，或通过投资到其中一个Hadoop供应商，或通过自己成为一个Hadoop供应商。随着Hadoop越来越受欢迎，MPP数据库进入他们的下降趋势。您可以看看Teradata股票的例子，在过去的3年中，他们不断下滑，其主要原因是新玩家进入市场，而且是Hadoop。

所以关于“我是否应该选择MPP解决方案或基于Hadoop的解决方案？”的问题，新来者的问题正在变得非常受欢迎。许多供应商正在将Hadoop定位为传统数据仓库的替代品，这意味着更换MPP解决方案。当Hadoop和MPP彼此离开并且集成在一个单一的解决方案中时，其中一些在消息传递和推动数据湖/数据中心概念方面更保守。

那么MPP是什么？ MPP代表大规模并行处理，这是网格计算中所有单独节点参与协调计算的方法。 MPP DBMS是建立在这种方法之上的数据库管理系统。在这些系统中，您正在凝视的每个查询都会被分解为由MPP网格的节点并行执行的一组协调进程，它们的运行时间比传统的SMP RDBMS系统快得多。该架构提供给您的另一个优点是可扩展性，因为您可以通过向其中添加新节点轻松扩展网格。为了能够处理大量的数据，这些解决方案中的数据通常在每个节点只处理其本地数据的方式在节点（分片）之间分割。这进一步加快了数据的处理速度，因为为这种设计使用共享存储将是一个巨大的过度 - 更复杂，更昂贵，更少的可扩展性，更高的网络利用率，更少的并行性。

这就是为什么大多数MPP_DBMS解决方案是无共享的，并且可以在DAS存储上或在小型服务器之间共享的一组存储架上工作。这种方法被Teradata，Greenplum，Vertica，Netezza等类似解决方案所使用。所有这些都有专门为MPP解决方案开发的复杂而成熟的SQL优化器。所有这些都是可扩展的，内置语言和这些解决方案的工具集支持几乎任何客户的愿望，无论是地理空间分析，数据挖掘的全文搜索。所有这些都是封闭源复杂的企业解决方案（但FYI，Greenplum将在2015年第四季度开放采购）在这个行业多年，它们足够稳定地运行其用户的关键任务工作负载。

Hadoop怎么样？这不是一个单一的技术，它是相关项目的生态系统，它的优缺点。最大的Pro是可扩展性 - 许多新组件出现（像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引擎一样，它们可以为您提供更低的延迟和更少的处理时间，而且可以降低可扩展性和较低的稳定性。

Spark_SQL是坐在MapReduce和MPP-over-Hadoop方法之间的不同的野兽，试图获得最好的两个世界并有自己的缺点。与MR类似，它将作业分成一组独立安排的任务，提供更好的稳定性。 像MPP一样，它尝试在执行阶段之间流式传输数据，以加快处理速度。

此外，它使用MPP（与其impalad和HAWQ段）熟悉的固定执行器概念来减少查询的延迟。 但它也结合了这些解决方案的缺点-不如MPP那么快，而不是像MapReduce那样稳定和可扩展。

大数据平台	MPP	Hadoop
平台开放性	封闭和专有	完全开源并提供商业支持
可扩展性	平均数十个节点，最大100-200	平均100个节点，可扩展至几千个节点个节点
可处理数据	平均10TB,最大1PB	平均100TB, 多值1oPB
延迟	10-20毫秒	10-20秒
平均查询时间	5-7 秒	10-15 分钟
最大查询时间	1-2小时	1-2周
查询优化	拥有复杂的企业级优化器	没有优化器或优化器功能非常有限，有时甚至优化不是基于成本的
查询调试和分析	便于查看的查询执行计划、OOM问题和Java堆转储分析	GC在群集组件上暂停，每个任务的单独日志给你很多有趣的时间查询执行统计信息说明性错误信息
技术价格	每个节点数十万美元	每个节点免费或高达数千美元
易用性	简单友好的SQL界面和简单可编译	SQL不完全符合ANSI标准，用户应该关心执行逻辑，底层数据布局。函数通常需要用Java编写，编译并放在集群上的数据库内功的数据库内置函数
目标用户	业务分析师	Java开发人员和经验丰富的DBA
单作业冗余	低，当MPP节点发生故障时作业失败	高，作业只有当节点管理作业执行失败时才会失败
最小数据集	任意	GB
最大并发性	十到数百个查询	多达10-20个job
技术可扩展性	仅使用供应商提供的工具	混搭
DBA技能等级要求	普通DBA	需要懂Java编程的高级RDBMSDBA
解决方案实施复杂性	一般	复杂

通过比较您可以总结为什么Hadoop不能用作传统企业数据仓库的完全替代品，但它可以用作以分布式方式处理大量数据并从数据中获得重要见解的引擎。

Facebook拥有一个300PB的Hadoop，并且仍然使用一个小型的50TBVertica集群，LinkedIn拥有一个巨大的Hadoop集群，并且仍然使用Aster_Data集群（由Teradata购买的MPP）。