MPP DB技术分类

随着数据量的增大,传统数据库如Oracle、MySQL、PostgreSQL等单实例模式将无法支撑大量数据的处理,数据仓库采用分布式技术成为自然的选择。

6.2.1 MPP的概念

在讨论MPP DB之前,我们先把MPP本身的概念搞清楚。MPP是系统架构角度的一种服务器分类方法。

从系统架构来看,目前的商用服务器大体可以分为三类,即对称多处理器结构(Symmetric Multi-Processor,SMP)、非一致存储访问结构(Non-Uniform Memory Access,NUMA),以及海量并行处理结构(Massive Parallel Processing,MPP)。它们的特征分别描述如下。

1.SMP(Symmetric Multi-Processor)

所谓对称多处理器结构,是指服务器中的多个CPU对称工作,无主次或从属关系。各CPU共享相同的物理内存,每个CPU访问内存中的任何地址所需时间是相同的,因此SMP也被称为一致存储器访问结构(Uniform Memory Access,UMA)。对SMP服务器进行扩展的方式包括增加内存、使用更快的CPU、增加CPU、扩充I/O(槽口数与总线数)及添加更多的外部设备(通常是磁盘存储)。

SMP服务器的主要特征是共享,系统中的所有资源(如CPU、内存、I/O等)都是共享的。也正是由于这种特征,导致了SMP服务器的主要问题,即它的扩展能力非常有限。对于SMP服务器而言,每个共享的环节都可能造成SMP服务器扩展时的瓶颈,而最受限制的则是内存。由于每个CPU必须通过相同的内存总线访问相同的内存资源,因此,随着CPU数量的增加,内存访问冲突将迅速增加,最终造成CPU资源的浪费,使CPU性能的有效性大大降低。实验证明,SMP服务器CPU利用率最好的情况是2~4个CPU,如图6.1所示。

图6.1

2.NUMA(Non-Uniform Memory Access)

由于SMP在扩展能力上的限制,人们开始探究如何进行有效的扩展从而构建大型系统的技术,NUMA就是这种努力下的结果之一。利用NUMA技术,可以把几十个CPU(甚至上百个CPU)组合在一台服务器内。其CPU模块结构如图6.2所示。

图6.2

NUMA服务器的基本特征是拥有多个CPU模块,每个CPU模块由多个CPU(如4个)组成,并且具有独立的本地内存、I/O槽口等。由于其节点之间可以通过互联模块(如称为CrossbarSwitch)进行连接和信息交互,因此,每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要区别)。显然,访问本地内存的速度将远远高于访问异地内存(系统内其他节点的内存)的速度,这也是非一致存储访问NUMA的由来。由于这个特点,为了更好地发挥系统性能,开发应用程序时需要尽量减少不同CPU模块之间的信息交互。利用NUMA技术,可以较好地解决原来SMP系统的扩展问题,在一台物理服务器内可以支持上百个CPU。比较典型的NUMA服务器包括惠普的Superdome、SUN15K、IBMp690等。

但NUMA技术同样有一定的缺陷,由于访问异地内存的时延远远超过访问本地内存,因此,当CPU数量增加时,系统性能无法线性增加。如惠普公司发布Superdome服务器时,曾公布了它与惠普其他UNIX服务器的相对性能值,结果发现,64路CPU的Superdome服务器(NUMA结构)的相对性能值是20,而8路N4000(共享的SMP结构)的相对性能值是6.3。从这个结果可以看出,8倍数量的CPU换来的只是3倍性能的提升。

3.MPP(Massive Parallel Processing)

