如何解析HBase冷熱分離技術(shù)原理

本篇文章給大家分享的是有關(guān)如何解析HBase冷熱分離技術(shù)原理，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

前言

HBase是當(dāng)下流行的一款海量數(shù)據(jù)存儲(chǔ)的分布式數(shù)據(jù)庫。往往海量數(shù)據(jù)存儲(chǔ)會(huì)涉及到一個(gè)成本問題，如何降低成本。常見的方案就是通過冷熱分離來治理數(shù)據(jù)。冷數(shù)據(jù)可以用更高的壓縮比算法（ZSTD），更低副本數(shù)算法（Erasure Coding），更便宜存儲(chǔ)設(shè)備（HDD，高密集型存儲(chǔ)機(jī)型）。

HBase冷熱分離常見解決方案

1.主備集群

備（冷）集群用更廉價(jià)的硬件，主集群設(shè)置TTL，這樣當(dāng)數(shù)據(jù)熱度退去，冷數(shù)據(jù)自然只在冷集群有。

cdn.com/b0b393c4b9d03d513e943b490444ed8d40ca9937.png">

優(yōu)點(diǎn)：方案簡(jiǎn)單，現(xiàn)成內(nèi)核版本都能搞
缺點(diǎn)：維護(hù)開銷大，冷集群CPU存在浪費(fèi)

1.x版本的HBase在不改內(nèi)核情況下，基本只能有這種方案。

2.HDFS Archival Storage + HBase CF-level Storage Policy

需要在2.x之后的版本才能使用。結(jié)合HDFS分層存儲(chǔ)能力 + 在Table層面指定數(shù)據(jù)存儲(chǔ)策略，實(shí)現(xiàn)同集群下，不同表數(shù)據(jù)的冷熱分離。

優(yōu)點(diǎn)：同一集群冷熱分離，維護(hù)開銷少，更靈活的配置不同業(yè)務(wù)表的策略
缺點(diǎn)：磁盤配比是個(gè)很大的問題，不同業(yè)務(wù)冷熱配比是不一樣的，比較難整合在一起，一旦業(yè)務(wù)變動(dòng)，集群硬件配置是沒法跟著變的。

云HBase冷熱分離解決方案

上述2套方案都不是最好的方案，對(duì)于云上來說。第一套方案就不說了，客戶搞2個(gè)集群，對(duì)于數(shù)據(jù)量不大的客戶其實(shí)根本降不了成本。第二套方案，云上客戶千千萬，業(yè)務(wù)各有各樣，磁盤配置是很難定制到合適的狀態(tài)。

云上要做 cloud native 的方案，必須滿足同集群下，極致的彈性伸縮，才能真正意義上做到產(chǎn)品化。云上低成本，彈性存儲(chǔ)，只有OSS了。所以很自然的想到如下架構(gòu)：

實(shí)現(xiàn)這樣的架構(gòu)，最直接的想法是直接改HBase內(nèi)核：1）增加冷表數(shù)據(jù)標(biāo)記 2）根據(jù)標(biāo)記增加寫OSS的IO路徑。

這樣做的缺陷非常明顯，你的外部系統(tǒng)（如：備份恢復(fù)，數(shù)據(jù)導(dǎo)入導(dǎo)出）很難兼容這些改動(dòng)，他們需要感知哪些是冷文件得去OSS哪個(gè)位置讀，哪些是熱文件得去部署在云盤上的HDFS上讀。這些本質(zhì)上都是一些重復(fù)的工作，所以從架構(gòu)設(shè)計(jì)角度來看必須抽象出一層。這一層能讀寫HDFS文件，讀寫OSS文件，感知冷熱文件。這一層也就是我最后設(shè)計(jì)出的ApsaraDB FileSystem，實(shí)現(xiàn)了Hadoop FileSystem API。對(duì)于HBase，備份恢復(fù)，數(shù)據(jù)導(dǎo)入導(dǎo)出等系統(tǒng)只要替換原先FileSystem的實(shí)現(xiàn)即可獲得冷熱分離的功能。

