驚了！ MySQL 熱冷數據分離設計還能這樣！
數據庫發展簡介
數據量的增長其實一直是隨著互聯網的發展呈現爆發式增長的，因為各種各樣的數據都在不斷的被原樣或者是經過少量的更改和增補后拷貝到互聯網的各個角落。為了適應互聯網數據的海量增長，在后端和架構意義上而言，數據庫的發展也大致經歷了「單庫單表 -> 主從讀寫分離 -> 分表分庫 -> NoSQL -> NewSQL」這樣的過程。
一開始，我們把數據都堆在一個數據表里；后來為了提高性能、增加數據擴展的能力，采用了「主從讀寫分離」和「分表分庫」的方式，前者只需要在主從實例之間做數據同步而不會對既有業務有較大的影響，后者則需要用一套切合業務邏輯的方式合理的制定分表分庫的策略；再后來出現的 NoSQL，打破了傳統關系型數據庫固有的一些限制，它們有不同的類型，有的是為了解決高性能讀寫的需求，有的則是為了解決海量數據存儲的需求，還有的需要數據結構本身具備可擴展性；
NoSQL 的不同類型在不同的側重點解決了不同的問題，而如今出現的 NewSQL 則傾向于把數據庫看作是一個黑匣子服務，你還是可以遵照傳統的數據庫協議的使用方式（比如傳統 MySQL 的使用方式）來使用它，但數據存儲服務本身既可以同時具備較高的讀寫性能又可以輕易的實現橫向擴展。NewSQL 并不是一個全新的東西，我們可以把它看作是之前積累的數據庫技術結合分布式技術的集大成解決方案，它使得使用數據服務的人幾乎不需要再考慮性能和擴展問題，而盡量在數據服務內部實現高可用、高性能、可擴展。
「熱數據」和「冷數據」
在簡單了解了數據庫發展歷程之后，再介紹一下我們目前在數據存儲上遇到的問題和一些業務背景。
作為氣象大數據服務商，隨著我們積累的數據量和數據種類越來越多，我們發現我們已經迫切需要一個在全局層面統一的數據路徑規劃和規范。很多時候，我們從數據源獲取到的數據，既需要馬上分發給線上用戶，也需要被內部項目使用，如果只是簡單的按需實現，那數據流轉會非?；靵y?；谶@種考慮，我們引入了「熱數據」（「在線數據」）和「冷數據」（「離線數據」）的概念：
「熱數據」指的是需要即時對用戶進行分發的數據，即從數據源抓取之后經過數據清洗，需要即時存儲到可以快速分發的存儲介質（如 Redis）供 API 或直接面向用戶的系統使用。「熱數據」線需要重點保障服務質量和穩定性，為了保證數據的時效性，在數據處理上也是優先級高的數據?！笩釘祿箍赡苁桥R時或短期存儲的，后來的數據可能會覆蓋已有的數據。
「冷數據」指的是不需要即時分發給用戶的數據，這些數據甚至可能永遠都不會原樣分發給用戶的，但它們需要經過長期的積累，使我們可以從中得出基于此的更高 level 的分析?！咐鋽祿沟湫偷氖褂脠鼍笆枪﹥炔繑祿u估系統做數據準確度的評估分析，同時也可以給算法團隊建模使用。設立這個數據線的原則是不影響「熱數據」的服務質量，尤其是時效性和穩定性，同時也滿足一些非線上項目的數據使用需求。
這其實也不是什么新鮮的概念，很多做數據服務的公司都有類似的設計，我們只是根據我們的業務特點借用了這樣的概念，不過它們的含義可能與你在其他地方看到的類似概念的含義有所不同。
結合我們具體的業務場景來說，「熱數據」線其實已經一直在有效運轉了，即我們從數據源獲取到數據然后盡快存儲到高性能存儲介質中，再通過HTTP協議分發出去，這些數據都是即時更新的最新的數據。而其中有一些類型的數據，我們還需要在可視化項目中查看歷史變化情況，并能進行簡單的聚合和計算，這意味著數據需要積累一段時間，那我們也需要一些可以持久化存儲的介質。
拿天氣實況來舉例，我們在采集完數據之后，隨即就存儲最新的一份數據到Redis，而出于數據積累的角度考慮，我們同時也把新數據寫入MySQL。這是之前我們的做法，然而隨著數據量的極速擴大，問題很快就會出在MySQL上。對于「億」級別行數往上的MySQL單表，操作會變得越來越困難，而大范圍的抽數或者插入數據的操作都可能使得整個MySQL無法提供服務，這對于線上業務而言是不可接受的。
離線數據中心的實現
在提出了「冷數據」的概念之后，我們意識到那些久遠的歷史數據其實需要存放到「冷數據」的數據中心池子里，而線上MySQL只需要保留最近一段時間的數據即可。另外，為了不改變現有項目使用數據的方式，降低數據庫使用者的門檻，不管是對于線上數據庫還是「離線數據」的數據中心，我們都需要兼容MySQL單表的使用協議。
很快我們就開始考慮NewSQL的方案，TiDB很自然地進入了我們的視野，這是一個既可以兼容現有數據使用方式，又可以實現數據橫向擴展的完美方案，但無奈搭建一個最小版本的TiDB 數據集群的成本，相比于目前我們把它作為一個「離線數據」存儲中心的角色而言，還是有一些偏高，而我們的存量服務也基本都是基于阿里云的，所以最終我們選擇了阿里云推出不久的云數據庫PolarDB。其間我們還研究了很多其他數據庫方案，比如DRDS、OceanBase、Google Cloud Spanner、Amazon Aurora等。
數據同步和數據過期
有了離線數據存儲中心之后，我們開始考慮如何把「熱數據」轉化為「冷數據」，同時也使得線上數據庫可以自動過期超出時間窗口的歷史數據。另外，由于內部可視化項目也希望看到實時的實況數據，所以離線數據最好也能很快獲得最新的實況數據。
既然是兩個 MySQL（集群）之間的實時數據轉移，很自然的就想到了我們可以做類似主從節點之間通過 binlog 的數據同步機制，這個同步可以做到秒級延遲，在實時性上是完全可以接受的。不過這不能是簡單的數據同步，因為離線數據是不能同步線上數據的過期操作的。更具體的，我們可以概括成：MySQL 從節點同步主節點所有數據增添和數據修改的操作，而對于數據的刪除操作不做同步。
在調研之后，我們發現TiDB提供的同步工具Syncer可以實現這一點，我們只需要在配置注明過濾掉DELETE的DML語句即可，示例如下：
- [[skip-dmls]]
- db-name = "weather_data"
- tbl-name = "weather_now_history"
- type = "delete"
而數據過期方案則可以直接借助MySQL本身的EVENT和PROCEDURE機制完成。首先我們可以創建一個刪除數據的PROCEDURE：
- CREATE DEFINER=`weather`@`%` PROCEDURE `weather_data`.`del_old_data`(IN `date_inter` int)
- BEGIN
- delete from weather_data.weather_now_history where datetime < date_sub(curdate(), interval date_inter day);
- END
這個PROCEDURE功能是刪除weather_now_history表中date_inter天之前的數據。然后我們再創建一個EVENT：
- CREATE EVENT del_old_data
- ON SCHEDULE EVERY 1 DAY
- STARTS '2018-12-25 10:08:35.000'
- ON COMPLETION PRESERVE
- ENABLE
- DO call del_old_data(30)
這個EVENT則會每天調用一次名為del_old_data的PROCEDURE，并同時把date_inter 賦值為30。這意味數據庫每天會刪一次數據，使得線上數據庫一直只保留最近30天的數據，而全量的數據是在數據寫入時就實時同步到了離線數據中心，可謂完美。
持續改進
上述的具體業務場景更多的還是case by case的解決了「熱數據」和「冷數據」的分離和轉化問題，這意味著方案并不具有普適性，以后我們遇到其他的數據庫或者不同的數據使用場景可能就不再適用。
另外，很多時候，「熱數據」和「冷數據」的劃分并不是那么明晰的，對于「冷數據」的需求有可能轉變為「熱數據」需求，我們需要可以靈活切換的機制，做到數據源只抓取一次（「熱數據」和「冷數據」不要分別抓?。?，而抓取到的數據可以任意自由的流淌到「熱數據」或「冷數據」線使用，這意味著我們在數據抓取和數據存儲之間應該再做一層隔離。
要實現數據抓取和數據存儲之間的隔離，我們可以采用「發布 / 訂閱模式」：簡單說，數據抓取服務在獲取數據之后將數據發布到消息隊列，后面的存儲服務任意訂閱這個消息隊列再做存儲，這樣數據源只需要抓取一次，我們可以把它作為熱數據使用，也可以作為冷數據使用，甚至可以即作為熱數據又作為冷數據使用，切換起來也十分簡單。這是后續系統架構可以改進的一個地方。
另外，離線數據中心僅僅使用 PolarDB 對于我們可能產生的數據量級而言也是遠遠不夠的，我們還需要更低成本的數據存儲方案來存儲時間更久遠、平時幾乎不大會訪問的一些需要被「歸檔」的數據，這個時候，一些基于列存儲的 NoSQL 數據庫可能可以派上用場。
數據治理需要一個長期持續的過程，我們還在結合自身的業務場景不斷的摸索當中。
