大数据 | GreenPlum--面向大数据的并行数据库系统

Posted on

大数据 | GreenPlum–面向大数据的并行数据库系统

亲爱的读者朋友大家晚上好，上次简单介绍了数据库中的并行技术，这次我们来介绍一种面向大数据的并行数据库系统 GreenPlum。在这篇文章中，小编会先带大家看看 GreenPlum 的设计初衷，给大家解析一下 GreenPlum 至关重要的 GreenPlum 架构，然后分析最重要的部分：数据，其次是重中之重：GreenPlum 的并行方案，紧接着是也很重要的 GreenPlum 组件，最后是不可或缺的 GreenPlum 的sql执行流程的串通、梳理。

image-20210419122430910

引入

GreenPlum设计的初衷

GreenPlum为大数据存储、计算、分析而设计；支持$ACID$四性、分布式事务；分布式数据库可以进行线性扩展、支持上百物理节点；集成了众多分析平台：$BI$、文本、图、$GIS$、混合负载等；支持标准 $SQL$ 数据库：$ANSI$ $SQL$ $2008$ 标准、$OLAP$、 $JDBC/ODBC$；是一个企业级的数据库：全球大客户数千生产集群；其开源数据库($greenplum.org$)，基于 $PostgreSQL$ 开源百万行源代码，超过$10$年的全球研发投入！！！一起来看看吧～

GreenPlum架构

GreenPlum采用主从架构，可以抽象为三个部分：$Master,Segment\ \And\ InterConnect$。这是一种MPP（大规模并行处理Massively Parallel Processing）架构（也被称为$shared\ nothing$架构），指有两个或者更多个处理器协同执行一个操作的系统，每一个处理器都有其自己的内存、操作系统和磁盘。Greenplum通过将数据和处理负载分布在多个服务器或者主机上来存储和处理大量的数据。

主从架构

image-20210419104520744
  • 主节点（$Master$）负责协调整个集群
  • 一个数据节点（从节点$Segment$）可以配置多个节点实例($Segment Instances$)
  • 节点实例并行处理查询($SQL$)
  • 数据节点有自己的$CPU$、磁盘和内存($Share nothing$)
  • 高速$Interconnect$处理持续数据流($Pipelining$)

MPP无共享拓扑架构

$Master$是全局系统目录的所在地。全局系统目录是一组包含了有关 Greenplum 数据库系统本身的元数据的系统表。 $Master$上不包含任何用户数据，数据只存在于$Segment$之上。 $Master$会认证客户端连接、处理到来的$SQL$命令、在$Segment$之间分布工作负载、协调每一个$Segment$返回的结果以及把最终结果呈现给客户端程序。Greenplum数据库的$Segment$实例是独立的$PostgreSQL$数据库，每一个都存储了数据的一部分并且执行查询处理的主要部分。其对应关系如下所示：

image-20210419110043471image-20210419110142642

GreenPlum数据

数据分布是并行化的根基，最重要的策略和目标是均匀分布数据到各个数据节点。可以采用哈希$Distribution$：数据均匀的分布到各个数据节点；也可以采用范围分区: 数据节点内部，根据多种规则分区，降低扫描量。为了更加优化扫描量，Greenplum 采用了多级分区存储和多态存储。

多级分区存储

image-20210419111118952

多态存储 根据数据温度选择最佳存储方式

image-20210419111238934

行存储：访问多行时速度快，支持高效更新和删除，AO主要为插入而优化

列存储：列存储更适合压缩，查询列子集时速度快，不同列可以使用不同压缩方式: $gzip (1-9)$, $quicklz$, $delta$, $RLE$

外部表：历史数据和不常访问的数据存储在 $HDFS$ 或者其他外部系统中，无缝查询所有数据，支持$Text$, $CSV$, $Binary$, $Avro$, $Parquet$ 等多种格式

GreenPlum并行计划

从用户逻辑一点一点靠近底层：生成并行查询计划 $\boldsymbol{\rightarrow}$ 执行并行计划 $\boldsymbol{\rightarrow}$ 大规模并行数据加载。

生成并行查询计划

举个例子吧：

1
2
3
SELECT customer,amount FROM sales
JOIN customer USING (cust_id)
WHERE date=2008

相应的查询计划如图所示：

image-20210419112053208

执行并行计划

针对上述例子，其并行执行计划如图所示，由主节点将任务下发给数据节点，数据节点完成提取数据后进行数据通信，通信完毕进行本地连接处理，之后返回由主节点进行合并。

image-20210419112233118

大规模并行数据加载

高速数据导入和导出：主节点不是瓶颈，$10+\ TB$/小时/$Rack$，线性扩展

低延迟：加载后立刻可用，不需要中间存储，不需要额外数据处理

导入/导出：文件系统，任意 $ETL$ 产品，$Hadoop$ 发行版

image-20210419112743335

GreenPlum组件

GreenPlum主要有以下这些组件，我们挨个来看看～

image-20210419113039849

解析器

主节点接受客户连接， 处理请求，执行认证，完成之后，解析器 执行词法分 析、语法分析并生成解析树。

优化器

处理解析树，生成查询计划，查询计划描述了如何执行查询。

调度器&执行器

做两件事情：一个是发送查询计划给各个$Segments$，另一个是分配处理查询需要的集群资源，收集并返回结果给客户端。

系统表

存储和管理数据库、 表、字段的元数据，每个节点保存一个拷贝。

分布式事务

主节点上的分布式事务管理器协调 $Segment$上的提交和回滚操作，$Segments$有自己的事务日志，确定何时提交或回滚自己的事务。

GreenPlum SQL执行流程

state visualize
0. the system at rest image-20210419113936697
1. client connects via the entry postmaster image-20210419114056130
2. entry postmaster forks a new backend – QD image-20210419114156267
3. QD connects to the segments via the segment postmasters image-20210419114318840
4. segment postmasters fork initial gang of QEs image-20210419114427572
5. client submits a query to the QD image-20210419114521620
6. QD plans query and submit plans to QEs image-20210419114613762
7. QD and QEs setup interconnect routes according to plans image-20210419114725550
8. QD and QEs execute their slices sending tuples up the slice tree image-20210419114832700
9. QEs return status to QD image-20210419114915309
10. QD returns result set and status to the client image-20210419115001113

总结

下次是开始就是Nosql和Newsql了，敬请期待～:smile: