Impala之02-原理、架构分析(1)

Apache Impala是由Cloudera开发并开源的一款基于HDFS/Hbase的MPP SQL引擎，是Google Dremel的开源实现。

在分析Impala架构、原理之前，先介绍一下相关背景知识。

一、SMP、NUMA、MPP体系结构介绍

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

1. SMP(Symmetric Multi-Processor)

SMP (Symmetric Multi Processing),对称多处理系统内有许多紧耦合多处理器，在这样的系统中，所有的CPU共享全部资源，如总线，内存和I/O系统等，操作系统或管理数据库的复本只有一个，这种系统有一个最大的特点就是共享所有资源。多个CPU之间没有区别，平等地访问内存、外设、一个操作系统。操作系统管理着一个队列，每个处理器依次处理队列中的进程。如果两个处理器同时请求访问一个资源（例如同一段内存地址），由硬件、软件的锁机制去解决资源争用问题。Access to RAM is serialized; this and cache coherency issues causes performance to lag slightly behind the number of additional processors in the system.

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

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

图 1.SMP 服务器 CPU 利用率状态

2. NUMA(Non-Uniform Memory Access)

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

图 2.NUMA 服务器 CPU 模块结构

NUMA 服务器的基本特征是具有多个 CPU 模块，每个 CPU 模块由多个 CPU( 如 4 个 ) 组成，并且具有独立的本地内存、 I/O 槽口等。由于其节点之间可以通过互联模块 ( 如称为 Crossbar Switch) 进行连接和信息交互，因此每个 CPU 可以访问整个系统的内存 ( 这是 NUMA 系统与 MPP 系统的重要差别 ) 。显然，访问本地内存的速度将远远高于访问远地内存 ( 系统内其它节点的内存 ) 的速度，这也是非一致存储访问 NUMA 的由来。由于这个特点，为了更好地发挥系统性能，开发应用程序时需要尽量减少不同 CPU 模块之间的信息交互。

利用 NUMA 技术，可以较好地解决原来 SMP 系统的扩展问题，在一个物理服务器内可以支持上百个 CPU 。比较典型的 NUMA 服务器的例子包括 HP 的 Superdome 、 SUN15K 、 IBMp690 等。

但 NUMA 技术同样有一定缺陷，由于访问远地内存的延时远远超过本地内存，因此当 CPU 数量增加时，系统性能无法线性增加。如 HP 公司发布 Superdome 服务器时，曾公布了它与 HP 其它 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 技术的一个关系数据库软件，基于此数据库来开发应用时，不管后台服务器由多少个节点组成，开发人员所面对的都是同一个数据库系统，而不需要考虑如何调度其中某几个节点的负载。

MPP (Massively Parallel Processing)，大规模并行处理系统，这样的系统是由许多松耦合的处理单元组成的，要注意的是这里指的是处理单元而不是处理器。每个单元内的CPU都有自己私有的资源，如总线，内存，硬盘等。在每个单元内都有操作系统和管理数据库的实例复本。这种结构最大的特点在于不共享资源。

二、并行数据库架构

MPP架构数据库一般指使用多个SQL数据库节点搭建的数据仓库系统，每个节点都是 SMP 结构的单机，多个节点一起构成一个 MPP 系统。执行查询的时候，查询可以分散到多个SQL数据库节点上执行，然后汇总返回给用户。并行数据库要求尽可能的去并行执行数据库操作，从而提高性能。

1. 并行计算体系结构

share-disk：每一个 CPU 使用自己的私有内存区域，通过内部通讯机制直接访问所有磁盘系统；
share-nothing：每一个 CPU 都有私有内存区域和私有磁盘空间，而且 2 个 CPU 不能访问相同磁盘空间，CPU 之间的通讯通过网络连接；
share-memory：多个 CPU 共享同一片内存，CPU 之间通过内部通讯机制（interconnection network）进行通讯。

从左至右分别是 share-disk, share-nothing 和 share-memory 架构。

2. MPP DB缺点

MPP DB解决了单个SQL数据库不能存放海量数据的问题，但是也存在一些问题。

扩展性

当节点数达到100左右的时候，MPP有些仍会遇到Scalability的问题，速度变慢，或者不稳定。而且，当增加或者删除节点的时候，需要的维护工作仍然比较大，集群会遇到数据迁移和重新平衡的问题

为什么MPP DB扩展性不好？

有很多原因，有产品成熟度，也有应用广度的问题，但是最根本的还是架构本身的问题。讲到架构这里就要先讲下CAP原则：

Consistency(一致性), 数据一致更新，所有数据变动都是同步的

Availability(可用性), 好的响应性能

Partition tolerance(分区容错性) 可靠性

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

