您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“怎么掌握HBase架構(gòu)”的有關(guān)知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細閱讀,能夠?qū)W有所成!
通過前文的描述,我們知道在HBase寫時,相同Cell(RowKey/ColumnFamily/Column相同)并不保證在一起,甚至刪除一個Cell也只是寫入一個新的Cell,它含有Delete標(biāo)記,而不一定將一個Cell真正刪除了,因而這就引起了一個問題,如何實現(xiàn)讀的問題?要解決這個問題,我們先來分析一下相同的Cell可能存在的位置:首先對新寫入的Cell,它會存在于MemStore中;然后對之前已經(jīng)Flush到HDFS中的Cell,它會存在于某個或某些StoreFile(HFile)中;最后,對剛讀取過的Cell,它可能存在于BlockCache中。既然相同的Cell可能存儲在三個地方,在讀取的時候只需要掃瞄這三個地方,然后將結(jié)果合并即可(Merge Read),在HBase中掃瞄的順序依次是:BlockCache、MemStore、StoreFile(HFile)。其中StoreFile的掃瞄先會使用Bloom Filter過濾那些不可能符合條件的HFile,然后使用Block Index快速定位Cell,并將其加載到BlockCache中,然后從BlockCache中讀取。我們知道一個HStore可能存在多個StoreFile(HFile),此時需要掃瞄多個HFile,如果HFile過多又是會引起性能問題。
MemStore每次Flush會創(chuàng)建新的HFile,而過多的HFile會引起讀的性能問題,那么如何解決這個問題呢?HBase采用Compaction機制來解決這個問題,有點類似Java中的GC機制,起初Java不停的申請內(nèi)存而不釋放,增加性能,然而天下沒有免費的午餐,最終我們還是要在某個條件下去收集垃圾,很多時候需要Stop-The-World,這種Stop-The-World有些時候也會引起很大的問題,比如參考本人寫的這篇文章,因而設(shè)計是一種權(quán)衡,沒有完美的。還是類似Java中的GC,在HBase中Compaction分為兩種:Minor Compaction和Major Compaction。
Minor Compaction是指選取一些小的、相鄰的StoreFile將他們合并成一個更大的StoreFile,在這個過程中不會處理已經(jīng)Deleted或Expired的Cell。一次Minor Compaction的結(jié)果是更少并且更大的StoreFile。(這個是對的嗎?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的一個HFile/SSTable稱為一次Minor Compaction)
Major Compaction是指將所有的StoreFile合并成一個StoreFile,在這個過程中,標(biāo)記為Deleted的Cell會被刪除,而那些已經(jīng)Expired的Cell會被丟棄,那些已經(jīng)超過最多版本數(shù)的Cell會被丟棄。一次Major Compaction的結(jié)果是一個HStore只有一個StoreFile存在。Major Compaction可以手動或自動觸發(fā),然而由于它會引起很多的IO操作而引起性能問題,因而它一般會被安排在周末、凌晨等集群比較閑的時間。
更形象一點,如下面兩張圖分別表示Minor Compaction和Major Compaction。
最初,一個Table只有一個HRegion,隨著數(shù)據(jù)寫入增加,如果一個HRegion到達一定的大小,就需要Split成兩個HRegion,這個大小由hbase.hregion.max.filesize指定,默認為10GB。當(dāng)split時,兩個新的HRegion會在同一個HRegionServer中創(chuàng)建,它們各自包含父HRegion一半的數(shù)據(jù),當(dāng)Split完成后,父HRegion會下線,而新的兩個子HRegion會向HMaster注冊上線,處于負載均衡的考慮,這兩個新的HRegion可能會被HMaster分配到其他的HRegionServer中。關(guān)于Split的詳細信息。
在HRegion Split后,兩個新的HRegion最初會和之前的父HRegion在相同的HRegionServer上,出于負載均衡的考慮,HMaster可能會將其中的一個甚至兩個重新分配的其他的HRegionServer中,此時會引起有些HRegionServer處理的數(shù)據(jù)在其他節(jié)點上,直到下一次Major Compaction將數(shù)據(jù)從遠端的節(jié)點移動到本地節(jié)點。
當(dāng)一臺HRegionServer宕機時,由于它不再發(fā)送Heartbeat給ZooKeeper而被監(jiān)測到,此時ZooKeeper會通知HMaster,HMaster會檢測到哪臺HRegionServer宕機,它將宕機的HRegionServer中的HRegion重新分配給其他的HRegionServer,同時HMaster會把宕機的HRegionServer相關(guān)的WAL拆分分配給相應(yīng)的HRegionServer(將拆分出的WAL文件寫入對應(yīng)的目的HRegionServer的WAL目錄中,并并寫入對應(yīng)的DataNode中),從而這些HRegionServer可以Replay分到的WAL來重建MemStore。
在NoSQL中,存在著名的CAP理論,即Consistency、Availability、Partition Tolerance不可全得,目前市場上基本上的NoSQL都采用Partition Tolerance以實現(xiàn)數(shù)據(jù)得水平擴展,來處理Relational DataBase遇到的無法處理數(shù)據(jù)量太大的問題,或引起的性能問題。因而只有剩下C和A可以選擇。HBase在兩者之間選擇了Consistency,然后使用多個HMaster以及支持HRegionServer的failure監(jiān)控、ZooKeeper引入作為協(xié)調(diào)者等各種手段來解決Availability問題,然而當(dāng)網(wǎng)絡(luò)的Split-Brain(Network Partition)發(fā)生時,它還是無法完全解決Availability的問題。從這個角度上,Cassandra選擇了A,即它在網(wǎng)絡(luò)Split-Brain時還是能正常寫,而使用其他技術(shù)來解決Consistency的問題,如讀的時候觸發(fā)Consistency判斷和處理。這是設(shè)計上的限制。
從實現(xiàn)上的優(yōu)點:
HBase采用強一致性模型,在一個寫返回后,保證所有的讀都讀到相同的數(shù)據(jù)。
通過HRegion動態(tài)Split和Merge實現(xiàn)自動擴展,并使用HDFS提供的多個數(shù)據(jù)備份功能,實現(xiàn)高可用性。
采用HRegionServer和DataNode運行在相同的服務(wù)器上實現(xiàn)數(shù)據(jù)的本地化,提升讀寫性能,并減少網(wǎng)絡(luò)壓力。
內(nèi)建HRegionServer的宕機自動恢復(fù)。采用WAL來Replay還未持久化到HDFS的數(shù)據(jù)。
可以無縫的和Hadoop/MapReduce集成。
實現(xiàn)上的缺點:
WAL的Replay過程可能會很慢。
災(zāi)難恢復(fù)比較復(fù)雜,也會比較慢。
Major Compaction會引起IO Storm。
“怎么掌握HBase架構(gòu)”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。