Hbase入门（一）——Hbase简介

最新推荐文章于 2023-09-12 11:19:53 发布

江湖小小虾

最新推荐文章于 2023-09-12 11:19:53 发布

阅读量402

点赞数

分类专栏： hbase

本文链接：https://blog.csdn.net/lishuan182/article/details/89531147

版权

hbase 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一、应用场景及特点

1. HBase能做什么

海量数据存储（百亿*百万）

准实时查询（百毫秒查询）-->1秒内完成查询

2. 实际业务场景中的应用

交通：长江航道中船舶的GPS信息；路口摄像头违章拍照

金融：存取款，借还款

电商：淘宝-》订单，物流，浏览记录

移动端：通话记录等等

3.特点

海量存储：（百亿*百万）传统数据（单表500w，30列）

面向列：动态增加列；存储和权限控制面向列--》只需要少数几个字段的话，大大减少读取的数据量

多版本：每一列的数据存储有多个Version

稀疏性：为空的列不占用存储空间，表可以很稀疏

扩展性：线性扩展，随着数据量增多可以通过节点扩展进行支撑

高性能：

①底层LSM数据结构和Rowkey有序排列等架构上的独特设计，使得HBase具有非常高的写入能力。

②region切分、主键索引和缓存机制使得Hbase在海量数据下具备一定的随机读取性能，改性能针对Rowkey的查询能够到达毫秒级别

高可靠性：

4.优势

不同点	传统数据库	Hbase
海量存储	500w*30时健康	百亿*百万
安全	不自带备份	数据存储在hdfs上，备份机制健全
准实时查询	数据达到一定数量开始缓慢，很大的话基本无法支撑	通过zookeeper协调查找数据，访问速度快
存储方式	行存储	列存储动态增加列存储和权限控制面向列只需要少数几个字段的话，大大减少读取的数据量
数据较大时候的切分	人工第三方插件	自动（Region），也支持手动指定Region
高并发读写	支持	不支持

5.劣势

只支持rowkey匹配查询，不支持条件查询等复杂查询

二、概念以及在Hadoop生态中的定义

1. HBase简介

HBASE是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBASE技术可在廉价PC Server上搭建起大规模结构化存储集群。

HBASE的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。

HBASE是Google Bigtable的开源实现，但是也有很多不同之处。

不同点	Google Bigtable	HBASE
文件存储系统	GFS	Hadoop HDFS
协同服务	Chubby	Zookeeper
相同点	都采用Hadoop MapReduce来处海量数据

2. 概念介绍

1.1 Cell

由{row key，columnFamily，version} 唯一确定的单元。HBASE中通过rowkey和columns确定的为一个存储单元称为cell

cell中的数据是没有类型的，全部是字节码形式存储。

关键字：无类型、字节码

1.2 HRegionServer管理一系列HRegion（每个HRegion对应了Table中的一个Region）

HRegion中由多个HStore组成（每个HStore对应了Table中的一个Column Family的存储）——可以看出每个ColumnFamily其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效。

HStore存储时HBas存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore*是Sorted Memory Buffer，

①用户写入数据首先会放入MemStore，

②当MemStore满了以后会flush成一个*StoreFile（底层是HFile）

③当StoreFile文件数增长到一定阈值，会触发Compact合并操作，将多个StoreFile合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立刻返回，保证了HBase IO的高性能

④当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定的阈值后，会触发Split操作，同时，会把当前的Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到响应的HRegion Server上，使得原先1个Region的压力得以分流道2个Region上

1.3 Hlog

HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，一次一旦HRegion Server意外退出，MemStore中的内存数据将会丢失，这就需要引入HLog了

每一个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中，HLog文件定期会滚动出新的，并删除旧的文件，当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应Region的目录下，然后再将失效的Region重新分配，领取到这些Region的HRegionServer在LoadRegion过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

1.4 ROOT表和META表

HBase中有两张特殊的Table，-ROOT-和.META.

l .META.：记录了用户表的Region信息，.META.可以有多个regoin

l -ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region

用户表的Regions元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个Regions。为了定位.META.表中各个Regions的位置，把.META.表中的所有Regions的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后方位-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，-ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多需要三次跳转就可以定位任意一个Region。为了加快访问速度，.META.表的Regions全部保存在内存中，如果.META.表中的每一行在内存中占大约1KB，且每个Region限制为128M，下图中的三层结构可以保存Regions的数目为(128M/1KB)*(128/1KB)=2^34个。

1.5 Zookeeper：

Zookeeper Quorum存储-ROOT-表地址、HMaster地址

HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况

Zookeeper避免HMaster单点问题

Zookeeper的主要作用：客户端首先联系ZooKeeper子集群（quorum）（一个由ZooKeeper节点组成的单独集群）查找行健。上述过程是通过ZooKeeper获取含有-ROOT-的region服务器名（主机名）来完成的。通过含有-ROOT-的region服务器可以查询到含有.META.表中对应的region服务器名，其中包含请求的行健信息。这两处的主要内容都被缓存下来了，并且都只查询一次。最终，通过查询.META服务器来获取客户端查询的行健数据所在region的服务器名。一旦知道了数据的实际位置，即region的位置，HBase会缓存这次查询的信息，同时直接联系管理实际数据的HRegionServer。所以，之后客户端可以通过缓存信息很好地定位所需的数据位置，而不用再次查找.META.表。

1.6 master

为HRegionServer分配HRegion

平衡RegionServer的负载，使各个RegionServer管理的region个数大致相等

发现失效的RegionServer并重新分配失效上面的region到别的Regionserver

处理Schema更新请求（建表、删表）

1.7

注意：region虽然是分布式存储的最小单元，但并不是存储的最小单元。region是由一个或者多个store组成的，每个store就是一个column family。每个store又由memStore和1至多个store file 组成(memstore到一个阀值会刷新，写入到storefile，有hlog来保证数据的安全性，一个regionServer有且只有一个hlog)　　