摘要： 9月27日，阿里雲HBase釋出了冷儲存特性。使用者可以在購買雲HBase例項時選擇冷儲存作為一個附加的儲存空間，並通過建表語句指定將冷資料存放在冷儲存介質上面，從而降低儲存成本。冷儲存的儲存成本僅為高效雲盤的1/3，適用於資料歸檔、訪問頻率較低的歷史資料等各種場景。

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

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

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

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

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

下表對HBase上的冷儲存和高效雲盤兩種形態做了比較。可以看出，冷儲存在冷資料場景下有極大的優勢。

大幅降低儲存成本
只看儲存成本的話，冷儲存的成本不到高效雲盤的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數量來衡量。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。