hbase中的Bloomfilter-转

本文详细介绍了BloomFilter在HBase中的应用原理及其对随机读性能的影响。包括BloomFilter的两种类型ROW与ROWCOL的区别及适用场景,以及它们如何帮助优化数据检索过程。
1.Bloomfilter在HBase中的作用?
HBase利用Bloomfilter来提高随机读(Get)的性能,对于顺序读(Scan)而言,设置Bloomfilter是没有作用的(0.92以后,如果设置了bloomfilter为ROWCOL,对于指定了qualifier的Scan有一定的优化,但不是那种直接过滤文件,排除在查找范围的形式)

2.Bloomfilter在HBase中的开销?
Bloomfilter是一个列族(cf)级别的配置属性,如果你在表中设置了Bloomfilter,那么HBase会在生成StoreFile时包含一份bloomfilter结构的数据,称其为MetaBlock;MetaBlock与DataBlock(真实的KeyValue数据)一起由LRUBlockCache维护。所以,开启bloomfilter会有一定的存储及内存cache开销。

4.Bloomfilter如何提高随机读(Get)的性能?
对于某个region的随机读,HBase会遍历读memstore及storefile(按照一定的顺序),将结果合并返回给客户端。如果你设置了bloomfilter,那么在遍历读storefile时,就可以利用bloomfilter,忽略某些storefile。

5.HBase中的Bloomfilter的类型及使用?

a)ROW, 根据KeyValue中的row来过滤storefile
举例:假设有2个storefile文件sf1和sf2,
sf1包含kv1(r1 cf:q1 v)、kv2(r2 cf:q1 v)
sf2包含kv3(r3 cf:q1 v)、kv4(r4 cf:q1 v)
如果设置了CF属性中的bloomfilter为ROW,那么get(r1)时就会过滤sf1,get(r3)就会过滤sf2

b)ROWCOL,根据KeyValue中的row+qualifier来过滤storefile
举例:假设有2个storefile文件sf1和sf2,
sf1包含kv1(r1 cf:q1 v)、kv2(r2 cf:q1 v)
sf2包含kv3(r1 cf:q2 v)、kv4(r2 cf:q2 v)
如果设置了CF属性中的bloomfilter为ROW,无论get(r1,q1)还是get(r1,q2),都会读取sf1+sf2;而如果设置了CF属性中的bloomfilter为ROWCOL,那么get(r1,q1)就会过滤sf2,get(r1,q2)就会过滤sf1

6.ROWCOL一定比ROW效果好么?
不一定

a)ROWCOL只对指定列(Qualifier)的随机读(Get)有效,如果应用中的随机读get,只含row,而没有指定读哪个qualifier,那么设置ROWCOL是没有效果的,这种场景就应该使用ROW

b)如果随机读中指定的列(Qualifier)的数目大于等于2,在0.90版本中ROWCOL是无效的,而在0.92版本以后,HBASE-2794对这一情景作了优化,是有效的(通过KeyValueScanner#seekExactly)

c)如果同一row多个列的数据在应用上是同一时间put的,那么ROW与ROWCOL的效果近似相同,而ROWCOL只对指定了列的随机读才会有效,所以设置为ROW更佳

7.ROWCOL与ROW只在名称上有联系,ROWCOL并不是ROW的扩展,不能取代ROW

8.region下的storefile数目越多,bloomfilter的效果越好

9.region下的storefile数目越少,HBase读性能越好

