MPP⼤规模并⾏处理架构详解
⾯试官：说下你知道的MPP架构的计算引擎？
这个问题不少⼩伙伴在⾯试时都遇到过，因为对MPP这个概念了解较少，不少⼈都卡壳了，但是我们常⽤的⼤数据计算引擎有很多都是MPP架构的，像我们熟悉的Impala、ClickHouse、Druid、Doris等都是MPP架构。
采⽤MPP架构的很多OLAP引擎号称：亿级秒开。
本⽂分为三部分讲解，第⼀部分详解MPP架构，第⼆部分剖析MPP架构与批处理架构的异同点，第三部分是采⽤MPP架构的
OLAP引擎介绍。
⼀、MPP架构
MPP是系统架构⾓度的⼀种服务器分类⽅法。
⽬前商⽤的服务器分类⼤体有三种：
1. SMP（对称多处理器结构）
2. NUMA（⾮⼀致存储访问结构）
3. MPP（⼤规模并⾏处理结构）
我们今天的主⾓是 MPP，因为随着分布式、并⾏化技术成熟应⽤，MPP引擎逐渐表现出强⼤的⾼吞吐、低时延计算能⼒，有很多采⽤MPP 架构的引擎都能达到“亿级秒开”。
先了解下这三种结构：
1. SMP
即对称多处理器结构，就是指服务器的多个CPU对称⼯作，⽆主次或从属关系。SMP服务器的主要特征是共享，系统中的所有资源（如CPU、内存、I/O等）都是共享的。也正是由于这种特征，导致了SMP服务器的主要问题，即扩展能⼒⾮常有限。
2. NUMA
即⾮⼀致存储访问结构。这种结构就是为了解决SMP扩展能⼒不⾜的问题，利⽤NUMA技术，可以把⼏
⼗个CPU组合在⼀台服务器内。NUMA的基本特征是拥有多个CPU模块，节点之间可以通过互联模块进⾏连接和信息交互，所以，每个CPU可以访问整个系统的内存（这是与MPP系统的重要区别）。但是访问的速度是不⼀样的，因为CPU访问本地内存的速度远远⾼于系统内其他节点的内存速度，这也是⾮⼀致存储访问NUMA的由来。
这种结构也有⼀定的缺陷，由于访问异地内存的时延远远超过访问本地内存，因此，当CPU数量增加时，系统性能⽆法线性增加。
3. MPP
即⼤规模并⾏处理结构。MPP的系统扩展和NUMA不同，MPP是由多台SMP服务器通过⼀定的节点互联⽹络进⾏连接，协同⼯作，完成相同的任务，从⽤户的⾓度来看是⼀个服务器系统。每个节点只访问⾃⼰的资源，所以是⼀种完全⽆共享（Share Nothing）结构。
MPP结构扩展能⼒最强，理论可以⽆限扩展。由于MPP是多台SPM服务器连接的，每个节点的CPU不能访问另⼀个节点内存，所以也不存在异地访问的问题。
MPP架构图：
每个节点内的CPU不能访问另⼀个节点的内存，节点之间的信息交互是通过节点互联⽹络实现的，这个过程称为数据重分配。
但是MPP服务器需要⼀种复杂的机制来调度和平衡各个节点的负载和并⾏处理过程。⽬前，⼀些基于M
PP技术的服务器往往通过系统级软件（如数据库）来屏蔽这种复杂性。举个例⼦，Teradata就是基于MPP技术的⼀个关系数据库软件（这是最早采⽤MPP架构的数据库），基于此数据库来开发应⽤时，不管后台服务器由多少节点组成，开发⼈员⾯对的都是同⼀个数据库系统，⽽⽆需考虑如何调度其中某⼏个节点的负载。
MPP架构特征：
任务并⾏执⾏;
数据分布式存储(本地化);
分布式计算;
⾼并发，单个节点并发能⼒⼤于300⽤户;
横向扩展，⽀持集节点的扩容;
Shared Nothing（完全⽆共享）架构。
NUMA和MPP区别：
⼆者有许多相似之处，⾸先NUMA和MPP都是由多个节点组成的；其次每个节点都有⾃⼰的CPU，内存，I/O等；都可以都过节点互联机制进⾏信息交互。
那它们的区别是什么呢，⾸先是节点互联机制不同，NUMA的节点互联是在同⼀台物理服务器内部实现的，MPP的节点互联是在不同的SMP服务器外部通过I/O实现的。
其次是内存访问机制不同，在NUMA服务器内部，任何⼀个CPU都可以访问整个系统的内存，但异地内存访问的性能远远低于本地内存访问，因此，在开发应⽤程序时应该尽量避免异地内存访问。⽽在MPP服务器中，每个节点只访问本地内存，不存在异地内存访问问题。
⼆、批处理架构和MPP架构
批处理架构（如 MapReduce）与MPP架构的异同点，以及它们各⾃的优缺点是什么呢？
相同点：
⾸先相同点，批处理架构与MPP架构都是分布式并⾏处理，将任务并⾏的分散到多个服务器和节点上，在每个节点上计算完成后，将各⾃部分的结果汇总在⼀起得到最终的结果。
不同点：
doris
批处理架构和MPP架构的不同点可以举例来说：我们执⾏⼀个任务，⾸先这个任务会被分成多个task执⾏，对于MapReduce来说，这些tasks被随机的分配在空闲的Executor上；⽽对于MPP架构的引擎来说，每个处理数据的task被绑定到持有该数据切⽚的指定Executor上。正是由于以上的不同，使得两种架构有各⾃优势也有各⾃缺陷：
批处理的优势：
对于批处理架构来说，如果某个Executor执⾏过慢，那么这个Executor会慢慢分配到更少的task执⾏，批处理架构有个推测执⾏策略，推测
出某个Executor执⾏过慢或者有故障，则在接下来分配task时就会较少的分配给它或者直接不分配。
MPP的缺陷：
对于MPP架构来说，因为task和Executor是绑定的，如果某个Executor执⾏过慢或故障，将会导致整个集的性能就会受限于这个故障节点的执⾏速度(所谓⽊桶的短板效应)，所以MPP架构的最⼤缺陷就是——短板效应。另⼀点，集中的节点越多，则某个节点出现问题的概率越⼤，⽽⼀旦有节点出现问题，对于MPP架构来说，将导致整个集性能受限，所以⼀般实际⽣产中MPP架构的集节点不易过多。
批处理的缺陷：
任何事情都是有代价的，对于批处理⽽⾔，会将中间结果写⼊到磁盘中，这严重限制了处理数据的性能。
MPP的优势：
MPP架构不需要将中间数据写⼊磁盘，因为⼀个单⼀的Executor只处理⼀个单⼀的task，因此可以简单直接将数据stream到下⼀个执⾏阶段。这个过程称为pipelining，它提供了很⼤的性能提升。
举个例⼦：要实现两个⼤表的join操作，对于批处理⽽⾔，如Spark将会写磁盘3次(第⼀次写⼊：表1根据join key进⾏shuffle；第⼆次写⼊：表2根据join key进⾏shuffle；第三次写⼊：Hash表写⼊磁盘)，⽽MPP只需要⼀次写⼊(Hash表写⼊)。这是因为MPP将mapper和reducer同时运⾏，⽽MapReduce将它们分成有依赖关系的tasks(DAG)，这些task是异步执⾏的，因此必须通过写⼊中间数据共享内存来解决数据的依赖。
批处理架构和MPP架构融合：
两个架构的优势和缺陷都很明显，并且它们有互补关系，如果我们能将⼆者结合起来使⽤，是不是就能发挥各⾃最⼤的优势。⽬前批处理和MPP也确实正在逐渐⾛向融合，也已经有了⼀些设计⽅案，⼀旦技
术成熟，可能会风靡⼤数据领域，我们拭⽬以待！
三、 MPP架构的OLAP引擎
采⽤MPP架构的OLAP引擎有很多，下⾯只选择常见的⼏个引擎对⽐下，可为公司的技术选型提供参考。
采⽤MPP架构的OLAP引擎分为两类，⼀类是⾃⾝不存储数据，只负责计算的引擎；⼀类是⾃⾝既存储数据，也负责计算的引擎。
1）只负责计算，不负责存储的引擎
1. Impala
Apache Impala是采⽤MPP架构的查询引擎，本⾝不存储任何数据，直接使⽤内存进⾏计算，兼顾数据仓库，具有实时，批处理，多并发等优点。
提供了类SQL（类Hsql）语法，在多⽤户场景下也能拥有较⾼的响应速度和吞吐量。它是由Java和C++实现的，Java提供的查询交互的接⼝和实现，C++实现了查询引擎部分。
Impala⽀持共享Hive Metastore，但没有再使⽤缓慢的 Hive+MapReduce 批处理，⽽是通过使⽤与商⽤并⾏关系数据库中类似的分布式查询引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成），可以直接从 HDFS 或 HBase 中⽤ SELECT、JOIN 和统计函数查询数据，从⽽⼤⼤降低了延迟。
Impala经常搭配存储引擎Kudu⼀起提供服务，这么做最⼤的优势是查询⽐较快，并且⽀持数据的Update和Delete。
2. Presto
Presto是⼀个分布式的采⽤MPP架构的查询引擎，本⾝并不存储数据，但是可以接⼊多种数据源，并且⽀持跨数据源的级联查询。Presto是⼀个OLAP的⼯具，擅长对海量数据进⾏复杂的分析；但是对于OLTP场景，并不是Presto所擅长，所以不要把Presto当做数据库来使⽤。Presto是⼀个低延迟⾼并发的内存计算引擎。需要从其他数据源获取数据来进⾏运算分析，它可以连接多种数据源，包括Hive、
RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。
2）既负责计算，⼜负责存储的引擎
1. ClickHouse
ClickHouse是近年来备受关注的开源列式数据库，主要⽤于数据分析（OLAP）领域。
它⾃包含了存储和计算能⼒，完全⾃主实现了⾼可⽤，⽽且⽀持完整的SQL语法包括JOIN等，技术上有着明显优势。相⽐于hadoop体系，以数据库的⽅式来做⼤数据处理更加简单易⽤，学习成本低且灵活度⾼。当前社区仍旧在迅猛发展中，并且在国内社区也⾮常⽕热，各个⼤⼚纷纷跟进⼤规模使⽤。
ClickHouse在计算层做了⾮常细致的⼯作，竭尽所能榨⼲硬件能⼒，提升查询速度。它实现了单机多核并⾏、分布式计算、向量化执⾏与SIMD指令、代码⽣成等多种重要技术。
ClickHouse从OLAP场景需求出发，定制开发了⼀套全新的⾼效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。
2. Doris
Doris是百度主导的，根据Google Mesa论⽂和Impala项⽬改写的⼀个⼤数据分析引擎，是⼀个海量分布式 KV 存储系统，其设计⽬标是⽀持中等规模⾼可⽤可伸缩的 KV 存储集。
Doris可以实现海量存储，线性伸缩、平滑扩容，⾃动容错、故障转移，⾼并发，且运维成本低。部署规模，建议部署4-100+台服务器。Doris3 的主要架构： DT（Data Transfer）负责数据导⼊、DS（Data S
eacher）模块负责数据查询、DM（Data Master）模块负责集元数据管理，数据则存储在 Armor 分布式 Key-Value 引擎中。Doris3 依赖 ZooKeeper 存储元数据，从⽽其他模块依赖 ZooKeeper 做到了⽆状态，进⽽整个系统能够做到⽆故障单点。
3. Druid
Druid是⼀个开源、分布式、⾯向列式存储的实时分析数据存储系统。
Druid的关键特性如下：
亚秒级的OLAP查询分析：采⽤了列式存储、倒排索引、位图索引等关键技术；
在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作；
实时流数据分析：Druid提供了实时流数据分析，以及⾼效实时写⼊；
实时数据在亚秒级内的可视化；
丰富的数据分析功能：Druid提供了友好的可视化界⾯；
SQL查询语⾔；
⾼可⽤性与⾼可拓展性：
Druid⼯作节点功能单⼀，不相互依赖；
Druid集在管理、容错、灾备、扩容都很容易；
4. TiDB
TiDB 是 PingCAP 公司⾃主设计、研发的开源分布式关系型数据库，是⼀款同时⽀持OLTP与OLAP的融合型分布式数据库产品。
TiDB 兼容 MySQL 5.7 协议和 MySQL ⽣态等重要特性。⽬标是为⽤户提供⼀站式 OLTP 、OLAP 、HTAP 解决⽅案。TiDB 适合⾼可⽤、强⼀致要求较⾼、数据规模较⼤等各种应⽤场景。
5. Greenplum
Greenplum 是在开源的 PostgreSQL 的基础上采⽤了MPP架构的性能⾮常强⼤的关系型分布式数据库。为了兼容Hadoop⽣态，⼜推出了HAWQ，分析引擎保留了Greenplum的⾼性能引擎，下层存储不再采⽤本地硬盘⽽改⽤HDFS，规避本地硬盘可靠性差的问题，同时融⼊Hadoop⽣态。
3）常⽤的引擎对⽐
⼀张图总结下常⽤的OLAP引擎对⽐：