HBase理论基础
一.HBase基本介绍
(一)HBase简介
HBase是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式NoSQL数据库系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase的设计目标就是为了存储并处理那些巨大的表,如数十亿行、数百万列。HBase是Google Bigtable的开源java版本。HBase是建立在hdfs之上,依赖于Hadoop和Zookeeper,与他们是紧耦合关系,使用HBase前需要确保Hadoop和Zookeeper已经正常启动。
HBase非常适合用来进行大数据的实时查询。Facebook是用Hbase进行消息和实时的分析。它也可以用来统计Facebook的连接数。
(二)HBase的特点★
- 海量存储:一个表可以有数十亿行,上百万列;
- 高并发:以链家PC为例,存储PB级数据仍能有百毫秒内的响应速度。
- 列式存储:面向列族的存储,列族下面可以有很多的列,列族在创建表的时必须指定。
- 易扩展:每行都有一个可排序的主键和任意多的列,列可以动态的增加,同表中不同行可以有不同的列;
- 稀疏:空(null)列并不占用存储空间,表可以设计的非常稀疏;
- 数据多版本:每个单元中的数据可以有多个版本,默认是版本单元格插入时的时间戳;
- 数据类型单一:Hbase中的数据都是字符串,没有类型。
(三)HBase的使用场景
-
半结构化或非结构化数据
对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用HBase。例如,当业务发展需要存储author的email,phone,address信息时RDBMS需要停机维护,而HBase支持动态增加。
-
记录稀疏的数据
RDBMS的行有多少列是固定的,值为null的列浪费了存储空间。而HBase的null列不会被存储,既节省空间又提高了读性能。
-
多版本数据
比如上例中的author的Address是会变动的,业务上一般只需要最新的值,但有时可能需要查询到历史值。
-
超大数据量
当数据量越来越大,RDBMS数据库撑不住了,就出现了读写分离策略,通过一个Master专门负责写操作,多个Slave负责读操作,服务器成本倍增。随着压力增加,Master撑不住了,这时就要分库了,把关联不大的数据分开部署,一些join查询不能用了,需要借助中间层。随着数据量的进一步增加,一个表的记录越来越大,查询就变得很慢,于是又得搞分表,比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。采用HBase就简单了,只需要加机器即可,HBase会自动水平切分扩展,跟Hadoop的无缝集成保障了其数据可靠性(HDFS)和海量数据分析的高性能(MapReduce)。
(四)HBase和RDBMS的比较
(五)HBase的表数据模型
-
Row Key(行键)
与其他nosql数据库一样,Row Key是用来检索记录的主键。访问hbase table中的行,只有三种方式:
1.通过单个Row Key访问,get rowkey;
2.通过Row Key的range,scan startrowkey stoprowkey;
3.全表扫描(很少用),scan table_name。
Row key (行键)可以是任意字符串(最大长度是 64KB,实际应用中长度一般为 10-100bytes),在hbase内部,row key保存为字节数组。
存储时,Hbase会对表中的数据按照Row key的字典序(byte order)排序存储。设计Row key时,要充分排序存储这个特性,将经常一起读取的行存储放到一起。(位置相关性)。
-
Column Family列族
列族是表的schema的一部分(而列不是),必须在使用表之前定义。
每一个列族下面对应可以有很多个列 每一个列族都是对应一个store模块。
列名都以列族作为前缀。例如courses:history , courses:math 都属于courses这个列族。
访问控制、磁盘和内存的使用统计都是在列族层面进行的。
列族越多,在取一行数据时所要参与IO、搜寻的文件就越多,所以,如果没有必要,不要设置太多的列族。 -
Column列
列族下面的具体列,每个列都对应唯一的一个列族,一个列族下面可以动态的扩展很多列。
-
Cell
HBase中通过{row key, column family:column, version}确定的为一个存贮单元称为cell。
cell中的数据是没有类型的,全部是字节码形式存贮。每个 cell都保存着同一份数据的多个版本,版本通过时间戳来索引。
-
VersionNum版本号
每个 cell都保存着同一份数据的多个版本,默认值为系统时间戳,类型为Long
-
Time Stamp时间戳
时间戳的类型是 64位整型。时间戳可以由hbase(在数据写入时自动 )赋值,此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突,就必须自己生成具有唯一性的时间戳。每个 cell中,不同版本的数据按照时间倒序排序,即最新的数据排在最前面。为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担,hbase提供了两种数据版本回收方式:一是保存数据的最后n个版本;二是保存最近一段时间内的版本(设置数据的生命周期TTL)。用户可以针对每个列族进行设置。
二.HBase系统架构★★
(一)客户端Client
- 整个HBase集群的访问入口;
- 使用HBase RPC机制与HMaster和HRegionServer进行通信;
- 使用HMaster进行通信管理类操作;
- 与HRegionServer进行数据读写类操作;
- 包含访问HBase的接口,并维护cache来加快对HBase的访问。
(二)协调服务组件Zookeeper
- Zookeeper的Master Election机制保证任何时候集群中只有一个HMaster在运行,解决了HMaster的单点故障问题;
- 实时监控HRegionServer的上线和下线信息,并实时通知给HMaster(HMaster与HRegionServer启动时会向Zookeeper注册);
- 存储HBase的schema和table元数据(包括有哪些table,每个table有哪些column family);
- Zookeeper Quorum存储-ROOT-表地址、HMaster地址。
- 存储所有的HRegion的寻址入口;
Zookeeper的主要作用:客户端首先联系ZooKeeper子集群(即quorum,一个由ZooKeeper节点组成的单独集群)查找行健。ZooKeeper获取含有-ROOT-的region服务器名(主机名)查询到含有HBase:meta表中对应的region服务器名。HBase:meta里面存放了其他表的元数据信息。最终,通过查询HBase:meta表所在服务器来获取客户端查询的行健数据所在region的服务器名。一旦知道了数据的实际位置,即region的位置,HBase会缓存这次查询的信息,同时直接联系管理实际数据的HRegionServer。所以,之后客户端可以通过缓存信息很好地定位所需的数据位置。即,HBaseClient–>连接ZooKeeper—>-ROOT—>.META.–>RegionServer–>Region
(三)主节点HMaster
HMaster通过Zookeeper发布自己的位置给客户端。
HMaster没有单点问题,HBase可以启动多个HMaster,通过Zookeeper的Master Election机制保证总有一个Master在运行。HMaster维护着Table和Region的元数据信息,主要负责Table和Region的管理工作:
- 管理用户对表的增删改查查操作;
- 负责HRegionServer的负载均衡,调整Region分布
- Region Split后,负责新Region的分布;
- 发现HRegion server失效时,负责失效HRegionServer上Region的迁移。
注意:Client访问HBase上数据的过程并不需要HMaster参与(寻址访问zookeeper和HRegionServer,数据读写访问HRegionServer),HMaster仅仅维护着table和Region的元数据信息,负载很低。
(四)从节点HRegionServer
- 维护HMaster分配给的region,负责响应用户对region的IO请求,向HDFS文件系统中读写;HRegionServer管理一系列HRegion对象,每个HRegion对象对应Table中一个Region,HRegion由多个HStore组成;每个HStore对应Table中一个Column Family的存储;Column Family就是一个集中的存储单元,故将具有相同IO特性的Column放在一个Column Family会更高效。
- 负责切分运行过程中变得过大的HRegion,即处理Region分片;
三.HBase的物理存储结构★★
从节点HRegionServer架构:
一个HLog + 多个HRegion
一个HRegion : 多个HStore模块 一个store模块对应一个列族
一个HStore模块:一个MemoryStore和多个StoreFile
HBase中的所有数据文件都存储在Hadoop HDFS文件系统上,格式主要有两种:
- HFile HBase中KeyValue数据的存储格式,HFile是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即StoreFile底层就是HFile 。
- HLog File,HBase中WAL(Write Ahead Log) 的存储格式,物理上是Hadoop的Sequence File。
(一)HLog
引入HLog原因:
在分布式系统环境中,无法避免系统出错或者宕机,一旦HRegionServer意外退出,MemStore中的内存数据就会丢失,引入HLog就是防止这种情况,HLog与HRegionServer一一对应。HLog File的物理存储格式是Hadoop中的Sequence File。
工作机制:
每个HRegionServer中都会有一个HLog对象,HLog是一个实现Write Ahead Log的类,每次用户操作写入MemStore的同时,也会写一份数据到HLog文件,HLog文件定期会滚动出新,并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后,HMaster会通过Zookeeper感知,HMaster首先处理遗留的HLog文件,将不同HRegion的log数据拆分,分别放到相应HRegion目录下,然后再将失效的HRegion重新分配,领取到这些HRegion的HRegionServer再Load。Region的过程中,会发现有历史HLog需要处理,因此会Replay
HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复。
扩展了解:Write-Ahead logs
当对HBase读写数据的时候,数据不是直接写进磁盘,它会在内存中保留一段时间(时间以及数据量阈值可以设定)。但把数据保存在内存中可能有更高的概率引起数据丢失,为了解决这个问题,数据会先写在一个叫做Write-Ahead logfile的文件中,然后再写入内存中。所以在系统出现故障的时候,数据可以通过这个日志文件重建。
(二)HRegion
Table中的所有行都按照row key的字典序排列。
Table 在行的方向上分割为多个HRegion。HRegion按大小分割的(默认10G),HRegion超过10G就会等分会两个新的HRegion。Table中的行不断增多,就会有越来越多的HRegion。
Hregion是Hbase中分布式存储和负载均衡的最小单元。不同的Hregion可以分布在不同的HRegion server上,但一个Hregion是不会拆分到多个HRegion server上。
HRegion虽然是负载均衡的最小单元,但并不是物理存储的最小单元。HRegion由一个或者多个HStore组成,每个HStore保存一个column family。每个HStore又由一个memStore和0至多个StoreFile组成。
- 扩展(了解)
1.每个HRegion由以下信息标识:
(1)<表名,startRowKey,创建时间>
(2)由目录表(-ROOT-和.META.)记录该HRegion的endRowKey
HRegion定位:HRegion被分配给哪个HRegionServer是完全动态的,所以需要机制来定位HRegion具体在哪个HRegionServer。
2.HBase使用三层结构来定位HRegion:
(1)通过zookeeper里的文件/hbase/rs得到-ROOT-表的位置,通过查找-ROOT-表获取到.META.表的位置。
注意:-ROOT-表有且只有一个HRegion,且-ROOT-表永远不会被分隔为多个HRegion,从而保证了最多需要三次跳转,就能定位到任意的HRegion。.META.表中的每一个HRegion在-ROOT-表中都是一行记录。
(2)通过-ROOT-表找到.META.表后,在.META.表中找到用户请求的表的第一个HRegion。
(3)通过.META.表找到所要的用户表HRegion的位置。用户表中的每个HRegion在.META表中都是一行记录。
(三)HStore
一个HRegion由多个HStore组成,每个HStore包含一个列族的所有数据,HStore包括位于内存的Memstore和位于硬盘的Storefile。当客户端检索数据时,先在Memstore找,找不到再找Storefile。
MemStore是存储内存缓冲区(Stored Memory Buffer),数据保存在WAL中(即HLog)之后,HRegsionServer会在MemStore中存储键值对。
Flash机制:当Memstore中的数据量达到某个128M(默认的阈值),Hregionserver启动Flashcache进程写入Storefile,每次写入形成单独一个Storefile。
Compact机制:随着StoreFile文件的不断增多,当其数量增长到一定阀值后,触发Compact合并操作。Compact操作会合并StoreFile形成一个大的Hfile文件,并清理过期的、被用户删除的、多余版本的数据,从而提高读写数据的效率。补充:Hbase当中删除和更新数据的API操作其实被没有对数据进行真正的删除,而是对数据进行了追加操作,只有当Compact操作的时候,才会真正的对数据进行清理。
Split机制:HFile达到阈值10GB,会把当前的HRegion分割成两个,并由HMaster分配给相应的region服务器,实现负载均衡,当然,HFile也会被一分为二。
(四)HFile
HFile是在磁盘上保存原始数据的实际的物理文件,是实际的存储文件。HFile的物理存储格式是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即StoreFile底层就是HFile。
可参阅:https://www.cnblogs.com/cenyuhai/p/3708135.html
四.HBase的读写流程(会背诵)
(一)HBase当中数据写入
第一步:Client连接Zookeeper,获取一张特殊表HBase:meta表位置;
第二步:连接HBase:meta表所在的HRegionServer,读取HBase:meta表数据;
第三步:获取对应表所在HRegion对应的HRegionServer的位置;
第四步:连接对应的HRegionServer
第五步:将数据写入到HLog,然后再写入到MemoryStore,这两个地方写入成功,就算写入成功了。
Flash机制:当Memstore中的数据量达到某个128M(默认的阈值),Hregionserver启动Flashcache进程写入Storefile,每次写入形成单独一个Storefile。
Compact机制:随着StoreFile文件的不断增多,当其数量增长到一定阀值后,触发Compact合并操作。Compact操作会合并StoreFile形成一个大的Hfile文件,并清理过期的、被用户删除的、多余版本的数据,从而提高读写数据的效率。补充:Hbase当中删除和更新数据的API操作其实被没有对数据进行真正的删除,而是对数据进行了追加操作,只有当Compact操作的时候,才会真正的对数据进行清理。
Split机制:HFile达到阈值10GB,会把当前的HRegion分割成两个,并由HMaster分配给相应的region服务器,实现负载均衡,当然,HFile也会被一分为二。
(二)HBase当中数据读取
第一步:Client连接Zookeeper,获取一张特殊表HBase:meta表位置;
第二步:连接HBase:meta表所在的HRegionServer,读取HBase:meta表数据;
第三步:获取对应表所在HRegion对应的HRegionServer的位置,与对应的regionServer进行通信;
第四步:进行数据查询:先查询memoryStore,如果memoryStore里面没有了,再去查询StoreFIle,如果StoreFile里面还是没有,就去查询HFile,使用的是布隆过滤器(BoomFilter)。
五.HBase集群环境搭建
注意事项:HBase集群强依赖于Zookeeper和Hadoop,安装HBase之前一定要保证Zookeeper和Hadoop能启动成功,且服务正常运行
(一)下载对应的HBase的安装包
所有关于CDH版本的软件包下载地址如下
http://archive.cloudera.com/cdh5/cdh/5/
HBase对应的版本下载地址如下
http://archive.cloudera.com/cdh5/cdh/5/hbase-1.2.0-cdh5.14.0.tar.gz
我们使用的是hbase-1.2.0-cdh5.14.0
版本
(二)压缩包上传并解压
#将我们的压缩包上传到node01服务器的/export/softwares路径下并解压
cd /export/softwares/
tar -zxvf hbase-1.2.0-cdh5.14.0-bin.tar.gz -C /export/servers/
(三)修改配置文件
1.第一台机器进行修改配置文件
cd /export/servers/hbase-1.2.0-cdh5.14.0/conf
2.修改第一个配置文件hbase-env.sh, 注释掉HBase使用内部zk
vim hbase-env.sh
export JAVA_HOME=/export/servers/jdk1.8.0_141
export HBASE_MANAGES_ZK=false
3.修改第二个配置文件hbase-site.xml
vim hbase-site.xml
<configuration>
<property>
<name>hbase.rootdir</name>
<value>hdfs://node01:8020/hbase</value>
</property>
<property>
<name>hbase.cluster.distributed</name>
<value>true</value>
</property>
<!-- 0.98后的新变动,之前版本没有.port,默认端口为60000 -->
<property>
<name>hbase.master.port</name>
<value>16000</value>
</property>
<property>
<name>hbase.zookeeper.quorum</name>
<value>node01,node02,node03</value>
</property>
<property>
<name>hbase.zookeeper.property.dataDir</name>
<value>/export/servers/zookeeper-3.4.5-cdh5.14.0/zkdatas</value>
</property>
<property>
<name>hbase.thrift.support.proxyuser</name>
<value>true</value>
</property>
<property>
<name>hbase.regionserver.thrift.http</name>
<value>true</value>
</property>
</configuration>
4.修改第三个配置文件regionservers
vim regionservers
node01
node02
node03
5.创建back-masters配置文件,实现HMaster的高可用
cd /export/servers/hbase-1.2.0-cdh5.14.0/conf
vim backup-masters
node02
(四)安装包分发到其他机器
将我们第一台机器的hbase的安装包拷贝到其他机器上面去
cd /export/servers/
scp -r hbase-1.2.0-cdh5.14.0/ node02:$PWD
scp -r hbase-1.2.0-cdh5.14.0/ node03:$PWD
(五)三台机器创建软连接
因为hbase需要读取hadoop的core-site.xml以及hdfs-site.xml当中的配置文件信息,所以我们三台机器都要执行以下命令创建软连接
ln -s /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/core-site.xml /export/servers/hbase-1.2.0-cdh5.14.0/conf/core-site.xml
ln -s /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/hdfs-site.xml /export/servers/hbase-1.2.0-cdh5.14.0/conf/hdfs-site.xml
(六)三台机器添加HBASE_HOME的环境变量
vim /etc/profile
export HBASE_HOME=/export/servers/hbase-1.2.0-cdh5.14.0
export PATH=:$HBASE_HOME/bin:$PATH
(七)HBase集群启动
启动方式一:
第一台机器执行以下命令进行启动
cd /export/servers/hbase-1.2.0-cdh5.14.0
bin/start-hbase.sh
警告提示:HBase启动的时候会产生一个警告,这是因为jdk7与jdk8的问题导致的,如果linux服务器安装jdk8就会产生这样的一个警告
[外链图片转存失败(img-p2PUvfRx-1568719526700)(…/…/…/MarkDown_Photo/图片59.png)]
我们可以删掉所有机器的hbase-env.sh当中的HBASE_MASTER_OPTS
和HBASE_REGIONSERVER_OPTS
配置来解决这个问题。不过警告不影响我们正常运行,可以不用解决
启动方式二:
我们也可以执行以下命令单节点进行启动
#启动HMaster命令
bin/hbase-daemon.sh start master
#启动HRegionServer命令
bin/hbase-daemon.sh start regionserver
为了解决HMaster单点故障问题,我们可以在node02和node03机器上面都可以启动HMaster节点的进程,以实现HMaster的高可用
bin/hbase-daemon.sh start master
(八)页面访问
浏览器页面访问
http://node01:60010/master-status