HBase Flush對(duì)讀寫服務(wù)的影響是什么

本篇內(nèi)容介紹了“HBase Flush對(duì)讀寫服務(wù)的影響是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

HBase的Flush操作的觸發(fā)條件：

1)Manual調(diào)用，HRegionInterface#flushRegion，可以被用戶態(tài)org.apache.hadoop.hbase.client.HBaseAdmin調(diào)用flush操作實(shí)現(xiàn)，該操作會(huì)直接觸發(fā)HRegion的internalFlush。

2)HRegionServer的一次更新操作，使得整個(gè)內(nèi)存使用超過警戒線。警戒線是globalMemStoreLimit, RS_JVM_HEAPSIZE * conf.getFloat(“hbase.regionserver.global.memstore.upperLimit”)，凡是超過這個(gè)值的情況，會(huì)直接觸發(fā)FlushThread，從全局的HRegion中選擇一個(gè)，將其MemStore刷入hdfs，從而保證rs全局的memstore容量在可控的范圍。

RS上HRegion的選擇算法：

步驟1：RS上的Region，按照其MemStore的容量進(jìn)行排序。

步驟2：選出Region下的Store中的StoreFile的個(gè)數(shù)未達(dá)到hbase.hstore.blockingStoreFiles，并且MemStore使用最多的Region。— bestFlushableRegion

步驟3:選出Region下的MemStore使用最多的Region?！?bestAnyRegion

步驟4：如果bestAnyRegion的memstore使用量超出了bestFlushableRegion的兩倍，這從另外一個(gè)角度說明，雖然當(dāng)前bestAnyRegion有超過blockingStoreFiles個(gè)數(shù)的文件，但是考慮到RS內(nèi)存的壓力，冒著被執(zhí)行Compaction的風(fēng)險(xiǎn)，也選擇這個(gè)Region，因?yàn)槭找娲?。否則，直接使用bestFlushableRegion。

指定的Region寫入hdfs的過程：

步驟1：獲得updatesLock的寫鎖，阻塞所有對(duì)于該Region的更新操作。由此，可知Flush操作會(huì)阻塞Region區(qū)域內(nèi)Row的更新操作(Put、Delete、Increment)，因?yàn)樵谧枞虏僮髌陂g，涉及到Memstore的snapshot操作，如果不做限制，那么很可能一個(gè)put操作的多個(gè)KV，分別落在kvset和snapshot當(dāng)中，從而與hbase保證row的原子性相悖。

步驟2：mvcc推進(jìn)一次寫操作事務(wù)。每個(gè)Region維護(hù)了一個(gè)mvcc對(duì)象(Multi Version

Consistency Control)，用來控制讀寫操作的事務(wù)性。

步驟3：從HLog中獲取一個(gè)新的newSeqNum，更新HLog的lastSeqWritten。由于此時(shí)該Region的更新操作會(huì)暫停，因此，會(huì)暫時(shí)刪除lastSeqWritten記錄的<RegionName,lastSeqNum>，寫入<”snp”+RegionName, newSeqNum>到lastSeqWritten中。這里的lastSeqWritten是HLog用來存儲(chǔ)每個(gè)Regiond到當(dāng)前時(shí)刻最后一次提交操作的SeqNum。

步驟4：為Region下的每個(gè)Store的MemStore執(zhí)行snapshot操作。

如上圖所示，HRegion上Store的個(gè)數(shù)是由Table中ColumnFamily的個(gè)數(shù)確定，每個(gè)Store是由一個(gè)MemStore和數(shù)個(gè)StoreFile(HFile)文件組成，在正常的更新操作過程中，更新的內(nèi)容會(huì)寫入MemStore里的kvset結(jié)構(gòu)中。HRegion執(zhí)行Flush操作，實(shí)際上是把MemStore的內(nèi)容全部刷入hdfs的過程。雖然，目前更新操作已經(jīng)通過加寫鎖阻塞，可是讀操作仍然可以繼續(xù)，因此，在memstore執(zhí)行snapshot的過程中，通過reference，snapshot會(huì)指向kvset，然后給kvset指向一個(gè)全新的內(nèi)存區(qū)域。代碼如下：

步驟5：釋放updatesLock的寫鎖，此時(shí)該HRegion可以接收更新操作。

步驟6：更新mvcc讀版本到當(dāng)前寫版本號(hào)。

這里有一個(gè)小插曲，在更新操作時(shí)，mvcc. completeMemstoreInsert 的操作在updatesLock的范圍之外，這樣在多線程高并發(fā)情況下，就存在已經(jīng)寫入MemStore的kvset當(dāng)中，但是事務(wù)還未完成提交的情況。該場景相關(guān)代碼如下：

從4358行，我們可以清晰看到，通過updatesLock保證了更新操作寫入了MemStore的kvset，但假定Flush線程在其它更新線程4363行之后，獲得了updatesLock寫鎖，并執(zhí)行了snapshot操作。那么，這里的mvcc就會(huì)出現(xiàn)讀寫的事務(wù)號(hào)不一致的情況，因此，在Region的Flush線程就需要使用waitForRead(w)，等待更新到目前寫版本號(hào)。

步驟7：將Store內(nèi)的snapshot寫成一個(gè)StoreFile臨時(shí)文件。

步驟8：重命名storefile文件，更新Store里文件和Memstore狀態(tài)。

在步驟8完成之前，整個(gè)Hregion的讀請(qǐng)求，是和之前沒有影響的。因?yàn)樵谧x請(qǐng)求過程中，StoreScanner對(duì)于kvset和snapshot進(jìn)行進(jìn)行同步讀取，即使kvset切換成snapshot，scan的操作仍然可以繼續(xù)，這部分的內(nèi)容是由MemStoreScanner來控制。

在讀過程中，Store里的scanner有兩部份,一個(gè)是StoreFileScanner，另外一個(gè)是MemStoreScanner，它們都繼承了KeyValueScanner接口，并通過StoreScanner中的KeyValueHeap封裝起來。于此類似，在RegionScannerImpl也是通過一個(gè)KeyValueHeap把每個(gè)Store的StoreScanner封裝起來，從而直接提供對(duì)外的服務(wù)。

讀到這里，可能細(xì)心的工程師們，就會(huì)有一個(gè)疑問：Flush操作對(duì)于讀的影響究竟有沒有呢？

有影響，但比較小。在步驟8以前那些階段，MemStoreScanner做到了對(duì)于kvset與snapshot的自由切換。

如上所示，如果kvset被重置，那么theNext將不再等于kvsetNextRow，從而切換成開始從snapshot迭代器中獲取數(shù)據(jù)。

因此，在步驟1~7之間，對(duì)于讀服務(wù)影響不大。但是在步驟8操作最后一步時(shí)，需要把生成storefile更新到可用的Store中的StoreFile列表，并清除snapshot的內(nèi)容。

于是，此時(shí)ChangedReaderOberver就開始起作用了。

// Tell listeners of the change in readers.

notifyChangedReadersObservers();

這里最為關(guān)鍵的是，將storescanner用來封裝全部StoreFileScanner和MemStoreScanner的heap清空，它會(huì)觸犯的作用是在執(zhí)行next()操作時(shí)，會(huì)觸發(fā)resetScannerStack操作，會(huì)重新加載Store下的所有Scanner，并執(zhí)行seek到最后一次更新的key。這個(gè)過程會(huì)使得flush操作對(duì)于某些next操作變得突然頓一下。

“HBase Flush對(duì)讀寫服務(wù)的影響是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！