下面將詳細(xì)闡述，這套FileSystem設(shè)計(jì)的細(xì)節(jié)與難點(diǎn)。

ApsaraDB FileSystem 設(shè)計(jì)

核心難點(diǎn)A

1.OSS并非文件系統(tǒng)

OSS并不是一個(gè)真正意義上的文件系統(tǒng)，它僅僅是兩級(jí)映射 bucket/object，所以它是對(duì)象存儲(chǔ)。你在OSS上看到類似這樣一個(gè)文件：
/root/user/gzh/file。你會(huì)以為有3層目錄+1個(gè)文件。實(shí)際上只有一個(gè)對(duì)象，這個(gè)對(duì)象的key包含了/字符罷了。

這么帶來的一個(gè)問題是，你要想在其上模擬出文件系統(tǒng)，你必須先能創(chuàng)建目錄。很自然想到的是用/結(jié)尾的特殊對(duì)象代表目錄對(duì)象。Hadoop社區(qū)開源的OssFileSystem就是這么搞的。有了這個(gè)方法，就能判斷到底存不存在某個(gè)目錄，能不能創(chuàng)建文件，不然會(huì)憑空創(chuàng)建出一個(gè)文件，而這個(gè)文件沒有父目錄。

當(dāng)然你這么做依然會(huì)有問題。除了開銷比較大（創(chuàng)建深層目錄多次HTTP請(qǐng)求OSS），最嚴(yán)重的是正確性的問題。試想一下下面這個(gè)場(chǎng)景：
把目錄/root/user/source rename 成 /root/user/target。這個(gè)過程除了該目錄，它底下的子目錄，子目錄里的子文件都會(huì)跟著變。類似這樣：/root/user/source/file => /root/user/target/file。這很好理解，文件系統(tǒng)就是一顆樹，你rename目錄，實(shí)際是把某顆子樹移動(dòng)到另一個(gè)節(jié)點(diǎn)下。這個(gè)在NameNode里的實(shí)現(xiàn)也很簡(jiǎn)單，改變下樹結(jié)構(gòu)即可。

但是如果是在OSS上，你要做rename，那你不得不遞歸遍歷/root/user/source把其下所有目錄對(duì)象，文件對(duì)象都rename。因?yàn)槟銢]法通過移動(dòng)子樹這樣一個(gè)簡(jiǎn)單操作一步到位。這里帶來的問題就是，假設(shè)你遞歸遍歷到一半，掛了。那么就可能會(huì)出現(xiàn)一半目錄或文件到了目標(biāo)位置，一半沒過去。這樣rename這個(gè)操作就不是原子的了，本來你要么rename成功，整個(gè)目錄下的內(nèi)容到新的地方，要么沒成功就在原地。所以正確性會(huì)存在問題，像HBase這樣依賴rename操作將臨時(shí)數(shù)據(jù)目錄移動(dòng)到正式目錄來做數(shù)據(jù)commit，就會(huì)面臨風(fēng)險(xiǎn)。

2.OSS rename實(shí)則是數(shù)據(jù)拷貝

前面我們提到了rename，在正常文件系統(tǒng)中應(yīng)該是一個(gè)輕量級(jí)的，數(shù)據(jù)結(jié)構(gòu)修改操作。但是OSS并沒有rename這個(gè)操作實(shí)際上，rename得通過 CopyObject + DeleteObject 兩個(gè)操作完成。首先是copy成目標(biāo)名字，然后delete掉原先的Object。這里有2個(gè)明顯的問題，一個(gè)是copy是深度拷貝開銷很大，直接會(huì)影響HBase的性能。另一個(gè)是rename拆分成2個(gè)操作，這2個(gè)操作是沒法在一個(gè)事物里的，也就是說：可能存在copy成功，沒delete掉的情況，此時(shí)你需要回滾，你需要delete掉copy出來的對(duì)象，但是delete依然可能不成功。所以rename操作本身實(shí)現(xiàn)上，正確性就難以保證了。

