Hbase1.2.4概述

安装Hbase的时候，需要注意版本与Hadoop的版本兼容，具体查看：https://hbase.apache.org/book.html#basic.prerequisites

如下图：

我的Hadoop2.7.3

概述：

HBase是⼀个构建在HDFS上的分布式列存储系统

Hbase读写强一致性，高可靠，与MR良好的继承

HBase的高可靠是怎么做的？通过把数据写在HDFS上面，所以要搭建启动HBase，需要先启动HDFS

HBase的缺点，不支持sql，不支持索引，不支持多表查询，所以HBase替代不了传统关系型数据库，但是在某写场景，HBase的表现是相当优秀的

举一个HBase的应用场景例子，比如监控信息：

阿里有10w台机器，每天机器加入有50个指标，比如cpu，内存等，每个指标要画出自己的走势图，需要进行采点，每5s采点一次，那么每秒要采100w的数据，用传统的关系型数据库是存不下来的，这个时候，HBase就派上用场了

HBase数据模型：

在我个人的理解中，HBase的数据模型就像是一个药柜（表），药柜竖着看，一般几列（列）药性相同的，组成一个组（列族），横着看，如果药柜的每一层前面有一个唯一的标识（rowKey）那就更完美了，每一个抽屉（格子）拉出来，会有这个药材（数据）的多个版本（不同时间戳的数据），所以这个药柜（HBase数据模型）是一个三维（个人感觉）的结构

即：在HBase中，一行数据由行健（RowKey）作为键，包含多个列族（Column  Family），列族是由具有同时访问特性的多个列（Qualifer）组成的。数据是可以具有多版本的，由时间戳（TimeStamp）索引

数据在文件中存储的样子，(Table, RowKey, Family, Qualifer, TimeStamp)——>Value，企业中一般将他们的名字设计的很短，比如a 、 b 、1 、2这种一两个字节，这样能大大减少存储空间。

比如说，有的列名就是时间，12345这种，一小时有3600秒，那就是从1到3600，3600列

数据模型中：

行键是主键，它是数据行在表中的唯一标识

所有操作都是基于主键的

表可以是稀疏的，空值是不被存储的

表中的数据按照行键排序

无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列

特点是：

⼤：⼀个表可以有数⼗亿⾏，上百万列

⾯向列：⾯向列（列族）的存储，列（列族）独⽴检索

稀疏：对于空（null）的列，并不占⽤存储空间，表可以设计的⾮常稀疏

数据多版本：每个单元中的数据可以有多个版本，一个格子有很多版本，默认拿到的是最新的版本，每个单元的数据可以有多个版本，可以设置我保留多少个版本，比如一万个，第一万零一个会被删除

数据类型单⼀：HBase中的数据都是字节，没有类型，类型的信息HBase是不维护的，那你要问了，我怎么知道某个值是什么意思，这就需要你在用户层自己转换成自己想要的类型了

传统的数据库中，比如mysql，一张表20列，如果一列的数据大小有1G，我只搜索2列，mysql是先将整张表，20列都获取到，然后在输出2列，做了很多没有用的事情，那用列存储，来取数据，就好太多了

HBase则是直接取出这2列，从这一点就可以看出，在某方面，列存储的优点，而且还能将相同的列进行压缩，io也会变得很小

举个例子，用户画像：

一个用户或者一行数据的列可能是有百万级别的，而且是不断增加的，这个用户画像表的列会无限的增长的，这种用户画像系统，用HBase很合适

HBase物理模型

HBase的数据是很大的，存储的时候会切分成很多块，每一块（Region）的大小都可以配置，默认一般是1G，说到这里，引申一下

HDFS的存储单位是file，file会被切分成block

kafka的存储单位是topic，topic会被切分成partition

HBase的存储单位是table，table会被切分成Region

结论：所有大数据的一些结构都会有一个数据集，这些数据集都会被切分，切分后就可以来分布式的存储，以及并行的处理

hbase 是主从架构，他有自己的master，他的 slaver 叫 Regionserver

Table中的所有⾏都按照row key的字典序排列

Table 在⾏的⽅向上分割为多个Region，比如有100分Region，20台机器，那最开始，每台机器上平均有5个Region，Region按⼤⼩分割的，每个表开始只有⼀个Region，随着数据增多，Region不断增⼤，当增⼤到⼀个阈值的时候，Region就会等分会两个新的Region，之后会有越来越多的Region

每一台机器上都会有一个RegionServer来管理这些Regions

Region是HBase中分布式存储和负载均衡的最⼩单元，不同Region会按照算法分布到不同RegionServer上

Region虽然是分布式存储的最⼩单元，但并不是存储的最⼩单元，每个Region里面是比较复杂的。

数据刚插入的时候，他会先放在一个memStor（一个内存的存储结构），当这个memStor超过一定大小之后（可以设置，记得默认是1G），会将数据写到磁盘上，变成StoreFile（存放在HDFS上），memStor腾出来空间后，数据则继续往里面写

1、Region由⼀个或者多个Store组成，每个Store保存⼀个columns family

2、每个Strore又由⼀个MemStore和0⾄多个StoreFile组成

3、MemStore存储在内存中，StoreFile存储在HDFS上

看到上面的图片，你可能会向，在Region中，他是先缓存在内存中的，万一这台机器挂掉，数据岂不是丢失了？不是的，和其他分布式存储系统或者数据库一样，在写入

