1.HBase的基本介绍
a.Hbase是建立在hdfs之上的一个数据库，
b.不支持join等SQL复杂操作
c.支持的数据类型：byte[]，
d.依靠横向扩展，一个表可以有上十亿行，上百万列。
e.面向列(族)的存储和权限控制
f.对于为空(null)的列，并不占用存储空间，是一个稀疏表。
2.HBASE的适用场景
海量数据、精确查询、快速返回
海量数据：指的是数据量的背景
精确查询：业务场景
快速返回：是业务对时效性的要求
3.Hbase和Hadoop之间的关系
HDFS：
海量数据存储，适合一次性扫描大量数据。
适合一次写入多次读取
不适合频繁更新的数据
HBASE：
适用一次扫描少量数据。
适合多次写入多次读取
支持数据更新
支持删除数据
4.Hbase与RDBMS的关系
RDBMS ：
支持SQL查询
支持事务
支持Join
HBASE ：
不支持SQL查询
不支持事务
不支持Join
5. Hbase详细架构
Client：
访问数据的入口，包含访问hbase的API接口,维护着一些cache来加快对hbase的访问
Zookeeper：
1.zookeeper的选举机制保证任何时候，集群中只有一个master
2.实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master
3.存储Hbase的schema
4 存贮所有Region的寻址入口
Master：
1.为Region server分配region
2.负责region server的负载均衡
3.发现失效的region server并重新分配其上的region
4.处理schema（元数据）更新请求
说明：Hmaster短时间下线，hbase集群依然可用，长时间不行。
Region server：
1.Region server维护Master分配给它的region，处理对这些region的IO请求
2.Region server负责切分在运行过程中变得过大的region
6. Row Key
最大长度是 64KB，完全可以自行设计。Hbase会对表中的数据按照rowkey排序（字典序）
7.列族Column Family
列族是表的schema的一部分，而列不是。（schema包含表名和列族）
每个列都所属于某一个列族。一个列族可以包含多个列。一个列族与列的关系是一对多。
8.时间戳
标记一个数据的不同版本，时间戳可以由hbase(在数据写入时自动 )赋值，hbase支持工程师自己定义时间戳。
每个 cell中，不同版本的数据按照时间倒序排序
9.hbase本身提供数据回收机制
1．保存数据的最后n个版本
2．保存最近一段时间内的版本
10. Cell
存储数据的最小单位，由{row key, column( = + ), version} 唯一确定的单元确定一个精确的数据
11.VersionNum
数据的版本号，默认值为系统时间戳。
12. hbase物理存储
1.一个regionserver内部可以有多个region,这多个region可能来自多个表或一个表。
一个region只能属于一个 regionserver.
2.一个regionserver只有一个HLog
3.一个region里面可以有多个store
4.一个store里面只有一个memstore
13.rtegion的切分
region按大小分割的(默认10G)。每个表一开始只有一个region，随着数据的增加，
一个region逐渐变大，达到 10G，进行分裂，等分成两个region.
14. Memstore与storefile
一个region由多个store组成，每个store包含一个列族的所有数据 Store包括位于内存的memstore和位于硬盘的 storefile
客户端检索数据时，先在memstore找，找不到再找storefile
15.HLog(WAL log)
每个Region Server维护一个Hlog,而不是每个Region一个.
Hlog的切分机制
1.当数据写入hlog以后，hbase发生异常。关闭当前的hlog文件
2.当日志的大小达到HDFS数据块的0.95倍的时候，关闭当前日志，生成新的日志
3.每隔一小时生成一个新的日志文件
16.读请求过程
meta表是hbase系统自带的一个表。里面存储了hbase用户表的元信息。
元信息为meta表内记录一行数据是用户表一个region的start key 到endkey的范围。
meta表存储在regionserver里。 具体存储在哪个regionserver里？zookeeper知道。
过程:
1. 客户端到zookeeper询问meta表在哪
2.客户端到meta所在的节点（regionserver）读取meta表的数据
3.客户端找到region 获取region和regionserver的对应关系，直接到regionserver读取region数据
17.HBase的特征：
1、 海量存储
Hbase适合存储PB级别的海量数据，在几十到百毫秒内返回数据。
2、列式存储
这里的列式存储其实说的是列族存储列族理论上可以很多，但实际上建议不要超过6个
3、 极易扩展
处理能力（RegionServer）的扩展，个是基于存储的扩展（HDFS）
hbase在最初设计的时候就考虑了扩展性。
4、高并发
这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多
5、稀疏
在列数据为空的情况下，是不会占用存储空间的。
18.hbase用途
主要用来存储结构化和半结构化的松散数据。
hdfs:什么都能存储
MR：不能做快速返回
最初的大数据，只有hdfs+ MR ,此时众多的企业有的数据依然是结构化数据（存储数据库内）。
大数据内没有提供快速查询的技术。需求：就是在大数据内添加一个能够处理（快速查询）结构化数据的组件。
hbase在最初设计的时候就考虑了扩展性。hbase具有很好的扩展性。
19.hbase数据的写入
1 Client 先访问zookeeper，找到Meta表，并获取Meta表元数据。确定将要写入的数据所对应的HRegion和HRegionServer服务器。
2 Client向该HRegionServer服务器发起写入数据请求.
3 Client先把数据写入到HLog，以防止数据丢失。
4 然后将数据写入到Memstore。
5 若Memstore达到阈值，会把Memstore中的数据flush到Storefile中
6 Storefile数量达到阈值（默认3个）时，会触发Compact合并操作，把过多的Storefile合并成一个大的Storefile
说明:支持数据更新（伪更新），这里的更新实际上时数据的新添加。
20. region 的管理
前提：一个region只能分配给一个region server。
1、master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server，哪些region还没有分配。
2、当需要分配的新的region，并且有一个region server上有可用空间时，master就给这个region server发送一个装载请求，把region分配给这个region server。
3、region server得到请求后，就开始对此region提供服务。
21.regionserver的上线
前提：master使用zookeeper来跟踪region server状态
1、region server启动时，会首先在zookeeper上的/hbase/rs 目录下建立代表自己的znode。
2、master订阅了/hbase/rs 目录上的变更消息，当/hbase/rs 目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。
3、一旦region server上线，/hbase/rs 有新增node, zookeeper 通知master,master能马上得到消息.
22.regionserver的下线
1、当region server下线时，它和zookeeper的会话断开
2、zookeeper而自动释放代表这台server的文件上的node
3、 zookeeper 通知master, master得知那个节点下线。
4、master将这台region server的region分配给其它还活着的regionserver.
23. Hmaster的上线
1 从zookeeper上获取唯一 一个代表active master的锁，用来阻止其它master成为真正你的master。
2 扫描zookeeper上的/hbase/rs节点，获得当前可用的region server列表。
3 和每个region server通信，获得当前已分配的region和region server的对应关系。
4 描.META.表数据，计算得到当前还未分配的region，将他们放入待分配region列表。
问题1：多个hmaster如何确定哪个是真正的master
从zookeeper上获取唯一 一个代表active master的锁
问题2：如何获取集群当前可用的regionserver 列表
扫描zookeeper上的/hbase/rs节点，获得当前可用的region server列表。
问题3:master 如何获得region和regionserver之间的对应关系
master和每个region server通信，获得当前已分配的region和region server的对应关系。
问题4 ：master 如何获得还未分配的region
描.META.表数据，计算得到当前还未分配的region.
23. Hmaster下线
master只维护表和region的元数据，不参与表数据IO的过程，master下线短时间内对整个hbase集群没有影响。
长时间下线的影响：
无法创建删除表，无法修改表的schema，无法进行region的负载均衡，
无法处理region 上下线，无法进行region的合并，（region的split可以正常进行）
master下线，启用Zookeeper的选举机制，确定新的master, 新master执行上线流程。
24. Hbase三个重要的机制
1、flush机制
hbase.regionserver.global.memstore.size： 默认;堆大小的40%
regionServer的全局memstore的大小（多个region），超过该大小会触发flush到磁盘的操作，flush时会阻塞客户端读写。
hbase主要用于海量数据的快速读写。读写的总内存是堆内存的80%，读占用堆内存的40%,写占用堆内存的40%，想提高哪个业务场景的效率，就提高相应的百分比。
hbase.hregion.memstore.flush.size： 默认：128M（单个region里memstore的缓存大小）
hbase.regionserver.optionalcacheflushinterval ：默认：1h
集群调优：
hbase.regionserver.global.memstore.size.lower.limit： 默认0.95
hbase.hregion.preclose.flush.size：5M
hbase.hstore.compactionThreshold：默认： 3个
2、compact机制
当flush文件的数量达到3个，把小的storeFile文件合并成大的Storefile文件
3、split机制
当Region达到阈值（默认10G），会把过大的Region一分为二
25.HBase的预分区
\* 增加数据读写效率： 默认方式所有数据存在一个节点上，预分区将数据分散到多各节点上。
\* 负载均衡，防止数据倾斜： 数据的rowkey分成多个区间，每个区间就是一个region,数据写入时，写入自己所在的范围的region
\* 方便集群容灾调度region: 将数据分散存储到了多个region中，region的粒度更小
\* 优化Map数量
原始（未使用与分区）的分区（region）是如何实现的？？
数据表在创建时，只有一个region,随着数据量的增加，region之间变大，达到阈(10g)值分裂成两个region.
一个region只能在一个regionserver内，此时，数据的读写都依赖于一个节点（或少量的节点）
大量数据的读取都在一个节点。如何优化？？
方案：在建表时人为指定这个表含有多个region（不使用默认10G 一分割）。
create 'staff001','info','partition1',SPLITS => ['1000','2000','3000','4000','5000','6000','7000','8000']
