《企業互聯網+轉型實戰：如何進行PB級別數據的架構變遷》要點：
本文介紹了企業互聯網+轉型實戰：如何進行PB級別數據的架構變遷，希望對您有用。如果有疑問，可以聯系我們。

隨著DT時代的來臨,數據對于企業經營決策的價值日益凸顯,而企業在進行互聯網+轉型的過程中,如何讓數據架構平滑遷移到大數據平臺,對于傳統業務的轉型升級至關重要.企業IT部門該如何進行PB級別大數據平臺的遷移規劃呢,請看云智慧運維總監張克琛帶來的經驗分享.

提到PB級別的大數據解決方案市面上有很多,比較火的有Hadoop、Spark、Kafka等等,如果是一個新上線的系統,相信大家都能找到適合自己的方案.但“大數據”在09年才逐漸成為互聯網信息技術的流行詞匯,一個較老的系統如何平滑遷移到PB級數據架構呢?

云智慧的第一款產品監控寶是08年啟動的,在設計之初緩存使用的是Redis,?數據庫使用的是MySQL,隨著業務的高速發展和全球分布式監控點的陸續建立,數據量也從開始的GB級迅速發展到PB級,大數據成為必然的選擇.面對PB級別數據存儲,云智慧一路走來也踩過很多坑,下面就給大家分享一下監控寶系統架構變遷的幾個比較重要的點.

一、Redis的擴展

我們面臨的第一個的問題是Redis的擴展,Redis進程無法使用多核,云智慧監控寶當時的Redis進程并發1.5W,單core??CPU占用率95%,偶發會達到100%,監控寶的任務調度會出現延遲現象,我們做了三套方案：

方案1 ：改程序邏輯,基于任務ID的一致性hash支持Redis多實例,但由于研發忙于產品功能,沒空修改,此方案只能放棄；

方案2 ：Redis?Cluster,看到官方架構圖,我就直接將此方案放棄了.監控寶有大量的寫操作,如果每個點都同步寫操作,理論上瓶頸無法解決,不適合我們的使用場景,而且生產環境用這個的好像也不多.

方案3：Codis, Twemproxy.

最終我們選擇了Codis,目前線上穩定運行一年多,從未出現任何問題.QPS 已經達到每秒15萬次.整個架構每一層都支持擴展,并且無單點,架構圖如下：

Codis有很多優點,而我們選擇的理由如下：

1、 平滑遷移：Codis提供了遷移工具,比較容易操作.我們生產環境已經驗證,從redis遷到codis 對業務影響為0,不過redis有些命令是不支持的,遷移之前還是要仔細讀下codis的文檔,是否適合自己的生產環境.

2、 擴展容易：Codis將數據默認分了1024個slot,看到這個當時就很開心,以后基本不用擔心數據量的問題了.理論上是可以擴展到1024個redis實例,擴展的時候先把新的redis實例加入到集群中,再將部分slot遷移至新的實例中就可以了,包括后面將要提到的Mycat 2.0 也會采用這種設計.

3、 友好的管理頁面：擴展的操作直接就可以通過管理頁面做了.

下面是遷移管理圖：

而上面這幾點Twemproxy是不具備的,Codis唯一的缺點就是稍稍復雜一些,入門的時候稍需要多花些時間,但相比其優點這些都微不足道了.

二、使用MySQL處理PB級別的數據存儲

我們面臨的第二個問題是PB級別的數據存儲,就拿監控寶的網站監控功能來說,云智慧在全球分布有200+個監測點,這些監測點按用戶設置的頻率訪問指定的網站頁面,監測數據傳到我們的數據中心.這個服務目前有30多萬用戶在使用,平均數據日增量在1TB以上.

這部分數據類似于日志數據,使用MySQL來存這些數據并不是什么高大上的做法,如果大家使用過ELK的話,會推薦我們使用elasticsearch來存儲這些日志數據吧.的確是這樣,我們的新產品透視寶、壓測寶都在用elasticsearch,也用到了hadoop、spark、suro、kafka、druid等大數據相關的框架應用,直接使用文件來存儲也是可以的.

但老系統的問題必須要解決.

使用MySQL做大量數據存儲很容易就想到分庫分表,提到分庫分表自然就會想到MySQL的中間件,大家在網站可以查到一些常用的分庫分表的中間件,包括大家比較熟悉的Atlas、Mycat(cobar)、TDDL 、HEISENBERG、OCEANUS、VITESS、ONEPORXY、DRDS 等,先不談這些中間件之間的區別,他們共有一個特性,只能在一個維度上對數據進行拆分或者說只能對數據進行一次拆分.

切分數據庫分為垂直切分和水平切分,先介紹一個比較簡單的垂直切分場景：

