HBase简介 http://hbase.apache.org/
HBase是一个高可靠性、高性能、面向列、可伸缩、 实时读写的分布式数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase利用Hadoop HDFS作为其文件存储系统,利用Hadoop MapReduce来处理HBase中的海量数据,利用zookeeper做协同服务。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
HBase特点
1、海量存储
Hbase适合存储PB级别的海量数据,在PB级别的数据以及采用廉价PC存储的情况下,能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性,才为海量数据的存储提供了便利。
2、列式存储
HBase通过列族来存储数据,列族下面可以有非常多的列,列族在创建表的时候就必须指定。
3、极易扩展
Hbase的扩展性主要体现在两个方面,一个是基于上层处理能力(RegionServer)的扩展,一个是基于存储的扩展(HDFS)。
- RegionServer的作用是管理region、承接业务的访问。通过横向添加RegionSever的机器,进行水平扩展,提升Hbase上层的处理能力,提升Hbsae服务更多Region的能力。
- 通过横向添加Datanode的机器,进行存储层扩容,提升Hbase的数据存储能力和提升后端存储的读写能力。
4、高并发
HBase HRegion servers集群中的所有的region的数据在服务器启动时都是被打开的,并且在内存初始化一些memstore,相应的这就在一定程度上加快系统响应;而Hadoop中的block中的数据文件默认是关闭的,只有在需要的时候才打开,处理完数据后就关闭,这在一定程度上就增加了响应时间。
5、稀疏
空(null)列并不占用存储空间,表可以设计的非常稀疏。
6、 数据多版本
每个单元中的数据可以有多个版本,默认情况下版本号自动分配,是单元格插入时的时间戳。
7、数据类型单一
Hbase中的数据都是字符串,没有类型。
HBase原理
1、HBase架构图
2、Client
- 包含访问HBase的接口并维护cache来加快对HBase的访问
3、Zookeeper
- 保证任何时候,集群中只有一个master
- 存贮所有Region的寻址入口。
- 存储HBase的schema和table元数据
4、 HMaster
- 为Region server分配region
- 负责Region server的负载均衡
- 发现失效的RegionServer并重新分配其上的region
- 管理用户对table的增删改操作
5、 RegionServer
HBase中最核心的模块,主要负责响应用户I/O请求,向HDFS文件系统中读写。
HRegionServer管理一系列HRegion对象;
每个HRegion对应Table中一个Region,HRegion由多个HStore组成;
每个HStore对应Table中一个Column Family的存储;
Column Family就是一个集中的存储单元,故将具有相同IO特性的Column放在一个Column Family会更高效。
client访问hbase上的数据并不需要master参与(寻址访问zookeeper和region server,数据读写访问region server),master仅仅维护table和region的元数据信息(table的元数据信息保存在zookeeper上),负载很低。HRegionServer存取一个子表时,会创建一个HRegion对象,然后对表的每个列族创建一个Store实例,每个Store都会有一个MemStore和0个或多个StoreFile与之对应,每个StoreFile都会对应一个HFile,HFile就是实际的存储文件。因此,一个HRegion(表)有多少个列族就有多少个Store。一个HRegionServer会有多个HRegion和一个HLog。
6、Region
Hbase表的分片,HBase表会根据RowKey值被切分成不同的region存储在RegionServer中,在一个RegionServer中可以有多个不同的region。
HRegion是HBase中分布式存储和负载均衡的最小单元。最小单元就表示不同的HRegion可以分布在不同的HRegionserver上。 HRegion由一个或者多个Store组成,每个store保存一个columns family。每个Strore又由一个memStore和0至多个StoreFile组成。
table和region的关系
table默认最初只有一个region,随着记录数的不断增加而变大,起初的region会逐渐分裂成多个region,一个region有【startKey, endKey】表示,不同的region会被master分配给相应的regionserver管理。
region是hbase分布式存储和负载均衡的最小单元,不同的region分不到不同的regionServer。
注意:region虽然是分布式存储的最小单元,但并不是存储的最小单元。region是由一个或者多个store组成的,每个store就是一个column family。每个store又由memStore和1至多个store file 组成(memstore到一个阀值会刷新,写入到storefile,有hlog来保证数据的安全性,一个regionServer有且只有一个hlog)
7、HLog(WAL log):
引入HLog原因:在分布式系统环境中,无法避免系统出错或者宕机,一旦HRegionServer意外退出,MemStore中的内存数据就会丢失,引入HLog就是防止这种情况。
工作机制:
每个HRegionServer中都会有一个HLog对象,HLog是一个实现Write Ahead Log的类,每次用户操作写入MemStore的同时,也会写一份数据到HLog文件,HLog文件定期会滚动出新,并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后,HMaster会通过Zookeeper感知,HMaster首先处理遗留的HLog文件,将不同region的log数据拆分,分别放到相应region目录下,然后再将失效的region重新分配,领取到这些region的HRegionServer在Load Region的过程中,会发现有历史HLog需要处理,因此会Replay HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复。
8、Store
HBase存储的核心。由MemStore和StoreFile组成。一个Store对应HBase表中的一个列族。
9、Memstore 与 storefile
store包括位于内存中的memstore和位于磁盘的storefile写操作先写入memstore,当memstore中的数据达到某个阈值,hregionserver会启动flashcache进程写入storefile,每次写入形成单独的一个storefile,当storefile文件的数量增长到一定阈值后,系统会进行合并(minor、 major、compaction),在合并过程中会进行版本合并和删除工作 (majar),形成更大的storefile。当一个region所有storefile的大小和超过一定阈值后,会把当前的region分割为两个,并由hmaster分配到相应的regionserver服务器,实现负载均衡。客户端检索数据,先在memstore找,找不到再找storefile。
HBase读写流程
1、HBase读流程
1)Client先访问zookeeper,从meta表读取region的位置,然后读取meta表中的数据。meta中又存储了用户表的region信息;
2)根据namespace、表名和rowkey在meta表中找到对应的region信息;
3)找到这个region对应的regionserver;
4)查找对应的region;
5)先从MemStore找数据,如果没有,再到BlockCache里面读;
6)BlockCache还没有,再到StoreFile上读(为了读取的效率);
7)如果是从StoreFile里面读取的数据,不是直接返回给客户端,而是先写入BlockCache,再返回给客户端。
寻址过程:client—>Zookeeper—>ROOT表—>.META. 表—>RegionServer—>Region—>client
2、HBase写流程
用户视角—》
1)Client向HregionServer发送写请求;
2)HregionServer将数据写到HLog(write ahead log)。为了数据的持久化和恢复;
3)HregionServer将数据写到内存(MemStore);
4)反馈Client写成功。
自身视角—》
- Client通过Zookeeper的调度,向RegionServer发出写数据请求,在Region中写数据;
- 数据被写入Region的MemStore,知道MemStore达到预设阀值(即MemStore满);
- MemStore中的数据被Flush成一个StoreFile;
- 随着StoreFile文件的不断增多,当其数量增长到一定阀值后,触发Compact合并操作,将多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除;
- StoreFiles通过不断的Compact合并操作,逐步形成越来越大的StoreFile;
- 单个StoreFile大小超过一定阀值后,触发Split操作,把当前Region Split成2个新的Region。父Region会下线,新Split出的2个子Region会被HMaster分配到相应的RegionServer上,使得原先1个Region的压力得以分流到2个Region上。
HBase只有增添数据,所有的更新和删除操作都是在后续的Compact历程中举行的,使得用户的写操作只要进入内存就可以立刻返回,实现了HBase I/O的高性能。
Hbase的优点及应用场景:
- 半结构化或非结构化数据:对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase,因为HBase支持动态添加列。
- 记录很稀疏:RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储,这样既节省了空间又提高了读性能。
- 多版本号数据: 依据Row key和Column key定位到的Value能够有随意数量的版本号值,因此对于须要存储变动历史记录的数据,用HBase是很方便的。比方某个用户的Address变更,用户的Address变更记录也许也是具有研究意义的。
- 仅要求最终一致性:对于数据存储事务的要求不像金融行业和财务系统这么高,只要保证最终一致性就行。(比如HBase+elasticsearch时,可能出现数据不一致)
- 高可用和海量数据以及很大的瞬间写入量:WAL解决高可用,支持PB级数据,put性能高,适用于插入比查询操作更频繁的情况。比如,对于历史记录表和日志文件。(HBase的写操作更加高效)。
业务场景简单: 不需要太多的关系型数据库特性,列入交叉列,交叉表,事务,连接等。
Hbase的缺点:
- 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询。
- 不适合于大范围扫描查询。
- 不直接支持 SQL 的语句查询。