安装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
完