前言
HBase是當下流行的一款海量數據存儲的分布式數據庫。往往海量數據存儲會涉及到一個成本問題，如何降低成本。
常見的方案就是通過冷熱分離來治理數據。冷數據可以用更高的壓縮比算法（ZSTD），更低副本數算法（Erasure Coding），更便宜存儲設備（HDD，高密集型存儲機型）。
HBase冷熱分離常見解決方案
-
1.主備集群
如果是傳統開源的HBase要做冷熱分離，方案只能是搞兩個集群（主備），主集群是SSD的配置，負責在線查詢，備（冷）集群用更廉價的硬件（HDD），負責歷史查詢和並行計算等等。
主集群設置TTL，這樣當數據熱度退去，冷數據自然只在冷集群有。這兩張表之間利用Replication機制進行同步，並且客戶端需要感知兩個集群的配置。
優點：方案簡單，現成內核版本都能搞，無需改動HBase代碼；
缺點：雙集群維護開銷大，冷集群CPU存在浪費；
注意：1.x版本的HBase在不改內核情況下，基本只能有這種方案。
-
2. HDFS Archival Storage + HBase CF-level Storage Policy
在2.0的HBase的版本中新加入了一個特性，可以指定表的HDFS存在哪種介質上。這利用了HDFS的分級存儲功能，HDFS的分級存儲功能，可以將DataNode配置到不同介質的盤。
比如下圖中有三塊是機械盤一塊SSD，在表上可以設置這樣的策略，指定表的HDFS是寫在冷介質還是熱介質上，最后調到HDFS接口的時候，會根據設置的文件的屬性放置數據。
需要在2.x之后的版本才能使用。結合HDFS分層存儲能力 + 在Table層面指定數據存儲策略，實現同集群下，不同表數據的冷熱分離。
優點：同一集群冷熱分離，維護開銷少，更靈活的配置不同業務表的策略
缺點：磁盤配比是個很大的問題，不同業務冷熱配比是不一樣的，比較難整合在一起，一旦業務變動，集群硬件配置是沒法跟着變的。
-
3.雲HBase冷熱分離解決方案
上述2套方案都不是最好的方案，對於雲上來說。第一套方案就不說了，客戶搞2個集群，對於數據量不大的客戶其實根本降不了成本。
第二套方案，雲上客戶千千萬，業務各有各樣，磁盤配置是很難定制到合適的狀態。
雲上要做 cloud native 的方案，必須滿足同集群下，極致的彈性伸縮，才能真正意義上做到產品化。
雲上低成本，彈性存儲，只有OSS了。所以很自然的想到如下架構：
引用：