企業互聯網+轉型實戰：如何進行PB級別數據的架構變遷

隨着DT時代的來臨，數據對於企業經營決策的價值日益凸顯，而企業在進行互聯網+轉型的過程當中，如何讓數據架構平滑遷移到大數據平臺，對於傳統業務的轉型升級相當重要。企業IT部門該如何進行PB級別大數據平臺的遷移規劃呢，請看雲智慧運維總監張克琛帶來的經驗分享。
提到PB級別的大數據解決方案市面上有不少，比較火的有Hadoop、Spark、Kafka等等，若是是一個新上線的系統，相信你們都能找到適合本身的方案。但「大數據」在09年才逐漸成爲互聯網信息技術的流行詞彙，一個較老的系統如何平滑遷移到PB級數據架構呢？
雲智慧的第一款產品監控寶是08年啓動的，在設計之初緩存使用的是Redis, 數據庫使用的是MySQL，隨着業務的高速發展和全球分佈式監控點的陸續創建，數據量也從開始的GB級迅速發展到PB級，大數據成爲必然的選擇。面對PB級別數據存儲，雲智慧一路走來也踩過不少坑，下面就給你們分享一下監控寶系統架構變遷的幾個比較重要的點。

1、Redis的擴展
咱們面臨的第一個的問題是Redis的擴展，Redis進程沒法使用多核，雲智慧監控寶當時的Redis進程併發1.5W，單core CPU佔用率95%，偶發會達到100%，監控寶的任務調度會出現延遲現象，咱們作了三套方案：
方案1：改程序邏輯，基於任務ID的一致性hash支持Redis多實例，但因爲研發忙於產品功能，沒空修改，此方案只能放棄；
方案2：Redis Cluster，看到官方架構圖，我就直接將此方案放棄了。監控寶有大量的寫操做，若是每一個點都同步寫操做，理論上瓶頸沒法解決，不適合咱們的使用場景，並且生產環境用這個的好像也很少。

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

Codis有不少優勢，而咱們選擇的理由以下：
平滑遷移：Codis提供了遷移工具，比較容易操做。咱們生產環境已經驗證，從redis遷到codis 對業務影響爲0，不過redis有些命令是不支持的，遷移以前仍是要仔細讀下codis的文檔，是否適合本身的生產環境。
擴展容易：Codis將數據默認分了1024個slot，看到這個當時就很開心，之後基本不用擔憂數據量的問題了。理論上是能夠擴展到1024個redis實例，擴展的時候先把新的redis實例加入到集羣中，再將部分slot遷移至新的實例中就能夠了，包括後面將要提到的Mycat 2.0 也會採用這種設計。
友好的管理頁面：擴展的操做直接就能夠經過管理頁面作了。

下面是遷移管理圖：

而上面這幾點Twemproxy是不具有的，Codis惟一的缺點就是稍稍複雜一些，入門的時候稍須要多花些時間，但相比其優勢這些都微不足道了。

2、使用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就能夠作到，對應用程序來看仍是同一個實例，在拆分過程能夠經過主從同步實現平滑遷移。
接下來介紹水平切分，水平切分是指將某個表按照某個字段的某種規則來分散到多個表之中，每一個表中包含一部分數據。

經常使用的根據主鍵或非主鍵的分片規則：
一、枚舉法：
   好比數據是按照地區省份來保存的，用戶經過多級別劃分的，本規則適用於這些特定的場景。
二、求模：
若是分片字段爲數字，對分片字段進行十進制/百進制求模運算，數據能夠均勻落在各分片內。也見過網友分享的對字符串hash取模，支持存在符號字母的字段的分片。
三、範圍約定
對分片字段約定一個範圍，好比ID 100001~200000爲一個分片，ID 200001~300000爲一個分片
四、按日期
能夠按月，按天，按小時分片
五、一致性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個維度對數據進行了分片

一、按日期爲第一維度對數據庫分片，必須按日期作第一次分片，而且分片時間點能夠在配置文件中自定義。二、按監測點ID爲第二維度對數據庫分片三、按實際分片數量對任務ID動態取模爲第三維度對數據庫分片四、對任務ID 100取模爲第四維度對數據表分片。建立後的數據庫類名似於db-201501-monitor01-0一、 db-201501-monitor01-02 …… 每一個庫是有100張表。這樣能夠的好處：一、冷熱數據天然分離二、能夠根據日期無限次分片三、在同一個時間段裏實際分片數能夠自定義。理論上能夠無限次分片。每次分片服務器的數量是可控的，而且下次分片的時間也變的可預期。能夠在最大程度是節約成本。四、數據無需遷移我細心的同窗會發現這樣對數據分片形成一個小問題，咱們對任務ID作了兩次取模，會形成部分實例中的某些表中數據是空的，不過並不影響應用。以上就是雲智慧在過去幾年裏從傳統數據架構向大數據遷移過程當中的一些經驗，但願爲你們的數據架構遷移提供參考。