Hbase总结1

特点：

　　分布式、可扩展、支持海量数据存储的NoSQL数据库，可以支持海量数据的秒级别查询

逻辑结构：

• 列族
• 列
• rowkey
• region：类似关系型数据库的表，是hbase表的横向切片。hbase定义表时，只需要声明列族，不需要声明具体的列。写入数据时可以按需在一个列族中动态扩展列。
• store：内容实际存储

物理结构：

rowkey	column family	column qualifier	timestamp	type	value
rowkey001	cf1	c1	t1	put	v1
rowkey001	cf1	c1	t2	delete	v1

 

 

 

 

架构：

master：

• 表的增删改查
• 分配region到region server，并负责region server状态监控

region server：

• 数据的增/改（put）、删（delete）、查（get）
• 管理region的分裂（split）及合并（compact）

StoreFile：

　　每个Store会有一个/多个StoreFile，StoreFile中的数据是以Hfile的形式存储在HDFS上（HFile是一种文件格式）。数据在每个StoreFile中都是有序的。

MemStore：

　　因为StoreFile/HFile中的数据都是有序的，所以数据先存储在内存中，到达flush条件时才会写到HFile中，每次flush形成一个HFile。

WAL（Hlog）

 

写流程：

操作 put tb1/rk1/cf1/c1：v1

1 client向ZK请求hbase meta表所在的region server

2 region server 返回meta表信息给到client

3 client访问上一步返回的rs，获取meta表内容，根据rowkey信息判断目标rowkey所在的region server（假设为 rs1）【将meta信息缓存起来，便于下一次访问】

4 client连接rs1，并将v1按照要求写入，先写到wal，然后写入memstore

5 写入完成后，rs1给client发送ack，写入完成。

MemStore刷写：

一个region server中有多个region

一个region中可能有多个store（每个store对应一个列族）

一个store中有一个memstore，每个memstore满足一定条件即可刷写（flush）

每次刷写生成一个HDFS上的StoreFile（以Hfile格式存储）

刷写条件为：

• 当一个region server中所有memstore大小达到对堆内存的40%，region server级别flush会阻塞客户端读写（参数：hbase.regionserver.global.memstore.size）；在客户端阻塞条件下，因为持续刷写导致的memstore大小降低，降低至hbase.regionserver.global.memstore.size * 95%（堆内存的38%）时，客户端又可以读写hbase。
• memstore数据自动刷新的时间阈值，默认1小时（以最后一条数据的时间为计算基准）
• 单个region的memstore大小达到hbase.hregion.memstore.flush.size（默认128M），整个region就会flush。

读流程：

操作 get：tb1/rk1

前三步骤和写流程一致

 

rowkey设计原则：

- 散列性：时间戳反转（时间戳本身有序，反转之后无序），

- 集中性

- 长度原则：60-100位长度