解決核心難點(diǎn)A

解決上面2個(gè)問題，需要自己做元數(shù)據(jù)管理，即相當(dāng)于自己維護(hù)一個(gè)文件系統(tǒng)樹，OSS上只放數(shù)據(jù)文件。而因?yàn)槲覀儹h(huán)境中仍然有HDFS存儲(chǔ)在（為了放熱數(shù)據(jù)），所以直接復(fù)用NameNode代碼，讓NodeNode幫助管理元數(shù)據(jù)。所以整體架構(gòu)就出來了：

ApsaraDB FileSystem（以下簡(jiǎn)稱ADB FS）將云端存儲(chǔ)分為：主存（PrimaryStorageFileSystem）和 冷存（ColdStorageFileSystem）。由ApsaraDistributedFileSystem類（以下簡(jiǎn)稱ADFS）負(fù)責(zé)管理這兩類存儲(chǔ)文件系統(tǒng)，并且由ADFS負(fù)責(zé)感知冷熱文件。

ApsaraDistributedFileSystem： 總?cè)肟?，?fù)責(zé)管理冷存和主存，數(shù)據(jù)該從哪里讀，該寫入哪里（ADFS）。
主存：PrimaryStorageFileSystem 默認(rèn)實(shí)現(xiàn)是 DistributedFileSystem（HDFS）
冷存：ColdStorageFileSystem 默認(rèn)實(shí)現(xiàn)是 HBaseOssFileSystem（HOFS） ，基于OSS實(shí)現(xiàn)的Hadoop API文件系統(tǒng)，可以模擬目錄對(duì)象單獨(dú)使用，也可以只作為冷存讀寫數(shù)據(jù)，相比社區(qū)版本有針對(duì)性優(yōu)化，后面會(huì)講。

具體，NameNode如何幫助管理冷存上的元數(shù)據(jù)，很簡(jiǎn)單。ADFS在主存上創(chuàng)建同名索引文件，文件內(nèi)容是索引指向冷存中對(duì)應(yīng)的文件。實(shí)際數(shù)據(jù)在冷存中，所以冷存中的文件有沒有目錄結(jié)構(gòu)無所謂，只有一級(jí)文件就行。我們?cè)倏聪乱籸ename操作過程，就明白了，rename目錄的場(chǎng)景也同理，直接在NameNode中rename就行。對(duì)于熱文件，相當(dāng)于全部代理HDFS操作即可，冷文件要在HDFS上創(chuàng)建索引文件，然后寫數(shù)據(jù)文件到OSS，然后關(guān)聯(lián)起來。

核心難點(diǎn)B

引入元數(shù)據(jù)管理解決方案，又會(huì)遇到新的問題：是索引文件和冷存中數(shù)據(jù)文件一致性問題。
我們可能會(huì)遇到如下場(chǎng)景：

• 主存索引文件存在，冷存數(shù)據(jù)文件不存在

• 冷存數(shù)據(jù)文件存在，主存索引文件不存住

• 主存索引文件信息不完整，無法定位冷存數(shù)據(jù)文件

先排除BUG或者人為刪除數(shù)據(jù)文件因素，上訴3種情況都會(huì)由于程序crash產(chǎn)生。也就是說我們要想把法，把生成索引文件，寫入并生成冷數(shù)據(jù)文件，關(guān)聯(lián)，這3個(gè)操作放在一個(gè)事物里。這樣才能具備原子性，才能保證要么創(chuàng)建冷文件成功，那么索引信息是完整的，也指向一個(gè)存在的數(shù)據(jù)文件。要么創(chuàng)建冷文件失?。òㄖ型境绦騝rash），永遠(yuǎn)也見不到這個(gè)冷文件。

