hbase如何创建二级索引

1.HBase初识

1.1 HBase特点

1.1.1 列式存储

HBase是面向列族的非关系型数据库，每行数据列都可以不同，并且列可以按照需求进行动态增加，因此在开始创建HBase表时，可以只创建列族，等需要时再创建相应的列。

HBase表RowKeyCF1CF2记录1列1 ... 列n列1， 列2， 列3记录2列1， 列2， 列3列1， 列2记录3列1， 列2， 列3， 列4， 列5列1

1.1.1.1 行/列式存储比较

列式存储最大的不同在于表的组织形式不同。

1.1.1.2 数据压缩

列式存储意味着数据往往类型相同，可以采用某种压缩算法进行统一的压缩存储。

如下图，使用字典表的方式压缩存储字符串：

查询Customers列为Miller且Material列为Regrigerator的流程如下：

1. 分别去两列的字典表找到对应的数字;
2. 将该数字回原表查询，得到行号组成的BitSet，即满足条件的行号位置的bit设为1，其余为0;
3. 将两个BitSet相与，得到最终结果BitSet;
4. 得到最终行号为6，去字典表拿出结果组装返回即可;

1.1.1.3 两种存储方式对比

行列优点1.便于按行查询数据，OLTP往往是此场景
2.便于行级插入、删除、修改
3.易保证行级一致性1.便于按列使用数据，如对列分组、排序、聚合等，OLAP很多是这样
2.列数据同类型，便于压缩
3.表设计灵活，易扩展列缺点1.当只需查询某几个列时，还是会读整行数据
2.扩展列代价往往较高1.不便于按行使用数据
2.很难保证行级一致性优化思想读取过程尽量减少冗余列提高读写效率优化措施1.设计表时尽量减少冗余列
2.内存中累积写入到阈值再批量写入1.多线程方式并行读取不同列文件；
2.行级一致性，可通过加入RDBMS中回滚机制、校验码等
3.内存中累积写入到阈值再批量写入应用场景OLTPOLAP

1.1.1.4 Row Key

row key是用来检索记录的主键。访问hbase table中的行，只有三种方式：

1 通过单个row key访问

2 通过row key的range

3 全表扫描

Row key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组。

存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)

注意：

字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用0作左填充。

行的一次读写是原子操作 (不论一次读写多少列)。这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。

1.1.1.5 列族

hbase表中的每个列，都归属与某个列族。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history ， courses:math 都属于 courses

访问控制、磁盘和内存的使用统计都是在列族层面进行。实际应用中，列族上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据（甚至可能因 为隐私的原因不能浏览所有数据）。

1.1.1.6 时间戳

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

为了避免数据存在过多版本造成的的管理 (包括存贮和索引)负担，hbase提供了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。

1.1.1.7 Cell

由{row key, column( =<family> + <label>), version}

1.1.2 极易扩展

可添加很多RS节点(region server节点)进行处理能力扩展，也可添加多个HDFS DataNode进行存储能力扩展。表自动分片，且支持自动Failover。

1.1.3 高并发

高效地、强一致性地读写海量数据

1.1.4 稀疏

空Cell不占空间

1.1.5 海量存储

HDFS支持的海量存储，链家PC存储PB级数据仍能有百毫秒内的响应速度。（扩展性十分好）

1.2 适用场景

HBase适用于：

• 持久化存储大量数据（TB、PB）
• 对扩展伸缩性有要求
• 需要良好的随机读写性能
• 简单的业务KV查询(不支持复杂的查询比如表关联等)
• 能够同时处理结构化和非结构化的数据
• 订单流水、交易记录、需要记录历史版本的数据等

不适用于（适用于RDBMS）：

• 几千、几百万数据
• 需要类型列（不过已经可以用Phoniex on HBase解决这个问题）
• 需要跨行事务，目前HBase只支持单行事务，需要跨行必须依赖第三方服务
• SQL查询（不过可以用Phoniex on HBase解决这个问题）
• 硬件太少，因为HBase依赖服务挺多，比如至少5个HDFS DataNode，1个HDFS NameNode(为了安全还需要个备节点)，一个Zookeeper集群，然后还需要HBase自身的各节点
• 需要表间Join。HBase只适合Scan和Get，虽然Phoenix支持了SQL化使用HBase，但Join性能依然很差。如果非要用HBase做Join，只能再客户端代码做

2.HBase架构

2.1 Client

