《企業(yè)互聯(lián)網(wǎng)+轉(zhuǎn)型實(shí)戰(zhàn):如何進(jìn)行PB級(jí)別數(shù)據(jù)的架構(gòu)變遷》要點(diǎn):
本文介紹了企業(yè)互聯(lián)網(wǎng)+轉(zhuǎn)型實(shí)戰(zhàn):如何進(jìn)行PB級(jí)別數(shù)據(jù)的架構(gòu)變遷,希望對(duì)您有用。如果有疑問,可以聯(lián)系我們。
隨著DT時(shí)代的來(lái)臨,數(shù)據(jù)對(duì)于企業(yè)經(jīng)營(yíng)決策的價(jià)值日益凸顯,而企業(yè)在進(jìn)行互聯(lián)網(wǎng)+轉(zhuǎn)型的過程中,如何讓數(shù)據(jù)架構(gòu)平滑遷移到大數(shù)據(jù)平臺(tái),對(duì)于傳統(tǒng)業(yè)務(wù)的轉(zhuǎn)型升級(jí)至關(guān)重要.企業(yè)IT部門該如何進(jìn)行PB級(jí)別大數(shù)據(jù)平臺(tái)的遷移規(guī)劃呢,請(qǐng)看云智慧運(yùn)維總監(jiān)張克琛帶來(lái)的經(jīng)驗(yàn)分享.
提到PB級(jí)別的大數(shù)據(jù)解決方案市面上有很多,比較火的有Hadoop、Spark、Kafka等等,如果是一個(gè)新上線的系統(tǒng),相信大家都能找到適合自己的方案.但“大數(shù)據(jù)”在09年才逐漸成為互聯(lián)網(wǎng)信息技術(shù)的流行詞匯,一個(gè)較老的系統(tǒng)如何平滑遷移到PB級(jí)數(shù)據(jù)架構(gòu)呢?
云智慧的第一款產(chǎn)品監(jiān)控寶是08年啟動(dòng)的,在設(shè)計(jì)之初緩存使用的是Redis,?數(shù)據(jù)庫(kù)使用的是MySQL,隨著業(yè)務(wù)的高速發(fā)展和全球分布式監(jiān)控點(diǎn)的陸續(xù)建立,數(shù)據(jù)量也從開始的GB級(jí)迅速發(fā)展到PB級(jí),大數(shù)據(jù)成為必然的選擇.面對(duì)PB級(jí)別數(shù)據(jù)存儲(chǔ),云智慧一路走來(lái)也踩過很多坑,下面就給大家分享一下監(jiān)控寶系統(tǒng)架構(gòu)變遷的幾個(gè)比較重要的點(diǎn).
一、Redis的擴(kuò)展
我們面臨的第一個(gè)的問題是Redis的擴(kuò)展,Redis進(jìn)程無(wú)法使用多核,云智慧監(jiān)控寶當(dāng)時(shí)的Redis進(jìn)程并發(fā)1.5W,單core??CPU占用率95%,偶發(fā)會(huì)達(dá)到100%,監(jiān)控寶的任務(wù)調(diào)度會(huì)出現(xiàn)延遲現(xiàn)象,我們做了三套方案:
方案1 :改程序邏輯,基于任務(wù)ID的一致性hash支持Redis多實(shí)例,但由于研發(fā)忙于產(chǎn)品功能,沒空修改,此方案只能放棄;
方案2 :Redis?Cluster,看到官方架構(gòu)圖,我就直接將此方案放棄了.監(jiān)控寶有大量的寫操作,如果每個(gè)點(diǎn)都同步寫操作,理論上瓶頸無(wú)法解決,不適合我們的使用場(chǎng)景,而且生產(chǎn)環(huán)境用這個(gè)的好像也不多.
方案3:Codis, Twemproxy.
最終我們選擇了Codis,目前線上穩(wěn)定運(yùn)行一年多,從未出現(xiàn)任何問題.QPS 已經(jīng)達(dá)到每秒15萬(wàn)次.整個(gè)架構(gòu)每一層都支持?jǐn)U展,并且無(wú)單點(diǎn),架構(gòu)圖如下:
Codis有很多優(yōu)點(diǎn),而我們選擇的理由如下:
1、 平滑遷移:Codis提供了遷移工具,比較容易操作.我們生產(chǎn)環(huán)境已經(jīng)驗(yàn)證,從redis遷到codis 對(duì)業(yè)務(wù)影響為0,不過redis有些命令是不支持的,遷移之前還是要仔細(xì)讀下codis的文檔,是否適合自己的生產(chǎn)環(huán)境.
2、 擴(kuò)展容易:Codis將數(shù)據(jù)默認(rèn)分了1024個(gè)slot,看到這個(gè)當(dāng)時(shí)就很開心,以后基本不用擔(dān)心數(shù)據(jù)量的問題了.理論上是可以擴(kuò)展到1024個(gè)redis實(shí)例,擴(kuò)展的時(shí)候先把新的redis實(shí)例加入到集群中,再將部分slot遷移至新的實(shí)例中就可以了,包括后面將要提到的Mycat 2.0 也會(huì)采用這種設(shè)計(jì).
3、 友好的管理頁(yè)面:擴(kuò)展的操作直接就可以通過管理頁(yè)面做了.
下面是遷移管理圖:
而上面這幾點(diǎn)Twemproxy是不具備的,Codis唯一的缺點(diǎn)就是稍稍復(fù)雜一些,入門的時(shí)候稍需要多花些時(shí)間,但相比其優(yōu)點(diǎn)這些都微不足道了.
二、使用MySQL處理PB級(jí)別的數(shù)據(jù)存儲(chǔ)
我們面臨的第二個(gè)問題是PB級(jí)別的數(shù)據(jù)存儲(chǔ),就拿監(jiān)控寶的網(wǎng)站監(jiān)控功能來(lái)說,云智慧在全球分布有200+個(gè)監(jiān)測(cè)點(diǎn),這些監(jiān)測(cè)點(diǎn)按用戶設(shè)置的頻率訪問指定的網(wǎng)站頁(yè)面,監(jiān)測(cè)數(shù)據(jù)傳到我們的數(shù)據(jù)中心.這個(gè)服務(wù)目前有30多萬(wàn)用戶在使用,平均數(shù)據(jù)日增量在1TB以上.
這部分?jǐn)?shù)據(jù)類似于日志數(shù)據(jù),使用MySQL來(lái)存這些數(shù)據(jù)并不是什么高大上的做法,如果大家使用過ELK的話,會(huì)推薦我們使用elasticsearch來(lái)存儲(chǔ)這些日志數(shù)據(jù)吧.的確是這樣,我們的新產(chǎn)品透視寶、壓測(cè)寶都在用elasticsearch,也用到了hadoop、spark、suro、kafka、druid等大數(shù)據(jù)相關(guān)的框架應(yīng)用,直接使用文件來(lái)存儲(chǔ)也是可以的.
但老系統(tǒng)的問題必須要解決.
使用MySQL做大量數(shù)據(jù)存儲(chǔ)很容易就想到分庫(kù)分表,提到分庫(kù)分表自然就會(huì)想到MySQL的中間件,大家在網(wǎng)站可以查到一些常用的分庫(kù)分表的中間件,包括大家比較熟悉的Atlas、Mycat(cobar)、TDDL 、HEISENBERG、OCEANUS、VITESS、ONEPORXY、DRDS 等,先不談這些中間件之間的區(qū)別,他們共有一個(gè)特性,只能在一個(gè)維度上對(duì)數(shù)據(jù)進(jìn)行拆分或者說只能對(duì)數(shù)據(jù)進(jìn)行一次拆分.
切分?jǐn)?shù)據(jù)庫(kù)分為垂直切分和水平切分,先介紹一個(gè)比較簡(jiǎn)單的垂直切分場(chǎng)景:
有幾個(gè)數(shù)據(jù)庫(kù)在同一個(gè)MySQL實(shí)例中,但因數(shù)據(jù)庫(kù)A 的IO相對(duì)較高,希望將其單獨(dú)拉到另外一臺(tái)服務(wù)器上,又不想讓研發(fā)改動(dòng)代碼.
以前一直以為Mycat只能做水平切分,其實(shí)也可以垂直切分,很實(shí)用,配置也很簡(jiǎn)單,因各種原因希望將原來(lái)一個(gè)MySQL實(shí)例中的多個(gè)庫(kù)分布到多個(gè)實(shí)例中,直接使用Mycat就可以做到,對(duì)應(yīng)用程序來(lái)看還是同一個(gè)實(shí)例,在拆分過程可以通過主從同步實(shí)現(xiàn)平滑遷移.
接下來(lái)介紹水平切分,水平切分是指將某個(gè)表按照某個(gè)字段的某種規(guī)則來(lái)分散到多個(gè)表之中,每個(gè)表中包含一部分?jǐn)?shù)據(jù).
常用的根據(jù)主鍵或非主鍵的分片規(guī)則:
1、枚舉法:
比如數(shù)據(jù)是按照地區(qū)省份來(lái)保存的,用戶通過多級(jí)別劃分的,本規(guī)則適用于這些特定的場(chǎng)景.
2、求模:
如果分片字段為數(shù)字,對(duì)分片字段進(jìn)行十進(jìn)制/百進(jìn)制求模運(yùn)算,數(shù)據(jù)可以均勻落在各分片內(nèi).也見過網(wǎng)友分享的對(duì)字符串hash取模,支持存在符號(hào)字母的字段的分片.
3、范圍約定
對(duì)分片字段約定一個(gè)范圍,比如ID 100001~200000為一個(gè)分片,ID 200001~300000為一個(gè)分片
4、按日期
可以按月,按天,按小時(shí)分片
5、一致性hash
一致性hash算法有效解決了分布式數(shù)據(jù)的擴(kuò)容問題.這個(gè)大家可以查下具體的算法實(shí)現(xiàn).
以上是常用的幾種方式,也有一些分片方式是根據(jù)上面5種變化得來(lái),比如對(duì)日期字段hash再分片的.
單獨(dú)使用一種分片規(guī)則是很難支撐大量數(shù)據(jù)的存儲(chǔ),哪怕使用一致性hash在生產(chǎn)環(huán)境中也是很麻煩的事情,光是數(shù)據(jù)遷移就是一件讓運(yùn)維頭疼的事了,這時(shí)候我們需同時(shí)采用垂直分片和水平分片,甚至多次水平分片,下面聊一下我們?cè)趯?shí)際生產(chǎn)中如何使用這些分片規(guī)則的.
以監(jiān)控寶API監(jiān)控為例,先介紹下應(yīng)用場(chǎng)景,現(xiàn)在我們手機(jī)里安裝的是各種APP,其架構(gòu)中必然存在大量的API,我們的用戶不但要監(jiān)控單個(gè)API請(qǐng)求,還要監(jiān)控連續(xù)請(qǐng)求構(gòu)成的事務(wù), 監(jiān)控寶API監(jiān)控的正確性是以斷言來(lái)判斷的,每個(gè)監(jiān)測(cè)點(diǎn)都會(huì)對(duì)用戶的API做出請(qǐng)求,請(qǐng)求數(shù)據(jù)及斷言的結(jié)果都將被存儲(chǔ)到數(shù)據(jù)中心.
我們借助于cobar, 對(duì)數(shù)據(jù)做了兩次分片,分片邏輯圖如下:
a、 首先我們是通過cobar ,采用枚舉法按監(jiān)測(cè)點(diǎn)ID對(duì)DB這層進(jìn)行了數(shù)據(jù)分片,這樣做的話物理上同一個(gè)監(jiān)測(cè)點(diǎn)的數(shù)據(jù)在一起,業(yè)務(wù)上也是好理解的.
b、在程序邏輯中按天對(duì)表進(jìn)行了分片.每天都會(huì)有腳本將一月之內(nèi)的表都創(chuàng)建好.
從上圖中大家可以看到,這里擴(kuò)展上是存在問題的.我們一共有200多個(gè)監(jiān)測(cè)點(diǎn),在第一階段,數(shù)據(jù)量沒有那么大的時(shí)候,為了節(jié)約成本,我們僅使用了10臺(tái)機(jī)器做存儲(chǔ),一臺(tái)機(jī)器存有多個(gè)監(jiān)測(cè)點(diǎn)的數(shù)據(jù).
隨著數(shù)據(jù)量增大,發(fā)展到第二階段,當(dāng)某臺(tái)機(jī)器硬盤快存滿的時(shí)候,我需要將一些監(jiān)測(cè)點(diǎn)的數(shù)據(jù)遷移至新增進(jìn)集群的機(jī)器中,按這個(gè)架構(gòu),最多我們可以擴(kuò)展到200+臺(tái)機(jī)器.
在生產(chǎn)環(huán)境中用戶對(duì)北上廣的監(jiān)測(cè)點(diǎn)是最有興趣的,所以這些監(jiān)測(cè)點(diǎn)的數(shù)據(jù)量是最大的. 這樣就會(huì)發(fā)展到第三階段,部分監(jiān)測(cè)點(diǎn)的數(shù)據(jù)量大到單臺(tái)機(jī)器的硬盤存不下了.
這時(shí)候如何解決問題呢,我們來(lái)分析一下數(shù)據(jù),單個(gè)數(shù)據(jù)庫(kù)中是按日期來(lái)分表的,而大于3個(gè)月的歷史數(shù)據(jù)較少有人查詢,用戶也可以接受歷史數(shù)據(jù)查詢時(shí)間稍長(zhǎng)一些,于是我們選用了TokuDB來(lái)壓縮歷史數(shù)據(jù),基本上1T的數(shù)據(jù)壓縮之后在100G左右.1:10的壓縮例,即使這樣,理論上最多也只能存儲(chǔ)4P左右的數(shù)據(jù)(數(shù)據(jù)放在UCLOUD上,云主機(jī)支持的最大硬盤為2T).
我們?cè)诰W(wǎng)站監(jiān)控的數(shù)據(jù)分庫(kù)中解決了這個(gè)問題,邏輯圖如下,我們從4個(gè)維度對(duì)數(shù)據(jù)進(jìn)行了分片
1、按日期為第一維度對(duì)數(shù)據(jù)庫(kù)分片,必須按日期做第一次分片,并且分片時(shí)間點(diǎn)可以在配置文件中自定義.
2、按監(jiān)測(cè)點(diǎn)ID為第二維度對(duì)數(shù)據(jù)庫(kù)分片
3、按實(shí)際分片數(shù)量對(duì)任務(wù)ID動(dòng)態(tài)取模為第三維度對(duì)數(shù)據(jù)庫(kù)分片
4、對(duì)任務(wù)ID 100取模為第四維度對(duì)數(shù)據(jù)表分片.
創(chuàng)建后的數(shù)據(jù)庫(kù)類名似于db-201501-monitor01-01、 db-201501-monitor01-02 ……??每個(gè)庫(kù)是有100張表.這樣可以的好處:
1、冷熱數(shù)據(jù)自然分離
2、可以根據(jù)日期無(wú)限次分片
3、在同一個(gè)時(shí)間段里實(shí)際分片數(shù)可以自定義.理論上可以無(wú)限次分片.每次分片服務(wù)器的數(shù)量是可控的,并且下次分片的時(shí)間也變的可預(yù)期.可以在最大程度是節(jié)約成本.
4、數(shù)據(jù)無(wú)需遷移
細(xì)心的同學(xué)會(huì)發(fā)現(xiàn)這樣對(duì)數(shù)據(jù)分片造成一個(gè)小問題,我們對(duì)任務(wù)ID做了兩次取模,會(huì)造成部分實(shí)例中的某些表中數(shù)據(jù)是空的,不過并不影響應(yīng)用.
以上就是云智慧在過去幾年里從傳統(tǒng)數(shù)據(jù)架構(gòu)向大數(shù)據(jù)遷移過程中的一些經(jīng)驗(yàn),希望為大家的數(shù)據(jù)架構(gòu)遷移提供參考.
轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址:
http://www.snjht.com/jiaocheng/4543.html