解決核心難點(diǎn)B

核心思想是利用主存的rename操作，因?yàn)橹鞔娴膔ename是具備原子性的。我們先在主存的臨時(shí)目錄中生產(chǎn)索引文件，此時(shí)索引文件內(nèi)容已經(jīng)指向冷存中的一個(gè)路徑（但是實(shí)際上這個(gè)路徑的數(shù)據(jù)文件還沒開始寫入）。在冷存完成寫入，正確close后，那么此時(shí)我們已經(jīng)有完整且正確的索引文件&數(shù)據(jù)文件。然后通過rename一把將索引文件改到用戶實(shí)際需要寫入到目標(biāo)路徑，即可。

如果中途進(jìn)程crash，索引文件要么已經(jīng)rename成功，要么索引文件還在臨時(shí)目錄。在臨時(shí)目錄我們認(rèn)為寫入沒有完成，是失敗的。然后我們通過清理線程，定期清理掉N天以前臨時(shí)目錄的文件即可。所以一旦rename成功，那目標(biāo)路徑上的索引文件一定是完整的，一定會(huì)指向一個(gè)寫好的數(shù)據(jù)文件。

為什么我們需要先寫好路徑信息在索引文件里？因?yàn)槿绻葘憯?shù)據(jù)文件，在這個(gè)過程中crash了，那我們是沒有索引信息指向這個(gè)數(shù)據(jù)文件的，從而造成類似“內(nèi)存泄漏”的問題。

冷熱文件標(biāo)記

對(duì)于主存，需要實(shí)現(xiàn)給文件冷熱標(biāo)記的功能，通過標(biāo)記判斷要打開怎樣的數(shù)據(jù)讀寫流。這點(diǎn)NameNode可以通過給文件設(shè)置StoragePolicy實(shí)現(xiàn)。這個(gè)過程就很簡(jiǎn)單了，不詳細(xì)贅述，下面說HBaseOssFileSystem寫入優(yōu)化設(shè)計(jì)。

HBaseOssFileSystem 寫入優(yōu)化

在說HOFS寫設(shè)計(jì)之前，我們先要理解Hadoop社區(qū)版本的OssFileSystem設(shè)計(jì)（這也是社區(qū)用戶能直接使用的版本）。

社區(qū)版本寫入設(shè)計(jì)

Write -> OutputStream -> disk buffer(128M) -> FileInputStream -> OSS

這個(gè)過程就是先寫入磁盤，磁盤滿128M后，將這128M的block包裝成FileInputStream再提交給OSS。這個(gè)設(shè)計(jì)主要是考慮了OSS請(qǐng)求成本，OSS每次請(qǐng)求都是要收費(fèi)的，但是內(nèi)網(wǎng)流量不計(jì)費(fèi)。如果你1KB寫一次，費(fèi)用就很高了，所以必須大塊寫。而且OSS大文件寫入，設(shè)計(jì)最多讓你提交10000個(gè)block（OSS中叫MultipartUpload），如果block太小，那么你能支持的最大文件大小也是受限。

所以要攢大buffer，另外一個(gè)因素是Hadoop FS API提供的是OutputStream讓你不斷write。OSS提供的是InputStream，讓你提供你要寫入內(nèi)容，它自己不斷讀取。這樣你必然要通過一個(gè)buffer去轉(zhuǎn)換。

這里會(huì)有比較大的一個(gè)問題，就是性能慢。寫入磁盤，再讀取磁盤，多了這么兩輪會(huì)比較慢，雖然有PageCache存在，讀取過程不一定有IO。那你肯定想，用內(nèi)存當(dāng)buffer不就好了。內(nèi)存當(dāng)buffer的問題就是前面說的，有費(fèi)用，所以buffer不能太小。所以你每個(gè)文件要開128M內(nèi)存，是不可能的。更何況當(dāng)你提交給OSS的時(shí)候，你要保證能繼續(xù)寫入新數(shù)據(jù)，你得有2塊128M內(nèi)存滾動(dòng)，這個(gè)開銷幾乎不能接受。

