HBase

HBase数据库介绍

HBase 是 BigTable 的开源 java 版本。 建立在 HDFS 之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的NoSQL 数据库系统。
NoSQL的两种解释，更精确的是后者
NoSQL = NO SQL
NoSQL = Not Only SQL
NoSQL：HBase, Redis, MongoDB
RDBMS：MySQL,Oracle,SQL Server,DB2
以下几点是HBase 这个 NoSQL 数据库的要点：
1、它仅能通过主键(row key)和主键的 range 来检索数据；
2、Hbase查询数据功能简单，不支持 join 等复杂操作；
3、不支持复杂的事务（行级的事务）；
4、Hbase中支持的数据类型：byte[] ；
5、主要用来存储结构化和半结构化的数据。
与 Hadoop 一样，HBase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存 储能力。
HBase 中的表一般有这样的特点：
1、大：一个表可以有上十亿行，上百万列；
2、面向列：面向列(族)的存储和权限控制，列(族)独立检索；
3、稀疏:对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。

RowKey

与 NoSQL 数据库们一样,Rowkey 是用来检索记录的主键。访问 HBase table 中的行，有如下的方式
： 1、通过单个Rowkey 访问
2、通过 Rowkey 的 range
3、全表扫描 Rowkey 行键 (Rowkey)可以是任意字符串(最大长度是
64KB，实际应用中长度一般为 10-100bytes)。在 HBase 内部rowkey 保存为字节数组。HBase 会对表中的数据按照 Rowkey 排序(字典顺序) 。 存储时，数据按照 Rowkey 的字典序(byte order)排序存储。设计 key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。

列簇（Column Family）

HBase表中的每个列，都归属与某个列簇。列簇是表的 schema 的一部分(而列不是)，必须在使用 表之前定义。
列名都以列簇作为前缀。例如 courses:history ， courses:math 都属于 courses 这个列簇。
列族越多，在取一行数据时所要参与 IO、搜寻的文件就越多，所以，如果没有必要，不要设置太 多的列族

时间戳

HBase 中通过 row 和 columns 确定的为一个存储单元称为 cell。
每个 cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64 位整型。 时间戳可以由 HBase(在数据写入时自动
)赋值，此时时间戳是精确到毫秒的当前系统时间。
时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的
时间戳。 每个 cell 中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

Cell
由{rowkey, column( = + ), version} 唯一确定的单元。
Cell 中的数据是没有类型的，全部是字节码形式存储。

系统架构

Client 职责

1、HBase 有两张特殊表： .meta.：记录了用户表的 Region 信息，.META.可以有多个 regoin
-root-：记录了.META.表的 Region 信息，-ROOT-只有一个 region 2、Client 访问用户数据前需要首先访问 zookeeper，找到-root-表的 region 所在的位置，然后 访问-
root-表，接着访问.meta.表，最后才能找到用户数据的位置去访问，中间需要多次网络操作，不过 client 端会做 cache 缓存。

ZooKeeper 职责

1、ZooKeeper 为 HBase 提供 Failover 机制，选举 master，避免单点 master 单点故障问题
2、存贮所有Region 的寻址入口：-root-表在哪台服务器上。-root-这张表的位置信息
3、实时监控 RegionServer 的状态，将 RegionServer 的上线和下线信息实时通知给 Master
4、存储 HBase 的 schema，包括有哪些 table，每个table 有哪些 column family

Master 职责

1、为 RegionServer 分配 region
2、负责 RegionServer 的负载均衡
3、发现失效的RegionServer 并重新分配其上的 region
4、HDFS 上的垃圾文件（hbase）回收
5、处理 schema更新请求（表的创建，删除，修改，列簇的增加等等）

RegionServer 职责

1、RegionServer 维护 Master 分配给它的 region，处理对这些 region 的 IO 请求
2、RegionServer 负责 Split 在运行过程中变得过大的 region，负责 Compact 操作 可以看到，client访问 hbase 上数据的过程并不需要 master 参与（寻址访问 zookeeper 和 RegioneServer，数据读写访问RegioneServer）， master 仅仅维护者 table 和 region 的元数据 信 息，负载很低。 .meta.存的是所有的 region 的位置信息，那么 RegioneServer 当中 region 在进行分裂之后 的新 产生的region，是由 master 来决定发到哪个 RegioneServer，这就意味着，只有 master 知道 new region 的位置信息，所以，由 master 来管理.meta.这个表当中的数据的 CRUD

整体物理结构

