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

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供枝江網(wǎng)站建設、枝江做網(wǎng)站、枝江網(wǎng)站設計、枝江網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、枝江企業(yè)網(wǎng)站模板建站服務，十年枝江做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

前言

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

HBase冷熱分離常見解決方案

1.主備集群

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

cdn.com/b0b393c4b9d03d513e943b490444ed8d40ca9937.png">

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

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

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

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

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

云HBase冷熱分離解決方案

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

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

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

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

下面將詳細闡述，這套FileSystem設計的細節(jié)與難點。

ApsaraDB FileSystem 設計

核心難點A

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

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

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

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

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

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

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

解決核心難點A

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

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

ApsaraDistributedFileSystem： 總?cè)肟冢撠煿芾砝浯婧椭鞔妫瑪?shù)據(jù)該從哪里讀，該寫入哪里（ADFS）。
主存：PrimaryStorageFileSystem 默認實現(xiàn)是 DistributedFileSystem（HDFS）
冷存：ColdStorageFileSystem 默認實現(xiàn)是 HBaseOssFileSystem（HOFS） ，基于OSS實現(xiàn)的Hadoop API文件系統(tǒng)，可以模擬目錄對象單獨使用，也可以只作為冷存讀寫數(shù)據(jù)，相比社區(qū)版本有針對性優(yōu)化，后面會講。

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

核心難點B

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

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

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

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

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

解決核心難點B

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

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

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

冷熱文件標記

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

HBaseOssFileSystem 寫入優(yōu)化

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

社區(qū)版本寫入設計

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

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

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

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

HBaseOssFileSystem 寫入設計

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

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

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

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

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

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

性能對比2：熱表 vs 冷表

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

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

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

以上就是如何解析HBase冷熱分離技術(shù)原理，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

分享名稱：如何解析HBase冷熱分離技術(shù)原理
標題路徑：http://vcdvsql.cn/article30/pepgpo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護、做網(wǎng)站、標簽優(yōu)化、電子商務、網(wǎng)站導航、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)