和NUMA不同,MPP提供了另外一种进行系统扩展的方式,它由多台SMP服务器通过一定的节点互联网络进行连接,协同工作,完成相同的任务,从用户角度来看是一个服务器系统。其基本特征是由多台SMP服务器(每台SMP服务器称为节点)通过节点互联网络连接而成,每个节点只访问自己的本地资源(内存、存储等),是一种完全无共享(Share Nothing)结构,因而扩展能力最强,理论上可以无限扩展,目前的技术可以实现512个节点互联,包含数千个CPU。目前业界对节点互联网络暂无标准,如NCR的Bynet、IBM的SPSwitch,它们都采用了不同的内部实现机制。但节点互联网络仅供MPP服务器内部使用,对用户而言是透明的。

在MPP系统中,每个SMP节点也可以运行自己的操作系统、数据库等。但和NUMA不同的是,它不存在异地内存访问的问题。换言之,每个节点内的CPU不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的,这个过程一般称为数据重分配(Data Redistribution)。

但是MPP服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。目前,一些基于MPP技术的服务器往往通过系统级软件(如数据库)来屏蔽这种复杂性。举例来说,NCR的Teradata就是基于MPP技术的一个关系数据库软件,基于此数据库来开发应用时,不管后台服务器由多少个节点组成,开发人员所面对的都是同一个数据库系统,而无须考虑如何调度其中某几个节点的负载。

4.NUMA与MPP的区别

从架构来看,NUMA与MPP有许多相似之处:它们都由多个节点组成;每个节点都有自己的CPU、内存、I/O;节点之间都可以通过节点互联机制进行信息交互。那么二者的区别在哪里?通过分析NUMA和MPP服务器的内部架构与工作原理不难发现其差异所在。

首先是节点互联机制不同。NUMA的节点互联机制是在同一台物理服务器内部实现的,当某个CPU需要进行异地内存访问时,它必须等待,这也是NUMA服务器无法实现CPU增加时性能线性扩展的主要原因。而MPP的节点互联机制是在不同的SMP服务器外部通过I/O实现的,每个节点只访问本地内存和存储,节点之间的信息交互与节点本身的处理是并行进行的。因此,MPP在增加节点时,其性能基本上可以实现线性扩展。

其次是内存访问机制不同。在NUMA服务器内部,任何一个CPU都可以访问整个系统的内存,但异地内存访问的性能远远低于本地内存访问,因此,在开发应用程序时应该尽量避免异地内存访问。而在MPP服务器中,每个节点只访问本地内存,不存在异地内存访问的问题。

5.数据仓库的选择

哪种服务器更加适应数据仓库环境?这需要从数据仓库环境本身的负载特征入手。众所周知,典型的数据仓库环境具有大量复杂的数据处理和综合分析,要求系统具有很高的I/O处理能力,并且存储系统需要提供足够的I/O带宽与之匹配。而一个典型的OLTP系统则以联机事务处理为主,每次交易所涉及的数据不多,要求系统具有很高的事务处理能力,能够在单位时间里处理尽量多的交易。显然,这两种应用环境的负载特征完全不同。

从NUMA架构来看,它可以在一台物理服务器内集成多个CPU,使系统具有较高的事务处理能力,但由于异地内存访问时延远长于本地内存访问,因此需要尽量减少不同CPU模块之间的数据交互。显然,NUMA架构更适用于OLTP事务处理环境,当用于数据仓库环境时,由于大量复杂的数据处理必然导致大量的数据交互,将使CPU的利用率大大降低。

相对而言,MPP服务器架构的并行处理能力更优越,更适合复杂的数据综合分析与处理环境。当然,它需要借助支持MPP技术的关系数据库系统来屏蔽节点之间负载平衡与调度的复杂性。另外,这种并行处理能力也与节点互联网络有很大的关系。显然,适应数据仓库环境的MPP服务器,其节点互联网络的I/O性能应该非常突出,这样才能充分发挥整个系统的性能。

6.MPP数据仓库架构分类

前面讲到MPP架构非常复杂,通常用到数据库系统来屏蔽节点间的负载平衡和调度的复杂性。在数据库架构设计中,又有多种架构,主要分为Share Disk和Share Nothing。

(1)Share Disk:各个处理单元使用自己的私有CPU和Memory,共享磁盘系统。典型代表是OracleRac,它共享数据,可以通过增加节点来提高并行处理能力,扩展能力较好。处理节点采用的是MPP架构,但是需要共享一套磁盘系统,因此,当存储器接口达到饱和的时候,增加节点并不能获得更高的性能。

(2)Share Nothing:各个处理单元都有自己私有的CPU、内存、硬盘等,不存在共享资源,类似于MPP(大规模并行处理)模式,各处理单元之间通过协议通信,并行处理和扩展能力更好。典型代表是DB2 DPF版本和Greenplum,各节点相互独立,各自处理自己的数据,处理后的结果可能向上层汇总或在节点间流转。

我们常说的Sharding其实就是Share Nothing架构,它把某张表从物理存储上水平分割,并分配给多台服务器(或多个实例),每台服务器可以独立工作,具备共同的Schema,如MySQL Proxy和Google的各种架构,只需增加服务器数量就可以增加处理能力和容量。

Share Nothing因为数据尤其是元数据存储在不同的服务器上,所以对各台服务器间的元数据同步及故障恢复来说是一个灾难。相对而言,Share Disk不存在同步问题,计算节点故障后简单复位就可以恢复工作,但是存在共享存储导致的存储瓶颈问题。

本文选自本人新作《大数据架构详解:从数据获取到深度学习》6.2.1节。

原文发布于微信公众号 - 大数据和云计算技术(jiezhu2007)

原文发表时间:2017-03-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏闵开慧

hive与hbase区别

1、hive是sql语言,通过数据库的方式来操作hdfs文件系统,为了简化编程,底层计算方式为mapreduce。 2、hive是面向行存储的数据库。 3、Hi...

3509
来自专栏大数据和云计算技术

HBase设计之rowkey设计

HBase应用场景非常广泛;社区前面有一系列文章。大家可以到社区看看看;张少华同学本篇主要讲HBASE最重要的一个基础知识,rowkey的涉及,非常赞!大力推...

3936
来自专栏分布式系统和大数据处理

Kafka 分布式消息系统

本来打算给这篇文章起名叫“搭建Kafka消息队列集群(基础概念篇)”,然而,和RabbitMQ不同,Kafka并没有实现消息队列的协议(例如AMQP,Advan...

1284
来自专栏CSDN技术头条

腾讯大规模Hadoop集群实践

TDW(Tencent distributed Data Warehouse,腾讯分布式数据仓库)基于开源软件Hadoop和Hive进行构建,打破了传统数据仓库...

3247
来自专栏IT技术精选文摘

大数据查询——HBase读写设计与实践

背景介绍 本项目主要解决 check 和 opinion2 张历史数据表(历史数据是指当业务发生过程中的完整中间流程和结果数据)的在线查询。原实现基于 Orac...

2495
来自专栏服务端思维

选择合适的数据存储方案

在服务端会经常遇到数据存储的选型问题,是选择使用关系型数据库 MySQL,还是选择内存数据库 Redis,还是选择文档数据库 MongoDB,还是选择列族数据库...

372
来自专栏Albert陈凯

CAP原则

CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition toleran...

2905
来自专栏美图数据技术团队

美图离线ETL实践

感谢阅读「美图数据技术团队」的第 13 篇文章,关注我们持续获取美图最新数据技术动态。

200
来自专栏java一日一条

如何提高 Java 中锁的性能

两个月前向Plumbr公司引进线程死锁的检测之后,我们开始收到一些类似于这样的询问:“棒极了!现在我知道造成程序出现性能问题的原因了,但是接下来该怎么做呢?”

151
来自专栏大数据和云计算技术

资源管理框架(mesos/YARN/coraca/Torca/Omega)分析

1 资源调度的目标和价值 1.1 子系统高效调度 任务之间资源隔离,减少争抢。 任务分配调度时结合资源分配,各个任务分配合理的资源,充分利用系统资源,减少资源利...

3438

扫描关注云+社区