1、Table 中的所有行都按照 rowkey 的字典序排列。
2、Table 在行的方向上分割为多个 Hregion。
3、Hregion按大小分割的(默认 10G)，每个表一开始只有一个 HRegion，随着数据不断插入表， HRegion不断增大，当增大到一个阀值的时候，HRegion 就会等分会两个新的 HRegion。当表中的行 不断增多，就会有越来越多的 HRegion。
4、HRegion 是 HBase 中分布式存储和负载均衡的最小单元。最小单元就表示不同的 HRegion 可以分布在不同的 HRegion Server 上。但一个 HRegion 是不会拆分到多个 Server 上的。
5、HRegion虽然是负载均衡的最小单元，但并不是物理存储的最小单元。事实上，HRegion 由一个或 者多个 Store 组成，每个 Store 保存一个Column Family。每个 Store 又由一个 memStore 和 0 至多 个 StoreFile 组成。

StoreFile和HFile结构

StoreFile 以 HFile 格式保存在 HDFS 上，请看下图 Hfile 的数据组织格式：

首先 HFile 文件是不定长的，长度固定的只有其中的两块：Trailer 和 FileInfo。正如图中所示 的， Trailer中有指针指向其他数据块的起始点。 File Info 中记录了文件的一些 Meta 信息，例如：AVG_KEY_LEN,
AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY 等。

HFile 分为六个部分：

Data Block 段----保存表中的数据，这部分可以被压缩 Meta Block 段 (可选的)–保存用户自定义的 kv对，可以被压缩。
File Info 段—–HFile 的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。

Data Block Index 段–Data Block 的索引。每条索引的 key 是被索引的 block 的第一条记录的 key。

Meta Block Index 段 (可选的)–Meta Block 的索引。

Trailer 段–—这一段是定长的。保存了每一段的偏移量，读取一个 HFile 时，会首先 读取 Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index 会读取到内存中，这样，当检索某个 key 时，不需要扫描整个 HFile，而只需从内存中找 到 key 所在的 block，通过一次磁盘 io将整个 block 读取到内存中，再找到需要的 key。 DataBlock Index 采用 LRU 机制淘汰。

HFile 的 Data Block，Meta Block 通常采用压缩方式存储，压缩之后可以大大减少网络 IO 和磁盘IO，随之而来的开销当然是需要花费 cpu 进行压缩和解压缩。 目标 Hfile 的压缩支持两种方式：Gzip，LZO。

Data Index 和 Meta Index 块记录了每个 Data 块和 Meta 块的起始点。

Data Block 是 HBase I/O 的基本单元，为了提高效率HRegionServer 中有基于 LRU 的 BlockCache 机制。每个 Data 块的大小可以在创建一个 Table 的时候通过参数指定，大号的 Block 有利于顺 序 Scan，小号Block 利于随机查询。 每个 Data 块除了开头的 Magic 以外就是一个 个 KeyValue 对拼 接而成, Magic内容就是一些随机数字，目的是防止数据损坏。

HFile 里面的每个 KeyValue 对就是一个简单的 byte 数组。但是这个 byte 数组里面包含了很 多
项，并且有固定的结构。我们来看看里面的具体结构：

开始是两个固定长度的数值，分别表示 Key 的长度和 Value 的长度。紧接着是 Key，开始是固定长
度的数值，表示 RowKey 的长度，紧接着是 RowKey，然后是固定长度的数值，表示 Family 的长度，
然后是 Family，接着是 Qualifier，然后是两个固定长度的数值，表示 Time Stamp 和 Key Type（Put/Delete）。 Value 部分没有这么复杂的结构，就是纯粹的二进制数据了。

MemStore和StoreFile

一个 Hregion 由多个 Store 组成，每个 Store 包含一个列族的所有数据
Store 包括位于内存的一个 memstore和位于硬盘的多个 storefile 组成
写操作先写入 memstore,当 memstore中的数据量达到某个阈值，HRegionServer 启动 flushcache 进程写入 storefile，每次写入形成单独一个 Hfile
当总 storefile 大小超过一定阈值后，会把当前的 region 分割成两个，并由 HMaster 分配给相 应 的 region 服务器，实现负载均衡
客户端检索数据时，先在 memstore 找，找不到再找 storefile

HLog（WAL）

WAL 意为 Write ahead log，类似 mysql 中的 binlog,用来 做灾难恢复之用，Hlog 记录数据的所有变更,一旦数据修改，就可以从 log 中进 行恢复。
每个 Region Server 维护一个 Hlog,而不是每个 Region 一个。这样不同 region(来自不同 table) 的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减 少磁盘寻址次
数，因此可以提高对 table 的写性能。带来的麻烦是，如果一台 region server 下线，为了恢复其上的region，需要将 region server 上的 log 进行拆分，然后分发到其它 region server 上进行恢复。