<think>我们正在讨论HBase的key-value存储机制。根据引用[1],HBase是三维有序存储的,通过rowkey(行键),column key(column family和qualifier)和TimeStamp(时间戳)这三个维度进行数据定位。同时,引用[2]提到写MemStore的过程是将KeyValue列表写入到以ConcurrentSkipListMap为核心的CellSet中。引用[3]指出HBase的数据模型是rowkey-列族-列,并提供了强一致性。 因此,HBase的key-value存储机制可以这样理解: 1. 每一行数据由rowkey唯一标识。 2. 每一行包含多个列族,每个列族包含多个列(qualifier)。 3. 每个列的值可能有多个版本,每个版本由时间戳标识。 4. 所以,HBase内部存储的最小单位是KeyValue结构,它包含了行键、列族、列限定符、时间戳和值。 具体到KeyValue的结构: - Key部分:由rowkey、column family、qualifier、timestamp以及key type(表示是Put还是Delete等)组成。 - Value部分:存储具体的值。 在存储时,KeyValue按照以下顺序排序: 1. 按rowkey的字典序升序排列。 2. 同一rowkey下,按column family升序排列。 3. 同一column family下,按qualifier升序排列。 4. 同一qualifier下,按timestamp降序排列(这样最新的数据排在最前面)。 引用[2]提到,MemStore使用ConcurrentSkipListMap来存储这些KeyValue,这样保证数据有序且支持高并发写入。同时,为了减少内存碎片,HBase采用了MSLab技术,分配固定大小的Chunk来存储数据。 另外,引用[3]提到HBase通过ZooKeeper来协调集群信息,实现较为简单,并提供强一致性。 所以,总结HBase的key-value存储机制原理: - 数据以KeyValue形式存储,Key包含行键、列族、列限定符、时间戳等信息,Value是具体的数据值。 - 所有KeyValue在MemStore中按Key的字典序排序存储(使用跳表实现)。 - 写入时先写WAL(Write-Ahead Log)保证持久性,然后写入MemStore。 - 当MemStore达到一定大小,会Flush到HDFS形成HFile,HFile内部也是按照KeyValue排序存储,并建立索引以便快速查找。 现在,我们根据这些信息来组织回答。</think>### HBase Key-Value 存储机制原理详解 #### 1. **核心存储单元:KeyValue结构** HBase 的最小存储单元是 **KeyValue 对象**,其二进制结构如下: ``` [ key length ] [ value length ] [ row key ] [ column family ] [ column qualifier ] [ timestamp ] [ key type ] [ value ] ``` - **Key 组成**(定位数据的四维坐标): - `rowkey`:行键(主键),全局唯一标识符 - `column family`:列族(物理存储单元) - `column qualifier`:列限定符(列族内的具体列) - `timestamp`:时间戳(数据版本标识) - **Value**:存储的实际数据字节[^1][^3] #### 2. **三维有序存储机制** HBase 通过以下三重排序实现高效检索: 1. **行级排序**:所有数据按 `rowkey` 字典序升序排列 2. **列族内排序**:同一 `rowkey` 下按 `(column family + column qualifier)` 升序排列 3. **时间维度排序**:同一列下按 `timestamp` **降序排列**(最新数据在最前)[^1] > *示例存储顺序*: > `(row1, cf:a, t3) → (row1, cf:a, t2) → (row1, cf:b, t5) → (row2, cf:a, t1)` #### 3. **写入流程中的KeyValue处理** 1. **写入WAL**:先写预写日志保证持久性 2. **写入MemStore**: - 将 KeyValue 批量写入内存数据结构 `ConcurrentSkipListMap`(跳表实现) - 跳表特性:保持 KeyValue 的有序性,支持高效范围查询[^2] 3. **内存优化(MSLab)**: - 通过分配固定大小 Chunk 存储数据 - 减少内存碎片,降低 GC 压力 - 优化跳表结构减少对象创建(如阿里改进方案)[^2] #### 4. **持久化存储结构** ```mermaid graph LR A[MemStore] -->|Flush| B[HFile] B --> C[Data Block] C --> D[KeyValue1] C --> E[KeyValue2] B --> F[Bloom Filter] B --> G[Block Index] ``` - **HFile 结构**: - **Data Block**:存储有序 KeyValue 序列 - **Bloom Filter**:快速过滤不存在的数据 - **Block Index**:记录每个 Data Block 的起始 Key - **检索过程**: 1. 通过 Block Index 定位目标 Data Block 2. 在 Data Block 内二分查找 KeyValue[^1][^2] #### 5. **强一致性实现** - **依赖组件**: - **ZooKeeper**:管理集群元数据(如 RegionServer 状态、meta 表位置) - **meta 表**:存储所有 Region 的 `rowkey` 范围及位置信息[^2][^3] - **数据访问流程**: 1. 客户端从 ZooKeeper 获取 `meta` 表位置 2. 查询 `meta` 表定位目标 Region 3. 直接访问对应 RegionServer 获取数据 #### 6. **与Cassandra的对比** | **特性** | **HBase** | **Cassandra** | |----------------|-------------------------------|-----------------------------| | 一致性模型 | 强一致性 | 最终一致性 | | 协调机制 | ZooKeeper | Gossip协议 | | 数据定位 | 三维有序存储 | 分布式哈希环 | | 适用场景 | 金融/强事务场景 | 高写入/全球化部署 | [^1][^3] --- ### 关键设计优势 1. **高效范围查询**:基于 `rowkey` 有序存储,避免全表扫描 2. **快速版本检索**:时间戳降序排列保证最新数据优先访问 3. **自动分区扩展**:Region 分裂机制实现水平扩展 4. **读写分离优化**:MemStore(写优化) + HFile(读优化) > 通过 KeyValue 的三维有序设计,HBase 在保证强一致性的同时,实现了海量数据的毫秒级查询[^1][^3]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值