Hbase基础
Hbase是一个实实在在的数据库
Hive可以认为是一个计算框架，在Hbase之上。
Hbase大部分数据都存在HDFS上，一部分在内存里。
所以可以支持随机写，HDFS不支持
Hbase定义
HBase是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的BigTable建模，实现的编程语言为 Java。
• 是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，因此可以容错地存储海量稀疏的数据。
稀疏数据：如下，不是全部key的列都是有数据的，对比像mysql，他是每一行都有值的
• 特性：
– 高可靠
– 高并发读写
– 面向列
– 可伸缩
– 易构建
行存储 vs 列存储
行存储：
- 优点：写入一次性完成，保持数据完整性
- 缺点：数据读取过程中产生冗余数据，若有少量数据可以忽略
如这种，查询的时候，是把对应的一行的数据都读出来了，只是没有展示出来。
列存储
- 优点：读取过程，不会产生冗余数据，特别适合对数据完整性要求不高的大数据领域
- 缺点：写入效率差，保证数据完整性方面差
Hbase 优势
• 海量数据存储
• 快速随机访问
• 大量写操作的应用
Hbase 应用场景
• 互联网搜索引擎数据存储
• 海量数据写入
• 消息中心
• 内容服务系统（schema-free）
• 大表复杂&多维度索引
• 大批量数据读取
H b a s e 数 据 模 型
RowKey（行键）：是Byte array，表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要。（是按照字节序排序的，方便快速查询，例如用二分查找去检索）
Column Family：列族，拥有一个名称(string)，包含一个或者多个相关列
大类的列是column Family，其中细分子列，为column qualifier
时间戳的概念就是保存的不同版本
Column：属于某一个column family，familyName:columnName，每条记录可动态添加
一个列不能属于两个列组，可以两个列族有同样的列名
Version Number：类型为Long，默认值是系统时间戳，可由用户自定义
Value(Cell)：Byte array
三维有序
{rowkey => {family => {qualifier => {version => value}}}}
a:cf1:bar:1368394583:7
存储的时候，把rowkey，column，时间戳进行排序
a:cf1:foo:1368394261:hello
还原为二维传统的形式
H b a s e 物 理 模 型（数据模型怎么实现的）
Hbase一张表由一个或多个H region（分区）组成
记录之间按照Row Key的字典序排列
region是按照顺序排序的，region里面rowkey也是按照顺序排序
region之间不均匀的情况，新插入67，77，因为按照顺序插入，有些热区插的比较多，就需要继续分
Region按大小分割的，每个表一开始只有一个region，随着
数据不断插入表，region不断增大，当增大到一个阀值的时
候，Hregion就会等分会两个新的Hregion。当table中的行
不断增多，就会有越来越多的Hregion
一个region只能属于一个region server
region server 挂掉的话？
有读也有写的时候，hbase会把整行加锁（粒度比较粗的锁）
H b a s e 物 理 模 型
region server 是一台机器，上面会运行一个进程HRegionService
HRegionService 内部管理了一系列的 HRegion 对象
region是一个逻辑的概念，HRegion是一个物理概念
- 表 -> HTable
- 按RowKey范围分的Region-> HRegion ->Region Servers
- HRegion按列族（Column Family） ->多个HStore
- HStore -> memstore + HFiles(均为有序的KV)
- HFiles -> HDFS
HStore ： 一个Column Family就是一个HStore，是一系列文件。一个Column Family可以认为是一类文件，便于列存储
HFiles：就是HDFS上的数据
memstore：系统默认128m，达到了之后，就往磁盘上进行spilt
HFiles -> HDFS 就是真正HDFS上存储的文件
HRegion是Hbase中分布式存储和负载均衡的最小单元。
• 最小单元就表示不同的Hregion可以分布在不同的HRegion server上。
• 但一个Hregion是不会拆分到多个server上的
HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。
storefile就是HFiles
组合起来的话，如下：
一个rs管理很多的region
H b a s e 系 统 架 构
• Client
访问Hbase的接口，并维护Cache加速Region Server的访问
• Master
– 负载均衡，分配Region到RegionServer
假如有一个region-server挂了，要分到哪个region-server上由master决定
• Region Server
– 维护Region，负责Region的IO请求
• Zookeeper
– 保证集群中只有一个Master
– 存储所有Region的入口（ROOT）地址（新版本已经没有了）
– 实时监控Region Server的上下线信息，并通知Master（通过心跳）
Hmaster（主）功能：
- 负载均衡：管理和分配Hregion
- DDL：增删改 ->针对 table，cf，namespace
- 类似namemode，管理一些元数据，table的
- ACL权限控制
HRegionServer（从）：
- 管理和存放本地的HRegion
- 读写HDFS，提供IO操作
- 本地化：数据尽量和数据所属的DataNode在一起，但是这个本地化不能够总是满足和实现
H b a s e 的 容 错
ZooKeeper协调集群所有节点的共享信息，在HMaster和HRegionServer连接到ZooKeeper后
创建Ephemeral节点，并使用Heartbeat机制维持这个节点的存活状态，如果某个Ephemeral节点实效，则HMaster会收到通知，并做相应的处理。
除了HDFS存储信息，HBase还在Zookeeper中存储信息，其中的znode信息：
– /hbase/root-region-server ，Root region的位置
– /hbase/table/-ROOT-，根元数据信息
– /hbase/table/.META.，元数据信息
– /hbase/master，当选的Mater
– /hbase/backup-masters，备选的Master
– /hbase/rs ，Region Server的信息
– /hbase/unassigned，未分配的Region
• Master容错：
– Zookeeper重新选择一个新的Master
• 无Master过程中，数据读取仍照常进行；
• 无master过程中，region切分、负载均衡等无法进行
• Region Server容错：
– 定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的
Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割
并派送给新的RegionServer
• Zookeeper容错：
– Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例
• WAL(Write-Ahead-Log)预写日志
• 是Hbase的RegionServer在处理数据插入和删除的过程中用
来记录操作内容的一种日志
• 在每次Put、 Delete等一条记录时，首先将其数据写入到
RegionServer对应的HLog文件的过程
类似于MySQL的主从复制，是把对应的日志同步过去，然后再执行一次
• 客户端往RegionServer端提交数据的时候，会写WAL日志，只有当WAL日志写成功以后，客户端才会被告诉提交数据成功，如果写WAL失败会告知客户端提交失败
• 数据落地的过程
• 在一个RegionServer上的所有的Region都共享一个HLog，一次数据的提交是先写WAL，写入成功后，再写memstore。当memstore值到达一定阈值，就会形成一个个StoreFile（理解为HFile格式的封装，本质上还是以HFile的形式存储的）
H b a s e 的 操 作
• 基本的单行操作：PUT，GET，DELETE
• 扫描一段范围的Rowkey: SCAN
– 由于Rowkey有序而让Scan变得有效
• GET和SCAN支持各种Filter，将逻辑推给Region Server
– 以此为基础可以实现复杂的查询
• 支持一些原子操作：INCREMENT、 APPEND、CheckAnd{Put,Delete}
• MapReduce
• 注：在单行上可以加锁，具备强一致性。这能满足很多应用的需求。
H b a s e 的 特 殊 的 表
• -ROOT- 表和.META.表是两个比较特殊的表
• .META.记录了用户表的Region信息，.META.可以有多个regoin。Meta表不做分裂，存储用户表的元数据
• -ROOT-记录了.META.表的Region信息，-ROOT-只有一
个region，Zookeeper中记录了-ROOT-表的location
• Hbase 0.96之后去掉了-ROOT- 表，因为：
– 三次请求才能直到用户Table真正所在的位置也是性能低下的
– 即使去掉-ROOT- Table，也还可以支持2^17(131072)个Hregion，对于集群来说，存储空间也足够
• 所以目前流程为：
– 从ZooKeeper(/hbase/meta-region-server)中获hbase:meta的位置（HRegionServer的位置），缓存该位置信息
– 从HRegionServer中查询用户Table对应请求的RowKey所在的HRegionServer，缓存该
位置信息
– 从查询到HRegionServer中读取Row。
H b a s e 的 写 入 流 程 — — 寻 址
从这个过程中，我们发现客户会缓存这些位置信息，然而第二步它只是缓存当前RowKey对应的HRegion的位置，因而如果下一个要查的RowKey不在同一个HRegion中，则需要继续
查询hbase:meta所在的HRegion，然而随着时间的推移，客户端缓存的位置信息越来越多，以至于不需要再次查找hbase:meta Table的信息，除非某个HRegion因为宕机或Split被移动，此时需要重新查询并且更新缓存。
hbase:meta表存储了所有用户HRegion的位置信息
H b a s e 的 写 入 流 程 — — 写 入
• 当客户端发起一个Put请求时，首先它从hbase:meta表中查出该Put数据最终需要去的HRegionServer。
然后客户端将Put请求发送给相应的HRegionServer，在HRegionServer中它首先会将该Put操作写入WAL日志(Flush到磁盘中)。
• Memstore是一个写缓存，每一个Column Family有一个自己的MemStore
• 写完WAL日志文件后，HRegionServer根据Put中的TableName和RowKey找到对应的
HRegion，并根据Column Family找到对应的HStore，并将Put写入到该HStore的MemStore
中。此时写成功，并返回通知客户端。
MemStore是一个In Memory Sorted Buffer，在每个HStore中都有一个MemStore，即它是
一个HRegion的一个Column Family对应一个实例。它的排列顺序以RowKey、 Column
Family、 Column的顺序以及Timestamp的倒序。
H b a s e 的 读 取 流 程：
HBase中扫瞄的顺序依次是：BlockCache、 MemStore、 StoreFile(HFile)
H b a s e 的 C o m p a c t i o n 和 S p l i t
• 问题：随着写入不断增多，flush次数不断增多，Hfile文件越来越多,所以Hbase需要对这些文件进行合并
• Compaction会从一个region的一个store中选择一些hfile文件进行合并。合并说来原理很简单，先从这些待合并的数据文件中读出KeyValues，再按照由小到大排列后写入一个新的文件中。之后，这个新生成的文件就会取代之前待合并的所有文件对外提供服务
• Minor Compaction：是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少并且更大的StoreFile
minor：为了保证服务不中断
major：母的是合并的更彻底，但是服务中断
• Major Compaction：是指将所有的StoreFile合并成一StoreFile，这个过程还会清理三类无意义数据：被删除的数据、 TTL过期数据、版本号超过设定版本号的数据
• Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发
合并：
1 region的合并：尽量吧小点region合并到一个大的，理想情况下，每个region的请求量是一样的（不能保证数量一样）
2 storefile 的合并：针对Hstorefile
如果hbase当做MapReduce的输入源的话，一个map对应一个region
• Compaction本质：使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟
• compact的速度远远跟不上HFile生成的速度，这样就会使HFile的数量会越来越多，导致读性能急剧下降。为了避免这种情况，在HFile的数量过多的时候会限制写请求的速度
• Split
– 当一个Region太大时，将其分裂成两个Region
• Split和Major Compaction可以手动或者自动做。