Greenplum 6.0: 从 OLAP 到 HTAP

Greenplum 创立于2003年,第一款产品发布于2005年,当时产品名字叫Bizgres,2008年改名为 Greenplum。2015年10月份正式以 Apache 协议开源。经过16年的发展,Greenplum 成为全球知名的大规模并行处理(MPP)无共享架构(Shared Nothing)数据库。Greenplum 传统的业务场景为数据仓库、OLAP(OnLine Analytical Processing)和即席(ad-hoc)查询。Gartner 2019年评测报告中 Greenplum 在这一领域位于 Teradata 和 Oracle 之后,世界排名第三。

HTAP或者Translytical

HTAP 一词最早由 Gartner 于2014年左右提出。Forrester 也提出了类似的概念,称为 Translytical 。其主要思想是避免传统OLTP和OLAP分离的架构,而采用混合 OLTP + OLAP 的架构。

传统的架构如下图所示。OLTP 数据库支撑事务业务,OLAP 数据库支撑分析业务。中间通过 ETL 实现数据同步。这种架构有几个痛点:

  • 复杂:ETL 过程本身比较复杂,需要专门的产品和设置以满足不同场景的需求。
  • 延迟:ETL 的延迟通常达数小时、数天甚至数周。数据的价值通常随着数据年龄的增长而降低,错过了数据早期最有价值的时间窗口。
  • 代价高:ETL 产品本身代价不菲,两类数据库的采购费用通常比一款数据库高。此外两类数据库加上 ETL 产品的管理运维技术通常不同,需要更多技术人员,人员成本高。
  • 知识共享难:OLTP产品、OLAP产品和ETL产品之间积累的经验和知识难以分享,形成统一知识库

https://www.gartner.com/imagesrv/media-products/pdf/Kx/KX-1-3CZ44RH.pdf

HTAP架构可以很好的解决上面问题,如下图所示。当然作为一个较新的技术,HTAP也有其风险,譬如产品成熟度、资源隔离等。

Greenplum HTAP之路

作为一款主打 OLAP 和数据分析的数据库,过去十几年来 Greenplum 团队一直以分析型查询作为主要优化对象。近年来随着 PostgreSQL 内核的升级(Greenplum 6.0 搭载 PostgreSQL 9.4 内核,Master 分支目前是 PostgreSQL 9.6内核)和客户对 OLTP 型查询需求的提升, 6.0 开发周期中投入部分精力,对OLTP型查询进行了优化。总体看起来效果非常不错。这儿有一个完整的带有评测环境(基于GCP,可验证)和步骤的评测结果,感兴趣者可以参考。

摘录主要结果如下:

  • TPCB:             4,500 tps
  • SELECT:         80,000 tps
  • INSERT:          18,000 tps
  • Update:           7,000 tps

这个性能可以满足很多 OLTP 的业务场景。当然 Greenplum HTAP 的现阶段目标不是处理极致的 OLTP 场景,而是希望达到单个 PostgreSQL 的能力,根据该评测,目前 Greenplum 6.0 和单节点的 PostgreSQL 的OLTP能力在同一个数量级上。

