HBASE相关

红太狼 2022-02-12 16:21 248阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2dHVsYQ_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2dHVsYQ_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2dHVsYQ_size_16_color_FFFFFF_t_70 2][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2dHVsYQ_size_16_color_FFFFFF_t_70 3][]

\---------------------------------------------------------------------------------

hbase是以rowkey，column，timestamp这三个维度来区分的。

即如果两条记录其rowkey，column，timestamp一样的话，那么hbase就会认为其是相同的数据。

Java代码

![收藏代码][icon_star.png]

1.           row     column   value   time  
2.  put      r1     cf:c1      '5'       10  
3.  put      r1     cf:c1      '6'       10  
4.  put      r1     cf:c2      '7'    
5.  put      r1     af:c2      '8'  
6.  put      r2     cf:c1      '9'

如上所示首先插入一条数据其值为5，然后又插入一条数据其值为6.

此时用客户端接口取到的都是value=‘6’的数据，这可以认为是对原数据的一个覆盖。

我们知道hbase的write数据是以append的形式追加的。只有当前compact的时候才会进行无效数据删除。

那么在compact之前hbase的存储文件就存在该记录的两份不同的数据，那么hbase是怎么区别这两份数据，并返回给用户的呢，下面从代码角度来分析

首先我们来看hbase的put过程，这个逻辑比较清除，首先根据table，和row找到相对应的region，然后和该region的regionserver通信。

其写入过程是一个wal过程，即先写日志后写内存，保证数据不会因为regionserver down而丢失。

写日志的过程不赘述了。

主要来看看写memstore的过程：

Java代码

![收藏代码][icon_star.png]

1.  private long applyFamilyMapToMemstore(Map<byte\[\], List<KeyValue>> familyMap) \{  
2.    ReadWriteConsistencyControl.WriteEntry w = null;  
3.    long size = 0;  
4.    try \{  
5.      w = rwcc.beginMemstoreInsert();  
6.    
7.      for (Map.Entry<byte\[\], List<KeyValue>> e : familyMap.entrySet()) \{  
8.        byte\[\] family = e.getKey();  
9.        List<KeyValue> edits = e.getValue();  
10.   
11.       Store store = getStore(family);  
12.       for (KeyValue kv: edits) \{  
13.         kv.setMemstoreTS(w.getWriteNumber());  
14.         size += store.add(kv);  
15.       \}  
16.     \}  
17.   \} finally \{  
18.     rwcc.completeMemstoreInsert(w);  
19.   \}  
20.   return size;  
21. \}

rwcc是用来控制读写一致性的，对于任何一个put，当其写入memstore的时候，都会设置其MemstoreTs的值。

而这个值在内存中是以一个递增的形式存在的，即新写入内存的数据比旧的其MemstoreTs大。而这个值就是用来保证在内存中的update的可靠性。举个例子，还是上面的两个put

1. put      r1     cf:c1      '5'       10  
2. put      r1     cf:c1      '6'       10

第一条记录首先写进内存其memstoreTs为1，第二条记录的memstoreTs为二，那么第二条记录在内存中就排在第一条记录前面，说到这来看看内存中数据是怎么排序的。

我们知道hbase 是以key-value存放数据的，其底层存储完全依赖HDFS文件系统。

同样在内存中存储的也是key-value，在磁盘上是以storefile（hfile）存储，且都是有序的

其排序规则如下：

（以自然序列排序 a<b,2<3,23<3）

首先比较 rowkey 小的排前面

然后是  family小的排前面

接下来按排 column

然后是timestamp 排序 时间越大的拍前面

接下来是按key的TYPE排序 有min，delete，deleteFamily，put，deletecolumn，max

最后比较文件的maxsequenceId，越大的说明越新排在前面。memstore的maxsequenceId默认是整数最大值

如果是两个相同key的put的数据都在内存里那么上面的比较规则就都不适用了，此时就会比较这两个put的memstoreTs, 大的排在前面。

我们知道一个put里面可以有很多cf，那么如果在一个put当中有两个一样的数据，此时会如何呢。

这个hbase也做了处理。一个put中维护的是一个familymap<family,map<>>格式，显然当有两条一致的数据插入时，map自动会覆盖前一条数据。

那么此时用户以指定key取该条数据的话，会遵循以下原则：

首先从定位memstore和每个storefile(一个family就是一个Hstore，包裹一个Memstore和n个storefile)的target value的row的起始处。，比较当前memstoe和storefile的keyvalue，选取最靠前的数据，若满足则返回，若不满足则取下一条知道找到为止。

显然在这个过程中上述的put的第二条数据肯定是在第一条数据前面的，所以首先会取到第二条即最新的数据~~~

hbase就是通过keyvalue的排序和get的机制来保证取到的都是最新的value

[https://punishzhou.iteye.com/blog/1266341][https_punishzhou.iteye.com_blog_1266341]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2dHVsYQ_size_16_color_FFFFFF_t_70]: /images/20220212/dd4d8afba71e48f4a2d4cd366870f89c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2dHVsYQ_size_16_color_FFFFFF_t_70 1]: /images/20220212/14d9864f5da5492ba811ed2689fe6eaa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2dHVsYQ_size_16_color_FFFFFF_t_70 2]: /images/20220212/34294695d8484982a4f629d82cbbc3f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x2dHVsYQ_size_16_color_FFFFFF_t_70 3]: /images/20220212/0e223d9c9a704624ad34b68b61d87676.png
[icon_star.png]: /images/20220212/5fa74a59822e45b788f35d358b598995.png
[https_punishzhou.iteye.com_blog_1266341]: https://punishzhou.iteye.com/blog/1266341