Client访问Hbase的接口，会去meta表查询目标region所在位置（此信息会放入缓存），并连接对应RegionServer进行数据读写。

当master rebalance region时，Client会重新进行查找。

2.1.1 Region定位旧版本

在0.96.0版本之前，region的查询通过三层架构来定位：

Region：所需要查询的数据具体所在的Region .

.META. :元数据表，存储了所有region的简要信息。.META.表中的一行记录就是一个Region，该行记录了该Region的起始行，结束行，和该Region的连接信息，这样客户端就可以通过这个来判断需要的数据在哪个region上。

-ROOT- : 存储.META.表的表，存储了.META.表在什么region上的信息（.META.表也是一张普通的表，也在Region上），通过两层的扩展最多可以支持 2*34 个Region。（171 7986 9184 个）。

1.用户通过查找zookeeper的/hbase/root-region-server节点来得知-root-表在哪个RegionServer上

2.访问-ROOT-表，查看所需要的数据在哪个.META.表上，这个.META．在哪个RegionService上

３.访问.META.表来看你要查询的行键在什么Region范围里面。

４.连接具体的数据所在的Region，用Scan来遍历row

其弊端在于：

通过三层架构虽然极大地扩展了可以容纳的Region数量，一直扩展到了171亿个Region，可是我们真的可以用到这么多吗？实际上不太可能。 虽然设计上是允许多个.META.表存在的，但是实际上在HBase的发展历史中，.META.表一直只有一个，所以-ROOT-中的记录一直都只有一行，-ROOT-表形同虚设。三层架构增加了代码的复杂度，容易产生BUG。

代码复杂度可不是小事，复杂度每增加一点产生BUG的概率都在上升，修改BUG的难度也在上升。可以说，增加代码的复杂度的效果等同于维护难度在以2次方的速度成倍增加。其实导致这个架构被改变的导火线也是某次关于三层查询的BUG。

2.1.2 Region定位新版本

从0.96版本之后这个三层查询架构被改成了二层查询架构。-ROOT-表被去掉了，同时zk中的/hbase/root-region-server也被去掉了。这回直接把.META.表所在的RegionServer信息存储到了zk中的/hbase/meta-region-server去了。再后来引入了namespace，.META.表这样别扭的名字被修改成了hbase:meta。

上面两幅图都是一个流程

（1）客户端先通过ZooKeeper的/hbase/meta-region-server节点查询到哪台RegionServer上有hbase:meta表。

（2）客户端连接含有hbase:meta表的RegionServer。hbase:meta表存储了所有Region的行键范围信息，通过这个表就可以查询出你要存取的rowkey属于哪个Region的范围里面，以及这个Region又是属于哪个RegionServer。

（3）获取这些信息后，客户端就可以直连其中一台拥有你要存取的rowkey的RegionServer，并直接对其操作。 客户端会把meta信息缓存起来，下次操作就不需要进行以上加载hbase:meta的步骤了。

说明：

1）root region永远不会被split，保证了只需要三次跳转，就能定位到任意的region；

2）hbase.meta表每行保存一个region的位置信息；

3）为了加快访问，hbase.meta表的全部region都保存在内存中；假设hbase.meta表的一行在内存中占用1KB，每个region限制为128MB，那么可以保存的region数量为：（128MB/1KB）*（128MB/1KB）=2（34次方）个region

4）client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。

2.2 Zookeeper

1. HMaster和RegionSerer都注册到ZK上，使HMaster可感知RegionServer上下线。
2. 选举，保证任何时候集群中都只有一个HMaster。
3. 保存.META.表所在RegionServer位置
   1）存储所有Region的寻址入口；
   2）存储HBase的schema，包括哪些table，每个table有哪些column family

2.3 HMaster

1. 监控RegionServe状态，并为之分配Region，以维护整个集群的负载均衡
2. 通过HMasterInterface接口维护集群的元数据信息，管理用户对table的增删改查操作
3. Region Failover：发现失效的Region，就到正常的RegionServer上恢复该Region
4. RegionSever Failover：由HMaster对其上的region进行迁移

2.4 HRegionServer

HRegionServer负责：

1. 处理用户读写请求，并和底层HDFS的交互。我们说RegionServer拥有某个region意思是region读写、flush之类的操作都是由当前regionserver管理的。如果该RegionServer本地没有HDFS DataNode 底层数据就要从其他DataNode节点远程读写。
2. 负责Region变大以后的split
3. 负责Storefile的合并工作