以下技术对 OLTP 性能提升起到关键作用:

  • 全局死锁检测(GDD、Global deadlockdetector):这项技术对Greenplum 6.0性能提升,特别是Update和Delete至关重要。锁是数据库中实现并发控制的重要技术,随之而来的死锁处理。有两种主要方式处理死锁:1)死锁检测;2)死锁预防。PostgreSQL 采用的是死锁检测机制。这种机制在单机上比较容易实现,也比较成熟,然而在分布式系统里面挑战较大。Greenplum 团队创新性的解决了这个问题,并准备申请美国专利,后来秉承开源精神主动放弃专利申请(申请通过了公司内部律师预审,团队成员拿到了专利奖金,但是没有提交美国专利局)。对内部实现技术感兴趣的朋友可以移步参阅代码中的README.md
  • 并发控制优化:除了全局死锁检测,Greenplum 还引入了多项其他并发控制优化方法,这些优化对 SELECT 和 INSERT 提升比较大。一个优化有关 procarray 锁,有关如何发现瓶颈并解决的细节,请移步参考这个文章。另一个优化和事务有关,大多数OLTP查询带有主键或者分布键,这种查询不需要两阶段提交(2PC)。
  • 复制表:Greenplum 6引入复制表,每个节点有数据的完整拷贝,比较适合数据量比较小的表。复制表可以避免连接(JOIN)时的数据移动,并且支持索引访问方法,可以有效提高某些场景的性能。
  • 多模存储:Greenplum支持多模存储,支持Heap表、AO表(Append Optimized)、AOCO表(列存)和外部表。不同场景可以采用不同的存储方式。对于 OLTP 型查询,heap表最合适。
  • 优化器:Greenplum 有两个优化器,一个称为ORCA,专为复杂查询优化而设计;一个是 PostgreSQL 自带的优化器,通常称为 planner,适合 OLTP 型查询。
  • 内核升级:PostgreSQL 内核的升级总体上对 OLTP 性能提升也很有裨益。

Greenplum HTAP应用场景

Greenplum 过去每次从大版本发布到新客户(注意是客户不是用户)采用通常需要一年以上的时间。然而 Greenplum 6.0 刚刚发布,就已经有多个客户开始使用,主要原因是 Greenplum 6.0 对 HTAP 的支持。

下面介绍下 Greenplum HTAP 和混合负载的两个典型场景。

插入密集型/INSERT 密集型 + 在线分析

大量准实时(秒级、亚秒级)插入/INSERT,少量 UPDATE,大量在线分析
这种场景在 Greenplum 6.0 发布之前已经有很多客户采用,采用的主要技术是 gpfdist 或者 Greenplum-kafka 连接器。业务数据流入 Kafka,通过 Kafka 连接器或者 gpfdist 以准实时的方式加载到 Greenplum 中。下图展示了Greenplum Kafka 连接器的内部架构图,充分利用了 Greenplum 的并行架构,数据直接加载入 segment 节点,master 节点只起控制作用。

某国际知名的证券交易所采用了这个架构,如下表所示,该所实现了秒级300万条记录的准实时数据导入,平均延迟170ms。且加载时各种资源利用率低于15%,与并发执行的在线分析业务互不影响。

UPDATE/INSERT 密集型 + 在线分析

大量 OLTP 查询,包括 INSERT、UPDATE 和 DELETE,大量在线分析,以分析业务为主。Greenplum 6.0 可以有效处理这种场景。

目前已经有多个客户生产环境中采用这种架构,还有数十客户试用中。其中有知名大型跨国银行、大型保险集团、在线资产交易平台、全球知名汽车制造商、数字广告服务提供商,还有大型保健健康服务提供商等。

如前面所述,这种架构有着明显的优势。我们再通过一组图片对比来感受下这种简洁的优雅。

原来架构:

总结

相对于传统OLTP和OLAP分离的架构,HTAP 优势非常明显,Greenplum 6.0 刚刚发布三个月,已经有多个大型客户采用,这对企业级产品而言非常难得。

现阶段 Greenplum 支持OLTP的目标是达到单节点TP数据库同一能力量级,譬如 PostgreSQL、Oracle等。

从目前测试来看基本上达到了这一目标。未来还有很大改进空间,有关更多信息敬请关注本社区最新资讯。

本文作者


分享本博文:

2020 Greenplum峰会

点击了解更多信息

《Data Warehousing with Greenplum》

Greenplum官方书籍《Data Warehousing with Greenplum》。阅读它,以了解如何充分利用Greenplum的功能。

关注微信公众号

Greenplum中文社区

Greenplum官方微信群

扫码加入我们的技术讨论,请备注“网站”