Hbase
Hbase参考
参考http://www.nosqlnotes.com/technotes/hbase/hbase-overview-concepts/
简介
Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库;存储在内存,面向列每一行之间列可以不同;
HBase常被用来存放一些结构简单，但数据量非常大的数据(通常在TB/PB级别)，如历史订单记录，日志数据，监控Metris数据等等，HBase提供了简单的基于Key值的快速查询能力。
数据模型
ROW KEY:
决定一行数据,按照字典顺序排序的,Row key最大只能存储64k的字节数据
稀疏矩阵：
HBase中一个表的数据是按照稀疏矩阵的方式组织的，如下表所示：
看的出来：每一行中，列的组成都是灵活的，行与行之间并不需要遵循相同的列定义， 也就是HBase数据表”schema-less“的特点。
Region:
Hbase中采用了“Range分区”，将Key的完整分区切割成一个个的“key Range”，每一个“Key range”称之为一个Region;
也可以这么理解：将Hbase中拥有数亿行的一个大表，横向切割成一个个子表，这一个"子表"就是Region
Region是HBase中负载均衡的基本单元，当一个Region增长到一定大小以后，会自动分裂成两个。
CF :
如果将Region看成是一个表的横向切割，那么，一个Region中的数据列的纵向切割，称之为一个Column Family。每一个列，都必须归属于一个Column Family，这个归属关系是在写数据时指定的，而不是建表时预先定义。如 create ‘test’, ‘course’；列名以列族作为前缀，每个“列族”都可以有多个列成员(column)；
KeyValue:
每一行中的每一列数据，都被包装成独立的拥有特定结构的KeyValue，KeyValue中包含了丰富的自我描述信息:
看的出来，KeyValue是支撑”稀疏矩阵”设计的一个关键点：一些Key相同的任意数量的独立KeyValue就可以构成一行数据。但这种设计带来的一个显而易见的缺点：每一个KeyValue所携带的自我描述信息，会带来显著的数据膨胀
时间戳:
精确到毫秒的系统时间,在HBase每个cell存储单元对同一份数据有多个版本，根据唯一的时间戳来区分每个版本之间的差异，不同版本的数据按照时间倒序排序，最新的数据版本排在最前面;
Cell单元格:
由行和列的坐标交叉决定；单元格是有版本的；单元格的内容是未解析的字节数组；
由{row key， column( =<family> +<qualifier>)， version} 唯一确定的单元,cell中的数据是没有类型的，全部是字节数组形式存贮;
Hbase适用场景
HBase的数据模型比较简单，数据按照RowKey排序存放，适合HBase存储的数据，可以简单总结如下：
一：以实体为中心的数据
实体可以包括但不限于如下几种：
自然人/账户/手机号/车辆相关数据
用户画像数据（含标签类数据）
图数据（关系类数据）
描述这些实体的，可以有基础属性信息，实体关系（图数据），所发生的事件
二： 以事件为中心的数据
监控数据
时序数据
实时位置类数据
消息/日志类数据
上面所描述的这些数据，有的是结构化数据，有的是半结构化或非结构化数据。HBase的“稀疏矩阵”设计，使其应对非结构化数据存储时能够得心应手，但在我们的实际用户场景中，结构化数据存储依然占据了比较重的比例。由于HBase仅提供了基于RowKey的单维度索引能力，在应对一些具体的场景时，依然还需要基于HBase之上构建一些专业的能力，
架构
架构图
Client:读写请求的发起方,并维护meta : region 本地缓存 cache来加快对HBase Region 的访问;
Zookeeper:
(1):保证任何时候，集群中只有一个活跃Master;
(2):存贮所有Region的寻址入口;集群所有Region的元数据是由一台RegionServer管理的,这里的寻址入口指的就是管理元数据的RegionServer;
(3):实时监控Region server的状态。并实时通知Master;
(4):保存表的相关信息;
Master:
1):为Region server分配region:
2):负责Region server的负载均衡:平衡RegionServer节点上的region;
3):发现失效的Region server并重新分配其上的regions:Zookeeper通知Master,Master重新分配;
4):建表/修改表/删除表等DDL操作请求的服务端执行主体；
5):Master自身也可以作为一个RegionServer提供服务，该能力是可配置的。
RegionServer:
1):Region server维护region，处理对这些region的IO请求;
2):Region server负责切分在运行过程中变得过大的region,切分出来的region由master重新分配regionserver;
组件:
region:
1):HBase自动把表水平划分成多个区域(region)，每个region会保存一个表里面某段连续的数据
2):每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，region就会等分会两个新的region（裂变）;
3):当table中的行不断增多，就会有越来越多的region。这样一张完整的表被保存在多个Regionserver 上。
store,Memstore 与 storefile:
2):store包括位于内存中的memstore和位于磁盘的storefile写操作先写入memstore，当memstore中的数据达到某个阈值，hregionserver会启动flashcache进程写入storefile，每次写入形成单独的一个storefile;
3):当storefile文件的数量增长到一定阈值后，系统会进行合并（minor、major compaction），在合并过程中会进行版本合并和删除工作（majar），形成更大的storefile;当一个region所有storefile的大小和数量超过一定阈值后，会把当前的region分割为两个，并由hmaster分配到相应的regionserver服务器，实现负载均衡;
4):客户端检索数据，先在memstore找，再到blockcache找,找不到再找storefile;
HLog(WAL log)(预写日志):
HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是” 写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。HLog SequeceFile的Value是HBase的KeyValue对象，即对应HFile中的KeyValue;
Hbase完全分布式搭建:
进入到conf目录 hbase-site.xml如下配置:
regionservers :配置regionserver节点信息
hbase-env.sh
vim backup-masters :配置备Hmaster
拷贝hbase到其他节点,配置hbase环境变量;
启动hbase集群;
访问hbase webUI
查看zookeeper存放数据
hbase集群启动后会在zookeeper集群注册如下节点:
1):replication:表示hbase副本状态,下面有三个节点:peer 节点管理slave集群在zk上的配置；state节点记录replication运行的状态；rs 节点记录着本集群rs中对应的hlog同步的信息，包括check point信息;
2):meta-region-server节点存放了当前hbase集群元数据哪台regionserver管理;
3):rs:记录在线的regionserver
4):splitWAL:当某台RegionServer服务器挂掉时，由于总有一部分新写入的数据还没有持久化到HFile中，因此在迁移该RegionServer的服务时，一个重要的工作就是从WAL中恢复这部分还在内存中的数据，而这部分工作最关键的一步就是SplitWAL，即HMaster需要遍历该RegionServer服务器的WAL，并按Region切分成小块移动到新的地址下，并进行日志的回放（replay）。
5):backup-masters:记录backup master节点
6):table-lock:记录defaults下所有表
7):flush-table-proc:
8):region-in-transition:region状态变迁(RegionState中region有四种状态:unassign,assign,split,merge)
9):online_snapshot:
10):master:master节点信息
11):running:
12):recovering-regions:
13):draining:
14):namespace:
15):hbaseid:hbase集群id
16):table:
HBase的数据模型比较简单，数据按照RowKey排序存放，适合HBase存储的数据，可以简单总结如下：
