本篇內(nèi)容介紹了“怎么掌握HBase架構(gòu)”的有關(guān)知識(shí),在實(shí)際案例的操作過程中,不少人都會(huì)遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
大化網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),大化網(wǎng)站設(shè)計(jì)制作,有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為大化上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢,請(qǐng)找那個(gè)售后服務(wù)好的大化做網(wǎng)站的公司定做!
通過前文的描述,我們知道在HBase寫時(shí),相同Cell(RowKey/ColumnFamily/Column相同)并不保證在一起,甚至刪除一個(gè)Cell也只是寫入一個(gè)新的Cell,它含有Delete標(biāo)記,而不一定將一個(gè)Cell真正刪除了,因而這就引起了一個(gè)問題,如何實(shí)現(xiàn)讀的問題?要解決這個(gè)問題,我們先來分析一下相同的Cell可能存在的位置:首先對(duì)新寫入的Cell,它會(huì)存在于MemStore中;然后對(duì)之前已經(jīng)Flush到HDFS中的Cell,它會(huì)存在于某個(gè)或某些StoreFile(HFile)中;最后,對(duì)剛讀取過的Cell,它可能存在于BlockCache中。既然相同的Cell可能存儲(chǔ)在三個(gè)地方,在讀取的時(shí)候只需要掃瞄這三個(gè)地方,然后將結(jié)果合并即可(Merge Read),在HBase中掃瞄的順序依次是:BlockCache、MemStore、StoreFile(HFile)。其中StoreFile的掃瞄先會(huì)使用Bloom Filter過濾那些不可能符合條件的HFile,然后使用Block Index快速定位Cell,并將其加載到BlockCache中,然后從BlockCache中讀取。我們知道一個(gè)HStore可能存在多個(gè)StoreFile(HFile),此時(shí)需要掃瞄多個(gè)HFile,如果HFile過多又是會(huì)引起性能問題。
MemStore每次Flush會(huì)創(chuàng)建新的HFile,而過多的HFile會(huì)引起讀的性能問題,那么如何解決這個(gè)問題呢?HBase采用Compaction機(jī)制來解決這個(gè)問題,有點(diǎn)類似Java中的GC機(jī)制,起初Java不停的申請(qǐng)內(nèi)存而不釋放,增加性能,然而天下沒有免費(fèi)的午餐,最終我們還是要在某個(gè)條件下去收集垃圾,很多時(shí)候需要Stop-The-World,這種Stop-The-World有些時(shí)候也會(huì)引起很大的問題,比如參考本人寫的這篇文章,因而設(shè)計(jì)是一種權(quán)衡,沒有完美的。還是類似Java中的GC,在HBase中Compaction分為兩種:Minor Compaction和Major Compaction。
Minor Compaction是指選取一些小的、相鄰的StoreFile將他們合并成一個(gè)更大的StoreFile,在這個(gè)過程中不會(huì)處理已經(jīng)Deleted或Expired的Cell。一次Minor Compaction的結(jié)果是更少并且更大的StoreFile。(這個(gè)是對(duì)的嗎?BigTable中是這樣描述Minor Compaction的:As write operations execute, the size of the memtable in- creases. When the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an SSTable and written to GFS. This minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. Incom- ing read and write operations can continue while com- pactions occur. 也就是說它將memtable的數(shù)據(jù)flush的一個(gè)HFile/SSTable稱為一次Minor Compaction)
Major Compaction是指將所有的StoreFile合并成一個(gè)StoreFile,在這個(gè)過程中,標(biāo)記為Deleted的Cell會(huì)被刪除,而那些已經(jīng)Expired的Cell會(huì)被丟棄,那些已經(jīng)超過最多版本數(shù)的Cell會(huì)被丟棄。一次Major Compaction的結(jié)果是一個(gè)HStore只有一個(gè)StoreFile存在。Major Compaction可以手動(dòng)或自動(dòng)觸發(fā),然而由于它會(huì)引起很多的IO操作而引起性能問題,因而它一般會(huì)被安排在周末、凌晨等集群比較閑的時(shí)間。
更形象一點(diǎn),如下面兩張圖分別表示Minor Compaction和Major Compaction。
最初,一個(gè)Table只有一個(gè)HRegion,隨著數(shù)據(jù)寫入增加,如果一個(gè)HRegion到達(dá)一定的大小,就需要Split成兩個(gè)HRegion,這個(gè)大小由hbase.hregion.max.filesize指定,默認(rèn)為10GB。當(dāng)split時(shí),兩個(gè)新的HRegion會(huì)在同一個(gè)HRegionServer中創(chuàng)建,它們各自包含父HRegion一半的數(shù)據(jù),當(dāng)Split完成后,父HRegion會(huì)下線,而新的兩個(gè)子HRegion會(huì)向HMaster注冊上線,處于負(fù)載均衡的考慮,這兩個(gè)新的HRegion可能會(huì)被HMaster分配到其他的HRegionServer中。關(guān)于Split的詳細(xì)信息。
在HRegion Split后,兩個(gè)新的HRegion最初會(huì)和之前的父HRegion在相同的HRegionServer上,出于負(fù)載均衡的考慮,HMaster可能會(huì)將其中的一個(gè)甚至兩個(gè)重新分配的其他的HRegionServer中,此時(shí)會(huì)引起有些HRegionServer處理的數(shù)據(jù)在其他節(jié)點(diǎn)上,直到下一次Major Compaction將數(shù)據(jù)從遠(yuǎn)端的節(jié)點(diǎn)移動(dòng)到本地節(jié)點(diǎn)。
當(dāng)一臺(tái)HRegionServer宕機(jī)時(shí),由于它不再發(fā)送Heartbeat給ZooKeeper而被監(jiān)測到,此時(shí)ZooKeeper會(huì)通知HMaster,HMaster會(huì)檢測到哪臺(tái)HRegionServer宕機(jī),它將宕機(jī)的HRegionServer中的HRegion重新分配給其他的HRegionServer,同時(shí)HMaster會(huì)把宕機(jī)的HRegionServer相關(guān)的WAL拆分分配給相應(yīng)的HRegionServer(將拆分出的WAL文件寫入對(duì)應(yīng)的目的HRegionServer的WAL目錄中,并并寫入對(duì)應(yīng)的DataNode中),從而這些HRegionServer可以Replay分到的WAL來重建MemStore。
在NOSQL中,存在著名的CAP理論,即Consistency、Availability、Partition Tolerance不可全得,目前市場上基本上的NoSQL都采用Partition Tolerance以實(shí)現(xiàn)數(shù)據(jù)得水平擴(kuò)展,來處理Relational DataBase遇到的無法處理數(shù)據(jù)量太大的問題,或引起的性能問題。因而只有剩下C和A可以選擇。HBase在兩者之間選擇了Consistency,然后使用多個(gè)HMaster以及支持HRegionServer的failure監(jiān)控、ZooKeeper引入作為協(xié)調(diào)者等各種手段來解決Availability問題,然而當(dāng)網(wǎng)絡(luò)的Split-Brain(Network Partition)發(fā)生時(shí),它還是無法完全解決Availability的問題。從這個(gè)角度上,Cassandra選擇了A,即它在網(wǎng)絡(luò)Split-Brain時(shí)還是能正常寫,而使用其他技術(shù)來解決Consistency的問題,如讀的時(shí)候觸發(fā)Consistency判斷和處理。這是設(shè)計(jì)上的限制。
從實(shí)現(xiàn)上的優(yōu)點(diǎn):
HBase采用強(qiáng)一致性模型,在一個(gè)寫返回后,保證所有的讀都讀到相同的數(shù)據(jù)。
通過HRegion動(dòng)態(tài)Split和Merge實(shí)現(xiàn)自動(dòng)擴(kuò)展,并使用HDFS提供的多個(gè)數(shù)據(jù)備份功能,實(shí)現(xiàn)高可用性。
采用HRegionServer和DataNode運(yùn)行在相同的服務(wù)器上實(shí)現(xiàn)數(shù)據(jù)的本地化,提升讀寫性能,并減少網(wǎng)絡(luò)壓力。
內(nèi)建HRegionServer的宕機(jī)自動(dòng)恢復(fù)。采用WAL來Replay還未持久化到HDFS的數(shù)據(jù)。
可以無縫的和Hadoop/MapReduce集成。
實(shí)現(xiàn)上的缺點(diǎn):
WAL的Replay過程可能會(huì)很慢。
災(zāi)難恢復(fù)比較復(fù)雜,也會(huì)比較慢。
Major Compaction會(huì)引起IO Storm。
“怎么掌握HBase架構(gòu)”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!
本文名稱:怎么掌握HBase架構(gòu)
標(biāo)題路徑:http://chinadenli.net/article0/gdodoo.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站收錄、建站公司、手機(jī)網(wǎng)站建設(shè)、虛擬主機(jī)、品牌網(wǎng)站設(shè)計(jì)、全網(wǎng)營銷推廣
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)