Greenplum 6.0：从 OLAP 到 HTAP

产品更新

2019-12-12

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等。

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