Greenplum 创立于2003年（https://en.wikipedia.org/wiki/Greenplum），第一款产品发布于2005年，当时产品名字叫Bizgres，2008年改名为 Greenplum。2015年10月份正式以 Apache 协议开源（https://github.com/greenplum-db/gpdb)。经过16年的发展，Greenplum 成为全球知名的大规模并行处理（MPP）无共享架构（Shared Nothing）数据库。Greenplum 传统的业务场景为数据仓库、OLAP（OnLine Analytical Processing）和即席（ad-hoc）查询。Gartner 2019年评测报告中 Greenplum 在这一领域位于 Teradata 和 Oracle 之后，世界排名第三。
HTAP或者Translytical
HTAP 一词最早由 Gartner 于2014年左右 (https://www.zdnet.com/article/what-is-hybrid-transactionanalytical-processing-htap/)提出。Forrester 也提出了类似的概念，称为 Translytical 。其主要思想是避免传统OLTP和OLAP分离的架构，而采用混合 OLTP + OLAP 的架构。 (https://www.forrester.com/report/Emerging+Technology+Translytical+Databases+Deliver+Analytics+At+The+Speed+Of+Transactions/-/E-RES116487)
传统的架构如下图所示。
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，可验证）和步骤的评测结果（https://greenplum.cn/2019/05/14/greenplum-6-oltp-60x/），感兴趣者可以参考。摘录主要结果如下：
- 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。（https://github.com/greenplum-db/gpdb/blob/master/src/backend/utils/gdd/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%，与并发执行的在线分析业务互不影响。
数据量 | 机器数 | 表个数 | 索引个数 | 并发数 | 插入间隔 | 平均时延 | 最长时延 | 插入速度 |
9.8亿 | 18 | 4 | 12 | 16 | 500ms | 170ms | 1100ms | 300万/s |
UPDATE/INSERT 密集型 + 在线分析
大量 OLTP 查询，包括 INSERT、UPDATE 和 DELETE，大量在线分析，以分析业务为主。Greenplum 6.0 可以有效处理这种场景。
目前已经有多个客户生产环境中采用这种架构，还有数十客户试用中。 其中有知名大型跨国银行、大型保险集团、在线资产交易平台、全球知名汽车制造商、数字广告服务提供商，还有大型保健健康服务提供商等。
如前面所述，这种架构有着明显的优势。我们再通过一组图片对比来感受下这种简洁的优雅。
原来架构：
采用Greenplum 6.0之后的 HTAP 架构：
总结
相对于传统OLTP和OLAP分离的架构，HTAP 优势非常明显，Greenplum 6.0 刚刚发布三个月，已经有多个大型客户采用，这对企业级产品而言非常难得。
