暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

从PostgreSQL说起MPP的演进历史

唢呐一响 2018-05-13
2587


PostgreSQL 名副其实的祖师爷

这些年MPP大行其道,如果说你需要一个OLAP引擎,支持海量/高吞吐/低延时的交互查询或BI平台时,非MPP他莫属。在MPP与SQL-on-Hadoop越来越模糊之前,实在是有太多的东西需要深入分析,MPP的演进历史与其生态,就是非常重要的方向。


多年以前Oracle/MySQL是企业首选的DBMS,当然到现在依然是,不妨看DB-Engines Ranking最受欢迎的前二。在OLTP体系里,MySQL是当之无愧的国民数据库,那谁是OLAP里的国民引擎呢?目前看来没有公认的,如果说非要选一个的话,我会选PostgreSQL(后续我统一用pg代替)。


原因在于它是OLAP领域里MPP数据引擎的一个始祖,100%支持ANSI SQL,从SQL-92、SQL:99到SQL:2003(最新版本在完善支持SQL:2008,MySQL完善SQL-92)。并且,它几乎是所有自研MPP的数据公司参考原型,比如当前大家都熟知并且性能经过商业认可的MPP的代表产品有:HP的Vertica,Amazon的Redshift,Pivotal的Greenplum,阿里巴巴的HybridDB等等。它们全部基于PostgreSQL,pg真可谓是祖师爷了!



用过pg的同学都知道它的特性,相较于MySQL而言,SQL支持度非常高,json/gis/fdw/物理复制标配,数据join关联三大难题(hash join、merge join、nestloop join)。pg 已经可以支持把sql编译为bytecode,通过llvm jit技术转化为native code 执行,对复杂查询加速效果明显,普通点查询效果一般。当然有了llvm的黑科技还很方便做vector加速。这些新特性在olap 领域相当重要。


说到OLAP里的向量计算(vector),不得不提的是俄罗斯如AK47类型的clickhouse也同样使用vector计算,外使用SIMD,性能秒杀pg就算了,连vertica/redshift同样碾压,千万、亿条记录级别下,clickhouse的性能是vertica的两倍。当然clickhouse也算是MPP架构,跟pg有些地方非常相似,如clickhouse的分布式表与pg的分区表非常相似(主表+子表 vs cluster表+local表)。从个人的使用体验之后还是很喜欢,全手动档,储存引擎非常多,集群自己管理,分布式自己管理等等。用得好就是屠龙刀,用得不好就是菜刀,后续我单独写一篇关于这ck(国人爱用ck缩写,国外爱用ch缩写)大杀器的分享。


刚才还提到阿里的HybridDB,这其实也是非常值得注意的一个引擎。我们一般会有在线业务OLTP数据库,比如MySQL,非常擅长于做一些高并发的事务;也会有做全量的数据分析OLAP,比如hive,这样的场景;HybridDB就是为了同时解决OLTP和OLAP两个问题,13年提出这解决方案确实挺先进的。这就引出另外一个概念HTAP(Hybrid transactional/analytical processing),这也是GP(greenplum)在走的路线。


何为MPP

我叨了这么久的MPP的产品,回归到它的概念上,MPP(Massively Parallel Processing)大规模并行处理系统/海量并行处理,系统是由许多松耦合的处理单元组成的,要注意的是这里指的是处理单元而不是处理器。每个单元内的 CPU都有自己私有的资源,如总线,内存,硬盘等,并且有操作系统和管理数据库的实例复本。


这种结构最大的特点在于不共享资源,也就是大家常说的shared nothing,其实这种设计理念最早是在计算机系统里演进出来的。由此我得再引申「非一致存储访问结构(NUMA)」概念,NUMA是节点与之间通过互联模块进行连接和信息交互,因此每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要差别)。


显然,访问本地内存的速度将远远高于访问异地内存的速度,这也是非一致存储访问NUMA的由来,这也是为什么会演进出MPP shared nothing这种设计。


Greenplum 的 MPP 架构

说pg必不可少的另一成员就是Greenplum(GP),GP是完全在PG的基础上衍生出的OLAP MPP数据库,国内很多大中小型保守性企业采用GP做数仓或OLAP引擎,比如地方邮政、电信等行业。GP可谓是为PG在国内扬名做了一份贡献,相得益彰。


GP在2015年开源,MPP 数据库的日子也并不好过,碎片化,各厂商为了低微的利润竞争恶化,市场难以有大的突破;其次随着 Hadoop 生态冲击,SQL-on-Hadoop也开始得到广泛应用,可谓竞争重重,进退两难,开源算是被迫的。


以上是一些闲话,说回 PG MPP 架构。



GP的最小并行单元不是节点层级,而是在实例层级,安装过GP的同学应该都看到每个实例都有自己的postgresql目录结构,都有各自的一套PG数据库守护进程(甚至可以通过UT模式进行单个实例的访问)。正因为如此,甚至一个运行在单节点上的GP也是一个小型的并行计算架构,一般一个节点配置6~8个实例,相当于在一个节点上有6~8个PG数据库同时并行工作,优势在于可以充分利用到每个节点的所有CPU和IO能力。


MPP 架构的缺陷

MPP最开始的设计目的是为了消除共享资源的使用,但是有一种情况例外,那就是当数据必须要通过网络进行交换的时候。当出现并发时,即每个executor执行同样的数据处理逻辑,处理的数据则是这个executor所在的节点的本地存储的数据分片,在这些执行步骤中,有一些被称为同步点,这些同步点多数情况下是在执行节点间的数据交换,比如spark和mr中得shuffle操作。如果shuffle的key比较均匀,将会出现如下task情况。


其中垂直的虚线表示同步点。当是比较复杂的情况,比如让人讨厌的join或aggregation计算,就需要一个同步操作来等待。如果某个节点在比其他的节点慢,整体的执行性能都会由这个最慢的节点决定了,悲剧就发生了。

比如这个可怕的 Executor 7。


由PG到PG,按道理还得讲HAWQ,再到oushu database,pg的MPP演进这条时间线才完整。下篇准备写另外一个主题 SQL-on-Hadoop (经常拿来与MPP对比的数据引擎类型)


上一篇:SQL的版本演进






技术、数据、写故事

微信 : wu-shuiyong





文章转载自唢呐一响,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论