首页 > 代码库 > 专访周金可:我们更倾向于Greenplum来解决数据倾斜的问题

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

周金可,就职于听云,维护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技术,欢迎大家免费报名参会、

技术分享

 

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