HLog 文件就是一个普通的 Hadoop Sequence File：
1、HLog Sequence File 的 Key 是HLogKey 对象，HLogKey 中记录了写入数据的归属信息，除 了 table 和 region 名字外，同时还包括 sequence number 和 timestamp，timestamp 是”写入 时 间”，sequence number 的起始值为 0，或者是最近一次存入文件系统中 sequence number。
2、HLog Sequece File 的 Value 是 HBase的 KeyValue 对象，即对应 HFile 中的 KeyValue

寻址机制

现在假设我们要从 user_info 里面寻找一条 RowKey 是 rk0001 的数据。那么我们应该遵循以下步 骤：
1、从.META.表里面查询哪个 Region 包含这条数据。
2、获取管理这个 Region 的 RegionServer 地址。
3、连接这个 RegionServer, 查到这条数据。

系统如何找到某个 RowKey (或者某个 RowKey range)所在的 region bigtable 使用三层类似 B+树的结构来保存 region 位置。

第一层是 zookeeper 里面保存的数据，它持有 root region 的位置。 第二层 root region
是.META.表的第一个 region 其中保存了.META.表其它 region 的位置。通过 rootregion，我们就可以访问.META.表的数据。
第三层是.META.，它是一个特殊的表，保存了 hbase 中所有数据表的region 位置信息。

说明：
1、root region 永远不会被 split，保证了最多需要三次跳转，就能定位到任意 region 。
2、META.表每行保存一个 region 的位置信息，rowkey 采用表名+表的最后一行编码而成。
3、为了加快访问，.META.表的全部 region 都保存在内存中。
4、client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果 client 上的缓存 全部失 效，则需要进行最多 6次网络来回，才能定位到正确的 region(其中三次用来发现缓 存失效，另外三次 用来获取位置信息)

读写过程

读请求过程
1、客户端通过 zookeeper 以及-root-表和.meta.表找到目标数据所在的 regionserver(就是数据所在的 region 的主机地址)
2、联系 regionserver 查询目标数据
3、regionserver 定位到目标数据所在的 region，发出查询请求
4、region 先在 memstore 中查找，命中则返回
5、如 果 在 memstore 中 找 不 到， 则 在 storefile 中 扫 描 （ 可 能 会 扫 描 到 很 多 的 storefile---- BloomFilter）（BloomFilter，布隆过滤器：迅速判断一个元素是不是在一个庞大的集合内，但是他有一个 弱点：它 有一定的误判率）
（误判率：原本不存在与该集合的元素，布隆过滤器有可能会判断说它存在，但是，如果 布隆过滤器,判断说某一个元素不存在该集合，那么该元素就一定不在该集合内）

写请求过程

1、client 先根据 rowkey 找到对应的 region 所在的 regionserver
2、client 向regionserver 提交写请求
3、regionserver 找到目标 region
4、region 检查数据是否与 schema 一致
5、如果客户端没有指定版本，则获取当前系统时间作为数据版本
6、将更新写入 WAL log
7、将更新写入 Memstore
8、判断 Memstore 的是否需要 flush 为 Store 文件。

HBase 在做数据插入操作时，首先要找到 rowkey 所对应的的 region，怎么找到的？
其实这个 简 单，因为.META.表存储了每张表每个 region 的起始 rowkey 了。 建议：在做海量数据的插入操作，避免出现递增 rowkey
的 put 操作 如果 put 操作的所有 rowkey 都是递增的，那么试想，当插入一部分数据的时候刚好进行分 裂，那 么之后的所有数据都开始往分裂后的第二个 region 插入，就造成了数据热点现象。

细节描述：

HBase 使用 MemStore 和 StoreFile 存储对表的更新。 数据在更新时首先写入 HLog(WALlog)和内存(MemStore)中，MemStore 中的数据是排序的， 当 MemStore 累计到一定阈值时，就会创建一个新的 MemStore，并且将老的 MemStore 添 加到 flush 队列，由单独的线程 flush 到磁盘上，成为一个StoreFile。于此同时，系统会在 zookeeper 中记录一 个 redo point，表示这个时刻之前的变更已经持久化了。当系统出现意外 时，可能导致内存 (MemStore)中的数据丢失，此时使用 HLog(WAL log)来恢复 checkpoint 之 后的数据。

StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。 当 一个 Store 中的StoreFile 达到一定的阈值后，就会进行一次合并(minor_compact, major_compact)， 将对同一个 key 的修改合并到一起，形成一个大的 StoreFile，当 StoreFile 的大小达到一定阈值后，又 会对 StoreFile 进行split，等分为两个 StoreFile。由于对表的更 新是不断追加的，compact 时，需要 访问 Store 中全部的StoreFile 和 MemStore，将他们按 row key 进行合并，由于 StoreFile 和 MemStore都是经过排序的，并且 StoreFile 带有内存中 索引，合并的过程还是比较快。

major_compact 和 minor_compact 的区别 minor_compact 仅仅合并小文件（HFile）major_compact 合并一个 region 内的所有文件 Client 写入 -> 存入 MemStore，一直到 MemStore满 -> Flush 成一个 StoreFile，直至增长到 一 定阈值 -> 触发 Compact 合并操作 -> 多个
StoreFile 合并成一个 StoreFile，同时进行版本 合并和数据 删除 -> 当StoreFilesCompact后，逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值 后，触发 Split 操作，把当前
Region Split 成 2 个 Region，Region 会下线， 新 Split 出的 2 个孩子 Region 会被HMaster 分配到相应的 HRegionServer 上，使得原先 1 个 Region 的压力得以分流到 2 个 Region上
由此过程可知，HBase 只是增加数据，有所得更新 和删除操作，都是在 Compact 阶段做的，所以，用户写操作只需要进入到内存即可立即返 回，从而保证 I/O 高性能。

写入数据的过程补充：
工作机制：每 个 HRegionServer 中都会有一个 HLog 对象，HLog 是一个实现 Write Ahead Log 的类，每次用户操作写入 Memstore 的同时，也会写一份数据到 HLog 文件，HLog 文件定期 会滚动出新，并删除旧的文件(已持久化到 StoreFile 中的数据)。
当 HRegionServer 意外终止 后，HMaster 会通 过Zookeeper 感知，HMaster 首先处理遗留的 HLog 文件，将不同 region 的 log 数据拆分，分别放到 相应region 目录下，然后再将失效的 region（带有刚刚拆分的 log） 重新分配，领取到这些 region 的HRegionServer 在 Load Region 的过程中，会发现有历史 HLog 需要处理，因此会 Replay HLog 中的数据到 MemStore 中，然后 flush 到 StoreFiles，完成数据恢复。

** RegionServer工作机制**

region 分配
任何时刻，一个 region 只能分配给一个 region server。master 记录了当前有哪些可用的 regionserver。以及当前哪些 region 分配给了哪些 region server，哪些 region 还没有分配。当需要 分配的 新的region，并且有一个 region server 上有可用空间时，master 就给这个 region server 发送一个装载请求，把 region 分配给这个 region server。region server 得到请求后，就开始 对此 region 提供服务。
region server 上线
master 使用 zookeeper 来跟踪 region server 状态。当某个 region server 启动时，会首先在
zookeeper 上的 server 目录下建立代表自己的 znode。由于 master 订阅了 server 目录上的变 更消
息，当 server 目录下的文件出现新增或删除操作时，master 可以得到来自 zookeeper 的 实时通知。
因此一旦 region server 上线，master 能马上得到消息。
region server 下线
当 region server 下线时，它和 zookeeper 的会话断开，zookeeper 而自动释放代表这台 server
的文件上的独占锁。master 就可以确定：
（1）region server 和 zookeeper 之间的网络断开了。
（2）region server 挂了
无论哪种情况，region server 都无法继续为它的 region 提供服务了，此时 master 会删除 server
目录下代表这台 region server 的 znode 数据，并将这台 region server 的 region 分配给其它还存活着
的server
** Master工作机制**
master 上线
master 启动进行以下步骤: 1、 从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为master。 2、扫描 zookeeper 上的 server 父节点，获得当前可用的 region server 列表。
3、和每个 region server 通信，获得当前已分配的 region 和 region server 的对应关系。
4、扫描.META.region 的集合，计算得到当前还未分配的 region，将他们放入待分配 region 列
表。
master 下线
由于 master 只维护表和 region 的元数据，而不参与表数据 IO 的过程，master 下线仅导 致所有
元数据的修改被冻结(无法创建删除表，无法修改表的 schema，无法进行 region 的负 载均衡，无法处
理 region 上下线，无法进行 region 的合并，唯一例外的是 region 的 split 可 以正常进行，因为只有
region server 参与)，表的数据读写还可以正常进行。因此 master 下 线短时间内对整个 hbase 集群没
有影响。
从上线过程可以看到，master 保存的信息全是可以冗余信息（都可以从系统其它地方 收集到或者计算出来）
因此，一般 hbase 集群中总是有一个 master 在提供服务，还有一个以上的 master 在等 待时机抢
占它的位置。