![cover](https://img-blog.csdnimg.cn/img_convert/f016401898cc4c2e9d9c2c0b29a69d0b.png)
MPP 还是主流架构吗
在此声明,吞吐量是在一个固定的时间区间内(时间足够长以产生一个代表性的结果),执行的相同种类的查询任务的数量。比如说,4个节点的集群和400个节点的集群将支持同一级别的并发度,而且他们性能下降的点基本上是同样。如果一个节点总是执行的慢于集群中其他的节点,整个集群的性能就会受限于这个故障节点的执行速度(所谓木桶的短板效应),无论集群有多少节点,都不会有所提高。事实上,在一个确定的量级,你的MPP系统
MPP 架构:
MPP 架构的产品:
-
Impala
-
ClickHouse
-
Druid
-
Doris
很多 OLAP 引擎都采用了 MPP 架构
批处理系统 - 使用场景分钟级、小时级以上的任务,目前很多大型互联网公司都大规模运行这样的系统,稳定可靠,低成本。
MPP系统 - 使用场景秒级、毫秒级以下的任务,主要服务于即席查询场景,对外提供各种数据查询和可视化服务。
MPP 架构针对问题:
MPP解决方案的最原始想法就是消除共享资源。每个执行器有单独的CPU,内存和硬盘资源。一个执行器无法直接访问另一个执行器上的资源,除非通过网络上的受控的数据交换。这种资源独立的概念,对于MPP架构来说很完美的解决了可扩展性的问题。
MPP的第二个主要概念就是并行。每个执行器运行着完全一致的数据处理逻辑,使用着本地存储上的私有数据块。在不同的执行阶段中间有一些同步点(我的理解:了解Java Gc机制的,可以对比GC中stop-the-world,在这个同步点,所有执行器处于等待状态),这些同步点通常被用于进行数据交换(像Spark和MapReduce中的shuffle阶段)。这里有一个经典的MPP查询时间线的例子: 每个垂直的虚线是一个同步点。例如:同步阶段要求在集群中”shuffle”数据以用于join和聚合(aggregations)操作,因此同步阶段可能执行一些数据聚合,表join,数据排序的操作,而每个执行器执行剩下的计算任务。
每个节点内的 CPU 不能访问另一个节点的内存,节点之间的信息交互是通过节点互联网络实现的,这个过程称为数据重分配。
NUMA 架构和 MPP 架构很多时候会被搞混,其实区别还是比较明显的。
首先是节点互联机制不同,NUMA 的节点互联是在同一台物理服务器内部实现的,MPP 的节点互联是在不同的 SMP 服务器外部通过 I/O 实现的。
其次是内存访问机制不同,在 NUMA 服务器内部,任何一个 CPU 都可以访问整个系统的内存,但异地内存访问的性能远远低于本地内存访问,因此,在开发应用程序时应该尽量避免异地内存访问。而在 MPP 服务器中,每个节点只访问本地内存,不存在异地内存访问问题。
MPP 架构的优势:
-
任务并行执行;
-
数据分布式存储(本地化);
-
分布式计算;
-
横向扩展,支持集群节点的扩容;
-
Shared Nothing(完全无共享)架构。
MPP的设计缺陷:
所有的MPP解决方案来说都有一个主要的问题——短板效应。如果一个节点总是执行的慢于集群中其他的节点,整个集群的性能就会受限于这个故障节点的执行速度(所谓木桶的短板效应),无论集群有多少节点,都不会有所提高。这里有一个例子展示了故障节点(下图中的Executor 7)是如何降低集群的执行速度的。
大多数情况下,除了Executor 7 其他的所有执行器都是空闲状态。这是因为他们都在等待Executor 7执行完成后才能执行同步过程,这也是我们的问题的根本。比如,当MPP系统中某个节点的RAID由于磁盘问题导致的性能很慢,或者硬件或者系统问题带来的CPU性能问题等等,都会产生这样的问题。所有的MPP系统都面临这样的问题。
如果你看一下Google的磁盘错误率统计报告,你就能发现观察到的AFR(annualized failure rate,年度故障率)在最好情况下,磁盘在刚开始使用的3个月内有百分之二十会发生故障。
如果一个集群有1000个磁盘,一年中将会有20个出现故障或者说每两周会有一个故障发生。如果有2000个磁盘,你将每周都会有故障发生,如果有4000个,将每周会有两次错误发生。两年的使用之后,你将把这个数字乘以4,也就是说,一个1000个磁盘的集群每周会有两次故障发生。
事实上,在一个确定的量级,你的MPP系统将总会有一个节点的磁盘队列出现问题,这将导致该节点的性能降低,从而像上面所说的那样限制整个集群的性能。这也是为什么在这个世界上没有一个MPP集群是超过50个节点服务器的。
MPP和批处理方案如MapReduce之间有一个更重要的不同就是并发度。并发度就是同一时刻可以高效运行的查询数。MPP是完美对称的,当查询运行的时候,集群中每个节点并发的执行同一个任务。这也就意味着MPP集群的并发度和集群中节点的数量是完全没有关系的。比如说,4个节点的集群和400个节点的集群将支持同一级别的并发度,而且他们性能下降的点基本上是同样。下面是一个例子。
16个并行查询会话产生了整个集群最大的吞吐量。如果你将会话数提高到20个以上的时候,吞吐量将慢慢下降到70%甚至更低。在此声明,吞吐量是在一个固定的时间区间内(时间足够长以产生一个代表性的结果),执行的相同种类的查询任务的数量。Yahoo团队调查Impala并发度限制时产生了一个相似的测试结果。Impala是一个基于Hadoop的MPP引擎。因此从根本上来说,较低的并发度是MPP方案必须承担的以提供它的低查询延迟和高数据处理速度。
MPP 架构的 OLAP 引擎
采用 MPP 架构的 OLAP 引擎分为两类,一类是自身不存储数据,只负责计算的引擎;一类是自身既存储数据,也负责计算的引擎。
只计算不存储数据:
-
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。
-
Presto
Presto 是一个分布式的采用 MPP 架构的查询引擎,本身并不存储数据,但是可以接入多种数据源,并且支持跨数据源的级联查询。Presto 是一个 OLAP 的工具,擅长对海量数据进行复杂的分析;但是对于 OLTP 场景,并不是 Presto 所擅长,所以不要把 Presto 当做数据库来使用。
Presto 是一个低延迟高并发的内存计算引擎。需要从其他数据源获取数据来进行运算分析,它可以连接多种数据源,包括 Hive、RDBMS(Mysql、Oracle、Tidb 等)、Kafka、MongoDB、Redis 等。
计算 & 存储数据:
-
ClickHouse
ClickHouse 是近年来备受关注的开源列式数据库,主要用于数据分析(OLAP)领域。
它自包含了存储和计算能力,完全自主实现了高可用,而且支持完整的 SQL 语法包括 JOIN 等,技术上有着明显优势。相比于 hadoop 体系,以数据库的方式来做大数据处理更加简单易用,学习成本低且灵活度高。当前社区仍旧在迅猛发展中,并且在国内社区也非常火热,各个大厂纷纷跟进大规模使用。
ClickHouse 在计算层做了非常细致的工作,竭尽所能榨干硬件能力,提升查询速度。它实现了单机多核并行、分布式计算、向量化执行与 SIMD 指令、代码生成等多种重要技术。
ClickHouse 从 OLAP 场景需求出发,定制开发了一套全新的高效列式存储引擎,并且实现了数据有序存储、主键索引、稀疏索引、数据 Sharding、数据 Partitioning、TTL、主备复制等丰富功能。以上功能共同为 ClickHouse 极速的分析性能奠定了基础。
-
Doris
Doris 是百度主导的,根据 Google Mesa 论文和 Impala 项目改写的一个大数据分析引擎,是一个海量分布式 KV 存储系统,其设计目标是支持中等规模高可用可伸缩的 KV 存储集群。
Doris 可以实现海量存储,线性伸缩、平滑扩容,自动容错、故障转移,高并发,且运维成本低。部署规模,建议部署 4-100+台服务器。
Doris3 的主要架构: DT(Data Transfer)负责数据导入、DS(Data Seacher)模块负责数据查询、DM(Data Master)模块负责集群元数据管理,数据则存储在 Armor 分布式 Key-Value 引擎中。Doris3 依赖 ZooKeeper 存储元数据,从而其他模块依赖 ZooKeeper 做到了无状态,进而整个系统能够做到无故障单点。
-
Druid
Druid 是一个开源、分布式、面向列式存储的实时分析数据存储系统。
Druid 的关键特性如下:
-
亚秒级的 OLAP 查询分析:采用了列式存储、倒排索引、位图索引等关键技术;
-
在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作;
-
实时流数据分析:Druid 提供了实时流数据分析,以及高效实时写入;
-
实时数据在亚秒级内的可视化;
-
丰富的数据分析功能:Druid 提供了友好的可视化界面;
-
SQL 查询语言;
-
高可用性与高可拓展性:Druid 工作节点功能单一,不相互依赖;Druid 集群在管理、容错、灾备、扩容都很容易;
MPP架构和其他架构数据库的场景对比:
Hadoop和MPP两种技术的特定和适用场景为:
-
Hadoop在处理非结构化和半结构化数据上具备优势,尤其适合海量数据批处理等应用要求。
-
MPP适合替代现有关系数据机构下的大数据处理,具有较高的效率。
MPP适合多维度数据自助分析、数据集市等;Hadoop适合海量数据存储查询、批量数据ETL、非机构化数据分析(日志分析、文本分析)等。
适合场景
-
有上百亿以上离线数据,不更新,结构化数据,需要各种复杂分析的sql语句
-
不需要频繁重复离线计算,不需要大并发量
-
几秒、几十秒立即返回分析结果,即:即席查询。例如sum,count,group by,order
更多推荐
所有评论(0)