面向海量數據的極致成本優化-雲HBase的一體化冷熱分離

前言

隨着業務的持續發展，業務數據庫存儲量會持續增加。一般數據量過億時，就須要考慮作分庫分表，或者選擇擴展能力更好的NOSQL/NewSQL數據庫，如HBase就能夠單表支持PB級數據，足夠知足大多數業務的存儲需求。然而，對於大量存儲瓶頸類業務，存儲成本依然是系統設計中須要關注的重中之重，冷熱分離的解決方案應用而生。

適合冷熱分離的業務

帳單/訂單類系統的數據很是適合作冷熱分離，這類系統的數據隨着時間的推移每每會積攢了海量數據，並且因爲數據的重要性，這些數據都要被永久保存。可是，用戶每每只會查詢最近消費的訂單或者帳單，超過半年的訂單基本不會被訪問。

 

監控系統的數據也呈很是明顯的冷熱分層特性。用戶一般只會查看實時監控，歷史數據只有在回溯故障的時候，纔可能去查詢。而若是把實時數據與歷史數據混雜在一塊兒，不只會讓存儲的成本很是高，並且會拖慢實時查詢的速度。

 

聊天系統是冷熱分離的另一個實用場景，用戶一般只會查看實時的聊天消息，聊天記錄的訪問頻次要低很是多。

 

總的來講，適合將數據作冷熱分離的業務會有如下幾個特徵：

• 海量數據持續增加的業務：如交易歷史數據，聊天記錄，數據沒法作TTL，且單個用戶的數據會持續累加。
• 數據生命週期分明的業務：如監控數據，物流信息，feed收件箱，一般只會查詢近期的數據，冷數據僅做爲回溯問題使用。
• 重寫輕讀的業務：在IOT場景下，車聯網中會有大量車輛上報的傳感器信息，和實時的軌跡信息，寫入吞吐會很是大。可是這些數據每每只是用來作歸檔，查詢的頻率很是低。

現有冷熱分離方案

目前業界的冷熱分離方案大可能是將數據分爲冷庫和熱庫兩個庫。熱庫能夠採用速度較快，但存儲成本比較高的數據庫方案如內存數據庫Redis，或是MySQL+SSD存儲介質。而冷庫則採用存儲成本比較低的數據庫方案，如MySQL+HDD或者是使用HBase等稀疏存儲的NoSQL數據庫，甚至使用高壓縮比的列存數據庫。而熱庫到冷庫的數據遷移每每會有如下幾個方案。

冷熱庫定時遷移

用戶實時寫入熱庫，並經過其餘中間件定時將舊的數據倒入離線庫。好比，熱庫能夠是使用SSD介質的MySQL數據庫，而冷庫能夠是使用HDD介質的MySQL數據庫，經過DataX等數據遷移工具，按期將熱庫的數據遷移到HDD介質的冷庫中。

 

冷熱庫雙寫

用戶實時雙寫冷熱庫，熱數據在較短期後過時（對於不支持TTL的數據庫，須要刪除清理）。好比熱庫採用內存數據庫Redis，冷庫採用MySQL或者海量存儲HBase，數據同時寫入Redis熱庫和冷庫。Redis中只保留最近7天的數據。查詢層先查詢在線庫，若是在線庫無數據則直接查詢離線庫返回。此方案無需維護一個定時遷移的任務，可是須要依賴用戶雙寫。

 

基於日誌的增量導出方案

在方案2的基礎上，不少有日誌導出能力的數據庫提供了基於日誌的離在線庫同步方案。好比咱們可使用MySQL作熱庫，HBase作爲冷庫，而後經過導出MySQL binlog的方式，將數據增量寫入到HBase中。除此以外，redis的冷熱分離方案swapdb，自己也是基於redis的PSYNC實現，本質上也是屬於增量導出的方案。

 

此方案能夠上減小冷熱數據庫管理的開銷。然而這種方案仍然須要用戶自行管理在線庫數據的生命週期問題，且須要額外的查詢層來分別訪問冷熱數據。

不管是使用哪一種同步方案，將數據分爲熱庫和冷庫兩個庫的方案，都存在必定的缺陷：

運維難度增長

用戶須要運維熱庫和冷庫兩個數據庫，在使用增量導出時，用戶還須要維護一個定時任務來作數據導出。

數據一致性難以維護

