zoukankan      html  css  js  c++  java
  • 数据仓库迁移——MPP架构和Hadoop的区别

    最近在做一个数据仓库迁移的项目,目前在前期阶段,所以学习一下MPP架构的概念。

    目前项目组想要替换掉的是Teradata所提供的一个MPP架构的数据仓库,所以做数据仓库迁移。迁移目标为南大通用所提供的GBASE。

    对于MPP架构网上的资料较少,开源的有Greenplum这几天在看。由于之前做大数据的时候一直是在做Hadoop那一套,所以想先看一下两个架构的区别与联系。

    这两种架构有区别又可以联系在一起。但是本质的思想还是不同的,各有千秋吧。不能说哪一种更好用什么的。目前来看就是价格的因素,Teradata真的是太贵了,大型机构都有些受不了。

    下面是找的一些材料:

    材料1:

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

    材料2:

    1. hadoop(hive)跟mpp的本质区别是什么,这个有的时候界限很模糊,比如说存储,如果我把mpp的存储架在hdfs上,那存储模型就没有区别了,所以以下我打算还是用比较传统的认知来作区别。

    2. hive跟mpp的存储模型不一样,hive用的hdfs,而mpp需要自己做切分,自己做切分就带来动态调整的问题,hdfs的扩展是通过元数据来做的,他有中心节点用来存元数据,在加入新的节点的时候,只需要修改元数据就可以了,所以hdfs的扩展能力是受到管理元数据那台机器的性能限制的,一般来说可以到10k这个规模,再向上就不行了。但是mpp通常采用的是没有中心节点的存储模型,比如hash,你每次增加节点的时候,都需要rehash,这样当规模到了几百台的时候,扩展能力就下来了。当然,现在可以把存储架在hdfs上,这样在存储上就没有太大区别了。

    3. hive跟mpp的内存管理方式不大一样,mpp内存管理比较精细,他主要的想法是在每个机器上放个数据库,传统数据库的内存管理比较复杂,主要是内外存交互的东西,这样的架构决定了mpp在小数据量的时候,latency可以做的比较小,但是在大数据量的时候,throughput做不上去。而hive的内存管理非常粗放,他后来就是mapreduce的job,mr的job是没有太多精细的内存管理的,他就是拼了命地scan,完了顶多就是个spill,这样的架构导致throughput很大,但是latency很高,当你集群规模很大的时候,你一般会追求很大的throughput,当数据量很大的时候,如果你用mpp那种传统的内存管理的话,大批量的计算反而会慢,而且更加占资源,所以vertica这种一开始就考虑了列式存储就是这个道理。

    4.事务,你可以认为hive不支持传统意义上的那种高并发的事务,而mpp试图想要支持,一旦你要上分布式事务,基本上你的可扩展性就上不去了,至于为啥,陈皓有一篇文章写的不错,建议看下。hive的ddl是可以多个并发的,但是dml不行,而ddl他是通过传统的数据库去做的,所以这个也是个中心节点,dml不行的话,就决定了他可以在底层跑mr这么重粒度的东西,他跑的时候,会在整个表上面加一把大锁。

    5.failover机制,hive的failover就是mr的failover,job挂掉了重新换机器跑就完了,但是mpp如果采用传统架构的话,他的计算是要attach到数据节点上去的,如果你规模上去,那么fail的可能性就上去了,这样如果你每次计算都有台机器挂了,你一挂,别人就要等你,而不是换台机器继续跑,那么这个也限制了可扩展性,当然,如果mpp在底层用了统一的存储,完了计算也可以到处转移,再想个办法把中间状态记录下来,也可以扩展(这个实际上就是sparksql)。

    上述材料均来自知乎,想阅读原文的小伙伴请到知乎去搜索。

  • 相关阅读:
    idea 类路径跳转问题?
    关于Guava中I/O中Files类各个方法的解读
    ELASTICSEARCH-分析器详解和搜索原理
    字符串正则替换
    使用jacob调用Windows的com对象,进行word、ppt等转换成ptf、html(二)
    使用jacob调用Windows的com对象,进行word、ppt等转换成ptf、html
    mongodb常用查询语法
    idea git 版本回滚
    ElasticSearch系列
    SpringBoot集成Elasticsearch 进阶,实现中文、拼音分词,繁简体转换高级搜索
  • 原文地址:https://www.cnblogs.com/zhuozige/p/14929622.html
Copyright © 2011-2022 走看看