Hbase 理论知识
要学习Hbase了，工欲善其事必先利其器，要真正在学习的时候看懂每一步操作，必须先把理论知识先过一遍，总结了一点Hbase的网络知识。
Hbase简介
Hbase 是构建在HDFS上的分布式列存储数据库，是一个高可靠性、高性能、面向列、客伸缩的分布式存储系统，利用Hbase技术可以再廉价PC sever上 搭建大规模结构化存储集群。
Hbase 是Google Bigtable 的开源实现，类似Google Bigtable 利用GFS 作为其我呢见存储系统，Google 运行Mapreduce 来说处理Bigtable 中的海量数据，Hbase 同样利用Hadoop Mapreduce 来处理 Hbase 中的海量数据；Google Bigdata利用 Chubby 作为协同服务，Hbase利用 Zookeeper作为协同服务。
Hbase生态圈
Hbase 利用HDFS 分布式文件系统存储数据，确保HDFS是ok的，先搭建HDFS再搭建HBase。海量存储与高并发操作就是要利用HBase。
HBase的特点
与传统数据库相比，Hbase具有如下特点：
- 大：单表可以数十亿行，数百万列（上TB级别的数据，底层采用分布式存储，从下往上解决存储，在想我的电脑才两个TB，每个虚拟机都才分配了20gb，看来到时候要租服务器玩了）
- 无模式：同一个表的不同行可以有截然不同的列（传统数据库有字段，空着也在占空间，Hbase空着的不占空间，每一行的列数都可以不一样）
- 面向列：存储、权限控制、检索均面向列（按列存储，同一类型的数据一个文件可以方便压缩，降低I/O，加快读取速度，Hbase的优势）
- 稀疏：空列不占用存储，表是稀疏的
- 多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳（每个单元格按不同时间插入可不同版本）
- 数据类型单一：数据都是字符串，没有类型（插入前转换成类型单一的字符串，读取的时候再转换回去）
HBase数据模型
第一列 Row Key 主键
第二列 version 版本
第三列 ColumnFamily 列簇1
第四列 ColumnFamily 列簇2
1.表
在Hbase 中数据是以表的形式存储的，通过表可以将某些列放在一起访问，同一个表中的数据通常是相关的，可以通过列簇进一步放在一起进行访问。用户可以通过命令行（shell）或者Java API 来创建，创建表时只需要指定表名和至少一个列簇。
Hbase的列式存储结构允许用户存储海量的数据到相同的表中，而在传统数据库中，海量数据需要被切分成多个表进行存储。
2.行键（Row Key）
RowKey既是Hbase表的行键，也是HBase表的主键。Hbase表中的记录是按照Rowkey的字典顺序进行存储。
在HBase中，为了高效地检索数据，需要设计良好地Rowkey来提高查询性能。首先，Rowkey被冗余存储，所以长度不宜过长，Rowkey过长见会占用大量地存储空间同时会降低检索效率：其次RowKey应该尽量均匀分布，避免产生热点问题（Hbase可划分成很多regions，最好分散均匀，保证负载均衡）；另外需要保证Rowkey的唯一性。
3.列簇（ColumnFamily）
HBase表中的每个列都归属于某个列簇，一个列簇中的所有列成员有着相同的前缀。比如，列url和host都 是列簇RI的成员。列簇是表的schema的一部分，必须在使用表之前定义列簇，但列却不是必须的，写数据的时候可以动态加入。一般将经常一起查询的列放在一个列簇中，合理划分列簇将减少查询时加载到缓存的数据，减少I/O，提高查询效率，但也不能有太多的列簇，因为跨列簇访问是非常低效的。
4.单元格
HBase中通过Row和Column确定的一个存储单元称为单元格(Cell)。每个单元格都保存着同一份数据的多个版本，不同时间版本的数据按照时间顺序倒序排序，最新时间的数据排在最前面。
为了避免数据存在过多版本造成的管理代包括存储和索引)负担，HBase提供了两种数据版本回收方式。一是保存数据的最后n个版本;二是保存最近一段时间内的数据版本，比如最近七天。用户可以针对每个列族进行设置。
Hbase物理模型
- 每个列簇存储在HDFS上的一个单独文件里
- RowKey和version在每一个列簇里均有一份
- 空值不保存，占位符都没有
- Table中的所有行都按照Row key 的字典序排列
- Table 在行的方向上分割为多个Region
（Hbase之所以可以分布式存储，是由下而上彻底解决分布式存储问题，如果不能拆分成很多Region 那就是一个整体，就没办法分别存储到各个节点。和hdfs 的数据块blocks差不多的意思，最终存储还是按照hdfs的blocks存储。）（负载均衡）
Table 默认最初只有一个Region，随着记录数不断增加而变大之后，会逐渐分裂成多个region，一个region由【startkey，endkey】表示，不同的region会被Master分配给相应的RegionSever进行管理。（每个regionserver都是不同节点，查询的时候不同需求不同节点，可以达到负载均衡）
Region 是Hbase 中分布式存储和负载均衡的最小单元，不同Region分布到不同的Regionserver。
（每个表的region分布在各个节点上，节点的region数量不同各节点之间会相互迁移region，平均分region达到负载均衡。）
region内部结构
- Region虽然是分布式存储的最小单元，但是并不是存储的最小单元。（最小存储单元是StoreFile）
- Region有一个或多个Store组成，每个Store保存一个columns family 。
- 每个Store 又由一个memStore 和0个或多个StoreFile组成
- memStore存储在内存中，StoreFile存储在HDFS
HBase系统架构
总架构
Hbase 采用Master /Slave 架构搭建集群，由HMaster节点，HRegionServer节点，Zookeeper集群组成，而在底层他将数据存储在HDFS中，因而涉及到HDFS的namenode，datanode等，每个Datanode上面最好启动一个HRegionServer，这样在一定程度上保持数据的本地性。（写的是最好，其实我感觉是一定，放在一个节点上，DN和HRS，提升请求反应的效率）
架构——Zookeeper
Zookeeper协调所有节点的共享信息，在HMaster和HRegionServer连接到Zookeeper后创建临时节点（Ephemeral节点），并使用Heartbeat机制维持这个节点的存活状态，如果某个Ephemeral节点失效，则HMaster会收到通知，并作相应的处理。
HMaster通过监听ZooKeeper中的Ephemeral节点(默认: /hbase/rs/*)来监 控HRegionServer的加入和宕机。在第一个HMaster连接到ZooKeeper时会创建Ephemeral节点(默认 : /hbase /master)来 表示Active的HMaster,其后加进来的HMaster则监听该Ephemeral节点，如果当前Active的HMaster宕机，则该节点消失，因而其他HMaster得到通知，而将自身转换成Active的HMaster,在变为Active的HMaster之前，它会创建在/hbase/back- masters/下创建自己的Ephemeral节点。
架构——Master
- 管理HRegionServer,实现其region负载均衡。
- 管理和分 配HRegion,在HRegion split时分配新的HRegion;在HRegionServer退 出时迁移其内的HRegion到其他HRegionServer上。
- 监控 集群中所有HRegionServer的状态。
- 实现DDL操作 (Data Definition Language, namespace和table的增删改，columnfamiliy的增删改等)。
- 管理namespace 和table的元数据(实际存储在HDFS上)。
架构-RegionServer
- Region server维护Master分配给它的region，处理对这些region的IO请求
- Region server负责切分在运行过程中变得过大的region。
- HRegionServer 一般和DN在同一台机器上运行，实现数据的本地性。
- HRegionServer包 含多个HRegion，由WAL(HLog)（预写日志）、BlockCache（读缓存）、MemStore（写缓存）、HFile（封装后变成StoreFile）组成。