不管是哪一種數據同步方案，冷庫和熱庫的數據一致性很難保證。好比說雙寫方案，用戶須要處理一邊寫成功一邊寫失敗的狀況來自行維護兩邊數據的一致性。定時遷移方案和加強導出因爲數據遷移都是異步的，處於冷熱邊界的數據有可能還在熱庫中，也有可能已經進入到冷庫，屢次讀取可能會產生不一樣的結果。

用戶查詢改形成本大

對於業務來講，使用了冷熱分離後，數據對於業務來講再也不是一個「單庫」，用戶須要決定這一次查詢須要去熱庫查詢仍是要去冷庫，而且因爲冷熱數據數據遷移是異步的，用戶並不知道數據究竟是在熱庫仍是冷庫中，一般要冷熱庫一塊兒查才能獲得全量數據。另外，在使用異構的冷庫和熱庫的狀況下（如熱庫使用Redis/MySQL,冷庫使用MySQL/HBase），用戶必須針對熱庫和冷庫查詢開發兩套查詢接口,開發成本大大上升。

冷熱分離一體化 —— 海量數據冷熱分離終極解決方案

針對設置冷庫熱庫這種將數據分離開，給業務帶來運維和改造困難的缺陷，雲HBase加強版開發了全新的一體冷熱分離特性——在同一張表中全透明地實現冷熱分離，服務端自動根據用戶設置的冷熱分界線自動將表中的冷數據歸檔到冷存儲中。

 

冷熱分離一體化的核心是應用無感知，HBase加強版用戶無需改動一行查詢便可享受冷熱分離帶來的好處。冷數據和熱數據存儲在一張表中，經過LSM的compaction操做在後臺將熱數據按期遷移到冷數據中。用戶能夠經過設置訪問的timerange來實現查詢優化，也能夠徹底不指定hint，雲HBase加強版會保證在查詢結果無損的狀況下經過kv層的訪問優化來最大程度上規避冷數據的訪問。

冷熱分離的一大目的就是爲了下降存儲成本，HBase加強版目前選用了雲盤（高效/SSD）作爲熱數據存儲，而使用了低成本的OSS作爲了冷存儲，冷存儲成本僅爲高效雲盤的1/3。

 

在使用過程當中，用戶只須要在HBase的表上加上冷熱分界線這個設置，便可開啓冷熱分離功能。在下面的例子中COLD_BOUNDARY被設置爲86400秒（一天），表明這張表中一天前的數據會被自動歸檔在冷存儲中。

hbase(main):002:0> create 'chsTable', {NAME=>'f', COLD_BOUNDARY=>'86400'}

在查詢時，因爲冷熱數據都在同一張表中，用戶全程只須要和一張表交互。用戶能夠設置Hot_Only的Hint告訴服務器只查熱數據，或者在Get/Scan請求中加上TimeRange，系統會根據設置TimeRange決定是查詢熱區，冷區仍是冷熱都查。具體的使用方式能夠參考HBase加強版幫助文檔中的冷存儲和冷熱分離章節

一體化的冷熱分離方案徹底避免了分庫方案的種種弊端。

分庫方案雲HBase加強版冷熱分離一體化運維複雜度須要運維冷熱兩個庫，並可能爲異構數據庫業務冷熱數據都在同一個庫中數據一致性兩個庫之間數據一致性很難保證冷熱數據在同一個表中，不存在一致性問題查詢複雜度查詢複雜度高，須要分別查兩個庫，查詢複雜度高冷熱數據一體化，業務查詢無需改造使用複雜度使用複雜度高，涉及到兩個庫的配置和查詢接口開發使用簡單，冷熱分離一個配置搞定

最後

雲HBase加強版是基於阿里內部HBase分支(別稱Lindorm)構建，歷經9年大規模考驗，屢次支持天貓雙十一，服務於阿里經濟體中的淘寶，天貓，支付寶，高德，優酷等幾乎全部部門。阿里內部署超過12000臺機器，主打成熟穩定、高性能、低成本、多租戶及安全等大規模場景追求的能力，並提供了最高7倍於HBase開源版本的性能和一半的存儲成本。冷熱分離只是HBase加強版衆多企業級特性中的一個。歡迎你們使用HBase加強版，直達鏈接：https://promotion.aliyun.com/ntms/act/hbaseenhancededition.html

招賢納士

歡迎對數據庫、雲計算、大數據有興趣的同窗，加入阿里雲數據庫NoSQL團隊（校招&社招），一塊兒探索學習數據庫及存儲計算的創新動向，在雲計算的蓬勃發展中作更好的本身！

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。