專訪周金可：咱們更傾向於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技術，歡迎你們免費報名參會、