Greenplum在运营商领域的HTAP实践

Greenplum中文社区

发布于

353

人观看

#信息技术

Greenplum作为拥有HTAP能力的大数据平台，在各个领域应用广泛，拥有众多商业和开源用户。用户在享受Greenplum带来的性能提升的同时，也或多或少遇到了一些困难。

4月29日，Greenplum将举办今年第二场直播活动。与示说社区合作，本次直播将对某运营商案例进行详细分析，着重介绍客户选型的考虑，测试的过程及生产运维过程中遇到的一些问题及建议，希望能给大家带来一些启发。该案例主要业务为运营商的分析业务，兼有部分TP的需求。

大纲

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

展开查看详情

7 .新版本向HTAP进化过程中的一些优化工作在向HTAP进化过程中，Greenplum内核团队还顺便写了一片论文《Greenplum: A Hybrid Database for Transactional and Analytical Workloads》，该论文入选了2021 西安 SIGMOD，大家可以到网上去寻找正华之前分享的内容，了解更多。老版本上update使用的是表锁，性能较差，通过全局死锁检测技术，降低为行级锁，性能大幅提升。GDD的基本逻辑是收集每个segment锁依赖关系图，在master上重建整个集群的锁依赖关系图，并检测是否有环。 l 全局死锁检测(GDD) 只读事务不需要分布式快照，也不需要2PC；而单节点查询也可以对两阶 l 事务优化段提交进行优化。 l 复制表复制表即每个segment都有表的全部数据，因而不需要网络数据传输，还可使用索引。 l 内核升级 2005年研发之初时其内核版本是PostgreSQL 7； 2017年发布的Greenplum 5之前一直是PostgreSQL 8.2版本；2017年9月发布的Greenplum 5，内核升级到了8.3；当前广泛使用的Greenplum 6，内核升级到9.4 正在研发的Greenplum 7，内核将会升级到12。 Confidential │ ©2021 VMware, Inc. 7

15 .规划与部署 - 整体架构的考虑 l 首先客户是体量巨大的运营商，数据量是可观的，所以三、五台机器只能应急，不能满足长远数据增长的规划，所以机器的数量设置为2+8+4； l 其次，客户是对现有系统进行Oracle替换改造，所以可能有长时间的并行运行要求，选用CDC与FTP是为了保证数据的实时性与双写； l 3节点Kafka集群基本可以保证3个月的增量日志，方便数据冗余和追溯； l FTP服务器充分考虑了高可用的要求， gpload和gpfdist入库均做了冗余。 Confidential │ ©2021 VMware, Inc. 15

16 .规划与部署 - Oracle的现状 l 客户当前Oracle服务器环境是双机RAC，能够，暂时还能满足业务要求，但是由于每天的跑批任务耗费时间巨大，有时到中午跑批任务仍然不能完成； l 经常出现莫名其妙的Oracle卡顿故障，多次调优仍然不能解决； l 经过清理的存量数据仍然达到100TB左右，对存储和备份的要求都很高，每天增量数据当时位于500～800GB，并有递增趋势； l 事实导致已经不得不考虑替代方案。 Confidential │ ©2021 VMware, Inc. 16

17 .规划与部署 - GPDB详细规划 l 集群采用2+8的部署方式，2台Master 采用keepalive做了高可用，提供虚拟 IP对接F5对外提供服务（F5此处可省略），正式上线运行有2年多时间，未发生过一次切换；Master节点的可用性尚能接受； l 网络层面万兆双网卡做了冗余，防止硬件故障； l 8台Segment主机方便后期以4台机器为单位进行扩容，当前8台50TB的存储可满足备份双副本及备份需求，备份机制为选择性备2删1。 Confidential │ ©2021 VMware, Inc. 17

19 .规划与部署 - ETL服务器规划 l ETL服务器基本承担了跟数据有关的所有任务，包括：FTP数据入库、Kafka 数据入库、日常维护工作、监控与调度； l gpload服务器与维护任务服务器互为备份，gpfdist与监控调度服务器互为备份；高可用通过自开发程序实现； l FTP数据文件量巨大，采用gpload入库，入库成功文件自动移动到NAS做备份，失败则保留在本地方便补录； l Kafka数据通过自研程序调度gpfdist实现数据微批入库，支持更新操作。 Confidential │ ©2021 VMware, Inc. 19

21 .选型的考虑 l 考虑到数据量大且增长率高，需要选用分布式架构数据库，支持横向扩容； l 基于当前的业务构建测试模型，测试结果需满足性能3倍于当前Oracle方案的要求；FTP入库及跑批需在工作日上班时间前完成；CDC入库近乎实时； l 主要定位与分析型场景，因为业务偏向大规模跑批；但是需要支持300左右并发，同时提供OLTP处理能力； l 迁移成本尽量低。 Confidential │ ©2021 VMware, Inc. 21

22 .测试内容 - 功能测试 l 存储过程迁移工作量，基本属于平行迁移，不复杂；很多Oracle中的窗口函数在GP中均已支持，例如： ROW_NUMBER() OVER(PARTITION BY xxx ORDER BY length(xxx) asc)；分区表迁移改动量少； l 完整的ACID支持；标准的SQL查询，改动较少； l 支持Kafka入库，支持文本文件入库； l 提供完整的数据生命周期管理软件。 Confidential │ ©2021 VMware, Inc. 22

23 .测试内容 - 性能测试 l 存储过程跑批任务，由10小时缩短到2 小时； l FTP文本文件高速入库，gpload，如上； l CDC数据入库，缩短到10分钟以内； l JMeter并发压测，30个测试SQL并发压到300，平均响应时间在10s以内，大部分响应时间在3s左右，部分稍复杂 SQL拖长平均时间； l 数据迁移采用并行化方式，gpfdist入库效率高，瓶颈基本在Oracle及网络端。 Confidential │ ©2021 VMware, Inc. 23

25 .迁移范围、原则及目标数据迁移范围现有生产环境Oracle数据库数据：101张数据表，筛选后总存储容量约需50TB。数据迁移目标将现有Oracle生产环境存量数据选择性迁入外地数据中心GP数据库中；从Kafka和FTP分别接入增量数据；并校验数据一致性。数据迁移原则不改动现有业务平台Oracle数据库的配置和数据；数据迁移在非业务时间进行，避免对生产环境业务及城市间现有业务传输造成太大影响。 Confidential │ ©2021 VMware, Inc. 25

28 .数据校验逻辑 - MD5+数据比对 l 首先进行MD5比对，如果一致记录结果； l MD5不一致进行数据比对，从远端拉取数据到GP端，利用并行的优势将差异数据筛选出来并修复； l 清理临时表和数据； l FTP数据比对因为FTP有T+1的时间差，所以较好控制； l Kafka数据需要选取合适的时间点，例如周末，通过暂停Oracle备份库的机制进行多次比对。 Confidential │ ©2021 VMware, Inc. 28

0点赞

0收藏