• 一个RegionServer上存在多个Region和一个HLog读写实例。
• HLog的就是WAL(Write-Ahead-Log)，相当于RDBMS中的redoLog，写数据时会先写一份到HLog。可以配置MultiWAL，多Region时使用多个管道来并行写入多个WAL流。
  一个RS共用一个HLog的原因是减少磁盘IO开销，减少磁盘寻道时间。
• Region属于某个表水平拆分的结果(初始一个Region)，每个表的Region分部到多个RegionServer。
• Region上按列族划分为多个Store
• 每个Store有一个MemStore，当有读写请求时先请求MemStore
• 每个Store又有多个StoreFile
• HFiles是数据的实际存储格式，他是二进制文件。StoreFile对HFile进行了封装。HBase的数据在底层文件中时以KeyValue键值对的形式存储的，HBase没有数据类型，HFile中存储的是字节，这些字节按字典序排列。

client访问hbase上的数据的过程并不需要master参与（寻址访问zookeeper和region server,数据读写访问region server），master仅仅维护table和region的元数据信息，负载很低。HRegionServer存取一个子表时，会创建一个HRegion对象，然后对表的每个列族创建一个Store实例，每个Store都会有一个MemStore和0个或多个StoreFile与之对应，每个StoreFile都会对应一个HFile，HFile就是实际的存储文件。因此，一个HRegion（表）有多少个列族就有多少个Store。一个HRegionServer会有多个HRegion和一个HLog。

2.5 HDFS

为HBase提供最终的底层数据存储服务，多副本保证高可用性。

HBase表的HDFS目录结构为：

/hbase /data /<Namespace> (集群里的Namespaces) /<Table> (该集群的Tables) /<Region> (该table的Regions) /<ColumnFamily> (该Region的列族) /<StoreFile> (该列族的StoreFiles)

HLog的HDFS目录结构如下：

/hbase /WALs /<RegionServer> (RegionServers) /<WAL> (WAL files for the RegionServer)

2.6 Region

2.6.1 概述

一个region水平切分的实例：

• 一个RegionServer上存在多个Region和一个HLog读写实例。
• Region属于某个表水平拆分的结果(初始一个Region)，每个表的Region分部到多个RegionServer。
• Region上按列族划分为多个Store
• 每个Store有一个MemStore，当有读写请求时先请求MemStore。MemStore内部是根据rowKey.Column,Version进行排序
• 每个Store又有多个StoreFile

2.6.2 Region分配

HMaster使用AssignmentManager，通过.META.表检测Region分配的合法性，当发现不合法（如RegionServer挂掉）时，调用LoadBalancerFactory来重分配Region到其他RS。分配完成并被RS打开后，需要更新.META.表。

任何时刻，一个region只能分配给一个region server。master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server，哪些region还没有分配。当存在未分配的region，并且有一个region server上有可用空间时，master就给这个region server发送一个装载请求，把region分配给这个region server。region server得到请求后，就开始对此region提供服务。

2.6.3 Region Merge(合并)

HBase是一种Log-Structured Merge Tree架构模式，用户数据写入先写WAL，再写缓存，满足一定条件后缓存数据会执行flush操作真正落盘，形成一个数据文件HFile。随着数据写入不断增多，flush次数也会不断增多，进而HFile数据文件就会越来越多。然而，太多数据文件会导致数据查询IO次数增多，因此HBase尝试着不断对这些文件进行合并，这个合并过程称为Compaction。

Compaction会从一个region的一个store中选择一些hfile文件进行合并。合并说来原理很简单，先从这些待合并的数据文件中读出KeyValues，再按照由小到大排列后写入一个新的文件中。之后，这个新生成的文件就会取代之前待合并的所有文件对外提供服务。HBase根据合并规模将Compaction分为了两类：MinorCompaction和MajorCompaction

1. Minor Compaction是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少并且更大的StoreFile。
2. Major Compaction是指将所有的StoreFile合并成一个StoreFile，这个过程还会清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发：

• 有更新时，老的数据就无效了，最新的那个<key, value>就被保留
• 被删除的数据，将墓碑<key,del>和旧的<key,value>都删掉
• 通过maxVersion制定了最大版本的数据，超出的旧版本数据会在合并时被清理掉不再写入合并后的StoreFile
• 有Split的父Region的数据会迁移到拆分后的子Region

3.物理存储

1 已经提到过，Table中的所有行都按照row key的字典序排列。