有幾個數據庫在同一個MySQL實例中,但因數據庫A 的IO相對較高,希望將其單獨拉到另外一臺服務器上,又不想讓研發改動代碼.

以前一直以為Mycat只能做水平切分,其實也可以垂直切分,很實用,配置也很簡單,因各種原因希望將原來一個MySQL實例中的多個庫分布到多個實例中,直接使用Mycat就可以做到,對應用程序來看還是同一個實例,在拆分過程可以通過主從同步實現平滑遷移.

接下來介紹水平切分,水平切分是指將某個表按照某個字段的某種規則來分散到多個表之中,每個表中包含一部分數據.

常用的根據主鍵或非主鍵的分片規則：

1、枚舉法：

比如數據是按照地區省份來保存的,用戶通過多級別劃分的,本規則適用于這些特定的場景.

2、求模：

如果分片字段為數字,對分片字段進行十進制/百進制求模運算,數據可以均勻落在各分片內.也見過網友分享的對字符串hash取模,支持存在符號字母的字段的分片.

3、范圍約定

對分片字段約定一個范圍,比如ID 100001~200000為一個分片,ID 200001~300000為一個分片

4、按日期

可以按月,按天,按小時分片

5、一致性hash

一致性hash算法有效解決了分布式數據的擴容問題.這個大家可以查下具體的算法實現.

以上是常用的幾種方式,也有一些分片方式是根據上面5種變化得來,比如對日期字段hash再分片的.

單獨使用一種分片規則是很難支撐大量數據的存儲,哪怕使用一致性hash在生產環境中也是很麻煩的事情,光是數據遷移就是一件讓運維頭疼的事了,這時候我們需同時采用垂直分片和水平分片,甚至多次水平分片,下面聊一下我們在實際生產中如何使用這些分片規則的.

以監控寶API監控為例,先介紹下應用場景,現在我們手機里安裝的是各種APP,其架構中必然存在大量的API,我們的用戶不但要監控單個API請求,還要監控連續請求構成的事務, 監控寶API監控的正確性是以斷言來判斷的,每個監測點都會對用戶的API做出請求,請求數據及斷言的結果都將被存儲到數據中心.

我們借助于cobar, 對數據做了兩次分片,分片邏輯圖如下：

a、 首先我們是通過cobar ,采用枚舉法按監測點ID對DB這層進行了數據分片,這樣做的話物理上同一個監測點的數據在一起,業務上也是好理解的.

b、在程序邏輯中按天對表進行了分片.每天都會有腳本將一月之內的表都創建好.

從上圖中大家可以看到,這里擴展上是存在問題的.我們一共有200多個監測點,在第一階段,數據量沒有那么大的時候,為了節約成本,我們僅使用了10臺機器做存儲,一臺機器存有多個監測點的數據.

隨著數據量增大,發展到第二階段,當某臺機器硬盤快存滿的時候,我需要將一些監測點的數據遷移至新增進集群的機器中,按這個架構,最多我們可以擴展到200+臺機器.

在生產環境中用戶對北上廣的監測點是最有興趣的,所以這些監測點的數據量是最大的. 這樣就會發展到第三階段,部分監測點的數據量大到單臺機器的硬盤存不下了.

這時候如何解決問題呢,我們來分析一下數據,單個數據庫中是按日期來分表的,而大于3個月的歷史數據較少有人查詢,用戶也可以接受歷史數據查詢時間稍長一些,于是我們選用了TokuDB來壓縮歷史數據,基本上1T的數據壓縮之后在100G左右.1:10的壓縮例,即使這樣,理論上最多也只能存儲4P左右的數據(數據放在UCLOUD上,云主機支持的最大硬盤為2T).

我們在網站監控的數據分庫中解決了這個問題,邏輯圖如下,我們從4個維度對數據進行了分片

1、按日期為第一維度對數據庫分片,必須按日期做第一次分片,并且分片時間點可以在配置文件中自定義.

2、按監測點ID為第二維度對數據庫分片

3、按實際分片數量對任務ID動態取模為第三維度對數據庫分片

4、對任務ID 100取模為第四維度對數據表分片.

創建后的數據庫類名似于db-201501-monitor01-01、 db-201501-monitor01-02 ……??每個庫是有100張表.這樣可以的好處：

1、冷熱數據自然分離

2、可以根據日期無限次分片

3、在同一個時間段里實際分片數可以自定義.理論上可以無限次分片.每次分片服務器的數量是可控的,并且下次分片的時間也變的可預期.可以在最大程度是節約成本.

4、數據無需遷移

細心的同學會發現這樣對數據分片造成一個小問題,我們對任務ID做了兩次取模,會造成部分實例中的某些表中數據是空的,不過并不影響應用.

以上就是云智慧在過去幾年里從傳統數據架構向大數據遷移過程中的一些經驗,希望為大家的數據架構遷移提供參考.

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4543.html