他在写任何数据之前，写在memstor之前，都会先写log，这些log会放在hdfs上，log写成功了，才会放在memstor中，log是追加式的写，随机写慢，追加写快，所以，放在memstor中的数据，电脑挂掉或者重启不会丢失

相同列族的数据是存放在一起的，比如列族a1的数据是存放在一个文件里面的，HBase是列族式存储，不是列式存储，相同列族里面的列是行式存储的，他这个列族呢，意思就是告诉大家，要经常访问的列，放在一起，我可以单独存取，这样我就可以不用读其他数据了

HBase架构

HBase是主从结构，主是HMaster，从是RegionServer，每一个节点上都会布一个RegionServer，来管理这个节点上的Region（又重复一遍）

一个表会划分成很多Region，放到不同的RegionServer上来管理

HMaster决定一个Region放在哪个节点上，当一个节点挂掉（数据可没有丢，在HDFS上），HMaster来决定该节点或者RegionServer 上的Region由哪台机器接管

RegionServer之间需要交互，知道彼此的存在，是通过zookeeper来做集群发现或者服务发现

一个Region里面会有很多文件

HRegion

HBase 会⾃动地将表划分为不同的区域，每个区域包含所有⾏的⼀个⼦集，对⽤户来说，每个表是⼀堆数据的集合，靠主键来区分，从物理上来说，⼀张表被拆分成了多块，每⼀块是⼀个HRegion，我们⽤表名+ 开始和结束主键，来区分每⼀个HRegion，⼀个HRegion 会保存⼀个表⾥⾯某段连续的数据，从开始主键到结束主键，⼀张完整的表格是保存在多个HRegion上⾯

HRegionServer

所有的数据库数据都保存在HDFS上⾯，⽤户通过访问HRegionServer获取这些数据，⼀台机器上⾯⼀般只运⾏⼀个HRegionServer，⼀个HRegionServer上⾯有多个HRegion，⼀个HRegion 也只会被⼀个HRegionServer维护，这个图片可以看懂吧？很好的再次的解释了之前说的理论

HRegionServer主要负责响应⽤户I/O请求，从HDFS读写数据，是HBase中最核⼼的模块，HRegionServer内部管理了⼀系列HRegion对象，这些HRegion对象可能是不同用户创建的不同表，每个HRegion对应了Table中的⼀个Region，HRegion中由多个HStore组成，每个HStore 对应了Table中的⼀个Column Family的存储，最好将具备共同IO特性的Column放在⼀个Column Family中

HMaster

每个HRegionServer都会与HMaster通信，HMaster的主要任务就是给HRegionServer分配HRegion，HMaster指定HRegionServer要维护哪些HRegion，当一台HRegionServer宕机时，HMaster会把它负责的HRegion标记为未分配，然后再把它们分配到其他HRegionServer 中

HMaster 没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有⼀个Master 运⾏，HMaster在功能上主要负责Table 和Region 的管理⼯作：管理⽤户对Table 的增、删、改、查操作，管理HRegion Server 的负载均衡，调整Region 分布，在Region Split 后，负责新Region 的分配，在HRegion Server 停机后，负责失效HRegion Server 上的Regions 迁移

其他组件

Client：HBase Client使⽤HBase的RPC机制与HMaster和HRegionServer进⾏通信对于管理类操作，Client与HMaster进⾏RPC对于数据读写类操作，Client与HRegionServer进⾏RPC

Zookeeper：Zookeeper中存储了META表的地址和HMaster的地址HRegionServer也会把⾃⼰以Ephemeral⽅式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的健康状态。此外，Zookeeper也避免了HMaster的单点问题

说一个HBase的应用：OpenTSDB

基于Hbase构建的分布式、可伸缩的时间序列数据库(TimeSeries Database )，秒级数据采集所有metrics，支持永久存储，可以做容量规划，可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的metrics并进行存储、索引以及服务

这个数据库，是专门来管理时间序列相关的数据库的，每一条数据都有一个时间，比如股票，监控数据，很多大公司都在用

OpenTSDB 基本概念

Metric：监控项，比如CPU利用率

Tags：用来描述metric的标签，由tagk和tagv组成，即tagk=tagv

Value：metric的实际值

Timestamp：时间戳，描述value对应的时间点

Data Point：即某个Metric在某个时间点的数值

举例：

metric：proc.loadavg.1m
timestamp：1234567890
value：0.42
tags：host=web42，pool=static

OpenTSDB 可能的实现方案

简单的实现方案：

rowKey=metric|timestamp|value|host=web42|pool=static

Column=v

Value=0.42

存在问题：

rowKey太长，占用大量存储资源，且为字符串类型，查找开销大，不易获得某个时间区间的所有值

OpenTSDB 实现方案

使用HBase存储，核心的存储，使用两张表，tsdb和tsdb-uid

tsdb-uid保存元数据信息，即编码信息，

　　metric-->3字节整数、tagk-->3字节整数、tagv-->3字节整数

　　proc.loadavg.1m-->052、host-->001、web42-->028、pool-->047、static-->001

tsdb保存实际数据

　　Rowkey：跟前一种方案类似，但是做了编码

　　Row：每行存储一个小时的数据，列名是秒偏移量，列值是metric值

OpenTSDB 实现方案：表tsdb-uid设计

OpenTSDB 实现方案：表tsdb设计

OpenTSDB 架构

Server: OpenTSDB的agent，通过Collector收集数据，推送数据

TSD：是对外通信的无状态的服务器，对数据进行汇总和存取

HBase：TSD收到数据后，通过异步客户端AsyncHbase将数据写入到HBase

完