2 Table 在行的方向上分割为多个region。

3 region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，region就会等分会两个新的region。当table中的行不断增多，就会有越来越多的region。

4 region是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的region可以分布在不同的HRegion server上。但一个region是不会拆分到多个server上的。

5 Region虽然是分布式存储的最小单元，但并不是存储的最小单元。

每一个HRegion由一个或多个Store组成，至少是一个Store，Hbase会把一起访问的数据放在一个Store里面，即为每个ColumnFamily建一个Store，如果有几个ColumnFamily，也就有几个Store。

一个Store由一个MemStore和0或者多个StoreFile组成。 Hbase以Store的大小来判断是否需要切分HRegion。

MemStore 是放在内存里的，保存修改的数据即keyValues。当MemStore的大小达到一个阀值（默认64MB）时，MemStore会被Flush到文件，即生成一个快照。目前Hbase会有一个线程来负责MemStore的Flush操作。

MemStore内存中的数据写到文件后就是StoreFile,StoreFile以HFile格式保存在HDFS上。

3.1 HFile

HFile是HBase中K-V数据的存储格式，是Hadoop的二进制格式文件。HFile的格式为：

Trailer部分的格式:

HFile分为六个部分，HFile文件不定长，长度固定的有两个，Trailer和FileInfo。

1）Data Block 段–保存表中的数据，这部分可以被压缩。Data Block是HBase I/O的基本单元，为了提高效率，Hregion Server中有基于LRU的Block Cache机制，每个Data Block大小可以在创建一个Table的时候通过参数指定，较大的Data Block有利于顺序scan，小的Data Block有利于随机查询；

2）Meta Block 段 (可选的)–保存用户自定义的kv对，可以被压缩。

3）File Info 段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息，记录了文件的META信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等

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

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

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

7）HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。

目标Hfile的压缩支持两种方式：Gzip，Lzo。

8）HFile里面的每个key-value对就是一个简单的byte数组，这个byte数组具有固定结构。

(1)KeyLength和ValueLength：两个固定的长度，分别代表Key和Value的长度

(2)Key部分：Row Length是固定长度的数值，表示RowKey的长度，Row 就是RowKey

(3)Column Family Length是固定长度的数值，表示Family的长度

(4)接着就是Column Family，再接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type（Put/Delete）

(5)Value部分没有这么复杂的结构，就是纯粹的二进制数据

3.2 HLog File

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

HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue。

WAL 意为Write ahead log，类似mysql中的binlog,用来做灾难恢复只用，Hlog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。WAL的详细讲解可看一下文章：Hbase史上最详细原理总结（）

每个Region Server维护一个Hlog,而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。

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

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

4.关键算法/流程

4.1 region server上线

master使用zookeeper来跟踪region server状态。当某个region server启动时，会首先在zookeeper上的server目录下建立代表自己的文件，并获得该文件的独占锁。由于master订阅了server 目录上的变更消息，当server目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。因此一旦region server上线，master能马上得到消息。

4.2 region server下线

当region server下线时，它和zookeeper的会话断开，zookeeper而自动释放代表这台server的文件上的独占锁。而master不断轮询 server目录下文件的锁状态。如果master发现某个region server丢失了它自己的独占锁，(或者master连续几次和region server通信都无法成功),master就是尝试去获取代表这个region server的读写锁，一旦获取成功，就可以确定：

1 region server和zookeeper之间的网络断开了。

2 region server挂了。

的其中一种情况发生了，无论哪种情况，region server都无法继续为它的region提供服务了，此时master会删除server目录下代表这台region server的文件，并将这台region server的region分配给其它还活着的同志。

如果网络短暂出现问题导致region server丢失了它的锁，那么region server重新连接到zookeeper之后，只要代表它的文件还在，它就会不断尝试获取这个文件上的锁，一旦获取到了，就可以继续提供服务。

4.3 master上线

master启动进行以下步骤:

1 从zookeeper上获取唯一一个代码master的锁，用来阻止其它master成为master。

2 扫描zookeeper上的server目录，获得当前可用的region server列表。

3 和2中的每个region server通信，获得当前已分配的region和region server的对应关系。

4 扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。

4.4 master下线

由于master只维护表和region的元数据，而不参与表数据IO的过 程，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。从上线过程可以看到，master保存的 信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来），因此，一般hbase集群中总是有一个master在提供服务，还有一个以上 的’master’在等待时机抢占它的位置。

