直播内容精华：Greenplum在运营商领域的HTAP实践

最新推荐文章于 2024-07-30 17:09:59 发布

Greenplum中文社区

最新推荐文章于 2024-07-30 17:09:59 发布

阅读量225

点赞数

文章标签：数据库 postgresql 运维 big data devops

本文链接：https://blog.csdn.net/gp_community/article/details/125082181

版权

4月29日，和示说社区合作，我们举办了今年的第二场线上活动。在活动中，社区专家苑泽福（阿福）为大家详细介绍了Greenplum在运营商领域的HTAP实践，活动获得了大家的一致好评。现在让我们通过这篇文章来回顾一下活动的精彩内容。

相关视频已上传B站Greenplum中文社区频道，PPT已上传至社区中文网站cn.greenplum.org/download。欢迎自行获取。

今天要跟大家分享的是Greenplum在运营商领域的HTAP实践。在今天要分享的案例中，该运营商在选型时期因为较为看重HTAP特性，因此最终选择了Greenplum这个HTAP大数据平台。 今天的内容将被分为五个部分来进行介绍，希望能为大家在Greenplum实践上带来一些启发。

Greenplum HTAP架构特点介绍
项目整体规划及部署架构
客户选型及测试内容分享
新老系统迁移及数据校验
生产运维经验分享

众所周知，Greenplum是一款开源MPP数据库，自2015年开源至今，拥有了众多开源和商业用户来为自己的生产提供业务支撑。Greenplum基于PostgreSQL，但针对大数据场景和用户对性能的极致追求做了大量特性和优化。近年来，Greenplum以敏捷的方式快速升级PostgreSQL内核，持续吸收上游的新功能、优化和增强，大大提升了Greenplum的总体能力。

在Greenplum早期，OLTP能力较弱，很多用户会选择使用PostgreSQL和Greenplum一起来支撑HTAP需求。随着PostgreSQL和Greenplum的不断演进，有些客户由于数据量较小，PostgreSQL 的单机能力完全可以承担业务运行，客户会选择使用PostgreSQL做一个基础的HTAP数据库。随着数据量的增大，很多客户会迁移到Greenplum，来满足其更大的数据量分析需求。因此在HTAP数据库的选择时，我个人的建议是推荐大家根据业务来选择，如果数据量不大，有高并发查询，也有分析型处理的话，可以使用PostgreSQL。但数据量上规模后，PostgreSQL其本身的分析性能，单机的处理能力并不能满足大数据量的并行分析需求，此时Greenplum就成为了一个更好的选择。

2021年，数据库顶级国际学术会议SIGMOD在西安举行，Greenplum内核团队的论文《Greenplum：A Hybrid Database for Transactional and Analytical Workloads》成功入选，被大会收录，具体的内容欢迎通过链接来了解。

Greenplum在向HTAP进化的过程中，做了哪些工作呢？我为大家总结了四个点：

// 内核升级

正如前文提到，Greenplum一直在持续不断地优化和升级内核代码。Greenplum 2003年研发之初，其内核版本是PostgreSQL 7；2017年发布的Greenplum 5之前一直是PostgreSQL 8.2版本；2017年9月发布的Greenplum 5，内核升级到了8.3；当前广泛使用的Greenplum 6，内核升级到9.4；正在研发的Greenplum 7，内核将会升级到12。

// 全局死锁检测（GDD）

该功能已开源，大家可以在网上获取到相关信息。Greenplum老版本上Update使用的是表锁，性能较差，如果要做Update需要把整个表锁定。从6版本开始，Greenplum通过全局死锁检测技术，堆表上表锁降低为行级锁，性能大幅提升。GDD的基本逻辑是收集每个segment锁依赖关系图，在master上重建整个集群的锁依赖关系图，并检测是否有环，从而避免死锁问题。因此，我们如果使用Greenplum做TP的操作时，更多的选型可以多创建一些堆表，这样增删改查的性能会比AO表更好一些。

// 事务优化

Greenplum 从6版本后，只读事务不需要分布式快照，也不需要2PC；而单节点查询也可以对两阶段提交进行优化。

// 复制表

Greenplum 在6版本增加了复制表。复制表即每个segment都有表的全部数据，因而不需要网络数据传输，还可以使用索引。通过复制表，用户可以将较小的数据在每一个计算实例上都放一份，在查询过程中，如果在某一份实例上定位到数据，就不再需要进行分布式数据查询。此外，如果做一些新型模型的Join查询，就可以在本地进行，而不需要做数据shuffle相关的工作。
这四个优化使Greenplum在TP性能上有了较大的提高。还有一些其他的特性，大家都可以从网上获取到相关资料，这里将不做赘述。
关于资源组的管理，在Greenplum 4版本和5版本中使用的是Resource Queue，对整个资源的控制力度不够强，如今很多主流数据库是采用Linux底层的cgroup来控制资源，Greenplum在6版本在资源组上也进行了增强，通过cgroup来控制。通过下面对比图，大家也可以看到，现在Greenplum对资源的控制力度，包括对一些特性的支持，都要比之前的资源队列好很多。大家在生产上可以追踪事件，看看如何更好的把resource group特性利用起来。