Hbase 原始碼分析之 Regionserver上的 Get 全流程
public Result get(byte[] regionName, Get get)
{
...
HRegion region = getRegion(regionName);
return region.get(get, getLockFromId(get.getLockId()));
...
}
我們看HRegion.get介面,其首先會做family檢測,保證Get中的family與Table的相符,然後通過RegionScanner.next來返回result
而Scanner是Hbase讀流程中的主要類,先做一個大概描述:
從Scanner的scan範圍來分有RegionScanner,StoreScanner,MemstoreScanner,HFileScanner;根據名稱很好理解他們的作用,而他們之間的關係:RegionScanner由一個或多個StoreScanner組成,StoreScanner由MemstoreScanner和HFileScanner組成;
再看RegionScanner類的構造形成過程:
List<KeyValueScanner> scanners = new ArrayList<KeyValueScanner>();
for (Map.Entry<byte[], NavigableSet<byte[]>> entry :
scan.getFamilyMap().entrySet())
{
Store store = stores.get(entry.getKey());
scanners.add(store.getScanner(scan, entry.getValue()));
}
this.storeHeap = new KeyValueHeap(scanners, comparator);
這段程式碼為RegionScanner類內部屬性storeHeap初始化,其內容就是Region下面所有StoreScanner的和;storeHeap是一個KeyValueHeap,從字面可以理解result就是從中獲取的
接著看store.getScanner(scan, entry.getValue())即StoreScanner類的構造形成過程:
Java程式碼
- //StoreScanner is a scanner for both the memstore and the HStore files
- List<KeyValueScanner> scanners = new LinkedList<KeyValueScanner>();
- // First the store file scanners
- if (memOnly == false) {
- List<StoreFileScanner> sfScanners = StoreFileScanner
- .getScannersForStoreFiles(store.getStorefiles(), cacheBlocks, isGet);
- // include only those scan files which pass all filters
- for (StoreFileScanner sfs : sfScanners) {
- if (sfs.shouldSeek(scan, columns)) {
- scanners.add(sfs);
- }
- }
- }
- // Then the memstore scanners
- if ((filesOnly == false) && (this.store.memstore.shouldSeek(scan))) {
- scanners.addAll(this.store.memstore.getScanners());
- }
- return scanners;
一般情況下StoreScanner中添加了HFileScanner和MemStoreScanner;
StoreFileScanner的內部屬性包括HFileScanner和Hfile.Reader,在新增前會根據timestamp,columns,bloomfilter過濾掉一部分
Scanner構造完畢以後,當最上層的RegionScanner.next時,首先會先從MemStoreScanner中獲取,如果沒有或者版本數不足,則再從HfileScanner中獲取,而從HfileScanner獲取時,先檢視是否在blockcache中,如果MISS則再從底層的HDFS中獲取block,並根據設定決定是否將Block cache到LruBlockCache中
相關推薦
Hbase 原始碼分析之 Regionserver上的 Get 全流程
當regionserver收到來自客戶端的Get請求時,呼叫介面 public Result get(byte[] regionName, Get get) { ... HRegion region = getRegion(regionName); return regio
HBase原始碼分析之HRegion上compact流程分析(二)
2016年03月03日 21:38:04 辰辰爸的技術部落格 閱讀數:2767 版權宣告:本文為博主原創文章,未經博主允許不得轉載。 https://blog.csdn.net/lipeng_bigdata/article/details/50791205
HBase原始碼分析之HRegionServer上compact流程分析
前面三篇文章中,我們詳細敘述了compact流程是如何在HRegion上進行的,瞭解了它的很多細節方面的問題。但是,這個compact在HRegionServer上是如何進行的?合併時檔案是如何選擇的呢?在這篇文章中,你將找到答案! 首先,在
HBase原始碼分析之regionserver讀取流程分析
資料的讀取包括Get和Scan2種,通過get的程式碼可以看出實際也是通過轉換為一個Scan來處理的。 //HRegion.java public List<Cell> get(Get get, boolean withCoprocessor)
netty原始碼分析之新連線接入全解析
本文收穫 通讀本文,你會了解到 1.netty如何接受新的請求 2.netty如何給新請求分配reactor執行緒 3.netty如何給每個新連線增加ChannelHandler 其實,遠不止這些~ 前序背景 讀這篇文章之前,最好掌握一些前序知識,包括netty中的r
hadoop2.7.3原始碼解析之hdfs刪除檔案全流程分析
客戶端刪除檔案 先來一段簡單的程式碼,用java的api刪除hdfs的 檔案 Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(co
hadoop原始碼解析之hdfs寫資料全流程分析---客戶端處理
DFSOutputStream介紹 DFSOutputStream概況介紹 這一節我們介紹hdfs寫資料過程中,客戶端的處理部分。客戶端的處理主要是用到了DFSOutputStream物件,從名字我們可以看出,這個是對dfs檔案系統輸出流的一個
hbase 原始碼分析(6)get 過程 詳解
上一個章節將getregionLocator的客戶端分析完了,服務端就是一個scan方法,這個等到分析SCAN的時候再做說明。 這一章節將分析GET過程。 **GET過程, 1)找到zk,拿到MATA裡的RegionService地址。 2)訪問第一
HBase原始碼分析之如何找到region location
通過client的原始碼分析,我們發現每次建立連線前需要先找到rowkey所屬region的regionserver。本篇來分析一下這個找到regionserver的整個流程。 從程式碼connection.getRegionLocator(tableName
HBase原始碼分析之KeyValue
HBase內部,單元格Cell的實現為KeyValue,它是HBase某行資料的某個單元格在記憶體中的組織形式,由Key Length、Value Length、Key、Value四大部分組成。其中,Key又由Row Length、Row、Column Fa
死磕以太坊原始碼分析之區塊上鍊入庫
> 死磕以太坊原始碼分析之區塊上鍊入庫 > > 配合以下程式碼進行閱讀:https://github.com/blockchainGuide/ > > 寫文不易,給個小關注,有什麼問題可以指出,便於大家交流學習。 ## 引言 不管是礦工挖礦還是`Fetcher`同步,`Dow
HBase源代碼分析之HRegion上MemStore的flsuh流程(二)
初始化 back represent 代碼分析 讀數 ott pass expect 出現異常 繼上篇《HBase源代碼分析之HRegion上MemStore的flsuh流程(一)》之後。我們繼續分析下HRegion上MemStore flush的核心方
Spark原始碼分析之Spark Shell(上)
https://www.cnblogs.com/xing901022/p/6412619.html 文中分析的spark版本為apache的spark-2.1.0-bin-hadoop2.7。 bin目錄結構: -rwxr-xr-x. 1 bigdata bigdata 1089 Dec
STL原始碼分析之hashtable關聯容器 上
前言 前面我們分析過RB-tree關聯容器, RB-tree在插入(可重複和不可重複), 刪除等操作時間複雜度都是O(nlngn), 以及滿足5個規則, 以及以他為底層的配接器; 本節就來分析hashtable另個關聯容器, 他在插入, 刪除等操作都可以做到O(1)的時間複雜度.
STL原始碼分析之RB-tree關聯容器 上
前言 本節將分析STL中難度很高的RB-tree, 如果對紅黑樹有所認識的那麼分析起來的難度也就不是很大, 對紅黑樹沒有太多瞭解的直接來分析的難度就非常的大了, 可以對紅黑樹有個瞭解紅黑樹之原理和演算法詳細介紹. 紅黑樹是很類似與AVL-tree的, 但是因為AVL-tree在插入,
STL原始碼分析之slist有序容器 上
前言 不同於list是Forward Iterator型別的雙向連結串列, slist是單向連結串列, 也是Bidirectional Iterator型別. slist主要耗費的空間小, 操作一些特定的操作更加的快, 同樣類似與slist, 在執行插入和刪除操作迭代器都不會像vec
STL原始碼分析之deque有序容器 上
前言 deque的功能很強大, 其複雜度也比list, vector複雜很多. deque是一個random_access_iterator_tag型別. 前面分析過vector是儲存在連續的線性空間, 頭插入和刪除其代價都很大, 當陣列滿了還要重新尋找更大的空間; deque也是一
istio原始碼分析之pilot-discovery模組分析(上)_Kubernetes中文社群
Istio是由Google/IBM/Lyft共同開發的新一代Service Mesh開源專案。 上次我們深入剖析了pilot-agent的各個功能,這次讓我們一起來看看pilot-discovery有何功能。 注:本文分析的istio程式碼版本為0.8.0,commit為0cd8d67,com
Spring Cloud Netflix Zuul原始碼分析之請求處理篇-上
微信公眾號:I am CR7如有問題或建議,請在下方留言;最近更新:2019-01-03 微信公眾號:I am CR7如有問題或建議,請在下方留言最近更新:2019-01-03 前言 經過前面兩篇文章的鋪墊,大戲正式上場。本文將對zuul是如何根據配置
RocketMQ原始碼分析之RocketMQ事務訊息實現原理上篇(二階段提交)
根據上文的描述,傳送事務訊息的入口為: TransactionMQProducer#sendMessageInTransaction: public TransactionSendResult sendMessageInTransaction(final Message msg, final Object