隨著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做了兩次取模，會造成部分例項中的某些表中資料是空的，不過並不影響應用。

以上就是雲智慧在過去幾年裡從傳統資料架構向大資料遷移過程中的一些經驗，希望為大家的資料架構遷移提供參考。