5.常用命令

查看hbase状态：status

创建表：create '表名','列族名1','列族名2','列族名N'

查看所有表：list

描述表：describe '表名'

判断表存在：exists '表名'

判断是否禁用启用表；is_enabled '表名' is_disabled '表名'

添加记录：put '表名','rowkey','列族:列'，'值'

根据rowKey查询某个记录：get '表名','rowkey'get 'tableName','rowkey','family:column';

获取某个列族的某个列查看所有记录：scan '表名'

扫描前2条记录：scan 'tableName',{LIMIT => 2},LIMIT必须大写

范围查询：scan 'tableName',{STARTROW => 'rowKey1', ENDROW => 'rowKey2'}，STARTROW和ENDROW必须大写

查看表中的记录总数：count 'tableName',{INTERVAL => intervalNum，CACHE => cacheNum};INTERVAL设置多少行显示一次及对应的rowkey，默认1000；CACHE每次去取的缓存区大小，默认是10，调整该参数可提高查询速度。

删除记录：delete '表名','行名','列族：列'

删除整行：deleteall '表名','rowkey' 删除一张表先要屏蔽该表，才能对该表进行删除 第一步 disable '表名'，第二步 drop '表名'

清空表：truncate '表名'

查看某个表某个列中所有数据：scan '表名',{COLUMNS=>'列族名：列名'}

更新记录就是重新一遍，进行覆盖，hbase没有修改，都是追加

6.高可用

6.1 WAL 保障数据高可用

我们理解下HLog的作用。Hbase中的HLog机制是WAL的一种实现，而WAL（一般翻译为预写日志）是事务机制中常见的一致性的实现方式。每个RegionServer中都会有一个HLog的实例，RegionServer会将更新操作（如 Put，Delete）先记录到 WAL（也就是HLo）中，然后将其写入到Store的MemStore，最终MemStore会将数据写入到持久化的HFile中（MemStore 到达配置的内存阀值）。这样就保证了Hbase的写的可靠性。如果没有 WAL，当RegionServer宕掉的时候，MemStore 还没有写入到HFile，或者StoreFile还没有保存，数据就会丢失。或许有的读者会担心HFile本身会不会丢失，这是由 HDFS 来保证的。在HDFS中的数据默认会有3份。因此这里并不考虑 HFile 本身的可靠性。

HFile由很多个数据块（Block）组成，并且有一个固定的结尾块。其中的数据块是由一个Header和多个Key-Value的键值对组成。在结尾的数据块中包含了数据相关的索引信息，系统也是通过结尾的索引信息找到HFile中的数据。

6.2 组件高可用

Master容错：Zookeeper重新选择一个新的Master。如果无Master过程中，数据读取仍照常进行，但是，region切分、负载均衡等无法进行；
RegionServer容错：定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer；
Zookeeper容错：Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例。

6.3 HBase读写流程

上文提到，hbase使用MemStore和StoreFile存储对表的更新。

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

前面提到过StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更 新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(major compact),将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行split，等分为两个StoreFile。

由于对表的更新是不断追加的，处理读请求时，需要访问Store中全部的 StoreFile和MemStore，将他们的按照row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。

写请求处理过程

1) Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据；

2) 数据被写入Region的MemStore，直到MemStore达到预设阀值(即MemStore满)；

3) MemStore中的数据被Flush成一个StoreFile；

4) 随着StoreFile文件的不断增多，当其数量增长到一定阀值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除；

5) StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile；

6) 单个StoreFile大小超过一定阀值后，触发Split操作，把当前Region Split成2个新的Region。父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使得原先1个Region的压力得以分流到2个Region上。

可以看出HBase只有增添数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase I/O的高性能。

读流程为：

1) Client访问Zookeeper，查找hbase.meta表信息；

2) 从hbase.meta表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer；

3) 通过RegionServer获取需要查找的数据；

4) RegionServer的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

寻址过程：client—>Zookeeper—>ROOT表—>.META.

参考文献：

1.HBase查询机制--Region定位，https://msd.misuland.com/pd/3047868153708151196；

2.HBase Compaction的前生今世－身世之旅，http://hbasefly.com/2016/07/13/hbase-compaction-1/?iwzgxa=o5fh62

3.HBase简介（很好的梳理资料）https://www.iteye.com/blog/jiajun-899632

4.HBase基本概念与基本使用

5.Hbase史上最详细原理总结（）