hbase的读写过程

hbase的读写过程:

hbase的架构:

Hbase真实数据
hbase真实数据存储在hdfs上，通过配置文件的hbase.rootdir属性可知，文件在/user/hbase/下
hdfs dfs -ls /user/hbase
Found 8 items
drwxr-xr-x - root supergroup 0 2019-05-30 10:05 /user/hbase/.tmp
drwxr-xr-x - root supergroup 0 2019-05-30 11:11 /user/hbase/MasterProcWALs
drwxr-xr-x - root supergroup 0 2019-05-30 10:05 /user/hbase/WALs
drwxr-xr-x - root supergroup 0 2019-05-27 18:49 /user/hbase/archive
drwxr-xr-x - root supergroup 0 2019-05-27 18:11 /user/hbase/data
-rw-r--r-- 3 root supergroup 42 2019-05-27 14:33 /user/hbase/hbase.id
-rw-r--r-- 3 root supergroup 7 2019-05-27 14:33 /user/hbase/hbase.version
drwxr-xr-x - root supergroup 0 2019-05-30 11:16 /user/hbase/oldWALs
 .tmp
当对表做创建或者删除操作的时候，会将表move 到该 tmp 目录下，然后再去做处理操作。
 MasterProcWALS
记录创建表等DDL操作时的一些事务信息，用于处理如 HMaster 中断导致的 DDL 无法执行、回滚等问题
 WALS
属于hbase的预写日志（write-ahead-logs），记录Hbase在数据写入时候的数据信息。数据写入过程中是先写入到WAL中，再写入到memstore。当发生 RegionServer 宕机重启后，RS 会读取 HDFS中的 WAL 进行 REPLAY 回放从而实现故障恢复。从数据安全的角度，建议开启 WAL
 archive
HBase 在做 Split或者 compact 操作完成之后，会将 HFile 先移到archive 目录中，然后将之前的hfile删除掉，该目录由 HMaster 上的一个定时任务定期去清理。
 data
真实数据文件HFile,HFile是通过memestore刷下来的.
 hbase.id
序列化文件，标识hbase集群的唯一id号，是一个 uuid。
 hbase.version
序列化文件，标识hbase集群的版本号。
 oldWALs
存放旧的被回收的WAL文件

命名空间目录
hdfs dfs -ls /user/hbase/data
Found 2 items
drwxr-xr-x - root supergroup 0 2019-05-30 11:43 /user/hbase/data/default
drwxr-xr-x - root supergroup 0 2019-05-27 14:33 /user/hbase/data/hbase
表级目录
hdfs dfs -ls -R /user/hbase/data/default/t1
drwxr-xr-x /user/hbase/data/default/t1/.tabledesc
drwxr-xr-x /user/hbase/data/default/t1/.tmp
drwxr-xr-x /user/hbase/data/default/t1/68e61220e866d62a27d0cdeb0c1eed83 #HFile

HFile、WAL和Memstore
HFile
HBase实际的存储文件功能是由HFile类实现的，它被专门创建以达到一个目的：有效的存储HBase数据。

HFile数据都在前面的data里:

WAL
regionserver会将数据保存到menstore（内存）中，直到积攒足够多的数据再将其刷写到磁盘上，这样可以避免创建很多小文件。但是存储在内存中的数据是不稳定的。例如，在服务器断电的情况下数据可能会丢失。
一个常见的解决方法是预写日志（WAL）：每次更新操作都会写入日志，只有写入成功才会通知客户端操作成功，然后服务器可以按需自由的批量处理或聚合内存中的数据

优化手段：
hbase数据是先写入到WAL然后写入到memstore，所以有的优化，建议大家关闭WAL
但是，关闭WAL之后，写入数据时如果发生宕机，那么数据肯定会丢失
而且，关闭WAL对于写入性能的提升，其实不是很明显.WAL其实就类似于hadoop中的edits文件

Hbase元数据:
# 列出hbase名字空间的表
hbase(main):023:0> list_namespace_tables 'hbase'
TABLE
meta
namespace
2 row(s) in 0.0140 seconds

Hbase数据定位过程:
Hbase在数据读取的时候，需要先查询hbase:meta表，通过这个表到指定的regionserver获取region信息并进行数据的读取。详细过程如下:
1.client通过zookeeper获取管理hbase:meta表的regionserver
2.zookeeper返回oldboy-node103
3.向oldboy-node103获取hbase:meta表的的数据信息
4.查找到t1的row1所对应的region是被oldboy-node102所管理
5.将信息返回给客户端
6.向oldboy-node102获取对应region的数据
一旦知道区域（region）的位置，Hbase会缓存这次查询信息。之后客户端可以通过缓存信息定位所需的数据位置，而不用再次查找hbase:meta。

读取过程:
区域（region）和列族（column family）是以文件夹形式存在于HDFS的，所以在读取的时候：
如果确定了区域位置，就直接从指定的region目录读取数据。
如果一个列族文件夹中的文件有多个StoreFile，客户端会通过布隆过滤器筛选出可能存在数据的块，对这些块进行数据的查找。
如果此行有多个列族的话，就会在所有的列族文件夹中同时进行以上操作

写入过程:
从上图可以看出，除了真实数据（StoreFile）外，Hbase还处理一种HLog文件，此文件称为预写日志（WAL）。用户发起put请求时，也会先定位数据位置，然后：
第一步，决定数据是否需要写到由HLog实现的预写日志（WAL）中，预写日志（WAL）存储了序列号和实际数据，所以在服务器崩溃时可以回滚到还未持久化的数据。
一旦数据被写入到WAL中，数据会被放到MemStore内存数据中。同时regionserver会检查MemStore是否已经写满，如果满了，就会被刷写（flush）到磁盘中。会把数据写成HDFS中的新StoreFile，同时也会保存最后写入的序列号，系统就知道那些数据被持久化了。
当Storefile 越来越多，会触发Compact 合并操作，把过多的 Storefile 合并成一个Storefile。
当Storefile 越来越大，Region 也会越来越大。达到阈值后，会触发Split 切割region操作。