HBaseOssFileSystem 寫入設(shè)計(jì)

我們既要解決費(fèi)用問題，也要解決性能問題，同時(shí)要保證開銷很低，看似不可能，那么怎么做呢？

這里要利用的就是這個(gè)InputStream，OSS讓你提供InputStream，并從中讀取你要寫入的內(nèi)容。那么我們可以設(shè)計(jì)一個(gè)流式寫入，當(dāng)我傳入這個(gè)InputStream給OSS的時(shí)候，流中并不一定得有數(shù)據(jù)。此時(shí)OSS調(diào)read讀取數(shù)據(jù)會(huì)block在read調(diào)用上。等用戶真的寫入數(shù)據(jù)，InputStream中才會(huì)有數(shù)據(jù)，這時(shí)候OSS就能順利讀到數(shù)據(jù)。當(dāng)OSS讀了超過128M數(shù)據(jù)時(shí)候，InputStream會(huì)自動(dòng)截?cái)?，返回EOF，這樣OSS會(huì)以為流已經(jīng)結(jié)束了，那么這塊數(shù)據(jù)就算提交完成。

所以我們本質(zhì)只要開發(fā)這么一個(gè)特殊的InputStream即可。用戶向Hadoop API提供的OutputStream中寫入數(shù)據(jù)，數(shù)據(jù)每填滿一個(gè)page（2M）就發(fā)給InputStream讓其可讀取。OuputStream相當(dāng)于生產(chǎn)者，InputStream相當(dāng)于消費(fèi)者。這里的內(nèi)存開銷會(huì)非常低，因?yàn)樯a(chǎn)者速度和消費(fèi)者速度相近時(shí)，也就2個(gè)page的開銷。最后將這整套實(shí)現(xiàn)封裝成OSSOutputStream類，當(dāng)用戶要寫入冷文件時(shí)，實(shí)際提供的是OSSOutputStream，這里面就包含了這個(gè)特殊InputStream的控制過程。

當(dāng)然實(shí)際生產(chǎn)中，我們會(huì)對(duì)page進(jìn)行控制，每個(gè)文件設(shè)置最多4個(gè)page。并且這4個(gè)page循環(huán)利用，減少對(duì)GC對(duì)影響。

性能對(duì)比1：社區(qū)版本 vs 云HBase版

因?yàn)椴挥脤懘疟P，所以寫入吞吐可以比社區(qū)的高很多，下圖為HBase1.0上測(cè)試結(jié)果。在一些大KV，寫入壓力更大的場(chǎng)景，實(shí)測(cè)可以接近1倍。這個(gè)比較是通過替換ADFS冷存的實(shí)現(xiàn)(用社區(qū)版本和云HBase版本)，都避免了rename深拷貝問題。如果直接裸用社區(qū)版本而不用ADFS那性能會(huì)差數(shù)倍。

性能對(duì)比2：熱表 vs 冷表

熱表數(shù)據(jù)在云盤，冷表數(shù)據(jù)在OSS。

得益于上述優(yōu)化，加上冷表WAL也是放HDFS的，并且OSS相對(duì)HBase來說是大集群（吞吐上限高），冷表的HDFS只用抗WAL寫入壓力。所以冷表吞吐反而會(huì)比熱表略高一點(diǎn)點(diǎn)。

不管怎么說，冷表的寫入性能和熱表相當(dāng)了，這樣的表現(xiàn)已經(jīng)相當(dāng)不錯(cuò)了?；臼遣粫?huì)影響用戶灌數(shù)據(jù)，否則使用冷存后，吞吐掉很多，那意味著要更多機(jī)器，那這功能就沒什么意義了。

以上就是如何解析HBase冷熱分離技術(shù)原理，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。