专访周金可：我们更倾向于Greenplum来解决数据倾斜的问题

Posted 2020-08-07 阿里云官方

周金可，就职于听云，维护mysql和GreenPlum的正常运行，以及调研适合听云业务场景的数据库技术方案。

 

听云周金可

 

9月24日，周金可将参加在北京举办的线下活动，并做主题为《GreenPlum在听云大数据实时分析的实践》的分享。值此，他分享了PG、工作上的一些经历和经验。

免费报名链接：http://click.aliyun.com/m/6101/

 

正文：

 

周金可刚参加工作时是做系统运维的，后来慢慢接触了各种数据库，开始对数据库感兴趣，经过一段时间的积累后转向了DBA。

 

“在我加入听云时，恰好是业务快速增长的阶段，后端我们的应用以及数据库经受了比较大的考验。去年大多数时间是在做扩容，我们的MySQL集群由最开始的数台实例扩展到现在的数百台实例。”他经历了听云业务量的爆发式增长。

 

而正是这种增长，让周金可和PG有了亲密接触：“某个模块的单表数据量达百亿级，MySQL Shared方式已经无法保证查询性能，所以又采用了GreenPlum MPP的方案来解决性能问题。”

 

“整个过程中分拆扩容的工作量是比较大的。而且在数据量巨大的情况下，MySQL Shared造成的数据倾斜问题给我们造成了比较大的困扰。目前我们对MySQL的中间件做了一次定制，支持将指定的某个用户的数据路由到一个单独的实例上，然后垂直扩展该实例的配置。但现在我们更倾向于Greenplum的方案，合理的涉及distribution key是可以完全避免数据倾斜的问题。”

 

因此，他本次分享的就是GreenPlum在听云大数据实时分析的实践，内容涉及具体应用场景GreenPlum选型，以及迁移至GreenPlum架构后与原来MySQL架构的性能对比。

 

除此之外，周金可也谈了自己为什么喜欢Golang的编程风格、听云内部的数据库管理平台的经历，以及对上段时间Uber从PG切换为MySQL一事的看法。

 

更为具体的内容，请查看以下完整采访：

 

云栖社区：请介绍下你以及所从事的工作。

 

周金可：我叫周金可，目前就职于听云。听云是一家在APM领域深耕10年的公司。我是在15年初加入听云，有幸经历了听云业务量的爆发式增长。

 

听云后端当前的数据库架构主要是MySQL分布式集群，也有一部分数据是采用GreenPlum的方案。而我们即将发布的CDN Controller产品后端，则采用的是Postgresql+Citus分布式方案。

 

目前主要的工作内容就是维护MySQL和GreenPlum的正常运行，以及调研适合听云业务场景的数据库技术方案。

 

云栖社区：你是怎么走上DBA道路的？目前工作中有哪些亮点？

 

周金可：刚参加工作的时候是做系统运维的，后来慢慢的接触了各种数据库，开始对数据库感兴趣，经过一段时间的积累后转向了DBA。

 

在我加入听云时，恰好是听云的业务快速增长的阶段，后端我们的应用以及数据库经受了比较大的考验，去年大多数时间是在做扩容，我们的MySQL集群由最开始的数台实例扩展到现在的数百台实例。

 

今年我们主要是做了一些优化的工作，比如使用ToKuDB存储引擎替换线上MySQL实例的InnoDB实例，大幅压缩数据并提升性能。将原来放在MySQL上的一部分业务数据迁移到Greenplum上，查询性能提升几百倍。当然这只是在我们的场景中，单节点MySQL跟Greenplum集群的对比，MySQL还是很优秀的DB。

 

云栖社区：你提到，比较喜欢Golang的编程风格，能聊下原因吗？你还使用Golang开发了听云内部的数据库管理平台，请介绍下这个平台，以及开发中一些记忆犹新的事吧。

 

周金可：Golang语法比Python简单，编程风格趋于脚本化但功能比shell强大很多，原生的并发变成模型和跨平台特性让我觉得Golang可以作为日常运维工作中的一把利剑。

 

数据库集群规模比较大，不可能每天对数百节点做人肉巡检，后来接触到了Golang的Web框架Beego，所以决定写一个数据库管理平台。这个平台会对MySQL集群中数百节点的数据量、qps、tps、慢sql等指标进行收集，然后在页面上以曲线图的形式展现，还会有一些汇总的报表数据，比如每月每个业务库的数据增量情况以及每天慢sql数量top12的实例列表。对慢sql做分析汇总，支持查看慢sql执行计划。

 

数据查询提取的窗口，支持数据的查询并以excel格式导出。还有一些我们自动维护表分区的一些监控。

 

云栖社区：作为国内较大的应用性能检测平台，听云在数据库上的演变过程是什么样的？都遇到哪些挑战，以及怎么解决的？

 

周金可：听云数据库经历了由MySQL单机到MySQL分库分表分布式架构的演变，后来数据量继续膨胀，又使用压缩引擎对数据进行压缩。某个模块的单表数据量达百亿级，MySQL Shared方式已经无法保证查询性能，所以又采用了GreenPlum MPP的方案来解决性能问题。

 

整个过程中分拆扩容的工作量是比较大的。而且在数据量巨大的情况下，MySQL Shared造成的数据倾斜问题给我们造成了比较大的困扰。目前我们对MySQL的中间件做了一次定制，支持将指定的某个用户的数据路由到一个单独的实例上，然后垂直扩展该实例的配置。但现在我们更倾向于Greenplum的方案，合理的涉及distribution key是可以完全避免数据倾斜的问题。

 

云栖社区：你是什么时候接触GreenPlum方案和PG的？目前在应用上积累了哪些经验？

 

周金可：接触Greenplum和PG有几个月的时间了，目前GreenPlum刚刚上生产，在前期调研的时候积累了一些使用场景的经验，对于GPDB维护上的经验，正在积累的过程中。

 

云栖社区：接下来，你还将如何拥抱PG？

 

周金可：我们一个新产品后端DB使用到postgresql新版本的jsonb特性，兼顾性能和运维的成本考虑。目前来看，除了PG暂时没有可替代的方案，所以我们到时候会采用citus+postgresql的方案。

 

云栖社区：在本期线下沙龙，你分享的内容将包括哪些内容？作为一个刚接触PG的技术人，你对与会者有什么寄语吗？

 

周金可：主要分享的是GreenPlum在听云大数据实时分析的实践，会从分享一下我们具体应用场景GreenPlum选型，以及迁移至GreenPlum架构后与原来MySQL架构的性能对比。

 

Postgresql发展还是挺迅速的，而且国内越来越多的公司也开始尝试使用Postgresql。PG的一些特性也确实很多吸引力，希望越来越多的使用者分享使用经验，让PG社区变得越来越好。

 

云栖社区：最后：作为一个MySQL DBA，你对上段时间Uber从PG切换为MySQL一事怎么看？

                                                                                                  

周金可：Uber的做法可能会对大众在DB的选型上产生一些误导，互联网公司在不同的阶段随着架构的演变会有技术的迭代，往往都会寻求新的技术方案来解决当下的一些痛点问题，所以还是那句话适合自己的就是最好的。

 

MySQL有可能更适合Uber现阶段的业务场景，据说Uber之前曾从MySQL迁移到PG，所以也很难说不是Uber DBA的个人情怀。

 

但这篇文章带来的影响还是很糟糕的。

 

周可金将在9月24日在开源数据库企业应用实践的会议上与大家面对面交流Greenplum技术，欢迎大家免费报名参会、