zoukankan      html  css  js  c++  java
  • MPP调研

    一、MMP数据库

    MPP是massively parallel processing,一般指使用多个SQL数据库节点搭建的数据仓库系统。执行查询的时候,查询可以分散到多个SQL数据库节点上执行,然后汇总返回给用户。MPP解决了单个SQL数据库不能存放海量数据的问题,但是也存在一些问题,例如:当节点数达到100左右的时候,MPP有些仍会遇到Scalability的问题,速度变慢,或者不稳定。而且,当增加或者删除节点的时候,需要的维护工作仍然比较大,集群会遇到数据迁移和重新平衡的问题。SQL on Hadoop是利用Hadoop平台存储数据,在其之上实现SQL查询引擎。最大的特点和Scalability非常好,可以支持超过1000各节点的集群。但是由于Hadoop的特点,很多查询还是需要做大量的数据扫描操作,因此查询速度往往比MPP要慢,而且支持的同时并发查询数一般也比较低。

    二、MPP原理

    MPP原理朴素上说就是分治思想,均分task。然后每个worker/segment上做的都是同样的sub-task,pipeline方式执行,理想情况下性能是非常优异的。但是很容易受到慢worker(它是最长路径)和interconnect的影响,所以scalability不佳,集群规模在十几个节点后就没有性能提升了(甚至还可能下降)。HADOOP原理更类似batch processing,更细粒度切分task,worker能者多劳(每个worker上执行的任务可以是不平均,不一致的)。单独worker看,性能不及MPP,但是胜在scalability优异,几百个节点是没问题的,在集群性上远胜MPP。另外从业务上看,传统企业数据量有限,所以更倾向于full-sql支持的MPP方案。而互联网企业更乐于用hadoop来处理更大规模的数据。近几年来二者是互相融合学习的(MPP提升scalability,hadoop提升sql的支持),所以今后二者的区别应该会越来越模糊,最后可能诞生一个大一统OLAP方案(甚至再融合OLTP)。

    三、MPP数据库对比SQL On Hadoop

    因为一些SQL On Hadoop系统例如Impala也被称为MPP架构。这里是正统的MPP数据库对比SQL On Hadoop。那么对比两边其实是诸如Vertica,阿里ADS,GreenPlum,Redshift vs Impala,Hive以及SparkSQL,Presto等。这两者很大程度上的差异其实在于,对存储的控制。
    对于Hadoop而言,数据最常见的存在形式是数据湖,也就是数据本身未经很多整理,数据倾向于读取的时候再解析,而且多个系统处理不同的workload一起共享同一套数据湖。例如你可以用Spark,MR以及Impala读取Hive的数据,甚至直接读取HDFS上的Parquet,ORC文件。这份数据可以用来做BI数仓也可以用来做ML模型训练等等。
    而MPP数据库则相反,MPP为了速度,需要将数据导入做一定处理,整理成优化的格式以便加速。这样做的后果就是,它们的存储类似一个黑盒,数据进去之后很难被别的系统直接读取。当然Vertica之类的系统也有SQL On Hadoop的运行模式,但是速度会有所下降,看过Vertica的Benchmark,对比Impala在Hadoop模式下,并不是有多大的优势,甚至有部分查询更慢。这部分性能损失,就是抛开黑盒存储所带来的差异。
    另外SQL On Hadoop产品和MPP数据库的很多差异,其实是工程上成熟度的差异。例如CBO这样的优化,可能在数据库领域已经非常常见,但是对SQL On Hadoop还可以说是个新鲜玩意,至少2016-08-30为止,SparkSQL和Presto还没有CBO。而列存的引入也是近些年的事情,相对Vertica应该是从诞生就使用了列存。这些差异很可能会很快被补上。而底层存储部分,随着Parquet ORC这样相对复杂,借用了不少传统数据库领域经验的格式不断优化,也许今后SQL On Hadoop会和MPP数据库越来越近似。

    参考文献:

    1. https://www.zhihu.com/question/27589901/answer/119759349
    2. https://www.zhihu.com/question/27589901/answer/52136396
    3. https://www.zhihu.com/question/27589901/answer/145205267
  • 相关阅读:
    670. Maximum Swap
    653. Two Sum IV
    639. Decode Ways II
    636. Exclusive Time of Functions
    621. Task Scheduler
    572. Subtree of Another Tree
    554. Brick Wall
    543. Diameter of Binary Tree
    535. Encode and Decode TinyURL
    博客园自定义背景图片
  • 原文地址:https://www.cnblogs.com/lidyan/p/9288208.html
Copyright © 2011-2022 走看看