HBase必备知识点
Hbase是基于HDFS的面向列的分布式数据库，用于海量结构化数据存储。内部的文件全部存储在HDFS上
HBase中表的特点：
1 大，一个表可以有几十亿行，上百万列
2 面向列，面向列族的存储和权限控制，列簇的独立检索
3 稀疏，对于为空的列，并不占据空间，因此表的设计可以非常稀疏
4 无模式，每行又有一个可排序的主键和任意多的列，列可以根据需要动态的添加，同一张表不同的行可以使用不同的列
Hbase的存储实例：
1 每个column family存储在HDFS上的一个单独的文件中
2 key和version number在每个column family中均有一份
3 空值不会被保存
4 hbase为每个值维护了多级索引，即row key、column family、column name、timestamp等
物理存储：
1 table中的所有行都按照row key的字典序排列
2 table在行的方向上分割为多个region
3 region按大小分割的，每个表开始只有一个region，随着数据的增大，region会不断的增大，当增大到一个阈值的时候，region就会等分为两个新的region，之后会有越来越多的region
4 region是hbase中分布式存储和负载均衡的最小单元。不同的region分布到不同的regionserver上。
5 region虽然是分布式存储的最小单元，但不是存储最小单元。Region由一个或者多个store组成。每个store保存一个column family，每个store又由一个memstore和0至多个storeFile组成，memStore存储在内存中，storeFile存储在HDFS上
Hbase架构图：
Zookeeper：
1 保证在任何时候，集群中只有一个master(负责Hmaster的选举)
2 存储所有region的寻址入口
3 实时监控regionServer的状态，将regionserver的上线和下线信息实时通知给master(服务器之间的状态同步)
4 存储Hbase的schema(元数据信息)，其中保存table和table中的colume family
Hmaster:主要负责table和region的管理工作
1 region分裂后，为regionServer分配新的region
2 负责regionServer的负载均衡，调整region的分配
3 发现失效的region Server并重新分配其上的region(region自动切分是Hbase能够拥有良好拓展性的重要因素之一)
4 管理用户对table的增删改查操作
5 监听zookeeper，基于zookeeper感应rs的上下线和保证HA(高可用)
6 处理schema更新请求(对表的增删改查)
7 不参与对表的访问读写
8 在一个regionServer宕机后，负责失效节点的region的迁移
HregionServer(负责响应用户对其上region的I/O请求，向HDFS读写数据):
1 HregionServer维护master分配给它的region
2 维护region的cache
3 处理region的flush、compact、split
4 内部管理一系列的Hregion对象
5 一个HRegionServer会有多个Hregion和一个HLog
Region/Hrgion:
1 每一个region由很多的store组成，每一个store存储的是一个列簇(columnFamily)下所有的数据。在每个store中又包含memstore，memstore驻留在内存中，数据到来时首先要更新到memstore中，当到达阈值后再flush(默认64M)到对应的storeFile/Hfile中。storeFile负责的是实际数据存储，为HBase中最小的存储单元
2 当region到达阈值时(默认为256M)，开始分裂。一个HRegionServer管理多个表，一个表下有多个region，一个Hregion有多少个列族就要多个列族就有多少个store，store下有多个storeFile文件，是Hbase中最小的存储单元。
3 每个column Family单独存储：storeFile。storeFile的数量达到阈值，合并。
4 当某个columnFamily累计的大小超过阈值时，自动分裂为两个region。
StoreFile：
Memstore内存中的数据写入到文件之后就是storeFile，storeFile底层是以Hfile格式保存
Hbase的容错性：
1 master容错：
Zookeeper重新选择一个新的master
没有master的过程中，数据读取依旧运行，但region的切分、负载均衡无法进行
2 regionServer容错
定时向zookeeper汇报心跳，如果一旦一段时间未出现心跳，master将该regionServer上的region重新分配到其他regionServer上。
失效服务器上日志(HLOG)由主服务器进行分割并派送给新的regionServer
3 zookeeper容错
Zookeeper后会介绍
什么时候适合使用HBase？
1 半结构化和非结构化数据：对于数据结构字段不确定或杂乱无章，很难以一个概念进行抽取的数据适合HBase，因为HBase支持动态添加列
2 记录很稀疏：传统的行列是固定的，null的存储浪费空间。而HBase的null不会被存储，这样既节省了空间又提高了读性能
3 多版本号数据：依据rowkey和column key 定位的value能够有随意数量的版本号，因此对于需要存储变动历史记录的数据，HBase很方便
4 仅要求最终一致性：对于数据存储事务的要求不像金融行业和财务系统那么高，只要保证最终一致性就可以。
5 高可用和海量数据以及很大的瞬间写入量
6 索引插入比查询更频繁的情况。例如，对历史记录表和日志文件
7 业务场景简单：不需要太多的关系型数据库特定
Rowkey 的设计：
Rowkey的概念和mysql中的主键概念是一致的，HBase使用rowkey来唯一的标识一行数据
HBase中仅支持三种查询方式：
1 基于rowkey的范围扫描
2 基于rowkey的单行查询
3 全表扫描
Rowkey的行键在实际应用中，长度一般为(10-100bytes)，最好16bytes。在HBase的内部，rowkey保存为字节数组。Hbase会对表中的数据按照rowkey排序(字典序)
设计原则：
1 唯一原则。必须保持其唯一性。如果同一张表插入相同的rowkey，则原先的数据会被覆盖掉
2 排序原则。根据实际情况。如对视频下方的评论，按时间作为rowkey排序最佳
3 散列原则：rowkey应该均匀的分布在HBase的各个节点上。如常见的时间戳，如果rowkey是按照系统时间戳的方式递增，rowkey的第一部分如果是时间戳信息的话，将会造成所有的新数据都在一个regionServer上堆积的热点现象。
解决热点问题：
Reverse反转：针对固定长度的rowkey反转后存储
Salt加盐：将每一个rowkey加一个前缀，前缀前使用一些随机字符，使数据分散在多个不同的region，达到region负载均衡的目标
Hash散列或者mod：将原始的rowkey进过hash处理
4 长度原则：Rowkey的行键在实际应用中，长度一般为(10-100bytes)，最好16bytes。
HBase 宕机如何处理
宕机分为 HMaster 宕机和 HRegisoner 宕机，如果是 HRegisoner 宕机， HMaster 会将其所管理的 region 重新分布到其他活动的 RegionServer 上，由于数据和日志都持久在 HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。如果是 HMaster 宕机， HMaster 没有单点问题， HBase 中可以启动多个 HMaster，通过Zookeeper 的 Master Election 机制保证总有一个 Master 运行。即 ZooKeeper 会保证总会有一个 HMaster 在对外提供服务。