?

9月27日，阿里云HBase發布了冷存儲特性。用戶可以在購買云HBase實例時選擇冷存儲作為一個附加的存儲空間，并通過建表語句指定將冷數據存放在冷存儲介質上面，從而降低存儲成本。冷存儲的存儲成本僅為高效云盤的1/3，適用于數據歸檔、訪問頻率較低的歷史數據等各種場景。

阿里云HBase是基于Apache HBase深度優化的全托管、PB級、千萬級QPS隨機讀寫的云數據庫，其在物聯網、車聯網、用戶畫像、歷史數據存儲、AI人工智能、Feeds等場景有廣泛的應用。自產品發布以來，我們一直在努力優化，為用戶提供更高的性能和更低的成本。此次發布的冷存儲特性，針對冷數據存儲的場景，可以在保證數據隨時可訪問及不低于云盤的寫入性能的前提下，大幅降低用戶的存儲成本。

適用場景

一般隨著業務的發展，HBase中存儲的數據量會逐漸變大。在這些數據中，業務最關心的，最常訪問的，往往是某些特定范圍的數據，比如說最近7天的數據，業務對這類數據訪問頻次高，延遲要求高，即所謂的熱數據。而其他的數據，一般訪問量極少，性能要求不高, 但這類數據往往數據量大，即冷數據。如果能把冷熱數據分離開，把熱數據存儲在性能更好的介質中，而把龐大的冷數據放到成本更低的介質中，從而實現把更多優質資源用來提高熱數據的讀寫性能，同時節省存儲成本的目的。

通常來說，冷數據具有如下特點：
1 數據量大，因此對成本更敏感。
2 較低的訪問頻率，因此可以容忍更低的訪問qps和更高的訪問延時，但是大多數場景下都要求隨時可以訪問。
3 寫入tps并不低。無論是歷史數據還是歸檔數據，他們的寫入速度其實都和熱數據相當。

基于以上這些特點，HBase冷存儲在優化成本的同時，提供了和高效云盤相當的寫入性能，并保證數據隨時可訪問。當然，作為優化成本的代價，冷存儲上HBase的讀操作qps較低，延時（在不命中緩存情況下）也比云盤要高一些。

下表對HBase上的冷存儲和高效云盤兩種形態做了比較?？梢钥闯?#xff0c;冷存儲在冷數據場景下有極大的優勢。

存儲介質	冷存儲	高效云盤
存儲成本(元/GB/月)	0.2	0.7
單機最大支持數據量	11TB	8TB
起步購買量	800GB	800GB
擴容最小單位	1GB	1GB
機型要求	無要求	無要求
寫入性能	較好（具體數據和機型有關）	較好（具體數據和機型有關）
查詢性能	較差（具體數據和機型有關）	較好（具體數據和機型有關）

大幅降低存儲成本

只看存儲成本的話，冷存儲的成本不到高效云盤的1/3，由于冷數據的量通常都比較大，存儲介質的成本占大頭，因此即使考慮到計算資源的成本不變，整體上成本仍然有很大幅度的下降。
以某車聯網應用為例：擁有10萬臺車， 每臺車每30秒上傳7K的包，數據半年后就很少訪問了，但是有時會有查詢歷史數據的需求，所以這部分冷數據又不能刪除。有了云HBase的冷存儲特性，就可以把半年之前的數據放在冷存儲上面節約存儲成本，半年內的數據仍然放在高效云盤保證熱數據的高效訪問。
我們以3年的存儲 ( 約2P)來估算成本，見下圖。

可見，對于冷熱數據混合的場景，通過把冷數據存放在冷存儲上面可以大幅降低存儲成本。對于純冷數據的場景（例如歸檔數據），節省的成本就更加可觀了。

寫入性能與云盤相當

測試環境：
HDFS 6臺8核32G DataNode
HBase 1臺8核32G RegionServer
每臺ECS掛載4塊300G 高效云盤valueSize=100B
threads=120
測試結果：

?

無需代碼改動，輕松搞定冷數據

冷存儲可以獨立購買，作為一個附加存儲空間使用。購買冷存儲介質后，可以在建表時候中指定把表創建在冷存儲上（即冷表），默認是創建在云盤介質上（即熱表）。HBase會根據表的屬性將數據放在對應的存儲介質上面，這個細節對應用是透明的，應用不需要關心表的數據存儲在哪里，都是通過hbase的API對表進行讀寫操作，因此訪問冷數據的代碼不需要做任何改動。

注意事項
1.冷存儲的__讀IOPS__能力很低，所以冷表只適合存儲冷數據。
2.寫入吞吐上，冷表和基于高效云盤的熱表相當，可以放心寫入數據。
3.建議平均每個core節點管理冷數據不要超過10T。如果是同時有冷熱表的集群，需要看region數量來衡量。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的阿里云HBase发布冷存储特性，助你不改代码，1/3成本轻松搞定冷数据处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。