周金可，就職于聽雲，維護mysql和greenplum的正常運作，以及調研适合聽雲業務場景的資料庫技術方案。
聽雲周金可
9月24日，周金可将參加在北京舉辦的線下活動，并做主題為《greenplum在聽雲大資料實時分析的實踐》的分享。值此，他分享了pg、工作上的一些經曆和經驗。
<b>正文：</b>
周金可剛參加工作時是做系統運維的，後來慢慢接觸了各種資料庫，開始對資料庫感興趣，經過一段時間的積累後轉向了dba。
“在我加入聽雲時，恰好是業務快速增長的階段，後端我們的應用以及資料庫經受了比較大的考驗。去年大多數時間是在做擴容，我們的mysql叢集由最開始的數台執行個體擴充到現在的數百台執行個體。”他經曆了聽雲業務量的爆發式增長。
而正是這種增長，讓周金可和pg有了親密接觸：“某個子產品的單表資料量達百億級，mysql shared方式已經無法保證查詢性能，是以又采用了greenplum mpp的方案來解決性能問題。”
“整個過程中分拆擴容的工作量是比較大的。而且在資料量巨大的情況下，mysql shared造成的資料傾斜問題給我們造成了比較大的困擾。目前我們對mysql的中間件做了一次定制，支援将指定的某個使用者的資料路由到一個單獨的執行個體上，然後垂直擴充該執行個體的配置。但現在我們更傾向于greenplum的方案，合理的涉及distribution
key是可以完全避免資料傾斜的問題。”
是以，他本次分享的就是greenplum在聽雲大資料實時分析的實踐，内容涉及具體應用場景greenplum選型，以及遷移至greenplum架構後與原來mysql架構的性能對比。
除此之外，周金可也談了自己為什麼喜歡golang的程式設計風格、聽雲内部的資料庫管理平台的經曆，以及對上段時間uber從pg切換為mysql一事的看法。
<b>更為具體的内容，請檢視以下完整采訪：</b>
<b>雲栖社群：請介紹下你以及所從事的工作。</b>
<b> </b>
<b>周金可：</b>我叫周金可，目前就職于聽雲。聽雲是一家在apm領域深耕10年的公司。我是在15年初加入聽雲，有幸經曆了聽雲業務量的爆發式增長。
聽雲後端目前的資料庫架構主要是mysql分布式叢集，也有一部分資料是采用greenplum的方案。而我們即将釋出的cdn
controller産品後端，則采用的是postgresql+citus分布式方案。
目前主要的工作内容就是維護mysql和greenplum的正常運作，以及調研适合聽雲業務場景的資料庫技術方案。
<b>雲栖社群：你是怎麼走上dba道路的？目前工作中有哪些亮點？</b>
<b>周金可：</b>剛參加工作的時候是做系統運維的，後來慢慢的接觸了各種資料庫，開始對資料庫感興趣，經過一段時間的積累後轉向了dba。
在我加入聽雲時，恰好是聽雲的業務快速增長的階段，後端我們的應用以及資料庫經受了比較大的考驗，去年大多數時間是在做擴容，我們的mysql叢集由最開始的數台執行個體擴充到現在的數百台執行個體。
今年我們主要是做了一些優化的工作，比如使用tokudb存儲引擎替換線上mysql執行個體的innodb執行個體，大幅壓縮資料并提升性能。将原來放在mysql上的一部分業務資料遷移到greenplum上，查詢性能提升幾百倍。當然這隻是在我們的場景中，單節點mysql跟greenplum叢集的對比，mysql還是很優秀的db。
<b>雲栖社群：你提到，比較喜歡golang的程式設計風格，能聊下原因嗎？你還使用golang開發了聽雲内部的資料庫管理平台，請介紹下這個平台，以及開發中一些記憶猶新的事吧。</b>
<b>周金可：</b>golang文法比python簡單，程式設計風格趨于腳本化但功能比shell強大很多，原生的并發變成模型和跨平台特性讓我覺得golang可以作為日常運維工作中的一把利劍。
資料庫叢集規模比較大，不可能每天對數百節點做人肉巡檢，後來接觸到了golang的web架構beego，是以決定寫一個資料庫管理平台。這個平台會對mysql叢集中數百節點的資料量、qps、tps、慢sql等名額進行收集，然後在頁面上以曲線圖的形式展現，還會有一些彙總的報表資料，比如每月每個業務庫的資料增量情況以及每天慢sql數量top12的執行個體清單。對慢sql做分析彙總，支援檢視慢sql執行計劃。
資料查詢提取的視窗，支援資料的查詢并以excel格式導出。還有一些我們自動維護表分區的一些監控。
<b>雲栖社群：作為國内較大的應用性能檢測平台，聽雲在資料庫上的演變過程是什麼樣的？都遇到哪些挑戰，以及怎麼解決的？</b>
<b>周金可：</b>聽雲資料庫經曆了由mysql單機到mysql分庫分表分布式架構的演變，後來資料量繼續膨脹，又使用壓縮引擎對資料進行壓縮。某個子產品的單表資料量達百億級，mysql shared方式已經無法保證查詢性能，是以又采用了greenplum mpp的方案來解決性能問題。
整個過程中分拆擴容的工作量是比較大的。而且在資料量巨大的情況下，mysql
shared造成的資料傾斜問題給我們造成了比較大的困擾。目前我們對mysql的中間件做了一次定制，支援将指定的某個使用者的資料路由到一個單獨的執行個體上，然後垂直擴充該執行個體的配置。但現在我們更傾向于greenplum的方案，合理的涉及distribution
key是可以完全避免資料傾斜的問題。
<b>雲栖社群：你是什麼時候接觸greenplum方案和pg的？目前在應用上積累了哪些經驗？</b>
<b>周金可：</b>接觸greenplum和pg有幾個月的時間了，目前greenplum剛剛上生産，在前期調研的時候積累了一些使用場景的經驗，對于gpdb維護上的經驗，正在積累的過程中。
<b>雲栖社群：接下來，你還将如何擁抱pg？</b>
<b>周金可：</b>我們一個新産品後端db使用到postgresql新版本的jsonb特性，兼顧性能和運維的成本考慮。目前來看，除了pg暫時沒有可替代的方案，是以我們到時候會采用citus+postgresql的方案。
<b>雲栖社群：在本期線下沙龍，你分享的内容将包括哪些内容？作為一個剛接觸pg的技術人，你對與會者有什麼寄語嗎？</b>
<b>周金可：</b>主要分享的是greenplum在聽雲大資料實時分析的實踐，會從分享一下我們具體應用場景greenplum選型，以及遷移至greenplum架構後與原來mysql架構的性能對比。
postgresql發展還是挺迅速的，而且國内越來越多的公司也開始嘗試使用postgresql。pg的一些特性也确實很多吸引力，希望越來越多的使用者分享使用經驗，讓pg社群變得越來越好。
<b>雲栖社群：最後：作為一個mysql dba，你對上段時間uber從pg切換為mysql一事怎麼看？</b>
<b> </b>
<b>周金可：</b>uber的做法可能會對大衆在db的選型上産生一些誤導，網際網路公司在不同的階段随着架構的演變會有技術的疊代，往往都會尋求新的技術方案來解決當下的一些痛點問題，是以還是那句話适合自己的就是最好的。
mysql有可能更适合uber現階段的業務場景，據說uber之前曾從mysql遷移到pg，是以也很難說不是uber dba的個人情懷。
但這篇文章帶來的影響還是很糟糕的。
