公司活动

瀚高王亮:解读《PB级数据仓库和开源Greenplum数据库》

2018 年 04 月 18 日

Petabyte Scale Data Warehousing with Open Source Greenplum Database
PB级数据仓库和开源Greenplum数据库

摘要:
       《PB级数据仓库和开源Greenplum数据库》是来自Pivotal Software公司的Marshall Presser的主题培训,介绍了GreenPlum系统一些技术方案。Marshall Presser 是Pivotal的数据实验室工程师,帮助用户来解决使用GreenPlum做大数据分析时候遇到的一些问题。
       本文是瀚高软件工程师王亮对此培训的总结及解读。
       GreenPlum是一款用于处理大量关系型数据的数据库系统,他跟那些单机系统最大的不同就是,他会运行在一个拥有大量设备的大型cluster环境中。虽然当今也有其他的类似的大数据处理系统,但是GreenPlum却是唯一一个成功应用于各种企业中的关系型数据类型开源软件。


       这是GreenPlum的master节点的一个处理流程,可以看出来这个过程就是PostgreSQL的执行处理模块:
       parser:把客户的SQL输入转化成计算机能够识别的表达式
       Query Optimizer:计算出数种可能的执行方案,选择一个最可行的出来(最可行的方案一般就是成本最低的方案),实际上这是一个非常困难的任务,所以对于此模块,它需要知道整个cluster中的所有节点工作状态,比如节点的网络状况,存储状况,处理能力,当前繁忙程度等,通过这些细节的数据才能更加准确的找到一个最合适的方案。实际上这里的Query Optimizer跟单节点的工作方式已经有了很大的不同,他将会是一个更复杂的,更加强大的控制中心。

      当处理优化完成之后,会把请求分发到最优方案中涉及到的segment节点,这里实际上每一个segment节点都是一个独立PostgreSQL节点,负责存储整合整个cluster数据中的一部分。master把优化之后的查询任务分发给需要参与的segment节点,然后并行的去执行任务,最后把结果返回给master节点,master节点在统一的对所有结果进行汇总整理。这里说明的是,GreenPlum最大的架构两点就是他的MPP(Massively Parallel Processing)结构,此结构中最为核心的就是master节点对所有segment节点的管理,能够产生能最大化够并行处理的查询方案,也就是说多大程度的并行处理方案,就多大程度的能够利用分布式的segment节点,从而提供更高的性能。
      如果你有阅读过google的关于MapReduce和DFS相关论文的话,对这个架构应该会非常的熟悉。

      作为一个能够支持ACID的cluster数据库系统,必须要拥有一个强大的全局事务系统。GreenPlum同样使用了MVCC来做为并行事务处理的机制, 他拥有一个全局的统一的事务id,全局事务管理的逻辑在master中执行,虽然MVCC的工作原理类似于单节点的PostgreSQL,但是MVCC中涉及到的一些概念已经得到了扩展,比如snapshot,已经不单纯的指本机的在执行的TransactionID集合,而是整个cluster的TransactionID集合。当然由于每一个Segment节点还是一个PostgreSQL,所以他还是会有自己的commit和日志操作。也许就是因为全局事务管理的复杂性,和各自segment还拥有自己的部分重复处理,会导致一部分的性能影响。

      作为一个cluster级别的系统,高可用肯定是一个再重要不过的话题了。为了提升系统的高可用级别,使用了基本的master节点镜像系统,会有一个独立的用于同步的进程来同步主节点的active主机和他的standby主机。实际上这个同步的过程的机制使用了PostgreSQL 的wal日志replication的机制。每一个segment节点也会有一个相应的镜像节点,如果一个节点宕机,会快的切换到他的备用节点。虽然这里没有讲述如何做到快速切换,但是我想肯定少不了一些辅助的监控和切换goon工具,还有就是配置Virtual IP的机制。

      Greenplum支持多种类型的存储方式,行存储,列存储,第三方的分布式文件系统。关于这几种文件系统的选择,可以同样采用存储模式的通用的选择策略,比如OLTP选择行存储,OLAP选择列存储等。当然还要根据自己业务的情况来选择和使用。
关于更多的关于Greenplum的列存储的技术内容,请查看下面链接:
https://wiki.hsr.ch/Datenbanken/files/SEM_DBS_HS1516_Column_Stores_Greenplum_Egloff_Paper.pdf

      在添加记录的时候,会引入一个关键的技术,就是distribution key,这个key就是我们用来把数据分配到不同的segment上面的依据。在创建table 的时候通过参数选项来制定distribution key的使用方式。下图就是一个根据distribution key来分配节点的数据结构图:

Greenplum分片处理机制

       事实上,master节点在对客户发过来的请求进行分片的时候,会给每一个分片至少安排一个相应的处理segment节点,当然也会存在一个处理分片也需要多个主机一起协同完成的情况,这里Greenplum叫他gang,需要协同的segment会通过segment之间的内部网络进行通信,这里需要注意的是,虽然每一个请求的分片处理都是并行的,但是每一个分片中的涉及到多个机器协作的情况,实际上每一个分段的工作都是串行处理的,即第一个处理完成之后,把得到的结果发送给下一个处理分段,直到处理完所有的分片工作。

< 返回活动

新闻推荐

2020/03/06

支援湖北,我们共同倡议!

活动推荐