MPP DB还是基于原DB扩展而来，DB里面天然追求一致性（Consistency），必然带来分区容错性较差。集群规模变得太大，业务数据太多时，MPP DB的元数据管理就完全是一个灾难。元数据巨大无比，一旦出错很难恢复，动不动导致毁库。

所以MPP DB要在扩展性上有质的提示，要对元数据，以及数据存储有架构上的突破，降低对一致性的要求，这样扩展性才能提升，否则的话很难相信一个MPP DB数据库是可以容易扩展的。

并发的支持

一个查询系统，设计出来就是提供人用的，所以能支持的同时并发越高越好。MPP DB核心原理是一个大的查询通过分析为一个个子查询，分布到底层的执行，最后再合并结果，说白了就是通过多线程并发来暴力SCAN来实现高速。这种暴力SCAN的方法，对单个查询来说，动用了整个系统的能力，单个查询比较快，但同时带来用力过猛的问题，整个系统能支持的并发必然不高，从目前实际使用的经验来说，也就支持50～100的并发能力。

当前HBASE/IMPALA应对复杂查询时，也是通过全盘SCAN的方法来实现的，这种场景下，硬盘数量越多越好，转速越快越好。HBASE为什么号称支持上千并发，这也是在特定的场景下（查询时带用户标示，即带row key)才能实现的，复杂查询场景下，什么系统都歇菜。

所以MPPDB应用场景已经非常明显了，适合小集群（100以内），低并发的（50左右）的场景。

三、数据仓库的选择

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

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

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

Reference

http://www.cnblogs.com/yubo/archive/2010/04/23/1718810.html
http://www.procedurego.com/article/72940.html
http://daixiaoyu.com/teradata-arch.html

更多文章欢迎关注微信公众号：大数据学苑（Bigdata-Eden）

Impala之02-原理、架构分析(1)相关推荐

Android-FrameWork原理与架构分析
Android-FrameWork原理与架构分析 Android架构主要分为分为四部分,从上往下依次为 APPLICATION(应用程序), APPLICATION FRAMEWORK(应用框架层), ...
深入浅出学习透析Nginx服务器的架构分析及原理分析「底层技术原理+运作架构机制」
Nginx再次回顾也许你已经忘记了Nginx是做什么的?我来再次给你夯实一下概念. 多协议反向代理 Nginx是个高性能的Web和反向代理服务器及HTTP服务器,它能反向代理HTTP,HTTPS和邮 ...
grpc通信原理_容器原理架构详解（全）
目录 1 容器原理架构 1.1 容器与虚拟化 1.2 容器应用架构 1.3 容器引擎架构 1.4 Namespace与Cgroups 1.5 容器镜像原理 2 K8S原理架构 2.1 K8S主要功能 ...
大型网站系统架构分析--转
大型网站系统架构分析原文地址:http://www.cnblogs.com/Mainz/archive/2009/04/28/1445424.html 千万级的注册用户,千万级的帖子,nTB级的附件 ...
Android10.0 日志系统分析(二)-logd、logcat架构分析及日志系统初始化-[Android取经之路]
摘要:本节主要来讲解Android10.0 日志系统的架构分析,以及logd.logcat的初始化操作阅读本文大约需要花费15分钟. 文章首发微信公众号:IngresGe 专注于Android系统级 ...
【嵌入式Linux学习七步曲之第五篇 Linux内核及驱动编程】PowerPC + Linux2.6.25平台下的SPI驱动架构分析
PowerPC + Linux2.6.25平台下的SPI驱动架构分析 Sailor_forever sailing_9806#163.com (本原创文章发表于Sailor_forever 的个人b ...
Log4j2架构分析与实战
为什么80%的码农都做不了架构师?>>> 1 系列目录 2种日志接口框架,4种日志实现框架 jdk-logging.log4j.logback日志介绍及原理 jcl与jul.l ...
SLG手游Java服务器的设计与开发——架构分析
微信公众号[程序员江湖] 作者黄小斜,斜杠青年,某985硕士,阿里 Java 研发工程师,于 2018 年秋招拿到 BAT 头条.网易.滴滴等 8 个大厂 offer,目前致力于分享这几年的学习经验. ...
知名网游Server端架构分析
http://blog.csdn.net/sodme/archive/2004/12/12/213995.aspx 类似于QQ游戏百万人同时在线的服务器架构实现收藏本文作者:sodme 本文出处: ...
b2c项目基础架构分析（一）b2c 大型站点方案简述已补充名词解释
b2c项目基础架构分析(一)b2c 大型站点方案简述已补充名词解释我最近一直在找适合将来用于公司大型bs,b2b b2c的基础架构. 实际情况是要建立一个bs架构b2b.b2c的网站,当然还包括w ...

Impala之02-原理、架构分析(1)

Impala之02-原理、架构分析(1)相关推荐

最新文章

热门文章